September 2024 - Linux-stable-mirror

[PATCH 0/1] ext4: fix crash on BUG_ON in ext4_alloc_group_tables

by Alexander Mikhalitsyn

A long story behind this one, first of all, we (LXD project folks) started to see issues in our tests on GitHub Actions ubuntu22.04 runners after they've got updated from 6.5 to 6.8-based kernel and this was reported on Launchpad tracker [1] by Wesley Hershberger. At the same time, Stéphane Graber from LXC containers project saw the same problem on Incus testsuite (also on Github Actions). Then we had a debugging session together with Stéphane and he found a quite minimalistic reproducer: curl https://pkgs.zabbly.com/get/incus-daily | sudo sh sudo apt-get install lvm2 --yes sudo incus storage create default lvm volume.size=25MiB size=1GiB sudo incus image copy images:alpine/edge local: --alias testimage sudo incus profile device add default root disk pool=default path=/ size=3GiB sudo incus create testimage a1 this thing produces the following output in kernel logs: [ 33.882936] EXT4-fs (dm-5): mounted filesystem 8aaf41b2-6ac0-4fa8-b92b-77d10e1d16ca r/w with ordered data mode. Quota mode: none. [ 33.888365] EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks [ 33.888740] ------------[ cut here ]------------ [ 33.888742] kernel BUG at fs/ext4/resize.c:324! [ 33.889075] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 33.889503] CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 [ 33.890039] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 33.890705] RIP: 0010:ext4_resize_fs+0x1212/0x12d0 [ 33.891063] Code: b8 45 31 c0 4c 89 ff 45 31 c9 31 c9 ba 0e 08 00 00 48 c7 c6 68 75 65 b8 e8 2b 79 01 00 41 b8 ea ff ff ff 41 5f e9 8d f1 ff ff <0f> 0b 48 83 bd 70 ff ff ff 00 75 32 45 31 c0 e9 53 f1 ff ff 41 b8 [ 33.892701] RSP: 0018:ffffa97f413f3cc8 EFLAGS: 00010202 [ 33.893081] RAX: 0000000000000018 RBX: 0000000000000001 RCX: 00000000fffffff0 [ 33.893639] RDX: 0000000000000017 RSI: 0000000000000016 RDI: 00000000e8c2c810 [ 33.894197] RBP: ffffa97f413f3d90 R08: 0000000000000000 R09: 0000000000008000 [ 33.894755] R10: ffffa97f413f3cc8 R11: ffffa2c1845bfc80 R12: 0000000000000000 [ 33.895317] R13: ffffa2c1843d6000 R14: 0000000000008000 R15: ffffa2c199963000 [ 33.895877] FS: 00007f46efd17000(0000) GS:ffffa2c89fc40000(0000) knlGS:0000000000000000 [ 33.896524] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.896954] CR2: 00005630a4a1cc88 CR3: 000000010532c000 CR4: 0000000000350eb0 [ 33.897516] Call Trace: [ 33.897638] <TASK> [ 33.897728] ? show_regs+0x6d/0x80 [ 33.897942] ? die+0x3c/0xa0 [ 33.898106] ? do_trap+0xe5/0x110 [ 33.898311] ? do_error_trap+0x6e/0x90 [ 33.898555] ? ext4_resize_fs+0x1212/0x12d0 [ 33.898844] ? exc_invalid_op+0x57/0x80 [ 33.899101] ? ext4_resize_fs+0x1212/0x12d0 [ 33.899387] ? asm_exc_invalid_op+0x1f/0x30 [ 33.899675] ? ext4_resize_fs+0x1212/0x12d0 [ 33.899961] ? ext4_resize_fs+0x745/0x12d0 [ 33.900239] __ext4_ioctl+0x4e0/0x1800 [ 33.900489] ? srso_alias_return_thunk+0x5/0xfbef5 [ 33.900832] ? putname+0x5b/0x70 [ 33.901028] ? srso_alias_return_thunk+0x5/0xfbef5 [ 33.901374] ? do_sys_openat2+0x87/0xd0 [ 33.901632] ? srso_alias_return_thunk+0x5/0xfbef5 [ 33.901981] ? srso_alias_return_thunk+0x5/0xfbef5 [ 33.902324] ? __x64_sys_openat+0x59/0xa0 [ 33.902595] ext4_ioctl+0x12/0x20 [ 33.902802] ? ext4_ioctl+0x12/0x20 [ 33.903031] __x64_sys_ioctl+0x99/0xd0 [ 33.903277] x64_sys_call+0x1206/0x20d0 [ 33.903534] do_syscall_64+0x72/0x110 [ 33.903771] ? srso_alias_return_thunk+0x5/0xfbef5 [ 33.904115] ? irqentry_exit+0x3f/0x50 [ 33.904362] ? srso_alias_return_thunk+0x5/0xfbef5 [ 33.904707] ? exc_page_fault+0x1aa/0x7b0 [ 33.904979] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 33.905349] RIP: 0033:0x7f46efe3294f [ 33.905579] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 [ 33.907321] RSP: 002b:00007ffe9b8833a0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 33.907926] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f46efe3294f [ 33.908487] RDX: 00007ffe9b8834a0 RSI: 0000000040086610 RDI: 0000000000000004 [ 33.909046] RBP: 00005630a4a0b0e0 R08: 0000000000000000 R09: 00007ffe9b8832d7 [ 33.909605] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004 [ 33.910165] R13: 00005630a4a0c580 R14: 00005630a4a10400 R15: 0000000000000000 [ 33.910740] </TASK> [ 33.910837] Modules linked in: [ 33.911049] ---[ end trace 0000000000000000 ]--- [ 33.911428] RIP: 0010:ext4_resize_fs+0x1212/0x12d0 [ 33.911810] Code: b8 45 31 c0 4c 89 ff 45 31 c9 31 c9 ba 0e 08 00 00 48 c7 c6 68 75 65 b8 e8 2b 79 01 00 41 b8 ea ff ff ff 41 5f e9 8d f1 ff ff <0f> 0b 48 83 bd 70 ff ff ff 00 75 32 45 31 c0 e9 53 f1 ff ff 41 b8 [ 33.913928] RSP: 0018:ffffa97f413f3cc8 EFLAGS: 00010202 [ 33.914313] RAX: 0000000000000018 RBX: 0000000000000001 RCX: 00000000fffffff0 [ 33.914909] RDX: 0000000000000017 RSI: 0000000000000016 RDI: 00000000e8c2c810 [ 33.915482] RBP: ffffa97f413f3d90 R08: 0000000000000000 R09: 0000000000008000 [ 33.916258] R10: ffffa97f413f3cc8 R11: ffffa2c1845bfc80 R12: 0000000000000000 [ 33.917027] R13: ffffa2c1843d6000 R14: 0000000000008000 R15: ffffa2c199963000 [ 33.917884] FS: 00007f46efd17000(0000) GS:ffffa2c89fc40000(0000) knlGS:0000000000000000 [ 33.918818] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.919322] CR2: 00005630a4a1cc88 CR3: 000000010532c000 CR4: 0000000000350eb0 [ 44.072293] ------------[ cut here ]------------ This patch is attempt to fix it and I can confirm that after applying it everything works just fine. At the same time, I'm not knowledgable in ext4 filesystem code so careful review is required here. Kind regards, Alex Cc: stable(a)vger.kernel.org # v6.8+ Fixes: 665d3e0af4d3 ("ext4: reduce unnecessary memory allocation in alloc_flex_gd()") Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2081231 [1] Cc: "Theodore Ts'o" <tytso(a)mit.edu> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: Jan Kara <jack(a)suse.cz> Cc: Baokun Li <libaokun1(a)huawei.com> Cc: Stéphane Graber <stgraber(a)stgraber.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: <linux-kernel(a)vger.kernel.org> Cc: <linux-fsdevel(a)vger.kernel.org> Cc: <linux-ext4(a)vger.kernel.org> Reported-by: Wesley Hershberger <wesley.hershberger(a)canonical.com> Reported-by: Stéphane Graber <stgraber(a)stgraber.org> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn(a)canonical.com> Alexander Mikhalitsyn (1): ext4: fix BUG at fs/ext4/resize.c fs/ext4/resize.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) -- 2.34.1

