> > > > > 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.
> > >
> > > That doesn't solve the fundamental problem.
> > >
> > > You would still have to be able to tell a remote server that some locks
> > > which previously belonged to one owner are being reallocated to several
> > > owners.
> >
> > No changing of lock owner is involved, that's the whole point.
>
> You still don't get it.
No! You don't get it! ;)
> For NFS/CIFS/... the locks on the server _also_ have a lock
> owner. The local lockowner is completely and utterly irrelevant.
You mean the "local lockowner being stable" is irrelevant.
Yes that is true, but the patch not only makes the local lockowner
stable, it makes the "owner" stable. And that is the important part
for NFS, etc.
The remote lockowner has to be derived from the owner, which used to
be current->files, but is changed to current->file->owner.
The fact that current->file->owner will remain stable across the exec
will mean that locking will behave consistently for local _and_ remote
filesystems.
Now I'm not saying I want to keep this weird semantics of always
inheriting locks on exec. All I'm saying that it's _possible_.
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]
