Date: Fri, 07 Oct 2022 10:49:07 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 266886] [FUSEFS] Handling of l_whence with fcntl(F_GETLK) Message-ID: <bug-266886-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266886 Bug ID: 266886 Summary: [FUSEFS] Handling of l_whence with fcntl(F_GETLK) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: jmillikin@gmail.com I'm not 100% sure this is a bug, but it's a difference in behavior from FUSE on Linux, and IMO the Linux version's behavior is more correct here. When using fcntl(F_GETLK) to check for the presence of advisory locks, it's possible to set the flock structure's `l_whence` field to `SEEK_CUR` or `SEEK_END` to adjust how the `l_start` and `l_end` fields are interpreted. For example, `SEEK_CUR` means they are relative to the file's current position. FUSE doesn't pass through `l_whence`, so the Linux kernel does the adjustment itself when generating the FUSE request. When parsing the response, it overwrites the flock structure's `l_whence` field to `SEEK_SET` to signal that absolute positions are being reported. FreeBSD's implementation of FUSE_GETLK doesn't have this behavior, it passes through the start and end offsets as-is in both directions. This causes FUSE mounts to have abberent advisory lock reporting for binaries that depend on the Linux behavior. (all of the above applies to F_SETLK / F_SETLKW also) -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266886-227>