Hi,

A while back, someone reported a failure on Fedora when trying to boot
a QEMU image off of a CIFS share. The issue was reduced down to a
test case (https://bugzilla.redhat.com/show_bug.cgi?id=1484130#c8)

# cat test-ofd-lock.c
#define _GNU_SOURCE
#include <errno.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>

int main(int argc, char **argv)
{
    int ret;
    int fd;
    struct flock fl = {
        .l_whence = SEEK_SET,
        .l_start  = 0,
        .l_len    = 0,
        .l_type   = F_RDLCK,
    };
    if (argc < 2) {
            fprintf(stderr, "Usage: %s <file>\n", argv[0]);
            return 1;
    }
    fd = open(argv[1], O_RDWR);
    if (fd < 0) {
            perror("open");
            return errno;
    }
    ret = fcntl(fd, F_OFD_SETLK, &fl);
    if (ret) {
            perror("setlk");
            return errno;
    }
    fl.l_type = F_WRLCK;
    ret = fcntl(fd, F_OFD_GETLK, &fl);
    if (ret) {
            perror("getlk");
            return errno;
    }
    if (fl.l_type != F_UNLCK) {
            fprintf(stderr, "get lock test failed\n");
            return 1;
    }
    return 0;
}
[root@localhost ~]# make test-ofd-lock
cc     test-ofd-lock.c   -o test-ofd-lock
[root@localhost ~]# touch /tmp/test && ./test-ofd-lock /tmp/test
[root@localhost ~]# echo $?
0
[root@localhost ~]# touch /mnt/test && ./test-ofd-lock /mnt/test
get lock test failed
[root@localhost ~]# mount | grep /mnt
//192.168.31.1/tddownload on /mnt type cifs (rw,relatime,vers=3.0,
cache=strict,username=admin,domain=,uid=0,
noforceuid,gid=0,noforcegid,addr=192.168.31.1,file_mode=0755,
dir_mode=0755,nounix,serverino,mapposix,rsize=1048576,
wsize=1048576,echo_interval=60,actimeo=1,user=admin)


As explained by one of the QEMU developers
(https://bugzilla.redhat.com/show_bug.cgi?id=1484130#c37)

'''
It is a kernel bug. The code snippet in comment 8 shows clearly that the kernel
is doing the wrong thing, which cannot be fixed/worked around by QEMU.

In man 2 fcntl:

       F_OFD_GETLK (struct flock *)
              On input to this call, lock describes an open file description 
lock
we would like to place on the file.  If the lock could  be  placed,  fcntl()  
does  not
              actually  place  it,  but  returns F_UNLCK in the l_type field of 
lock
and leaves the other fields of the structure unchanged.  If one or more 
incompatible
              locks would prevent this lock being placed, then details about 
one of
these locks are returned via lock, as described above for F_GETLK.

which is not the case with the new CIFS behaviour.
''

You can read the full context at 
https://bugzilla.redhat.com/show_bug.cgi?id=1484130

Any suggestions?

Thanks,
Laura

Reply via email to