October 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] nfsd: fix delegation_blocked() to block correctly for at" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 45bb63ed20e02ae146336412889fe5450316a84f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100728-graves-septic-4380@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 45bb63ed20e0 ("nfsd: fix delegation_blocked() to block correctly for at least 30 seconds") b3f255ef6bff ("nfsd: use ktime_get_seconds() for timestamps") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 45bb63ed20e02ae146336412889fe5450316a84f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.de> Date: Mon, 9 Sep 2024 15:06:36 +1000 Subject: [PATCH] nfsd: fix delegation_blocked() to block correctly for at least 30 seconds The pair of bloom filtered used by delegation_blocked() was intended to block delegations on given filehandles for between 30 and 60 seconds. A new filehandle would be recorded in the "new" bit set. That would then be switch to the "old" bit set between 0 and 30 seconds later, and it would remain as the "old" bit set for 30 seconds. Unfortunately the code intended to clear the old bit set once it reached 30 seconds old, preparing it to be the next new bit set, instead cleared the *new* bit set before switching it to be the old bit set. This means that the "old" bit set is always empty and delegations are blocked between 0 and 30 seconds. This patch updates bd->new before clearing the set with that index, instead of afterwards. Reported-by: Olga Kornievskaia <okorniev(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: 6282cd565553 ("NFSD: Don't hand out delegations for 30 seconds after recalling them.") Signed-off-by: NeilBrown <neilb(a)suse.de> Reviewed-by: Benjamin Coddington <bcodding(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index cb5a9ab451c5..ac1859c7cc9d 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -1078,7 +1078,8 @@ static void nfs4_free_deleg(struct nfs4_stid *stid) * When a delegation is recalled, the filehandle is stored in the "new" * filter. * Every 30 seconds we swap the filters and clear the "new" one, - * unless both are empty of course. + * unless both are empty of course. This results in delegations for a + * given filehandle being blocked for between 30 and 60 seconds. * * Each filter is 256 bits. We hash the filehandle to 32bit and use the * low 3 bytes as hash-table indices. @@ -1107,9 +1108,9 @@ static int delegation_blocked(struct knfsd_fh *fh) if (ktime_get_seconds() - bd->swap_time > 30) { bd->entries -= bd->old_entries; bd->old_entries = bd->entries; + bd->new = 1-bd->new; memset(bd->set[bd->new], 0, sizeof(bd->set[0])); - bd->new = 1-bd->new; bd->swap_time = ktime_get_seconds(); } spin_unlock(&blocked_delegations_lock);

1 year

2
1
0 0

[PATCH stable 4.12] nfsd: fix delegation_blocked() to block correctly for at least 30 seconds

by NeilBrown