3 months

5
18
0 0

RTL8852BE wifi no longer working after 6.11 upgrade

by Marcel Weißenbach

Hi there, i upgraded my Archlinux testing setup from 6.10.9 to 6.11 and noticed that my wifi is no longer working. Here is the output from the working 6.10.x Kernel 04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller Subsystem: AzureWave Device 5470 Kernel driver in use: rtw89_8852be Kernel modules: rtw89_8852be On 6.11, loading the Kernel Module fails. After veryfing it is not an Archlinux issue by manually building the Kernel from kernel.org manually, i can verify, it happens with an vanilla Kernel too. Here are the relevant parts from dmesg [...] [ 4.687462] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 4.687472] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 4.687477] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 4.687486] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687501] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687516] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3b [ 4.687531] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687546] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3f [ 4.687561] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687576] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f57 [ 4.687591] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687606] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4f [ 4.687621] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687636] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 4.687651] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687666] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f37 [ 4.687681] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687696] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f53 [ 6.376153] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 6.376163] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 6.376168] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 6.376178] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 6.376193] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f43 [ 6.376208] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 6.376223] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f41 [ 6.376238] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3f [ 6.376253] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376268] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376283] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f57 [ 6.376298] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 6.376313] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376327] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376342] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 6.376357] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 6.376372] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376387] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 7.135332] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control off [ 8.097173] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 8.097183] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 8.097188] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 8.097197] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f53 [ 8.097212] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 8.097227] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097242] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f2f [ 8.097257] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 8.097272] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097287] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097302] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f31 [ 8.097317] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f33 [ 8.097332] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f33 [ 8.097347] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdb [ 8.097362] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f33 [ 8.097377] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097391] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097406] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdb [ 9.817051] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 9.817059] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 9.817063] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 9.817072] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817087] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817102] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 9.817117] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 9.817133] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccf7 [ 9.817147] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3d [ 9.817162] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 9.817177] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817192] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817207] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817222] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f55 [ 9.817237] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f53 [ 9.817252] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 9.817267] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 9.817282] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536604] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 11.536615] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 11.536621] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 11.536632] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 11.536648] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f55 [ 11.536664] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890cce1 [ 11.536680] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f7f [ 11.536697] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536713] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890cce3 [ 11.536730] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f31 [ 11.536746] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536762] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 11.536778] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 11.536794] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 11.536809] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536825] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 11.536842] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f57 [ 11.536859] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536874] rtw89_8852be 0000:04:00.0: failed to setup chip information [ 11.537455] rtw89_8852be 0000:04:00.0: probe with driver rtw89_8852be failed with error -110 [...] The whole dmesg can be found here (with an Download button on the top right): https://ignaz.org/nextcloud/index.php/s/gMtZCxS5wjtWSYc Best Regards Marcel #regzbot introduced: v6.10.9..v6.11

