Messages in this thread |  | | | Subject | Re: DoS with POSIX file locks? | | From | Miklos Szeredi <> | | Date | Tue, 21 Mar 2006 18:58:03 +0100 |
| |
> > Apps using LinuxThreads seem to be candidates: > > > > According to POSIX 1003.1c, a successful `exec*' in one of the > > threads should automatically terminate all other threads in the > > program. This behavior is not yet implemented in LinuxThreads. > > Calling `pthread_kill_other_threads_np' before `exec*' achieves > > much of the same behavior, except that if `exec*' ultimately > > fails, then all other threads are already killed. > > > > steal_locks() was probably added as a workaround for this case, no? > > Possibly, but LinuxThreads were never really POSIX thread compliant > anyway. Anyhow, the problem isn't really LinuxThreads, it is rather that > the existence of the standalone CLONE_FILES flag allows you to do a lot > of weird inheritance crap with 'posix locks' that the POSIX standards > committees never even had to consider.
Yes. The execve-with-multiple-threads/posix-locks interaction is not documented for LinuxThreads but removing steal_locks() makes that implementation slighly differently incompatible to POSIX. Some application _might_ be relying on the current behavior.
It's just a question of how much confidence do we have, that no app will break if steal_locks() is removed. This function was added by Chris Wright on 2003-12-29 (Cset 1.1371.111.3):
Add steal_locks helper for use in conjunction with unshare_files to make sure POSIX file lock semantics aren't broken due to unshare_files.
Chris, do you remember if this was due to some concrete breakage or just a preemtive measure?
Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |