On Thu, Jun 16, 2016 at 3:22 PM, Stanislav Kinsburskiy <skinsbursky@xxxxxxxxxxxxx> wrote: > Hello Miklos, > > 16.06.2016 13:49, Miklos Szeredi пишет: >> >> On Fri, Jun 3, 2016 at 8:49 PM, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> >> wrote: >>> >>> Hi Miklos, >>> >>> fuse_file_lock() since its inception in 2006 implements F_SETLK command >>> like >>> this: >>> >>>> 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: >>> >>>> 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? >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