3 months

2
7
0 0

[PATCH v2] rust: sync: require `T: Sync` for `LockedBy::access`

by Alice Ryhl

The `LockedBy::access` method only requires a shared reference to the owner, so if we have shared access to the `LockedBy` from several threads at once, then two threads could call `access` in parallel and both obtain a shared reference to the inner value. Thus, require that `T: Sync` when calling the `access` method. An alternative is to require `T: Sync` in the `impl Sync for LockedBy`. This patch does not choose that approach as it gives up the ability to use `LockedBy` with `!Sync` types, which is okay as long as you only use `access_mut`. Cc: stable(a)vger.kernel.org Fixes: 7b1f55e3a984 ("rust: sync: introduce `LockedBy`") Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- Changes in v2: - Use a `where T: Sync` on `access` instead of changing `impl Sync for LockedBy`. - Link to v1: https://lore.kernel.org/r/20240912-locked-by-sync-fix-v1-1-26433cbccbd2@goo… --- rust/kernel/sync/locked_by.rs | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs index babc731bd5f6..ce2ee8d87865 100644 --- a/rust/kernel/sync/locked_by.rs +++ b/rust/kernel/sync/locked_by.rs @@ -83,8 +83,12 @@ pub struct LockedBy<T: ?Sized, U: ?Sized> { // SAFETY: `LockedBy` can be transferred across thread boundaries iff the data it protects can. unsafe impl<T: ?Sized + Send, U: ?Sized> Send for LockedBy<T, U> {} -// SAFETY: `LockedBy` serialises the interior mutability it provides, so it is `Sync` as long as the -// data it protects is `Send`. +// SAFETY: If `T` is not `Sync`, then parallel shared access to this `LockedBy` allows you to use +// `access_mut` to hand out `&mut T` on one thread at the time. The requirement that `T: Send` is +// sufficient to allow that. +// +// If `T` is `Sync`, then the `access` method also becomes available, which allows you to obtain +// several `&T` from several threads at once. However, this is okay as `T` is `Sync`. unsafe impl<T: ?Sized + Send, U: ?Sized> Sync for LockedBy<T, U> {} impl<T, U> LockedBy<T, U> { @@ -118,7 +122,10 @@ impl<T: ?Sized, U> LockedBy<T, U> { /// /// Panics if `owner` is different from the data protected by the lock used in /// [`new`](LockedBy::new). - pub fn access<'a>(&'a self, owner: &'a U) -> &'a T { + pub fn access<'a>(&'a self, owner: &'a U) -> &'a T + where + T: Sync, + { build_assert!( size_of::<U>() > 0, "`U` cannot be a ZST because `owner` wouldn't be unique" @@ -127,7 +134,10 @@ pub fn access<'a>(&'a self, owner: &'a U) -> &'a T { panic!("mismatched owners"); } - // SAFETY: `owner` is evidence that the owner is locked. + // SAFETY: `owner` is evidence that there are only shared references to the owner for the + // duration of 'a, so it's not possible to use `Self::access_mut` to obtain a mutable + // reference to the inner value that aliases with this shared reference. The type is `Sync` + // so there are no other requirements. unsafe { &*self.data.get() } } --- base-commit: 93dc3be19450447a3a7090bd1dfb9f3daac3e8d2 change-id: 20240912-locked-by-sync-fix-07193df52f98 Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

