[PATCH] Convert Samba to OFD locking - version 2

[Steve French]

On Mon, May 23, 2016 at 9:26 AM, Jeff Layton <jlayton at samba.org> wrote:
> On Fri, 2016-05-20 at 17:07 -0700, Jeremy Allison wrote:
>> On Fri, May 20, 2016 at 07:01:18AM -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?
>>
>> Looks exactly right to me. With that and my patches
>> OFD-locks should work over the wire to Samba with
>> cifsfs and SMB1. You'll have to wait until my
>> autobuild lands in master first though (2 unrelated
>> and random different failures so far, grrr. I keep trying).
>>
>> SMB2 uses the persistent part of the handle as the
>> lock context so once we've gotten SMB2+ unix extensions
>> onboard this should just work out of the box over
>> SMB3.
>>
>
> AFAICT, this patch makes no material difference in testing.
>
> The client first compares the incoming lock request vs. the local lock
> database. If there is already a conflicting lock set on the file, it's
> rejected there before the lock request ever goes to the server. I guess
> this makes sense from a performance standpoint -- no need to go out
> over the network if we already know there's a conflicting lock.
>
> This patch does seem more correct to me than sending the pid, given how
> samba uses that field. But, I think we already have working OFD
> semantics anyway, as long as the client's kernel supports them properly
> for local filesystems.
>
> Steve, I figure this is your call. Should I send it to linux-cifs? If
> you do want it, there's certainly no urgency. It could soak in linux-
> next for a cycle or two...

I think it belongs in.  Not sure soaking an extra 10 weeks would help.
Why not send it on list - if no negative feedback, don't see strong
reason not to consider merging it

-- 
Thanks,

Steve