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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266886 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 FUS= E 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 adjustme= nt itself when generating the FUSE request. When parsing the response, it overwrites the flock structure's `l_whence` field to `SEEK_SET` to signal t= hat absolute positions are being reported.=20 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) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266886-227>