Messages in this thread | | | Date | Fri, 25 Jul 1997 01:21:55 +0100 (BST) | From | Bryn Paul Arnold Jones <> | Subject | Re: File locking anomaly under 2.0.30 |
| |
On 24 Jul 1997, Matthias Urlichs wrote:
> "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.
| |