Re: Different behavior of POSIX file locks depending on cache mode

[Kevin Ottens <kevin.ottens@enioka.com>]

Hello,

On Thursday 23 May 2024 18:12:27 CEST Steve French wrote:
> What is the behavior with "nobrl" mount option?

With nobrl no failure shows whatever the cache policy (so my lock_test gives 
always the output of the example with cache=none below).

> and what is the behavior when running with the POSIX extensions enabled
> (e.g. to current Samba or ksmbd adding "posix" to the mount options)

By current you mean 4.20.1?

So far I tested with 4.19.6 but couldn't get it to work. I get the following 
in dmesg:
CIFS: VFS: Server does not support mounting with posix SMB3.11 extensions

Despite having the following in my smb.conf:
server max protocol = SMB3_11
smb3 unix extensions = yes

Am I using something too old? I honestly don't know when the extensions were 
added.

Regards.
 
> On Thu, May 23, 2024 at 11:08 AM Kevin Ottens <kevin.ottens@enioka.com> 
wrote:
> > Hello,
> > 
> > I've been hunting down a bug exhibited by Libreoffice regarding POSIX file
> > locks in conjunction with CIFS mounts. In short: just before saving, it
> > reopens a file on which it already holds a file lock (via another file
> > descriptor in the same process) in order to read from it to create a
> > backup
> > copy... but the read call fails.
> > 
> > I've been in discussion with Andrew Bartlett for a little while regarding
> > this issue and, after exploring several venues, he advised me to send an
> > email to this list in order to get more opinions about it.
> > 
> > The latest discovery we did was that the cache option on the mountpoint
> > seems to impact the behavior of the POSIX file locks. I made a minimal
> > test> 
> > application (attached to this email) which basically does the following:
> >  * open a file for read/write
> >  * set a POSIX write lock on the whole file
> >  * open the file a second time and try to read from it
> >  * open the file a third time and try to write to it
> > 
> > It assumes there is already some text in the file. Also, as it goes it
> > outputs information about the calls.
> > 
> > The output I get is the following with cache=strict on the mount:
> > ---
> > Testing with /mnt/foo
> > Got new file descriptor 3
> > Lock set: 1
> > Second file descriptor 4
> > Read from second fd: x count: -1
> > Third file descriptor 5
> > Wrote to third fd: -1
> > ---
> > 
> > If I'm using cache=none:
> > ---
> > Testing with /mnt/foo
> > Got new file descriptor 3
> > Lock set: 1
> > Second file descriptor 4
> > Read from second fd: b count: 1
> > Third file descriptor 5
> > Wrote to third fd: 1
> > ---
> > 
> > That's the surprising behavior which prompted the email on this list. Is
> > it
> > somehow intended that the cache option would impact the semantic of the
> > file locks? At least it caught me by surprise and I wouldn't expect such
> > a difference in behavior.
> > 
> > Now, since the POSIX locks are process wide, I would have expected to have
> > the output I'm getting for the "cache=none" case to be also the one I'm
> > getting for the "cache=strict" case.
> > 
> > I'm looking forward to feedback on this one. I really wonder if we missed
> > something obvious or if there is some kind of bug in the cifs driver.
> > 
> > Regards.
> > --
> > Kévin Ottens
> > kevin.ottens@enioka.com
> > +33 7 57 08 95 13


-- 
Kévin Ottens
kevin.ottens@enioka.com
+33 7 57 08 95 13