> > > The vfs documentation states: release() is "called when the last
> > > reference to an open file is closed".
> > >
> > > Let's say we have a program with threads T1 and T2.
> > >
> > > - T1 calls ioctl on a file descriptor FD.
> > > - (on another processor) T2 closes FD.
> > >
> > > Since the last reference to FD was closed by T2, release is called.
>
> That's subtly wrong. T2 releases its reference to the file descriptor.
>
> > > But while release is being called, the ioctl call from T1 may still
> > > be running, right ?
>
> Remember that ioctl needs an open FD as well - so the ioctl() grabs its own
> reference, and then *that* reference to the file descriptor stays in place at
> least until the ioctl() return. At *that* point, the reference count goes to
> zero and the file is actually closed.
Well, my assumption was that T1 and T2 would share the exact same file
descriptor. For example, a main thread T0 would call open() to get the
file descriptor, and then spawn T1 and T2 which would both use this
common FD.
Let's say:
- main thread T0 calls open() and gets FD 3
- T0 spawns T1 and T2
- T1 calls ioctl(3, ...) or read(3, ...)/write(3, ...)
- (on another processor) T2 calls close(3)
Do you mean that the ioctl/read/write call increments the reference
count in this case ? It would mean that these syscalls aren't really
using passed FD but instead create duplicates to make sure the open
file description won't be freed during their execution, right ?
Cheers,
hugo
--
Hugo Lefeuvre (hle) | www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
