[PATCH] Convert Samba to OFD locking.

Jeremy Allison jra at samba.org
Thu May 19 18:03:24 UTC 2016


On Thu, May 19, 2016 at 01:53:18PM -0400, Simo wrote:
> On Thu, 2016-05-19 at 10:29 -0700, Jeremy Allison wrote:
> > On Thu, May 19, 2016 at 05:14:51PM +0000, Simo wrote:
> > > 
> > > It will be extremely common actually, compile time and runtime are
> > > just 2 different beasts,
> > That implies a Samba compiled with a recent glibc on a
> > modern kernel being moved to a system with an older glibc
> > and kernel.
> 
> No just older kernel, it happens all the time to run chrooted or
> containerized environments, where the userspace (including glibc) is
> Fedora 23 and the kernel is RHEL7 or even RHEL6.
> I am not saying this is an ideal combination, but people do these
> things all the time.
> 
> Glibc does have checks to see if the kernel support syscalls and return
> ENOSYS as necessary if not.

Unfortunately this isn't something that glibc can detect.
They syscall is fcntl, which doesn't change. The specific
op request would be unknown - which means fcntl returns
EINVAL. We already spam the log with :

        if (!ret && ((errno == EFBIG) || (errno == ENOLCK) || (errno ==  EINVAL))) {

                DEBUG(0, ("posix_fcntl_lock: WARNING: lock request at offset "
                          "%ju, length %ju returned\n",
                          (uintmax_t)offset, (uintmax_t)count));
                DEBUGADD(0, ("an %s error. This can happen when using 64 bit "
                             "lock offsets\n", strerror(errno)));
                DEBUGADD(0, ("on 32 bit NFS mounted file systems.\n"));

in this case to catch people exporting NFS systems with
broken locking.

We're in no worse shape with OFD locks here.

> I know it is not pretty, but for kernel features I think it is
> appropriate, seem my reply to your other epoll email as well.

As I said, I really don't want to do this to cope with
people doing broken things. All that is going to happen
if they do this is they're going to get a lot of debug
level 0 messages in their log.

*GOOD*. It might make them realize that they're running
in an unsupported and broken configureation and get
them to fix it.



More information about the samba-technical mailing list