[PATCH] Convert Samba to OFD locking - version 2

[Jeff Layton]

On Fri, 2016-05-20 at 17:09 -0700, Jeremy Allison wrote:
> On Fri, May 20, 2016 at 08:04:52AM -0400, Jeff Layton wrote:
> > On Fri, 2016-05-20 at 07:01 -0400, Jeff Layton wrote:
> > > On Thu, 2016-05-19 at 14:12 -0700, Jeremy Allison wrote:
> > > > 
> > > > OK, here is version 2 with Uri and Simo's changes
> > > > incorporated. Compile-time checks now run the test
> > > > code rather than just compiling, and there's a
> > > > tuneable "smbd:force process locks" that will force
> > > > the old-style process specific locks. Advice to
> > > > use it gets printed in the log if fcntl returns
> > > > EINVAL.
> > > > 
> > > > Please review and push if happy !
> > > > 
> > > > Thanks,
> > > > 
> > > > Jeremy.
> > > Looks reasonable to me, though again, I don't know the userland
> > > samba
> > > code that well. So, fwiw...
> > > 
> > >     Acked-by: Jeff Layton <jlayton at samba.org>
> > > 
> > > ...also attached is an untested patch for cifsfs, which I was
> > > thinking
> > > would do the right thing wrt lockowners. I'll test it out as soon
> > > as I
> > > can put a test rig together for it. In the meantime, thoughts?
> > > 
> > 
> > The main catch with the cifs patch is the pid field after a F_GETLK
> > request will contain the hashed owner field, rather than an actual
> > pid.
> > 
> > Is this a problem? If the file is locked, there's no indication
> > ofwhatmachine that pid is running on, so it's utility on a network
> > filesystemhas always been a bit suspect anyway...
> 
> Not in the server code - it treats this only as a token
> anyway. I'll take a look in the cifsfs client code to
> see what gets passed back on GETLK.
> 

The main question is whether any applications that would be using
cifs.ko as their filesystem would care. I think I'll just assume the
answer to that is also "no". :)


-- 
Jeff Layton <jlayton at samba.org>