> "Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> > Yup, you're quite right. POSIX states,
> >
> > "All locks associated with a file for a given process shall be
> > removed when a file descriptor for that file is closed by that
> > process or the process holding that file descriptor terminates.
> > Locks are not inherited by a child process created using the
> > fork() function."
> >
> By extension, this should hold for Linux' clone() too. Hence the patch.
>
> BTW, this points to a potential problem if we ever try to do async I/O with
> mandatory locks. Thread A locks something, then starts an async I/O
> request, which spawns Thread B, which fails to actually read/write the
> data because it doesn't own the lock. Ugh.
>
Erm, I can't see a problem. An async I/O thread would share (not have a
copy of as with fork) all file descriptors, and I'd apply that to locks
too.
Eg if a process opens a file, and forks a child, the child can close the
file descriptor without closing it for the parient, but a child cloned
with CLONE_FILES will close it for both the parient, and child.
So we have two cases, the child has a copy of the file descriptors, when
the POSIX fork semantics should apply to locks; and when the child has the
same file descriptors as the parient when POSIX fork semantics should not.
Ofcourse, any process that is allowed to access the locked space by vertue
of this should be able to revoke the lock.
[...]
>
> A possible solution would be to have a flag for clone() which gets stored
> in the child's task_struct and which would instruct the kernel to use
> current->pptr instead of current for lock checks. This would mean that
> async-I/O threads wouldn't be managed with the standard threading code,
> which (under LinuxThreads, anyway) collects all "work" threads under one
> common managing thread, no matter which subthread actually spawned off
> another thread, which may or may not be a problem.
>
We already have such a flag, CLONE_FILES, where the parient and child
share there filedescriptors.
> Better ideas, anybody?
>
Bryn
PS If I missunderstood how CLONE_FILES and/or locks work, please correct me.
--
PGP Pub key http://www.gytha.demon.co.uk/pubkey.asc ID: 1024/30AF2D69
On-line, adj.: FP: FC 4E 41 9E 64 C3 AB 28 A3 5A 57 F8 CC D9 A7 B8
The idea that a human being should always be accessible to a computer.