3 months

3
3
0 0

[merged mm-hotfixes-stable] ocfs2-fix-uninit-value-in-ocfs2_get_block.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ocfs2: fix uninit-value in ocfs2_get_block() has been removed from the -mm tree. Its filename was ocfs2-fix-uninit-value-in-ocfs2_get_block.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Joseph Qi <joseph.qi(a)linux.alibaba.com> Subject: ocfs2: fix uninit-value in ocfs2_get_block() Date: Wed, 25 Sep 2024 17:06:00 +0800 syzbot reported an uninit-value BUG: BUG: KMSAN: uninit-value in ocfs2_get_block+0xed2/0x2710 fs/ocfs2/aops.c:159 ocfs2_get_block+0xed2/0x2710 fs/ocfs2/aops.c:159 do_mpage_readpage+0xc45/0x2780 fs/mpage.c:225 mpage_readahead+0x43f/0x840 fs/mpage.c:374 ocfs2_readahead+0x269/0x320 fs/ocfs2/aops.c:381 read_pages+0x193/0x1110 mm/readahead.c:160 page_cache_ra_unbounded+0x901/0x9f0 mm/readahead.c:273 do_page_cache_ra mm/readahead.c:303 [inline] force_page_cache_ra+0x3b1/0x4b0 mm/readahead.c:332 force_page_cache_readahead mm/internal.h:347 [inline] generic_fadvise+0x6b0/0xa90 mm/fadvise.c:106 vfs_fadvise mm/fadvise.c:185 [inline] ksys_fadvise64_64 mm/fadvise.c:199 [inline] __do_sys_fadvise64 mm/fadvise.c:214 [inline] __se_sys_fadvise64 mm/fadvise.c:212 [inline] __x64_sys_fadvise64+0x1fb/0x3a0 mm/fadvise.c:212 x64_sys_call+0xe11/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:222 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This is because when ocfs2_extent_map_get_blocks() fails, p_blkno is uninitialized. So the error log will trigger the above uninit-value access. The error log is out-of-date since get_blocks() was removed long time ago. And the error code will be logged in ocfs2_extent_map_get_blocks() once ocfs2_get_cluster() fails, so fix this by only logging inode and block. Link: https://syzkaller.appspot.com/bug?extid=9709e73bae885b05314b Link: https://lkml.kernel.org/r/20240925090600.3643376-1-joseph.qi@linux.alibaba.… Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reported-by: syzbot+9709e73bae885b05314b(a)syzkaller.appspotmail.com Tested-by: syzbot+9709e73bae885b05314b(a)syzkaller.appspotmail.com Cc: Heming Zhao <heming.zhao(a)suse.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/aops.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/fs/ocfs2/aops.c~ocfs2-fix-uninit-value-in-ocfs2_get_block +++ a/fs/ocfs2/aops.c @@ -156,9 +156,8 @@ int ocfs2_get_block(struct inode *inode, err = ocfs2_extent_map_get_blocks(inode, iblock, &p_blkno, &count, &ext_flags); if (err) { - mlog(ML_ERROR, "Error %d from get_blocks(0x%p, %llu, 1, " - "%llu, NULL)\n", err, inode, (unsigned long long)iblock, - (unsigned long long)p_blkno); + mlog(ML_ERROR, "get_blocks() failed, inode: 0x%p, " + "block: %llu\n", inode, (unsigned long long)iblock); goto bail; } _ Patches currently in -mm which might be from joseph.qi(a)linux.alibaba.com are

3 months

1
0
0 0

