Skip to contentSkip to conversation

fuse does not show lock info in /proc/.../fdinfo/...

DISCUSSION Maxim Patlasov 3 participants 4 messages Jun 3, 2016 – Jun 16, 2016 VFS

lore
Share & tools
lore

Maxim Patlasov

author
#0 lore raw

Hi Miklos,

fuse_file_lock() since its inception in 2006 implements F_SETLK command like this:

Quoted 4 lines
        if (fc->no_lock)
            err = posix_lock_file(file, fl, NULL);
        else
            err = fuse_setlk(file, fl, 0);

where fc->no_lock is a per-mount-point tunable. It would be more natural to posix-lock in both cases, like this:

Quoted 3 lines
        err = posix_lock_file(file, fl, NULL);
        if (!err && !fc->no_lock)
            err = fuse_setlk(file, fl, 0);

Otherwise, by default, when fc->no_lock=0, posix_lock_file() is never called, and from end-user perspective it is weird that the file was locked successfully, but "fdinfo" does not show the lock.

Do you think there were some reasons to implement it that way -- not calling posix_lock_file unconditionally?

Thanks,
Maxim

#1 lore raw
Quoted 19 lines · Maxim Patlasov

Hi Miklos,

fuse_file_lock() since its inception in 2006 implements F_SETLK command like this:

Quoted 4 lines
        if (fc->no_lock)
            err = posix_lock_file(file, fl, NULL);
        else
            err = fuse_setlk(file, fl, 0);

where fc->no_lock is a per-mount-point tunable. It would be more natural to posix-lock in both cases, like this:

Quoted 3 lines
        err = posix_lock_file(file, fl, NULL);
        if (!err && !fc->no_lock)
            err = fuse_setlk(file, fl, 0);
Quoted 6 lines

Otherwise, by default, when fc->no_lock=0, posix_lock_file() is never called, and from end-user perspective it is weird that the file was locked successfully, but "fdinfo" does not show the lock.

Do you think there were some reasons to implement it that way -- not calling posix_lock_file unconditionally?

Calling posix_lock_file() *before* we know the file can actually be locked may be setting us up for weird bugs. It could be called afterwards, when we already know the real locking operation succeeded.
But we need to think very carefully about races between two locking
operations, because locking state update is non-atomic after that change.

So I think this possibly can be done, but needs some thought.

Thanks,
Miklos

#2 lore raw

Hello Miklos,

16.06.2016 13:49, Miklos Szeredi пишет:

Quoted 18 lines · Maxim Patlasov
Quoted 17 lines

Hi Miklos,

fuse_file_lock() since its inception in 2006 implements F_SETLK command like this:

Quoted 4 lines
         if (fc->no_lock)
             err = posix_lock_file(file, fl, NULL);
         else
             err = fuse_setlk(file, fl, 0);

where fc->no_lock is a per-mount-point tunable. It would be more natural to posix-lock in both cases, like this:

Quoted 3 lines
         err = posix_lock_file(file, fl, NULL);
         if (!err && !fc->no_lock)
             err = fuse_setlk(file, fl, 0);
Quoted 8 lines
Quoted 6 lines

Otherwise, by default, when fc->no_lock=0, posix_lock_file() is never called, and from end-user perspective it is weird that the file was locked successfully, but "fdinfo" does not show the lock.

Do you think there were some reasons to implement it that way -- not calling posix_lock_file unconditionally?

Calling posix_lock_file() *before* we know the file can actually be locked may be setting us up for weird bugs.

Could you elaborate a bit on these bugs?
(BTW, it's done like this in NFS)

Quoted 10 lines

It could be called
afterwards, when we already know the real locking operation succeeded.
But we need to think very carefully about races between two locking
operations, because locking state update is non-atomic after that change.

So I think this possibly can be done, but needs some thought.

Thanks,
Miklos

#3 lore raw
Quoted 37 lines · Stanislav Kinsburskiy

Hello Miklos,

16.06.2016 13:49, Miklos Szeredi пишет:

Quoted 34 lines
Quoted 30 lines · Maxim Patlasov

Hi Miklos,

fuse_file_lock() since its inception in 2006 implements F_SETLK command like
this:

Quoted 4 lines
         if (fc->no_lock)
             err = posix_lock_file(file, fl, NULL);
         else
             err = fuse_setlk(file, fl, 0);

where fc->no_lock is a per-mount-point tunable. It would be more natural to
posix-lock in both cases, like this:

Quoted 3 lines
         err = posix_lock_file(file, fl, NULL);
         if (!err && !fc->no_lock)
             err = fuse_setlk(file, fl, 0);

Otherwise, by default, when fc->no_lock=0, posix_lock_file() is never called, and from end-user perspective it is weird that the file was locked
successfully, but "fdinfo" does not show the lock.

Do you think there were some reasons to implement it that way -- not calling.
posix_lock_file unconditionally?

Quoted 6 lines
Quoted 2 lines

Calling posix_lock_file() *before* we know the file can actually be locked may be setting us up for weird bugs.

Could you elaborate a bit on these bugs?
(BTW, it's done like this in NFS)

Suppose range 0-9 is locked remotely two processes are concurrently trying to lock the following ranges (nonblocking):

A: 5-15
B: 10-19

The situation is clear enough: "A" should fail, "B" should succeed.

However, with the above logic "B" might fail as well if it's done after "A" acquired the lock locally, but before failure from the remote lock operation was received

Thanks,
Miklos