Linux kernel LOCK_MAND deprecation
Christof Schmitt
cs at samba.org
Mon Sep 13 18:11:45 UTC 2021
On Mon, Sep 13, 2021 at 10:40:50AM -0700, Jeremy Allison via samba-technical wrote:
> On Mon, Sep 13, 2021 at 10:02:01AM -0400, Jeff Layton via samba-technical wrote:
> > I recently proposed a patch to remove most of the support for
> > flock(..., LOCK_MAND...) from the Linux kernel. The code in question has
> > been broken for well over a decade, such that trying to use LOCK_MAND
> > flock locks is really just a no-op:
> >
> > https://lore.kernel.org/linux-fsdevel/20210910201915.95170-1-jlayton@kernel.org/
> >
> > Samba references that symbol in kernel_flock(). I started to take a look
> > at removing the code from samba, but the work kind of snowballed with
> > all of the wrappers and indirection.
> >
> > Would anyone who is actively working on samba want to take a stab at
> > removing kernel_flock()? It should be safe to just rip it out since it
> > hasn't worked in ages.
> >
> > If it's not removed, then you may see kernel warnings on Linux when
> > samba tries to set a LOCK_MAND lock, a'la:
> >
> > pr_warn_once("Attempt to set a LOCK_MAND lock via flock(2). This support has been removed and the request ignored.\n");
>
> So the only code that sets it is in source3/smbd/open.c:
>
> 4048 if (!fsp->fsp_flags.is_pathref &&
> 4049 fsp_get_io_fd(fsp) != -1 &&
> 4050 lp_kernel_share_modes(SNUM(conn)))
> 4051 {
> 4052 int ret_flock;
> 4053 /*
> 4054 * Beware: streams implementing VFS modules may
> 4055 * implement streams in a way that fsp will have the
> 4056 * basefile open in the fsp fd, so lacking a distinct
> 4057 * fd for the stream kernel_flock will apply on the
> 4058 * basefile which is wrong. The actual check is
> 4059 * deferred to the VFS module implementing the
> 4060 * kernel_flock call.
> 4061 */
> 4062 ret_flock = SMB_VFS_KERNEL_FLOCK(fsp, share_access, access_mask);
> 4063 if(ret_flock == -1 ){
> 4064 4065 del_share_mode(lck, fsp);
> 4066 TALLOC_FREE(lck);
> 4067 fd_close(fsp);
> 4068 4069 return NT_STATUS_SHARING_VIOLATION;
> 4070 }
> 4071 4072 fsp->fsp_flags.kernel_share_modes_taken = true;
> 4073 }
>
> and removes it in source3/smbd/close.c:
>
> 454 if (fsp->fsp_flags.kernel_share_modes_taken) {
> 455 int ret_flock;
> 456 457 /*
> 458 * A file system sharemode could block the unlink;
> 459 * remove filesystem sharemodes first.
> 460 */
> 461 ret_flock = SMB_VFS_KERNEL_FLOCK(fsp, 0, 0);
> 462 if (ret_flock == -1) {
> 463 DBG_INFO("removing kernel flock for %s failed: %s\n",
> 464 fsp_str_dbg(fsp), strerror(errno));
> 465 }
> 466 467 fsp->fsp_flags.kernel_share_modes_taken = false;
> 468 }
>
> (and a couple of other places that do the same thing on close).
>
> The rest is just boilerplace VFS glue that allows the VFS call:
>
> int (*kernel_flock_fn)(struct vfs_handle_struct *handle, struct files_struct *fsp,
> uint32_t share_access, uint32_t access_mask);
>
> to be caught by all VFS modules. It's not too hard to rip out
> for 4.16.x (too late for a VFS change in 4.15.0).
>
> The only question I have, is this being used in IBM gpfs at all ?
GPFS implements the Samba VFS call and implements sharemodes through a
private API call to the file system (see vfs_gpfs_kernel_flock). From
what i can see, the locking calls in kernel_flock are not needed, so
that function can be removed. I would still advocate for keeping the VFS
interface in Samba, so that we can still use the codepath in vfs_gpfs.
Christof
More information about the samba-technical
mailing list