[merged mm-hotfixes-stable] kselftests-mm-fix-wrong-__nr_userfaultfd-value.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kselftests: mm: fix wrong __NR_userfaultfd value has been removed from the -mm tree. Its filename was kselftests-mm-fix-wrong-__nr_userfaultfd-value.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Subject: kselftests: mm: fix wrong __NR_userfaultfd value Date: Mon, 23 Sep 2024 10:38:36 +0500 grep -rnIF "#define __NR_userfaultfd" tools/include/uapi/asm-generic/unistd.h:681:#define __NR_userfaultfd 282 arch/x86/include/generated/uapi/asm/unistd_32.h:374:#define __NR_userfaultfd 374 arch/x86/include/generated/uapi/asm/unistd_64.h:327:#define __NR_userfaultfd 323 arch/x86/include/generated/uapi/asm/unistd_x32.h:282:#define __NR_userfaultfd (__X32_SYSCALL_BIT + 323) arch/arm/include/generated/uapi/asm/unistd-eabi.h:347:#define __NR_userfaultfd (__NR_SYSCALL_BASE + 388) arch/arm/include/generated/uapi/asm/unistd-oabi.h:359:#define __NR_userfaultfd (__NR_SYSCALL_BASE + 388) include/uapi/asm-generic/unistd.h:681:#define __NR_userfaultfd 282 The number is dependent on the architecture. The above data shows that: x86 374 x86_64 323 The value of __NR_userfaultfd was changed to 282 when asm-generic/unistd.h was included. It makes the test to fail every time as the correct number of this syscall on x86_64 is 323. Fix the header to asm/unistd.h. Link: https://lkml.kernel.org/r/20240923053836.3270393-1-usama.anjum@collabora.com Fixes: a5c6bc590094 ("selftests/mm: remove local __NR_* definitions") Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Reviewed-by: Shuah Khan <skhan(a)linuxfoundation.org> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/pagemap_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/mm/pagemap_ioctl.c~kselftests-mm-fix-wrong-__nr_userfaultfd-value +++ a/tools/testing/selftests/mm/pagemap_ioctl.c @@ -15,7 +15,7 @@ #include <sys/ioctl.h> #include <sys/stat.h> #include <math.h> -#include <asm-generic/unistd.h> +#include <asm/unistd.h> #include <pthread.h> #include <sys/resource.h> #include <assert.h> _ Patches currently in -mm which might be from usama.anjum(a)collabora.com are

3 months

1
0
0 0

[merged mm-hotfixes-stable] compilerh-specify-correct-attribute-for-rodatac_jump_table.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: compiler.h: specify correct attribute for .rodata..c_jump_table has been removed from the -mm tree. Its filename was compilerh-specify-correct-attribute-for-rodatac_jump_table.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Tiezhu Yang <yangtiezhu(a)loongson.cn> Subject: compiler.h: specify correct attribute for .rodata..c_jump_table Date: Tue, 24 Sep 2024 14:27:10 +0800 Currently, there is an assembler message when generating kernel/bpf/core.o under CONFIG_OBJTOOL with LoongArch compiler toolchain: Warning: setting incorrect section attributes for .rodata..c_jump_table This is because the section ".rodata..c_jump_table" should be readonly, but there is a "W" (writable) part of the flags: $ readelf -S kernel/bpf/core.o | grep -A 1 "rodata..c" [34] .rodata..c_j[...] PROGBITS 0000000000000000 0000d2e0 0000000000000800 0000000000000000 WA 0 0 8 There is no above issue on x86 due to the generated section flag is only "A" (allocatable). In order to silence the warning on LoongArch, specify the attribute like ".rodata..c_jump_table,\"a\",@progbits #" explicitly, then the section attribute of ".rodata..c_jump_table" must be readonly in the kernel/bpf/core.o file. Before: $ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c" 21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA After: $ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c" 21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA By the way, AFAICT, maybe the root cause is related with the different compiler behavior of various archs, so to some extent this change is a workaround for LoongArch, and also there is no effect for x86 which is the only port supported by objtool before LoongArch with this patch. Link: https://lkml.kernel.org/r/20240924062710.1243-1-yangtiezhu@loongson.cn Signed-off-by: Tiezhu Yang <yangtiezhu(a)loongson.cn> Cc: Josh Poimboeuf <jpoimboe(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> [6.9+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/compiler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/linux/compiler.h~compilerh-specify-correct-attribute-for-rodatac_jump_table +++ a/include/linux/compiler.h @@ -133,7 +133,7 @@ void ftrace_likely_update(struct ftrace_ #define annotate_unreachable() __annotate_unreachable(__COUNTER__) /* Annotate a C jump table to allow objtool to follow the code flow */ -#define __annotate_jump_table __section(".rodata..c_jump_table") +#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@progbits #") #else /* !CONFIG_OBJTOOL */ #define annotate_reachable() _ Patches currently in -mm which might be from yangtiezhu(a)loongson.cn are

3 months

1
0
0 0

