On Tue, 2006-03-21 at 10:44 +0100, Miklos Szeredi wrote:
> > The _only_ sane way to solve it is to decree that you lose your locks if
> > you clone(CLONE_FILES) and then call exec(). If there are any
> > applications out there that rely on the current behaviour,
>
> 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.
The fact remains, though, that steal_locks() is not a solution: it is
inherently broken for several of the most common filesystems that are
out there.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