commit 45bb63ed20e02ae146336412889fe5450316a84f The pair of bloom filtered used by delegation_blocked() was intended to block delegations on given filehandles for between 30 and 60 seconds. A new filehandle would be recorded in the "new" bit set. That would then be switch to the "old" bit set between 0 and 30 seconds later, and it would remain as the "old" bit set for 30 seconds. Unfortunately the code intended to clear the old bit set once it reached 30 seconds old, preparing it to be the next new bit set, instead cleared the *new* bit set before switching it to be the old bit set. This means that the "old" bit set is always empty and delegations are blocked between 0 and 30 seconds. This patch updates bd->new before clearing the set with that index, instead of afterwards. Reported-by: Olga Kornievskaia <okorniev(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: 6282cd565553 ("NFSD: Don't hand out delegations for 30 seconds after recalling them.") Signed-off-by: NeilBrown <neilb(a)suse.de> Reviewed-by: Benjamin Coddington <bcodding(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/nfsd/nfs4state.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 7ac644d64ab1..d45487d82d44 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -743,7 +743,8 @@ static void nfs4_free_deleg(struct nfs4_stid *stid) * When a delegation is recalled, the filehandle is stored in the "new" * filter. * Every 30 seconds we swap the filters and clear the "new" one, - * unless both are empty of course. + * unless both are empty of course. This results in delegations for a + * given filehandle being blocked for between 30 and 60 seconds. * * Each filter is 256 bits. We hash the filehandle to 32bit and use the * low 3 bytes as hash-table indices. @@ -772,9 +773,9 @@ static int delegation_blocked(struct knfsd_fh *fh) if (seconds_since_boot() - bd->swap_time > 30) { bd->entries -= bd->old_entries; bd->old_entries = bd->entries; + bd->new = 1-bd->new; memset(bd->set[bd->new], 0, sizeof(bd->set[0])); - bd->new = 1-bd->new; bd->swap_time = seconds_since_boot(); } spin_unlock(&blocked_delegations_lock); base-commit: de2cffe297563c815c840cfa14b77a0868b61e53 -- 2.46.0

1 year

1
0
0 0

[PATCH v5 1/5] tpm: Return on tpm2_create_null_primary() failure

by Jarkko Sakkinen

tpm2_sessions_init() does not ignores the result of tpm2_create_null_primary(). Address this by returning -ENODEV to the caller. Cc: stable(a)vger.kernel.org # v6.10+ Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v5: - Do not print klog messages on error, as tpm2_save_context() already takes care of this. v4: - Fixed up stable version. v3: - Handle TPM and POSIX error separately and return -ENODEV always back to the caller. v2: - Refined the commit message. --- drivers/char/tpm/tpm2-sessions.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c index d3521aadd43e..0f09ac33ae99 100644 --- a/drivers/char/tpm/tpm2-sessions.c +++ b/drivers/char/tpm/tpm2-sessions.c @@ -1338,7 +1338,8 @@ static int tpm2_create_null_primary(struct tpm_chip *chip) tpm2_flush_context(chip, null_key); } - return rc; + /* Map all errors to -ENODEV: */ + return rc ? -ENODEV : rc; } /** @@ -1354,7 +1355,7 @@ int tpm2_sessions_init(struct tpm_chip *chip) rc = tpm2_create_null_primary(chip); if (rc) - dev_err(&chip->dev, "TPM: security failed (NULL seed derivation): %d\n", rc); + return rc; chip->auth = kmalloc(sizeof(*chip->auth), GFP_KERNEL); if (!chip->auth) -- 2.46.1

1 year

2
2
0 0

[PATCH] net: explicitly clear the sk pointer, when pf->create fails

by Ignat Korchagin

We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling. Fixes: 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails") Signed-off-by: Ignat Korchagin <ignat(a)cloudflare.com> Cc: stable(a)vger.kernel.org --- net/socket.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/socket.c b/net/socket.c index 7b046dd3e9a7..19afac3c2de9 100644 --- a/net/socket.c +++ b/net/socket.c @@ -1575,8 +1575,13 @@ int __sock_create(struct net *net, int family, int type, int protocol, rcu_read_unlock(); err = pf->create(net, sock, protocol, kern); - if (err < 0) + if (err < 0) { + /* ->create should release the allocated sock->sk object on error + * but it may leave the dangling pointer + */ + sock->sk = NULL; goto out_module_put; + } /* * Now to bump the refcnt of the [loadable] module that owns this -- 2.39.5

1 year

4
6
0 0

queue-5.10 panic on shutdown

by Chuck Lever III

Hi- I've seen the following panic on shutdown for about a week. I've been fighting a stomach bug, so I haven't been able to drill into it until now. I'm bisecting, but thought I should report the issue now. [52704.952919] BUG: unable to handle page fault for address: ffffffffffffffe8 [52704.954545] #PF: supervisor read access in kernel mode [52704.955755] #PF: error_code(0x0000) - not-present page [52704.956952] PGD 1c4415067 P4D 1c4415067 PUD 1c4417067 PMD 0 [52704.958291] Oops: 0000 [#1] SMP PTI [52704.959136] CPU: 3 PID: 1 Comm: systemd-shutdow Not tainted 5.10.226-g9ee79287d0d8 #1 [52704.960950] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [52704.962902] RIP: 0010:platform_shutdown+0x9/0x50 [52704.964010] Code: 02 00 00 ff 75 dd 31 c0 48 83 05 19 c9 b6 02 01 5d c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 68 <48> 8b 40 e8 48 85 c0 74 23 55 48 83 ef 10 48 83 05 01 ca b6 02 01 [52704.968215] RSP: 0018:ffffaaf780013d88 EFLAGS: 00010246 [52704.969426] RAX: 0000000000000000 RBX: ffff8f91478b6018 RCX: 0000000000000000 [52704.971095] RDX: 0000000000000001 RSI: ffff8f91478b6018 RDI: ffff8f91478b6010 [52704.972758] RBP: ffffaaf780013db8 R08: ffff8f91478b4408 R09: 0000000000000000 [52704.974433] R10: 000000000000000f R11: ffffffffa654d2e0 R12: ffffffffa6ba0440 [52704.976083] R13: ffff8f91478b6010 R14: ffff8f91478b6090 R15: 0000000000000000 [52704.977765] FS: 00007f0f126e6b80(0000) GS:ffff8f92b7d80000(0000) knlGS:0000000000000000 [52704.979653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [52704.981008] CR2: ffffffffffffffe8 CR3: 00000001501be006 CR4: 0000000000170ee0 [52704.982697] Call Trace: [52704.983309] ? show_regs.cold+0x22/0x2f [52704.984223] ? __die_body+0x28/0xb0 [52704.985076] ? __die+0x39/0x4c [52704.985827] ? no_context.constprop.0+0x190/0x480 [52704.986940] ? __bad_area_nosemaphore+0x51/0x290 [52704.988050] ? bad_area_nosemaphore+0x1e/0x30 [52704.989082] ? do_kern_addr_fault+0x9a/0xf0 [52704.990098] ? exc_page_fault+0x1d3/0x350 [52704.991047] ? asm_exc_page_fault+0x1e/0x30 [52704.992041] ? platform_shutdown+0x9/0x50 [52704.992997] ? platform_dev_attrs_visible+0x50/0x50 [52704.994152] ? device_shutdown+0x260/0x3d0 [52704.995132] kernel_restart_prepare+0x4e/0x60 [52704.996180] kernel_restart+0x1b/0x50 [52704.997070] __do_sys_reboot+0x24d/0x330 [52704.998026] ? finish_task_switch+0xf6/0x620 [52704.999049] ? __schedule+0x486/0xf50 [52704.999926] ? exit_to_user_mode_prepare+0xc3/0x390 [52705.000840] __x64_sys_reboot+0x26/0x40 [52705.001542] do_syscall_64+0x50/0x90 [52705.002218] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [52705.003356] RIP: 0033:0x7f0f1369def7 [52705.004216] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 51 af 0c 00 f7 d8 64 89 02 b8 [52705.008496] RSP: 002b:00007fffcbc9eb48 EFLAGS: 00000206 ORIG_RAX: 00000000000000a9 [52705.010235] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f1369def7 [52705.011915] RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead [52705.013593] RBP: 00007fffcbc9eda0 R08: 0000000000000000 R09: 00007fffcbc9df40 [52705.015272] R10: 00007fffcbc9e100 R11: 0000000000000206 R12: 00007fffcbc9ebd8 [52705.016928] R13: 0000000000000000 R14: 0000000000000000 R15: 000055a7848b1968 [52705.018585] Modules linked in: sunrpc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill nf_tables nfnetlink iTCO_wdt intel_rapl_msr intel_rapl_common intel_pmc_bxt kvm_intel iTCO_vendor_support kvm virtio_net irqbypass rapl joydev net_failover i2c_i801 lpc_ich failover i2c_smbus virtio_balloon fuse zram xfs crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel virtio_blk virtio_console qemu_fw_cfg [last unloaded: nft_fib] [52705.029015] CR2: ffffffffffffffe8 [52705.029832] ---[ end trace 40dfe466fd371faa ]--- [52705.030908] RIP: 0010:platform_shutdown+0x9/0x50 [52705.031972] Code: 02 00 00 ff 75 dd 31 c0 48 83 05 19 c9 b6 02 01 5d c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 68 <48> 8b 40 e8 48 85 c0 74 23 55 48 83 ef 10 48 83 05 01 ca b6 02 01 [52705.036245] RSP: 0018:ffffaaf780013d88 EFLAGS: 00010246 [52705.037474] RAX: 0000000000000000 RBX: ffff8f91478b6018 RCX: 0000000000000000 [52705.039143] RDX: 0000000000000001 RSI: ffff8f91478b6018 RDI: ffff8f91478b6010 [52705.040827] RBP: ffffaaf780013db8 R08: ffff8f91478b4408 R09: 0000000000000000 [52705.042463] R10: 000000000000000f R11: ffffffffa654d2e0 R12: ffffffffa6ba0440 [52705.044135] R13: ffff8f91478b6010 R14: ffff8f91478b6090 R15: 0000000000000000 [52705.045784] FS: 00007f0f126e6b80(0000) GS:ffff8f92b7d80000(0000) knlGS:0000000000000000 [52705.047637] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [52705.048992] CR2: ffffffffffffffe8 CR3: 00000001501be006 CR4: 0000000000170ee0 [52705.050655] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [52705.053432] Kernel Offset: 0x23000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [52705.055871] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]--- -- Chuck Lever

1 year

3
2
0 0

Previous Message

by Cheng Allen

Hello, I hope this email finds you well. I reached out to you a few hours ago, but I have not received a response yet. I just wanted to check in to see if you had the chance to review my previous message or if there were any issues that may have prevented you from getting back to me. Could you please confirm receipt of my earlier correspondence and provide a response at your earliest convenience? Your prompt attention to this matter is greatly appreciated. Thank you for your cooperation. Warm regards, Dr. Allen Cheng Human Resource Manager | Product Research Assistant FC Industrial Laboratories Ltd This electronic mail and its attachment(s) is intended only for the recipient(s) to whom it is addressed. It may contain information which may be confidential and/or protected by legal privilege. If you are not the intended recipient(s), reading, disclosing, printing, copying, forwarding this electronic mail and its attachment(s) and/or taking any action in reliance on the information in this electronic mail and its attachment(s) are prohibited. Koperasi Telkomsel/Koperasi Telekomunikasi Selular/Kisel shall not be liable in respect of communication made by its employee which is contrary to the company policy and/or outside the scope of the employment of the individual concerned. The employee will be personally liable for any damages or other liability arising Surat elektronik ini beserta lampirannya dimaksudkan hanya untuk penerima kepada siapa surat tersebut ditujukan. Informasi yang terdapat di dalamnya dapat bersifat rahasia dan/atau dilindungi oleh hukum. Jika Anda bukan penerima yang dituju, Anda dilarang untuk membaca, mengungkapkan, mencetak, menduplikasi/menyalin, meneruskan surat elektronik ini beserta lampirannya dan/atau mengambil tindakan apapun berdasarkan informasi yang terdapat dalam surat elektronik ini beserta lampirannya. Koperasi Telkomsel/Koperasi Telekomunikasi Selular/Kisel tidak bertanggung jawab atas setiap komunikasi karyawan yang bertentangan dengan kebijakan perusahaan dan/atau berada di luar lingkup pekerjaannya. Segala resiko dan akibat yang ditimbulkan merupakan tanggung jawab personal masing-masing.

1 year

1
0
0 0

[PATCH] Bluetooth: Fix type of len in rfcomm_sock_{bind,getsockopt_old}()

by Andrej Shadura

Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_bind and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_bind and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable(a)vger.kernel.org Fixes: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: https://github.com/ClangBuiltLinux/linux/issues/2007 Link: https://github.com/llvm/llvm-project/issues/85647 Signed-off-by: Andrej Shadura <andrew.shadura(a)collabora.co.uk> --- net/bluetooth/rfcomm/sock.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c index 37d63d768afb..c0fe96673b3c 100644 --- a/net/bluetooth/rfcomm/sock.c +++ b/net/bluetooth/rfcomm/sock.c @@ -328,14 +328,15 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr { struct sockaddr_rc sa; struct sock *sk = sock->sk; - int len, err = 0; + int err = 0; + size_t len; if (!addr || addr_len < offsetofend(struct sockaddr, sa_family) || addr->sa_family != AF_BLUETOOTH) return -EINVAL; memset(&sa, 0, sizeof(sa)); - len = min_t(unsigned int, sizeof(sa), addr_len); + len = min(sizeof(sa), addr_len); memcpy(&sa, addr, len); BT_DBG("sk %p %pMR", sk, &sa.rc_bdaddr); @@ -729,7 +730,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u struct sock *l2cap_sk; struct l2cap_conn *conn; struct rfcomm_conninfo cinfo; - int len, err = 0; + int err = 0; + size_t len; u32 opt; BT_DBG("sk %p", sk); @@ -783,7 +785,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u cinfo.hci_handle = conn->hcon->handle; memcpy(cinfo.dev_class, conn->hcon->dev_class, 3); - len = min_t(unsigned int, len, sizeof(cinfo)); + len = min(len, sizeof(cinfo)); if (copy_to_user(optval, (char *) &cinfo, len)) err = -EFAULT; -- 2.43.0

1 year

4
6
0 0

FAILED: patch "[PATCH] mm: z3fold: deprecate CONFIG_Z3FOLD" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 7a2369b74abf76cd3e54c45b30f6addb497f831b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100711-ebook-refund-46f3@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 7a2369b74abf ("mm: z3fold: deprecate CONFIG_Z3FOLD") 04cb7502a5d7 ("zsmalloc: use all available 24 bits of page_type") 43d746dc49bb ("mm/zsmalloc: use a proper page type") 8db00ad56461 ("mm: allow reuse of the lower 16 bit of the page type with an actual type") 6d21dde7adc0 ("mm: update _mapcount and page_type documentation") ff202303c398 ("mm: convert page type macros to enum") 46df8e73a4a3 ("mm: free up PG_slab") d99e3140a4d3 ("mm: turn folio_test_hugetlb into a PageType") fd1a745ce03e ("mm: support page_mapcount() on page_has_type() pages") 29cfe7556bfd ("mm: constify more page/folio tests") 443cbaf9e2fd ("crash: split vmcoreinfo exporting code out from crash_core.c") 85fcde402db1 ("kexec: split crashkernel reservation code out from crash_core.c") 55c49fee57af ("mm/vmalloc: remove vmap_area_list") d093602919ad ("mm: vmalloc: remove global vmap_area_root rb-tree") 7fa8cee00316 ("mm: vmalloc: move vmap_init_free_space() down in vmalloc.c") 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources") 9f2a63523582 ("Merge tag 'mm-nonmm-stable-2024-01-09-10-33' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7a2369b74abf76cd3e54c45b30f6addb497f831b Mon Sep 17 00:00:00 2001 From: Yosry Ahmed <yosryahmed(a)google.com> Date: Wed, 4 Sep 2024 23:33:43 +0000 Subject: [PATCH] mm: z3fold: deprecate CONFIG_Z3FOLD The z3fold compressed pages allocator is rarely used, most users use zsmalloc. The only disadvantage of zsmalloc in comparison is the dependency on MMU, and zbud is a more common option for !MMU as it was the default zswap allocator for a long time. Historically, zsmalloc had worse latency than zbud and z3fold but offered better memory savings. This is no longer the case as shown by a simple recent analysis [1]. That analysis showed that z3fold does not have any advantage over zsmalloc or zbud considering both performance and memory usage. In a kernel build test on tmpfs in a limited cgroup, z3fold took 3% more time and used 1.8% more memory. The latency of zswap_load() was 7% higher, and that of zswap_store() was 10% higher. Zsmalloc is better in all metrics. Moreover, z3fold apparently has latent bugs, which was made noticeable by a recent soft lockup bug report with z3fold [2]. Switching to zsmalloc not only fixed the problem, but also reduced the swap usage from 6~8G to 1~2G. Other users have also reported being bitten by mistakenly enabling z3fold. Other than hurting users, z3fold is repeatedly causing wasted engineering effort. Apart from investigating the above bug, it came up in multiple development discussions (e.g. [3]) as something we need to handle, when there aren't any legit users (at least not intentionally). The natural course of action is to deprecate z3fold, and remove in a few cycles if no objections are raised from active users. Next on the list should be zbud, as it offers marginal latency gains at the cost of huge memory waste when compared to zsmalloc. That one will need to wait until zsmalloc does not depend on MMU. Rename the user-visible config option from CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED so that users with CONFIG_Z3FOLD=y get a new prompt with explanation during make oldconfig. Also, remove CONFIG_Z3FOLD=y from defconfigs. [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndq… [2]https://lore.kernel.org/lkml/EF0ABD3E-A239-4111-A8AB-5C442E759CF3@gmail.c… [3]https://lore.kernel.org/lkml/CAJD7tkbnmeVugfunffSovJf9FAgy9rhBVt_tx=nxUve… [arnd(a)arndb.de: deprecate ZSWAP_ZPOOL_DEFAULT_Z3FOLD as well] Link: https://lkml.kernel.org/r/20240909202625.1054880-1-arnd@kernel.org Link: https://lkml.kernel.org/r/20240904233343.933462-1-yosryahmed@google.com Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Chris Down <chris(a)chrisdown.name> Acked-by: Nhat Pham <nphamcs(a)gmail.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Acked-by: Vitaly Wool <vitaly.wool(a)konsulko.com> Acked-by: Christoph Hellwig <hch(a)lst.de> Cc: Aneesh Kumar K.V <aneesh.kumar(a)kernel.org> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Huacai Chen <chenhuacai(a)kernel.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Naveen N. Rao <naveen.n.rao(a)linux.ibm.com> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: WANG Xuerui <kernel(a)xen0n.name> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig index b4252c357c8e..75b366407a60 100644 --- a/arch/loongarch/configs/loongson3_defconfig +++ b/arch/loongarch/configs/loongson3_defconfig @@ -96,7 +96,6 @@ CONFIG_ZPOOL=y CONFIG_ZSWAP=y CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y CONFIG_ZBUD=y -CONFIG_Z3FOLD=y CONFIG_ZSMALLOC=m # CONFIG_COMPAT_BRK is not set CONFIG_MEMORY_HOTPLUG=y diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 544a65fda77b..d39284489aa2 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y CONFIG_PARTITION_ADVANCED=y CONFIG_BINFMT_MISC=m CONFIG_ZSWAP=y -CONFIG_Z3FOLD=y CONFIG_ZSMALLOC=y # CONFIG_SLAB_MERGE_DEFAULT is not set CONFIG_SLAB_FREELIST_RANDOM=y diff --git a/mm/Kconfig b/mm/Kconfig index 1aa282e35dc7..09aebca1cae3 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -146,12 +146,15 @@ config ZSWAP_ZPOOL_DEFAULT_ZBUD help Use the zbud allocator as the default allocator. -config ZSWAP_ZPOOL_DEFAULT_Z3FOLD - bool "z3fold" - select Z3FOLD +config ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED + bool "z3foldi (DEPRECATED)" + select Z3FOLD_DEPRECATED help Use the z3fold allocator as the default allocator. + Deprecated and scheduled for removal in a few cycles, + see CONFIG_Z3FOLD_DEPRECATED. + config ZSWAP_ZPOOL_DEFAULT_ZSMALLOC bool "zsmalloc" select ZSMALLOC @@ -163,7 +166,7 @@ config ZSWAP_ZPOOL_DEFAULT string depends on ZSWAP default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD - default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD + default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC default "" @@ -177,15 +180,25 @@ config ZBUD deterministic reclaim properties that make it preferable to a higher density approach when reclaim will be used. -config Z3FOLD - tristate "3:1 compression allocator (z3fold)" +config Z3FOLD_DEPRECATED + tristate "3:1 compression allocator (z3fold) (DEPRECATED)" depends on ZSWAP help + Deprecated and scheduled for removal in a few cycles. If you have + a good reason for using Z3FOLD over ZSMALLOC, please contact + linux-mm(a)kvack.org and the zswap maintainers. + A special purpose allocator for storing compressed pages. It is designed to store up to three compressed pages per physical page. It is a ZBUD derivative so the simplicity and determinism are still there. +config Z3FOLD + tristate + default y if Z3FOLD_DEPRECATED=y + default m if Z3FOLD_DEPRECATED=m + depends on Z3FOLD_DEPRECATED + config ZSMALLOC tristate prompt "N:1 compression allocator (zsmalloc)" if (ZSWAP || ZRAM)

1 year

2
1
0 0

Re: Patch "coredump: Standartize and fix logging" has been added to the 6.10-stable tree

by Roman Kisel

Sasha, Thank you very much for taking this to the stable kernel! With the 6.12-rc1, folks saw unkillable processes, and the suspicion was that get_task_comm() takes a lock on the task_struct. Kees was kind enough to look into that and sent out https://lore.kernel.org/all/20240928210830.work.307-kees@kernel.org/. As much as I'd love to see these logs produced by the kernel to help with core dump diagnostics, I am really worried that lock might cause more harm than the patches bring value, let alone this is a stable kernel, and as I understand, folks might run very important workloads trusting the stable kernel. If you see why these patches are good for the stable kernel (e.g. there is no lock as in 6.12), I trust your judgement. Added Kees and Eric in hopes they have time to help if this is a good change for the stable kernel. Thank you all for your help! On 10/6/2024 8:27 AM, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > coredump: Standartize and fix logging > > to the 6.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > coredump-standartize-and-fix-logging.patch > and it can be found in the queue-6.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit f0a5649db30d6ff2509281ace680db9cc08ce258 > Author: Roman Kisel <romank(a)linux.microsoft.com> > Date: Thu Jul 18 11:27:24 2024 -0700 > > coredump: Standartize and fix logging > > [ Upstream commit c114e9948c2b6a0b400266e59cc656b59e795bca ] > > The coredump code does not log the process ID and the comm > consistently, logs unescaped comm when it does log it, and > does not always use the ratelimited logging. That makes it > harder to analyze logs and puts the system at the risk of > spamming the system log incase something crashes many times > over and over again. > > Fix that by logging TGID and comm (escaped) consistently and > using the ratelimited logging always. > > Signed-off-by: Roman Kisel <romank(a)linux.microsoft.com> > Tested-by: Allen Pais <apais(a)linux.microsoft.com> > Link: https://lore.kernel.org/r/20240718182743.1959160-2-romank@linux.microsoft.c… > Signed-off-by: Kees Cook <kees(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/fs/coredump.c b/fs/coredump.c > index a57a06b80f571..19d3343b93c6b 100644 > --- a/fs/coredump.c > +++ b/fs/coredump.c > @@ -586,8 +586,7 @@ void do_coredump(const kernel_siginfo_t *siginfo) > struct subprocess_info *sub_info; > > if (ispipe < 0) { > - printk(KERN_WARNING "format_corename failed\n"); > - printk(KERN_WARNING "Aborting core\n"); > + coredump_report_failure("format_corename failed, aborting core"); > goto fail_unlock; > } > > @@ -607,27 +606,21 @@ void do_coredump(const kernel_siginfo_t *siginfo) > * right pid if a thread in a multi-threaded > * core_pattern process dies. > */ > - printk(KERN_WARNING > - "Process %d(%s) has RLIMIT_CORE set to 1\n", > - task_tgid_vnr(current), current->comm); > - printk(KERN_WARNING "Aborting core\n"); > + coredump_report_failure("RLIMIT_CORE is set to 1, aborting core"); > goto fail_unlock; > } > cprm.limit = RLIM_INFINITY; > > dump_count = atomic_inc_return(&core_dump_count); > if (core_pipe_limit && (core_pipe_limit < dump_count)) { > - printk(KERN_WARNING "Pid %d(%s) over core_pipe_limit\n", > - task_tgid_vnr(current), current->comm); > - printk(KERN_WARNING "Skipping core dump\n"); > + coredump_report_failure("over core_pipe_limit, skipping core dump"); > goto fail_dropcount; > } > > helper_argv = kmalloc_array(argc + 1, sizeof(*helper_argv), > GFP_KERNEL); > if (!helper_argv) { > - printk(KERN_WARNING "%s failed to allocate memory\n", > - __func__); > + coredump_report_failure("%s failed to allocate memory", __func__); > goto fail_dropcount; > } > for (argi = 0; argi < argc; argi++) > @@ -644,8 +637,7 @@ void do_coredump(const kernel_siginfo_t *siginfo) > > kfree(helper_argv); > if (retval) { > - printk(KERN_INFO "Core dump to |%s pipe failed\n", > - cn.corename); > + coredump_report_failure("|%s pipe failed", cn.corename); > goto close_fail; > } > } else { > @@ -658,10 +650,8 @@ void do_coredump(const kernel_siginfo_t *siginfo) > goto fail_unlock; > > if (need_suid_safe && cn.corename[0] != '/') { > - printk(KERN_WARNING "Pid %d(%s) can only dump core "\ > - "to fully qualified path!\n", > - task_tgid_vnr(current), current->comm); > - printk(KERN_WARNING "Skipping core dump\n"); > + coredump_report_failure( > + "this process can only dump core to a fully qualified path, skipping core dump"); > goto fail_unlock; > } > > @@ -730,13 +720,13 @@ void do_coredump(const kernel_siginfo_t *siginfo) > idmap = file_mnt_idmap(cprm.file); > if (!vfsuid_eq_kuid(i_uid_into_vfsuid(idmap, inode), > current_fsuid())) { > - pr_info_ratelimited("Core dump to %s aborted: cannot preserve file owner\n", > - cn.corename); > + coredump_report_failure("Core dump to %s aborted: " > + "cannot preserve file owner", cn.corename); > goto close_fail; > } > if ((inode->i_mode & 0677) != 0600) { > - pr_info_ratelimited("Core dump to %s aborted: cannot preserve file permissions\n", > - cn.corename); > + coredump_report_failure("Core dump to %s aborted: " > + "cannot preserve file permissions", cn.corename); > goto close_fail; > } > if (!(cprm.file->f_mode & FMODE_CAN_WRITE)) > @@ -757,7 +747,7 @@ void do_coredump(const kernel_siginfo_t *siginfo) > * have this set to NULL. > */ > if (!cprm.file) { > - pr_info("Core dump to |%s disabled\n", cn.corename); > + coredump_report_failure("Core dump to |%s disabled", cn.corename); > goto close_fail; > } > if (!dump_vma_snapshot(&cprm)) > @@ -983,11 +973,10 @@ void validate_coredump_safety(void) > { > if (suid_dumpable == SUID_DUMP_ROOT && > core_pattern[0] != '/' && core_pattern[0] != '|') { > - pr_warn( > -"Unsafe core_pattern used with fs.suid_dumpable=2.\n" > -"Pipe handler or fully qualified core dump path required.\n" > -"Set kernel.core_pattern before fs.suid_dumpable.\n" > - ); > + > + coredump_report_failure("Unsafe core_pattern used with fs.suid_dumpable=2: " > + "pipe handler or fully qualified core dump path required. " > + "Set kernel.core_pattern before fs.suid_dumpable."); > } > } > > diff --git a/include/linux/coredump.h b/include/linux/coredump.h > index 0904ba010341a..45e598fe34766 100644 > --- a/include/linux/coredump.h > +++ b/include/linux/coredump.h > @@ -43,8 +43,30 @@ extern int dump_align(struct coredump_params *cprm, int align); > int dump_user_range(struct coredump_params *cprm, unsigned long start, > unsigned long len); > extern void do_coredump(const kernel_siginfo_t *siginfo); > + > +/* > + * Logging for the coredump code, ratelimited. > + * The TGID and comm fields are added to the message. > + */ > + > +#define __COREDUMP_PRINTK(Level, Format, ...) \ > + do { \ > + char comm[TASK_COMM_LEN]; \ > + \ > + get_task_comm(comm, current); \ > + printk_ratelimited(Level "coredump: %d(%*pE): " Format "\n", \ > + task_tgid_vnr(current), (int)strlen(comm), comm, ##__VA_ARGS__); \ > + } while (0) \ > + > +#define coredump_report(fmt, ...) __COREDUMP_PRINTK(KERN_INFO, fmt, ##__VA_ARGS__) > +#define coredump_report_failure(fmt, ...) __COREDUMP_PRINTK(KERN_WARNING, fmt, ##__VA_ARGS__) > + > #else > static inline void do_coredump(const kernel_siginfo_t *siginfo) {} > + > +#define coredump_report(...) > +#define coredump_report_failure(...) > + > #endif > > #if defined(CONFIG_COREDUMP) && defined(CONFIG_SYSCTL) -- Thank you, Roman

1 year

2
2
0 0

FAILED: patch "[PATCH] drm/sched: Always increment correct scheduler score" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100755-unedited-smuggler-ece7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 087913e0ba2b ("drm/sched: Always increment correct scheduler score") cbc8764e29c2 ("drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job") 440d52b370b0 ("drm/sched: Fix dynamic job-flow control race") f92a39ae4707 ("drm/sched: Partial revert of "Qualify drm_sched_wakeup() by drm_sched_entity_is_ready()"") a78422e9dff3 ("drm/sched: implement dynamic job-flow control") f3123c259000 ("drm/sched: Qualify drm_sched_wakeup() by drm_sched_entity_is_ready()") bc8d6a9df990 ("drm/sched: Don't disturb the entity when in RR-mode scheduling") f12af4c461fb ("drm/sched: Drop suffix from drm_sched_wakeup_if_can_queue") 35a4279d42db ("drm/sched: Rename drm_sched_run_job_queue_if_ready and clarify kerneldoc") 67dd1d8c9f65 ("drm/sched: Rename drm_sched_free_job_queue to be more descriptive") e608d9f7ac1a ("drm/sched: Move free worker re-queuing out of the if block") 7abbbe2694b3 ("drm/sched: Rename drm_sched_get_cleanup_job to be more descriptive") f7fe64ad0f22 ("drm/sched: Split free_job into own work item") a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue rather than kthread") 35963cf2cd25 ("drm/sched: Add drm_sched_wqueue_* helpers") 0da611a87021 ("dma-buf: add dma_fence_timestamp helper") 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") 7b05a7c0c9ca ("drm/nouveau: get vmm via nouveau_cli_vmm()") e02238990b1a ("drm/nouveau: new VM_BIND uAPI interfaces") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 Mon Sep 17 00:00:00 2001 From: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Date: Tue, 24 Sep 2024 11:19:09 +0100 Subject: [PATCH] drm/sched: Always increment correct scheduler score MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Entities run queue can change during drm_sched_entity_push_job() so make sure to update the score consistently. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: d41a39dda140 ("drm/scheduler: improve job distribution with multiple queues") Cc: Nirmoy Das <nirmoy.das(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Luben Tuikov <ltuikov89(a)gmail.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.9+ Reviewed-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-4-tursuli… Signed-off-by: Christian König <christian.koenig(a)amd.com> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index a75eede8bf8d..b2cf3e0c1838 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -586,7 +586,6 @@ void drm_sched_entity_push_job(struct drm_sched_job *sched_job) ktime_t submit_ts; trace_drm_sched_job(sched_job, entity); - atomic_inc(entity->rq->sched->score); WRITE_ONCE(entity->last_user, current->group_leader); /* @@ -614,6 +613,7 @@ void drm_sched_entity_push_job(struct drm_sched_job *sched_job) rq = entity->rq; sched = rq->sched; + atomic_inc(sched->score); drm_sched_rq_add_entity(rq, entity); spin_unlock(&entity->rq_lock);

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024