December 2024 - Linux-stable-mirror

[PATCH] crypto: qce - fix priority to be less than ARMv8 CE

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> As QCE is an order of magnitude slower than the ARMv8 Crypto Extensions on the CPU, and is also less well tested, give it a lower priority. Previously the QCE SHA algorithms had higher priority than the ARMv8 CE equivalents, and the ciphers such as AES-XTS had the same priority which meant the QCE versions were chosen if they happened to be loaded later. Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Cc: stable(a)vger.kernel.org Cc: Bartosz Golaszewski <brgl(a)bgdev.pl> Cc: Neil Armstrong <neil.armstrong(a)linaro.org> Cc: Thara Gopinath <thara.gopinath(a)gmail.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- drivers/crypto/qce/aead.c | 2 +- drivers/crypto/qce/sha.c | 2 +- drivers/crypto/qce/skcipher.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/qce/aead.c b/drivers/crypto/qce/aead.c index 7d811728f047..97b56e92ea33 100644 --- a/drivers/crypto/qce/aead.c +++ b/drivers/crypto/qce/aead.c @@ -784,11 +784,11 @@ static int qce_aead_register_one(const struct qce_aead_def *def, struct qce_devi alg->encrypt = qce_aead_encrypt; alg->decrypt = qce_aead_decrypt; alg->init = qce_aead_init; alg->exit = qce_aead_exit; - alg->base.cra_priority = 300; + alg->base.cra_priority = 275; alg->base.cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_NEED_FALLBACK; alg->base.cra_ctxsize = sizeof(struct qce_aead_ctx); diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c index fc72af8aa9a7..71b748183cfa 100644 --- a/drivers/crypto/qce/sha.c +++ b/drivers/crypto/qce/sha.c @@ -480,11 +480,11 @@ static int qce_ahash_register_one(const struct qce_ahash_def *def, else if (IS_SHA256(def->flags)) tmpl->hash_zero = sha256_zero_message_hash; base = &alg->halg.base; base->cra_blocksize = def->blocksize; - base->cra_priority = 300; + base->cra_priority = 175; base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY; base->cra_ctxsize = sizeof(struct qce_sha_ctx); base->cra_alignmask = 0; base->cra_module = THIS_MODULE; base->cra_init = qce_ahash_cra_init; diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c index 5b493fdc1e74..ffb334eb5b34 100644 --- a/drivers/crypto/qce/skcipher.c +++ b/drivers/crypto/qce/skcipher.c @@ -459,11 +459,11 @@ static int qce_skcipher_register_one(const struct qce_skcipher_def *def, IS_DES(def->flags) ? qce_des_setkey : qce_skcipher_setkey; alg->encrypt = qce_skcipher_encrypt; alg->decrypt = qce_skcipher_decrypt; - alg->base.cra_priority = 300; + alg->base.cra_priority = 275; alg->base.cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY; alg->base.cra_ctxsize = sizeof(struct qce_cipher_ctx); alg->base.cra_alignmask = 0; base-commit: ceb8bf2ceaa77fe222fe8fe32cb7789c9099ddf1 -- 2.47.1

10 months, 4 weeks

3
2
0 0

Re: kernel v6.7 warn in add_uevent_var: buffer size too small

by Greg KH

On Wed, Dec 04, 2024 at 05:29:26PM +0800, wzs wrote: > Hello, > when fuzzing the Linux kernel 6.7.0, > the following crash was triggered. > > kernel config : https://pastebin.com/3JeQFdUr > console output : https://pastebin.com/9ADtBQtP > > Basically, we use gadget module to simulate the connection and interaction > process of a USB device > (device type code : 0003, vendor id : 046D, product id : C312, serial > number : 27B4, with function : input event). > > It seems to be caused by a mismatch between the uevent's environmental > limit and the buffer size used to receive the uevent, which triggers such > kernel warning. > > The crash report is as follow: > 、、、 > [203835.102225] input: wingfuz Keyboard as > /devices/platform/dummy_hcd.0/usb3/3-1/3-1:1.0/0003:046D:C312.27B4/input/input5893 > [203835.155527] ------------[ cut here ]------------ > [203835.155533] add_uevent_var: buffer size too small > [203835.162092] WARNING: CPU: 11 PID: 57434 at lib/kobject_uevent.c:671 > add_uevent_var+0x2fe/0x390 I think this is already fixed in newer kernel versions. 6.7.0 is very old and obsolete. Can you test this on 6.12.1? thanks, greg k-h

10 months, 4 weeks

1
0
0 0

[PATCH 0/6] rtc: Fix problems with missing UIE irqs

by Esben Haabendal

This fixes a couple of different problems, that can cause RTC (alarm) irqs to be missing when generating UIE interrupts. The first commit fixes a long-standing problem, which has been documented in a comment since 2010. This fixes a race that could cause UIE irqs to stop being generated, which was easily reproduced by timing the use of RTC_UIE_ON ioctl with the seconds tick in the RTC. The last commit ensures that RTC (alarm) irqs are enabled whenever RTC_UIE_ON ioctl is used. The driver specific commits avoids kernel warnings about unbalanced enable_irq/disable_irq, which gets triggered on first RTC_UIE_ON with the last commit. Before this series, the same warning should be seen on initial RTC_AIE_ON with those drivers. Signed-off-by: Esben Haabendal <esben(a)geanix.com> --- Esben Haabendal (6): rtc: interface: Fix long-standing race when setting alarm rtc: isl12022: Fix initial enable_irq/disable_irq balance rtc: cpcap: Fix initial enable_irq/disable_irq balance rtc: st-lpc: Fix initial enable_irq/disable_irq balance rtc: tps6586x: Fix initial enable_irq/disable_irq balance rtc: interface: Ensure alarm irq is enabled when UIE is enabled drivers/rtc/interface.c | 27 +++++++++++++++++++++++++++ drivers/rtc/rtc-cpcap.c | 1 + drivers/rtc/rtc-isl12022.c | 1 + drivers/rtc/rtc-st-lpc.c | 1 + drivers/rtc/rtc-tps6586x.c | 1 + 5 files changed, 31 insertions(+) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241203-rtc-uie-irq-fixes-f2838782d0f8 Best regards, -- Esben Haabendal <esben(a)geanix.com>

10 months, 4 weeks

1
3
0 0

[PATCH v2 5.15] tty: n_gsm: Fix use-after-free in gsm_cleanup_mux

by mingli.yu＠eng.windriver.com

From: Longlong Xia <xialonglong(a)kylinos.cn> commit 9462f4ca56e7d2430fdb6dcc8498244acbfc4489 upstream. BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock. Signed-off-by: Longlong Xia <xialonglong(a)kylinos.cn> Cc: stable <stable(a)kernel.org> Suggested-by: Jiri Slaby <jirislaby(a)kernel.org> Link: https://lore.kernel.org/r/20240926130213.531959-1-xialonglong@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Mingli: Backport to fix CVE-2024-50073, no guard macro defined resolution] Signed-off-by: Mingli Yu <mingli.yu(a)windriver.com> --- drivers/tty/n_gsm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index aae9f73585bd..1becbdf7c470 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2443,6 +2443,7 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc) int i; struct gsm_dlci *dlci; struct gsm_msg *txq, *ntxq; + unsigned long flags; gsm->dead = true; mutex_lock(&gsm->mutex); @@ -2471,9 +2472,12 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc) mutex_unlock(&gsm->mutex); /* Now wipe the queues */ tty_ldisc_flush(gsm->tty); + + spin_lock_irqsave(&gsm->tx_lock, flags); list_for_each_entry_safe(txq, ntxq, &gsm->tx_list, list) kfree(txq); INIT_LIST_HEAD(&gsm->tx_list); + spin_unlock_irqrestore(&gsm->tx_lock, flags); } /** -- 2.34.1

10 months, 4 weeks

4
4
0 0

[PATCH net] net :mana :Request a V2 response version for MANA_QUERY_GF_STAT

by Shradha Gupta

The current requested response version(V1) for MANA_QUERY_GF_STAT query results in STATISTICS_FLAGS_TX_ERRORS_GDMA_ERROR value being set to 0 always. In order to get the correct value for this counter we request the response version to be V2. Cc: stable(a)vger.kernel.org Fixes: e1df5202e879 ("net :mana :Add remaining GDMA stats for MANA to ethtool") Signed-off-by: Shradha Gupta <shradhagupta(a)linux.microsoft.com> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 57ac732e7707..f73848a4feb3 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -2536,6 +2536,7 @@ void mana_query_gf_stats(struct mana_port_context *apc) mana_gd_init_req_hdr(&req.hdr, MANA_QUERY_GF_STAT, sizeof(req), sizeof(resp)); + req.hdr.resp.msg_version = GDMA_MESSAGE_V2; req.req_stats = STATISTICS_FLAGS_RX_DISCARDS_NO_WQE | STATISTICS_FLAGS_RX_ERRORS_VPORT_DISABLED | STATISTICS_FLAGS_HC_RX_BYTES | -- 2.43.0

11 months

1
0
0 0

Re: [PATCH] riscv: Fix vector state restore in rt_sigreturn()

by Yangyu Chen

I think this patch should also be backported to the v6.6 LTS tree. Since it should recolonize as Fixes: 8ee0b41898 ("riscv: signal: Add sigcontext save/restore for vector") and that commit first appears since v6.5-rc1 and this patch land to master branch since v6.9-rc3 Thanks, Yangyu Chen On 4/3/24 15:26, Björn Töpel wrote: > From: Björn Töpel <bjorn(a)rivosinc.com> > The RISC-V Vector specification states in "Appendix D: Calling > Convention for Vector State" [1] that "Executing a system call causes > all caller-saved vector registers (v0-v31, vl, vtype) and vstart to > become unspecified.". In the RISC-V kernel this is called "discarding > the vstate". > Returning from a signal handler via the rt_sigreturn() syscall, vector > discard is also performed. However, this is not an issue since the > vector state should be restored from the sigcontext, and therefore not > care about the vector discard. > The "live state" is the actual vector register in the running context, > and the "vstate" is the vector state of the task. A dirty live state, > means that the vstate and live state are not in synch. > When vectorized user_from_copy() was introduced, an bug sneaked in at > the restoration code, related to the discard of the live state. > An example when this go wrong: > 1. A userland application is executing vector code > 2. The application receives a signal, and the signal handler is > entered. > 3. The application returns from the signal handler, using the > rt_sigreturn() syscall. > 4. The live vector state is discarded upon entering the > rt_sigreturn(), and the live state is marked as "dirty", indicating > that the live state need to be synchronized with the current > vstate. > 5. rt_sigreturn() restores the vstate, except the Vector registers, > from the sigcontext > 6. rt_sigreturn() restores the Vector registers, from the sigcontext, > and now the vectorized user_from_copy() is used. The dirty live > state from the discard is saved to the vstate, making the vstate > corrupt. > 7. rt_sigreturn() returns to the application, which crashes due to > corrupted vstate. > Note that the vectorized user_from_copy() is invoked depending on the > value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which > means that vlen has to be larger than 128b for this bug to trigger. > The fix is simply to mark the live state as non-dirty/clean prior > performing the vstate restore. > Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-relea… # [1] > Reported-by: Charlie Jenkins <charlie(a)rivosinc.com> > Reported-by: Vineet Gupta <vgupta(a)kernel.org> > Fixes: c2a658d41924 ("riscv: lib: vectorize copy_to_user/copy_from_user") > Signed-off-by: Björn Töpel <bjorn(a)rivosinc.com> > --- > arch/riscv/kernel/signal.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c > index 501e66debf69..5a2edd7f027e 100644 > --- a/arch/riscv/kernel/signal.c > +++ b/arch/riscv/kernel/signal.c > @@ -119,6 +119,13 @@ static long __restore_v_state(struct pt_regs *regs, void __user *sc_vec) > struct __sc_riscv_v_state __user *state = sc_vec; > void __user *datap; > + /* > + * Mark the vstate as clean prior performing the actual copy, > + * to avoid getting the vstate incorrectly clobbered by the > + * discarded vector state. > + */ > + riscv_v_vstate_set_restore(current, regs); > + > /* Copy everything of __sc_riscv_v_state except datap. */ > err = __copy_from_user(&current->thread.vstate, &state->v_state, > offsetof(struct __riscv_v_ext_state, datap)); > @@ -133,13 +140,7 @@ static long __restore_v_state(struct pt_regs *regs, void __user *sc_vec) > * Copy the whole vector content from user space datap. Use > * copy_from_user to prevent information leak. > */ > - err = copy_from_user(current->thread.vstate.datap, datap, riscv_v_vsize); > - if (unlikely(err)) > - return err; > - > - riscv_v_vstate_set_restore(current, regs); > - > - return err; > + return copy_from_user(current->thread.vstate.datap, datap, riscv_v_vsize); > } > #else > #define save_v_state(task, regs) (0) > base-commit: 7115ff4a8bfed3b9294bad2e111744e6abeadf1a

11 months

1
0
0 0

[PATCH net-next v2 0/5] virtio_net: correct netdev_tx_reset_queue() invocation points

by Koichiro Den

When virtnet_close is followed by virtnet_open, some TX completions can possibly remain unconsumed, until they are finally processed during the first NAPI poll after the netdev_tx_reset_queue(), resulting in a crash [1]. Commit b96ed2c97c79 ("virtio_net: move netdev_tx_reset_queue() call before RX napi enable") was not sufficient to eliminate all BQL crash cases for virtio-net. This issue can be reproduced with the latest net-next master by running: `while :; do ip l set DEV down; ip l set DEV up; done` under heavy network TX load from inside the machine. This patch series resolves the issue and also addresses similar existing problems: (a). Drop netdev_tx_reset_queue() from open/close path. This eliminates the BQL crashes due to the problematic open/close path. (b). As a result of (a), netdev_tx_reset_queue() is now explicitly required in freeze/restore path. Add netdev_tx_reset_queue() to free_unused_bufs(). (c). Fix missing resetting in virtnet_tx_resize(). virtnet_tx_resize() has lacked proper resetting since commit c8bd1f7f3e61 ("virtio_net: add support for Byte Queue Limits"). (d). Fix missing resetting in the XDP_SETUP_XSK_POOL path. Similar to (c), this path lacked proper resetting. Call netdev_tx_reset_queue() when virtqueue_reset() has actually recycled unused buffers. This patch series consists of five commits: [1/5]: Resolves (a) and (b). [2/5]: Prerequisite for (c). [3/5]: Resolves (c). [4/5]: Preresuisite for (d). [5/5]: Resolves (d). Changes for v2: - add tx queue resetting for (b) to (d) above v1: https://lore.kernel.org/all/20241130181744.3772632-1-koichiro.den@canonical… [1]: ------------[ cut here ]------------ kernel BUG at lib/dynamic_queue_limits.c:99! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G N 6.12.0net-next_main+ #2 Tainted: [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), \ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 Code: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff <0f> 0b 01 d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009 RDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000 RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001 R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40 FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <IRQ> ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? dql_completed+0x26b/0x290 ? exc_invalid_op+0x4c/0x60 ? dql_completed+0x26b/0x290 ? asm_exc_invalid_op+0x16/0x20 ? dql_completed+0x26b/0x290 __free_old_xmit+0xff/0x170 [virtio_net] free_old_xmit+0x54/0xc0 [virtio_net] virtnet_poll+0xf4/0xe30 [virtio_net] ? __update_load_avg_cfs_rq+0x264/0x2d0 ? update_curr+0x35/0x260 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? sched_clock_cpu+0xd/0x1a0 handle_softirqs+0x138/0x3e0 do_softirq.part.0+0x89/0xc0 </IRQ> <TASK> __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicast+0x23e/0x390 ? netlink_sendmsg+0x21e/0x490 ? ____sys_sendmsg+0x31b/0x350 ? avc_has_perm_noaudit+0x67/0xf0 ? cred_has_capability.isra.0+0x75/0x110 ? __nla_validate_parse+0x5f/0xee0 ? __pfx___probestub_irq_enable+0x3/0x10 ? __create_object+0x5e/0x90 ? security_capable+0x3b/0x7[I0 rtnl_newlink+0x784/0xaf0 ? avc_has_perm_noaudit+0x67/0xf0 ? cred_has_capability.isra.0+0x75/0x110 ? stack_depot_save_flags+0x24/0x6d0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x34f/0x3f0 ? do_syscall_64+0x6c/0x180 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 netlink_unicast+0x23e/0x390 netlink_sendmsg+0x21e/0x490 ____sys_sendmsg+0x31b/0x350 ? copy_msghdr_from_user+0x6d/0xa0 ___sys_sendmsg+0x86/0xd0 ? __pte_offset_map+0x17/0x160 ? preempt_count_add+0x69/0xa0 ? __call_rcu_common.constprop.0+0x147/0x610 ? preempt_count_add+0x69/0xa0 ? preempt_count_add+0x69/0xa0 ? _raw_spin_trylock+0x13/0x60 ? trace_hardirqs_on+0x1d/0x80 __sys_sendmsg+0x66/0xc0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f41defe5b34 Code: 15 e1 12 0f 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d 35 95 0f 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffe5336ecc8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f41defe5b34 RDX: 0000000000000000 RSI: 00007ffe5336ed30 RDI: 0000000000000003 RBP: 00007ffe5336eda0 R08: 0000000000000010 R09: 0000000000000001 R10: 00007ffe5336f6f9 R11: 0000000000000202 R12: 0000000000000003 R13: 0000000067452259 R14: 0000556ccc28b040 R15: 0000000000000000 </TASK> [...] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Koichiro Den (5): virtio_net: correct netdev_tx_reset_queue() invocation point virtio_ring: add 'flushed' as an argument to virtqueue_resize() virtio_net: add missing netdev_tx_reset_queue() to virtnet_tx_resize() virtio_ring: add 'flushed' as an argument to virtqueue_reset() virtio_net: add missing netdev_tx_reset_queue to virtnet_sq_bind_xsk_pool() drivers/net/virtio_net.c | 18 +++++++++++++----- drivers/virtio/virtio_ring.c | 13 +++++++++++-- include/linux/virtio.h | 6 ++++-- 3 files changed, 28 insertions(+), 9 deletions(-) -- 2.43.0

11 months

3
11
0 0

[PATCH] net: wireless: sme: Initialize n_channels before accessing channels in cfg80211_conn_scan

by Haoyu Li

With the new __counted_by annocation in cfg80211_scan_request struct, the "n_channels" struct member must be set before accessing the "channels" array. Failing to do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Signed-off-by: Haoyu Li <lihaoyu499(a)gmail.com> --- net/wireless/sme.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/wireless/sme.c b/net/wireless/sme.c index 431da30817a6..268171600087 100644 --- a/net/wireless/sme.c +++ b/net/wireless/sme.c @@ -83,6 +83,7 @@ static int cfg80211_conn_scan(struct wireless_dev *wdev) if (!request) return -ENOMEM; + request->n_channels = n_channels; if (wdev->conn->params.channel) { enum nl80211_band band = wdev->conn->params.channel->band; struct ieee80211_supported_band *sband = -- 2.34.1

11 months

4
4
0 0

[net] net: Make napi_hash_lock irq safe

by Joe Damato

Make napi_hash_lock IRQ safe. It is used during the control path, and is taken and released in napi_hash_add and napi_hash_del, which will typically be called by calls to napi_enable and napi_disable. This change avoids a deadlock in pcnet32 (and other any other drivers which follow the same pattern): CPU 0: pcnet32_open spin_lock_irqsave(&lp->lock, ...) napi_enable napi_hash_add <- before this executes, CPU 1 proceeds spin_lock(napi_hash_lock) [...] spin_unlock_irqrestore(&lp->lock, flags); CPU 1: pcnet32_close napi_disable napi_hash_del spin_lock(napi_hash_lock) < INTERRUPT > pcnet32_interrupt spin_lock(lp->lock) <- DEADLOCK Changing the napi_hash_lock to be IRQ safe prevents the IRQ from firing on CPU 1 until napi_hash_lock is released, preventing the deadlock. Cc: stable(a)vger.kernel.org Fixes: 86e25f40aa1e ("net: napi: Add napi_config") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Closes: https://lore.kernel.org/netdev/85dd4590-ea6b-427d-876a-1d8559c7ad82@roeck-u… Suggested-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Joe Damato <jdamato(a)fastly.com> --- net/core/dev.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 13d00fc10f55..45a8c3dd4a64 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6557,18 +6557,22 @@ static void __napi_hash_add_with_id(struct napi_struct *napi, static void napi_hash_add_with_id(struct napi_struct *napi, unsigned int napi_id) { - spin_lock(&napi_hash_lock); + unsigned long flags; + + spin_lock_irqsave(&napi_hash_lock, flags); WARN_ON_ONCE(napi_by_id(napi_id)); __napi_hash_add_with_id(napi, napi_id); - spin_unlock(&napi_hash_lock); + spin_unlock_irqrestore(&napi_hash_lock, flags); } static void napi_hash_add(struct napi_struct *napi) { + unsigned long flags; + if (test_bit(NAPI_STATE_NO_BUSY_POLL, &napi->state)) return; - spin_lock(&napi_hash_lock); + spin_lock_irqsave(&napi_hash_lock, flags); /* 0..NR_CPUS range is reserved for sender_cpu use */ do { @@ -6578,7 +6582,7 @@ static void napi_hash_add(struct napi_struct *napi) __napi_hash_add_with_id(napi, napi_gen_id); - spin_unlock(&napi_hash_lock); + spin_unlock_irqrestore(&napi_hash_lock, flags); } /* Warning : caller is responsible to make sure rcu grace period @@ -6586,11 +6590,13 @@ static void napi_hash_add(struct napi_struct *napi) */ static void napi_hash_del(struct napi_struct *napi) { - spin_lock(&napi_hash_lock); + unsigned long flags; + + spin_lock_irqsave(&napi_hash_lock, flags); hlist_del_init_rcu(&napi->napi_hash_node); - spin_unlock(&napi_hash_lock); + spin_unlock_irqrestore(&napi_hash_lock, flags); } static enum hrtimer_restart napi_watchdog(struct hrtimer *timer) -- 2.25.1

11 months

4
3
0 0

[PATCH] dt-bindings: soc: fsl: cpm_qe: Limit matching to nodes with "fsl,qe"

by Chen-Yu Tsai

Otherwise the binding matches against random nodes with "simple-bus" giving out all kinds of invalid warnings: $ make CHECK_DTBS=y mediatek/mt8188-evb.dtb SYNC include/config/auto.conf.cmd UPD include/config/kernel.release SCHEMA Documentation/devicetree/bindings/processed-schema.json DTC [C] arch/arm64/boot/dts/mediatek/mt8188-evb.dtb arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: compatible:0: 'fsl,qe' was expected from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: compatible: ['simple-bus'] is too short from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000:compatible:0: 'fsl,qe-ic' was expected from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000:reg: [[0, 201326592, 0, 262144], [0, 201588736, 0, 2097152]] is too long from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000:#interrupt-cells:0:0: 1 was expected from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000: '#redistributor-regions', 'ppi-partitions' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: 'reg' is a required property from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: 'bus-frequency' is a required property from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# Fixes: ecbfc6ff94a2 ("dt-bindings: soc: fsl: cpm_qe: convert to yaml format") Cc: Frank Li <Frank.Li(a)nxp.com> Cc: <stable(a)vger.kernel.org> # v6.11+ Signed-off-by: Chen-Yu Tsai <wenst(a)chromium.org> --- .../devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml index 89cdf5e1d0a8..9e07a2c4d05b 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml @@ -21,6 +21,14 @@ description: | The description below applies to the qe of MPC8360 and more nodes and properties would be extended in the future. +select: + properties: + compatible: + contains: + const: fsl,qe + required: + - compatible + properties: compatible: items: -- 2.47.0.338.g60cca15819-goog

11 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024