> Concrete breakage. Something like:
>
> clone(CLONE_FILES)
> /* in child */
> lock
> execve
> lock
>
> w/out the kludge[1], the lock fails. I should have a test program about
> that I wrote to test this, although it was originally triggered via some
> LTP or LSB type of test (don't recall which).
>
> thanks,
> -chris
>
> [1] happy to see it go.
We all agree on this then.
I'm just little paranoid about a real-world app (LTP/LSB don't matter)
relying on the current semantics.
But maybe there's no other way to find out, than to remove
steal_locks() and see if anybody complains.
> i concur with Trond, there's no sane way to get rid of it w/out
> formalizing CLONE_FILES and locks on exec
Probably there is. It would involve allocating a separate
lock-owner-ID stored in files_struct but separate from it. But it's
more complicated than simply not propagating locks on exec in the
CLONE_FILES case.
Miklos
-
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]