[merged mm-hotfixes-stable] ocfs2-fix-deadlock-in-ocfs2_get_system_file_inode.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ocfs2: fix deadlock in ocfs2_get_system_file_inode has been removed from the -mm tree. Its filename was ocfs2-fix-deadlock-in-ocfs2_get_system_file_inode.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Mohammed Anees <pvmohammedanees2003(a)gmail.com> Subject: ocfs2: fix deadlock in ocfs2_get_system_file_inode Date: Tue, 24 Sep 2024 09:32:57 +0000 syzbot has found a possible deadlock in ocfs2_get_system_file_inode [1]. The scenario is depicted here, CPU0 CPU1 lock(&ocfs2_file_ip_alloc_sem_key); lock(&osb->system_file_mutex); lock(&ocfs2_file_ip_alloc_sem_key); lock(&osb->system_file_mutex); The function calls which could lead to this are: CPU0 ocfs2_mknod - lock(&ocfs2_file_ip_alloc_sem_key); . . . ocfs2_get_system_file_inode - lock(&osb->system_file_mutex); CPU1 - ocfs2_fill_super - lock(&osb->system_file_mutex); . . . ocfs2_read_virt_blocks - lock(&ocfs2_file_ip_alloc_sem_key); This issue can be resolved by making the down_read -> down_read_try in the ocfs2_read_virt_blocks. [1] https://syzkaller.appspot.com/bug?extid=e0055ea09f1f5e6fabdd Link: https://lkml.kernel.org/r/20240924093257.7181-1-pvmohammedanees2003@gmail.c… Signed-off-by: Mohammed Anees <pvmohammedanees2003(a)gmail.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reported-by: <syzbot+e0055ea09f1f5e6fabdd(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=e0055ea09f1f5e6fabdd Tested-by: syzbot+e0055ea09f1f5e6fabdd(a)syzkaller.appspotmail.com Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/extent_map.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/fs/ocfs2/extent_map.c~ocfs2-fix-deadlock-in-ocfs2_get_system_file_inode +++ a/fs/ocfs2/extent_map.c @@ -973,7 +973,13 @@ int ocfs2_read_virt_blocks(struct inode } while (done < nr) { - down_read(&OCFS2_I(inode)->ip_alloc_sem); + if (!down_read_trylock(&OCFS2_I(inode)->ip_alloc_sem)) { + rc = -EAGAIN; + mlog(ML_ERROR, + "Inode #%llu ip_alloc_sem is temporarily unavailable\n", + (unsigned long long)OCFS2_I(inode)->ip_blkno); + break; + } rc = ocfs2_extent_map_get_blocks(inode, v_block + done, &p_block, &p_count, NULL); up_read(&OCFS2_I(inode)->ip_alloc_sem); _ Patches currently in -mm which might be from pvmohammedanees2003(a)gmail.com are ocfs2-fix-typo-in-comment.patch

3 months

1
0
0 0

