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@xxxxxxxxxx> 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@xxxxxxxxxx > > +33 7 57 08 95 13 -- Kévin Ottens kevin.ottens@xxxxxxxxxx +33 7 57 08 95 13
