[PATCH] Convert Samba to OFD locking.

Simo s at ssimo.org
Thu May 19 17:57:15 UTC 2016


On Thu, 2016-05-19 at 10:44 -0700, Jeremy Allison wrote:
> On Thu, May 19, 2016 at 08:34:37PM +0300, Uri Simchoni wrote:
> > 
> > > 
> > > 
> > My angle is custom-built (and probably cross-compiled) linux, such
> > as we
> > see in NAS appliances. For that purpose a runtime test is not
> > needed
> > (and I was not asking for one) - a configure-time test that runs
> > would
> > suffice.
> OK, fair point. I'll update to a configure-time code run test.
> 
> > 
> > I tend to agree with Richard that the kernel is usually newer than
> > the
> > toolchain (and libc), but as a safety measure, we should at least
> > panic
> > if fcntl fails with EINVAL - can't hide this error.
> No, I don't think panic is the right thing here.
> 
> We already have messages that cope with 64-bit
> lock offsets failing on 32 bit NFS mounted file systems.
> 
> Remember, lock requests within smbd's are already
> correctly handled by the internal locking layer,
> this would be a failure of mapping the internal
> lock layer onto the underlying POSIX locks - which
> is something that is already optional in smbd
> and is only used for coordination with local
> locks on the system.
> 
> We should certainly log any EINVAL return at
> level zero, but it's not a panic-level error.

Given locks are kind of advisory anyway in POSIX I think I can agree on
just logging, but then what is the user to do ? recompile ? That is not
always possible. I am ok not doing a runtime check if we can have
smb.conf option to force to use classic locking.
People would have to manually set it (default to auto) if they want to
use classic but at least they have the option to have locking work and
silence the slew of level 0 logs about locking being broken.

Simo.

-- 
Simo Sorce




More information about the samba-technical mailing list