[merged mm-hotfixes-stable] ocfs2-reserve-space-for-inline-xattr-before-attaching-reflink-tree.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ocfs2: reserve space for inline xattr before attaching reflink tree has been removed from the -mm tree. Its filename was ocfs2-reserve-space-for-inline-xattr-before-attaching-reflink-tree.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Gautham Ananthakrishna <gautham.ananthakrishna(a)oracle.com> Subject: ocfs2: reserve space for inline xattr before attaching reflink tree Date: Wed, 18 Sep 2024 06:38:44 +0000 One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix. Link: https://lkml.kernel.org/r/20240918063844.1830332-1-gautham.ananthakrishna@o… Fixes: ef962df057aa ("ocfs2: xattr: fix inlined xattr reflink") Signed-off-by: Gautham Ananthakrishna <gautham.ananthakrishna(a)oracle.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/refcounttree.c | 26 ++++++++++++++++++++++++-- fs/ocfs2/xattr.c | 11 +---------- 2 files changed, 25 insertions(+), 12 deletions(-) --- a/fs/ocfs2/refcounttree.c~ocfs2-reserve-space-for-inline-xattr-before-attaching-reflink-tree +++ a/fs/ocfs2/refcounttree.c @@ -25,6 +25,7 @@ #include "namei.h" #include "ocfs2_trace.h" #include "file.h" +#include "symlink.h" #include <linux/bio.h> #include <linux/blkdev.h> @@ -4148,8 +4149,9 @@ static int __ocfs2_reflink(struct dentry int ret; struct inode *inode = d_inode(old_dentry); struct buffer_head *new_bh = NULL; + struct ocfs2_inode_info *oi = OCFS2_I(inode); - if (OCFS2_I(inode)->ip_flags & OCFS2_INODE_SYSTEM_FILE) { + if (oi->ip_flags & OCFS2_INODE_SYSTEM_FILE) { ret = -EINVAL; mlog_errno(ret); goto out; @@ -4175,6 +4177,26 @@ static int __ocfs2_reflink(struct dentry goto out_unlock; } + if ((oi->ip_dyn_features & OCFS2_HAS_XATTR_FL) && + (oi->ip_dyn_features & OCFS2_INLINE_XATTR_FL)) { + /* + * Adjust extent record count to reserve space for extended attribute. + * Inline data count had been adjusted in ocfs2_duplicate_inline_data(). + */ + struct ocfs2_inode_info *new_oi = OCFS2_I(new_inode); + + if (!(new_oi->ip_dyn_features & OCFS2_INLINE_DATA_FL) && + !(ocfs2_inode_is_fast_symlink(new_inode))) { + struct ocfs2_dinode *new_di = (struct ocfs2_dinode *)new_bh->b_data; + struct ocfs2_dinode *old_di = (struct ocfs2_dinode *)old_bh->b_data; + struct ocfs2_extent_list *el = &new_di->id2.i_list; + int inline_size = le16_to_cpu(old_di->i_xattr_inline_size); + + le16_add_cpu(&el->l_count, -(inline_size / + sizeof(struct ocfs2_extent_rec))); + } + } + ret = ocfs2_create_reflink_node(inode, old_bh, new_inode, new_bh, preserve); if (ret) { @@ -4182,7 +4204,7 @@ static int __ocfs2_reflink(struct dentry goto inode_unlock; } - if (OCFS2_I(inode)->ip_dyn_features & OCFS2_HAS_XATTR_FL) { + if (oi->ip_dyn_features & OCFS2_HAS_XATTR_FL) { ret = ocfs2_reflink_xattrs(inode, old_bh, new_inode, new_bh, preserve); --- a/fs/ocfs2/xattr.c~ocfs2-reserve-space-for-inline-xattr-before-attaching-reflink-tree +++ a/fs/ocfs2/xattr.c @@ -6511,16 +6511,7 @@ static int ocfs2_reflink_xattr_inline(st } new_oi = OCFS2_I(args->new_inode); - /* - * Adjust extent record count to reserve space for extended attribute. - * Inline data count had been adjusted in ocfs2_duplicate_inline_data(). - */ - if (!(new_oi->ip_dyn_features & OCFS2_INLINE_DATA_FL) && - !(ocfs2_inode_is_fast_symlink(args->new_inode))) { - struct ocfs2_extent_list *el = &new_di->id2.i_list; - le16_add_cpu(&el->l_count, -(inline_size / - sizeof(struct ocfs2_extent_rec))); - } + spin_lock(&new_oi->ip_lock); new_oi->ip_dyn_features |= OCFS2_HAS_XATTR_FL | OCFS2_INLINE_XATTR_FL; new_di->i_dyn_features = cpu_to_le16(new_oi->ip_dyn_features); _ Patches currently in -mm which might be from gautham.ananthakrishna(a)oracle.com are

3 months

1
0
0 0

[merged mm-hotfixes-stable] mm-migrate-annotate-data-race-in-migrate_folio_unmap.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: migrate: annotate data-race in migrate_folio_unmap() has been removed from the -mm tree. Its filename was mm-migrate-annotate-data-race-in-migrate_folio_unmap.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jeongjun Park <aha310510(a)gmail.com> Subject: mm: migrate: annotate data-race in migrate_folio_unmap() Date: Tue, 24 Sep 2024 22:00:53 +0900 I found a report from syzbot [1] This report shows that the value can be changed, but in reality, the value of __folio_set_movable() cannot be changed because it holds the folio refcount. Therefore, it is appropriate to add an annotate to make KCSAN ignore that data-race. [1] ================================================================== BUG: KCSAN: data-race in __filemap_remove_folio / migrate_pages_batch write to 0xffffea0004b81dd8 of 8 bytes by task 6348 on cpu 0: page_cache_delete mm/filemap.c:153 [inline] __filemap_remove_folio+0x1ac/0x2c0 mm/filemap.c:233 filemap_remove_folio+0x6b/0x1f0 mm/filemap.c:265 truncate_inode_folio+0x42/0x50 mm/truncate.c:178 shmem_undo_range+0x25b/0xa70 mm/shmem.c:1028 shmem_truncate_range mm/shmem.c:1144 [inline] shmem_evict_inode+0x14d/0x530 mm/shmem.c:1272 evict+0x2f0/0x580 fs/inode.c:731 iput_final fs/inode.c:1883 [inline] iput+0x42a/0x5b0 fs/inode.c:1909 dentry_unlink_inode+0x24f/0x260 fs/dcache.c:412 __dentry_kill+0x18b/0x4c0 fs/dcache.c:615 dput+0x5c/0xd0 fs/dcache.c:857 __fput+0x3fb/0x6d0 fs/file_table.c:439 ____fput+0x1c/0x30 fs/file_table.c:459 task_work_run+0x13a/0x1a0 kernel/task_work.c:228 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xbe/0x130 kernel/entry/common.c:218 do_syscall_64+0xd6/0x1c0 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffffea0004b81dd8 of 8 bytes by task 6342 on cpu 1: __folio_test_movable include/linux/page-flags.h:699 [inline] migrate_folio_unmap mm/migrate.c:1199 [inline] migrate_pages_batch+0x24c/0x1940 mm/migrate.c:1797 migrate_pages_sync mm/migrate.c:1963 [inline] migrate_pages+0xff1/0x1820 mm/migrate.c:2072 do_mbind mm/mempolicy.c:1390 [inline] kernel_mbind mm/mempolicy.c:1533 [inline] __do_sys_mbind mm/mempolicy.c:1607 [inline] __se_sys_mbind+0xf76/0x1160 mm/mempolicy.c:1603 __x64_sys_mbind+0x78/0x90 mm/mempolicy.c:1603 x64_sys_call+0x2b4d/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:238 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0xffff888127601078 -> 0x0000000000000000 Link: https://lkml.kernel.org/r/20240924130053.107490-1-aha310510@gmail.com Fixes: 7e2a5e5ab217 ("mm: migrate: use __folio_test_movable()") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/migrate.c~mm-migrate-annotate-data-race-in-migrate_folio_unmap +++ a/mm/migrate.c @@ -1196,7 +1196,7 @@ static int migrate_folio_unmap(new_folio int rc = -EAGAIN; int old_page_state = 0; struct anon_vma *anon_vma = NULL; - bool is_lru = !__folio_test_movable(src); + bool is_lru = data_race(!__folio_test_movable(src)); bool locked = false; bool dst_locked = false; _ Patches currently in -mm which might be from aha310510(a)gmail.com are mm-percpu-fix-typo-to-pcpu_alloc_noprof-description.patch mm-shmem-fix-data-race-in-shmem_getattr.patch

