Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Andrew Bartlett <abartlet@samba.org>
To: Steve French <smfrench@gmail.com>,
	Kevin Ottens <kevin.ottens@enioka.com>
Cc: linux-cifs@vger.kernel.org
Subject: Re: Different behavior of POSIX file locks depending on cache mode
Date: Mon, 10 Jun 2024 16:41:40 +1200	[thread overview]
Message-ID: <5fad6c05eab959e06fe3518d9104376b79dcbcb9.camel@samba.org> (raw)
In-Reply-To: <CAH2r5mtzzgG9-peAakYhBNdpahQ=R8wkhJxUQJ+oZtzEvuNjSg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5925 bytes --]

(resend due spam rules on list)

Kia Ora Steve,

I'm working with Kevin on this, and I set up a clean environment with
the latest software to make sure this is all still an issue on current
software:

I was hoping to include the old SMB1 unix extensions in this test also,
but these seem unsupported in current kernels.  When did they go away?

Anyway, here is the data.  It certainly looks like an issue with the
SMB3 client, as only the client changes with the cache=none

Server is Samba 4.20.1 from Debian Sid.  Kernel is 
Linux debian-sid-cifs-client 6.7.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.7.9-2 (2024-03-13) x86_64 GNU/Linux

With SMB1 but not unix extensions (seems unsupported):

root@debian-sid-cifs-client:~# mount.cifs //192.168.122.234/testuser
mnt -o user=testuser,pass=pass,vers=1.0
root@debian-sid-cifs-client:~# cd mnt/
root@debian-sid-cifs-client:~/mnt# ../lock_test foo 
Testing with foo
Got new file descriptor 3
Lock set: 1
Second file descriptor 4
Read from second fd: x count: 0
Third file descriptor 5
Wrote to third fd: 1

root@debian-sid-cifs-client:~# mount.cifs //192.168.122.234/testuser
mnt -o user=testuser,pass=penguin12#,vers=3.1.1,posix
root@debian-sid-cifs-client:~# cd mnt/
root@debian-sid-cifs-client:~/mnt# ../lock_test foo 
Testing with 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
root@debian-sid-cifs-client:~# mount.cifs //192.168.122.234/testuser
mnt -o user=testuser,pass=penguin12#,vers=3.1.1,unix

root@debian-sid-cifs-client:~# mount.cifs //192.168.122.234/testuser
mnt -o user=testuser,pass=penguin12#,vers=3.1.1,unix,nobrl
root@debian-sid-cifs-client:~# cd mnt/
root@debian-sid-cifs-client:~/mnt# ../lock_test foo 
Testing with foo
Got new file descriptor 3
Lock set: 1
Second file descriptor 4
Read from second fd: o count: 1
Third file descriptor 5
Wrote to third fd: 1

And with cache=none

root@debian-sid-cifs-client:~# mount.cifs //192.168.122.234/testuser
mnt -o user=testuser,pass=penguin12#,vers=3.1.1,posix,cache=none
root@debian-sid-cifs-client:~# cd mnt/
root@debian-sid-cifs-client:~/mnt# ../lock_test foo 
Testing with foo
Got new file descriptor 3
Lock set: 1
Second file descriptor 4
Read from second fd: o count: 1
Third file descriptor 5
Wrote to third fd: 1

On Thu, 2024-05-23 at 11:12 -0500, Steve French wrote:
> What is the behavior with "nobrl" mount option? 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)
> 
> 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
> 
> 

-- 

Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead                https://catalyst.net.nz/services/samba
Catalyst.Net Ltd

Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company

Samba Development and Support: https://catalyst.net.nz/services/samba

Catalyst IT - Expert Open Source Solutions

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead                https://catalyst.net.nz/services/samba
Catalyst.Net Ltd

Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company

Samba Development and Support: https://catalyst.net.nz/services/samba

Catalyst IT - Expert Open Source Solutions

[-- Attachment #2: lock_test.cpp --]
[-- Type: text/x-c++src, Size: 1037 bytes --]

#include <iostream>

#include <unistd.h>
#include <fcntl.h>

using namespace std;

int main(int argc, char **argv) {
    if (argc <= 1) {
        cout << "Please provide path to a file" << endl;
        return 1;
    }   

    const auto filepath = argv[1];
    cout << "Testing with " << filepath << endl;

    int fd = open(filepath, O_RDWR);
    cout << "Got new file descriptor " << fd << endl;


    struct flock lock;
    lock.l_type = F_WRLCK;
    lock.l_whence = SEEK_SET;
    lock.l_start = 0;
    lock.l_len = 0;
    int code = fcntl(fd, F_SETLK, &lock);
    cout << "Lock set: " << (code == 0) << endl;

    int fd2 = open(filepath, O_RDONLY);
    cout << "Second file descriptor " << fd2 << endl;

    char c = 'x';
    int count = read(fd2, &c, 1);
    cout << "Read from second fd: " << c << " count: " << count << endl;

    int fd3 = open(filepath, O_WRONLY|O_APPEND);
    cout << "Third file descriptor " << fd3 << endl;

    c = 'o';
    count = write(fd3, &c, 1);
    cout << "Wrote to third fd: " << count << endl;
}

  parent reply	other threads:[~2024-06-10  4:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 16:08 Different behavior of POSIX file locks depending on cache mode Kevin Ottens
2024-05-23 16:12 ` Steve French
2024-05-27 16:38   ` Kevin Ottens
2024-06-10  4:41   ` Andrew Bartlett [this message]
2024-06-10 20:05     ` Steve French
2024-06-10 20:50       ` Andrew Bartlett
     [not found]       ` <c6da3de7c205d40a41907874a0e6d26b6c8132fe.camel@samba.org>
2024-06-10 20:53         ` Steve French
2024-06-10 20:57           ` Andrew Bartlett
2024-06-10 21:19           ` Ralph Boehme
2024-06-10 22:49             ` Steve French
2024-06-10 22:53               ` Steve French
2024-06-24  4:54     ` Steve French
2024-06-25  6:00       ` Andrew Bartlett
2024-06-25  7:41         ` Kevin Ottens
2024-06-27 15:04           ` Kevin Ottens
2024-07-10  9:28             ` Andrew Bartlett
2024-07-11  2:03               ` Steve French
2024-07-11  4:20                 ` Andrew Bartlett
2024-08-15 20:47     ` Steve French
2024-08-22 17:06       ` Kevin Ottens
2024-09-01  4:48         ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5fad6c05eab959e06fe3518d9104376b79dcbcb9.camel@samba.org \
    --to=abartlet@samba.org \
    --cc=kevin.ottens@enioka.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox