[PATCH] Convert Samba to OFD locking.

[Simo]

It will be extremely common actually, compile time and runtime are just 2 different beasts, at the very least we need a config option to turn off ofd and fallback to the classic locking, but that's really not admin friendly, it is easy enough to test if ofd is actually supported st runtime, you try and if you get enosys you log it and turn off the ofd path.

On May 19, 2016 11:45:09 AM EDT, Jeremy Allison <jra at samba.org> wrote:
>On Thu, May 19, 2016 at 07:25:45AM -0700, Richard Sharpe wrote:
>> On Thu, May 19, 2016 at 1:44 AM, Stefan Metzmacher <metze at samba.org>
>wrote:
>> > Am 19.05.2016 um 07:14 schrieb Uri Simchoni:
>> >> On 05/19/2016 12:42 AM, Jeremy Allison wrote:
>> >>> Hi Jeff, Steve and Simo,
>> >>>
>> >>> Here is the patchset we discussed to convert
>> >>> smbd to open file description locking on
>> >>> modern kernels. It also includes a regression
>> >>> test to ensure we stay working even on systems
>> >>> that don't have the required kernels :-).
>> >>>
>> >>> Now all we need is the fix you and I discussed
>> >>> to the calls to CIFSSMBPosixLock() to convert
>> >>> the lock context from current->tgid for process-associated
>> >>> record locks to a handle-specific lock context
>> >>> for open file description record locks.
>> >>>
>> >>> This will put us in really good shape for
>> >>> doing the OFD-POSIX locks we need in the
>> >>> SMB2+ UNIX extensions protocol changes.
>> >>>
>> >>> Please review and let me know !
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Jeremy.
>> >>>
>> >> Seems like the wscript test is a compile-time test. Should be a
>test
>> >> that runs code to verify the kernel actually supports it (or gets
>it
>> >> from the answer file and fails if there's no answer). The
>fcntl_lock
>> >> test just above it can be a good reference.
>> >>
>> >> Just my 2c, I have some learning curve to understand locking.
>> >
>> > I think we also need a runtime test similar to the robust mutex
>tests.
>> >
>> > It's not uncommon to run samba in an lxc container these days and
>there
>> > it could
>> > happen that the kernel is older or newer than the distribution
>within
>> > the container.
>> 
>> I am not sure that I believe the bit about the kernel being older
>than
>> the distro because glibc usually depends on (or uses) newer kernel
>> features, doesn't it?
>
>Yes. I don't think Metze's case is a realistic failure
>scenario.

-- 
Simo.

Sent from my mobile device. Please excuse my brevity.