3 months

1
0
0 0

[merged mm-hotfixes-stable] mm-hugetlb-simplify-refs-in-memfd_alloc_folio.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hugetlb: simplify refs in memfd_alloc_folio has been removed from the -mm tree. Its filename was mm-hugetlb-simplify-refs-in-memfd_alloc_folio.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Steve Sistare <steven.sistare(a)oracle.com> Subject: mm/hugetlb: simplify refs in memfd_alloc_folio Date: Wed, 4 Sep 2024 12:41:08 -0700 The folio_try_get in memfd_alloc_folio is not necessary. Delete it, and delete the matching folio_put in memfd_pin_folios. This also avoids leaking a ref if the memfd_alloc_folio call to hugetlb_add_to_page_cache fails. That error path is also broken in a second way -- when its folio_put causes the ref to become 0, it will implicitly call free_huge_folio, but then the path *explicitly* calls free_huge_folio. Delete the latter. This is a continuation of the fix "mm/hugetlb: fix memfd_pin_folios free_huge_pages leak" [steven.sistare(a)oracle.com: remove explicit call to free_huge_folio(), per Matthew] Link: https://lkml.kernel.org/r/Zti-7nPVMcGgpcbi@casper.infradead.org Link: https://lkml.kernel.org/r/1725481920-82506-1-git-send-email-steven.sistare@… Link: https://lkml.kernel.org/r/1725478868-61732-1-git-send-email-steven.sistare@… Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios") Signed-off-by: Steve Sistare <steven.sistare(a)oracle.com> Suggested-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/gup.c | 4 +--- mm/memfd.c | 3 +-- 2 files changed, 2 insertions(+), 5 deletions(-) --- a/mm/gup.c~mm-hugetlb-simplify-refs-in-memfd_alloc_folio +++ a/mm/gup.c @@ -3615,7 +3615,7 @@ long memfd_pin_folios(struct file *memfd pgoff_t start_idx, end_idx, next_idx; struct folio *folio = NULL; struct folio_batch fbatch; - struct hstate *h = NULL; + struct hstate *h; long ret = -EINVAL; if (start < 0 || start > end || !max_folios) @@ -3659,8 +3659,6 @@ long memfd_pin_folios(struct file *memfd &fbatch); if (folio) { folio_put(folio); - if (h) - folio_put(folio); folio = NULL; } --- a/mm/memfd.c~mm-hugetlb-simplify-refs-in-memfd_alloc_folio +++ a/mm/memfd.c @@ -89,13 +89,12 @@ struct folio *memfd_alloc_folio(struct f numa_node_id(), NULL, gfp_mask); - if (folio && folio_try_get(folio)) { + if (folio) { err = hugetlb_add_to_page_cache(folio, memfd->f_mapping, idx); if (err) { folio_put(folio); - free_huge_folio(folio); return ERR_PTR(err); } folio_unlock(folio); _ Patches currently in -mm which might be from steven.sistare(a)oracle.com are

3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024