| Message ID | 20230716-fixes-overly-restrictive-mmap-v1-0-0683b283b932@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | fs/9p: fix mmap regression | expand |
On 17.07.23 18:28, Eric Van Hensbergen wrote: > This series attempts to fix a reported exception with mmap > on newer kernels. > > -- original regression report -- > > TL;DR: mmap() seems to be broken on 9pfs on Linux 6.4. setting > "rootflags=ignoreqv" fixes it as well, but it feels like a regression. > > [...] > > I could track down the breakage to > > 1543b4c5071c54d76aad7a7a26a6e43082269b0c > > My test setup has, in addition to the patch above, the following patches also > reverted on top of a vanilla 6.4 kernel: > > 4eb3117888a923f6b9b1ad2dd093641c49a63ae5 > 21e26d5e54ab7cfe6b488fd27d4d70956d07e03b > > as 1543b cannot be reverted without those; however, the effect only goes away > when I also revert 1543b. The kernel has no other patches applied, only these > three reverts. > > -- end bug report -- > > Reported-by: Robert Schwebel <r.schwebel@pengutronix.de> This tag afaics should be in some or all of the commits -- together with a Link: or Closes: tag to the report (https://lore.kernel.org/v9fs/ZK25XZ%2BGpR3KHIB%2F@pengutronix.de/ ). 'Fixes:' tags would seem appropriate here as well. And to get this fixed in Linux 6.4.y. a "Cc: <stable..." would be great as well. See Documentation/handling-regressions.rst ( https://docs.kernel.org/process/handling-regressions.html ) and the links to Documentation/process/submitting-patches.rst or Documentation/process/5.Posting.rst for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot ^backmonitor: https://lore.kernel.org/v9fs/ZK25XZ%2BGpR3KHIB%2F@pengutronix.de/
This series attempts to fix a reported exception with mmap on newer kernels. -- original regression report -- TL;DR: mmap() seems to be broken on 9pfs on Linux 6.4. setting "rootflags=ignoreqv" fixes it as well, but it feels like a regression. I'm tracking down an issue which recently turned up in DistroKit [1] (an embedded Linux distro based on the ptxdist build system). The issue was a bit uggly, as my CI didn't find it (systems boot up normally after a while, and I only use 9p for virtual qemu machines, while most of the test farm is real hardware). The qemu machine in question is qemu-system-arm, emulating an ARM v7a machine. When starting the systems interactively, I get a lot of error output from ldconfig, like this: [ 17.412964] systemd-rc-once[127]: ldconfig: Cannot mmap file /lib/libgcc_s.so.1. [ 17.418851] systemd-rc-once[127]: ldconfig: Cannot mmap file /lib/libstdc++.so. [ 17.425009] systemd-rc-once[127]: ldconfig: Cannot mmap file /lib/libstdc++.so.6.0.30. [ 17.436671] systemd-rc-once[127]: ldconfig: Cannot mmap file /lib/libstdc++.so.6. [ 17.448451] systemd-rc-once[127]: ldconfig: Cannot mmap file /lib/libatomic.so. [ 17.456418] systemd-rc-once[127]: ldconfig: Cannot mmap file /lib/libatomic.so.1.2.0. ... Running ldconfig with strace shows this, for all libraries:: | statx(AT_FDCWD, "/lib/libnm.so.0", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFLNK|0777, stx_size=14, ...}) = 0 | statx(AT_FDCWD, "/lib/libnm.so.0", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|064 4, stx_size=862228, ...}) = 0 | openat(AT_FDCWD, "/lib/libnm.so.0", O_RDONLY|O_LARGEFILE) = 4 | statx(4, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_s ize=862228, ...}) = 0 | mmap2(NULL, 862228, PROT_READ, MAP_SHARED, 4, 0) = -1 ENODEV (No such device) | write(2, "ldconfig: ", 10ldconfig: ) = 10 | write(2, "Cannot mmap file /lib/libnm.so.0"..., 34Cannot mmap file /lib/libnm.so.0.) = 34 | write(2, "\n", 1) = 1 | close(4) = 0 I could track down the breakage to 1543b4c5071c54d76aad7a7a26a6e43082269b0c My test setup has, in addition to the patch above, the following patches also reverted on top of a vanilla 6.4 kernel: 4eb3117888a923f6b9b1ad2dd093641c49a63ae5 21e26d5e54ab7cfe6b488fd27d4d70956d07e03b as 1543b cannot be reverted without those; however, the effect only goes away when I also revert 1543b. The kernel has no other patches applied, only these three reverts. -- end bug report -- Reported-by: Robert Schwebel <r.schwebel@pengutronix.de> Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org> --- Eric Van Hensbergen (3): fs/9p: remove unecessary and overrestrictive check fs/9p: fix typo in comparison logic for cache mode fs/9p: fix type mismatch in file cache mode helper fs/9p/fid.h | 6 +++--- fs/9p/vfs_file.c | 2 -- 2 files changed, 3 insertions(+), 5 deletions(-) --- base-commit: 95f41d87810083d8b3dedcce46a4e356cf4a9673 change-id: 20230716-fixes-overly-restrictive-mmap-30a23501e787 Best regards,