April 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] virtio_net: Do not send RSS key if it is not supported" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 059a49aa2e25c58f90b50151f109dd3c4cdb3a47 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024041412-subduing-brewing-cd04@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 059a49aa2e25 ("virtio_net: Do not send RSS key if it is not supported") fb6e30a72539 ("net: ethtool: pass a pointer to parameters to get/set_rxfh ethtool ops") 02cbfba1add5 ("idpf: add ethtool callbacks") a5ab9ee0df0b ("idpf: add singleq start_xmit and napi poll") 3a8845af66ed ("idpf: add RX splitq napi poll support") c2d548cad150 ("idpf: add TX splitq napi poll support") 6818c4d5b3c2 ("idpf: add splitq start_xmit") d4d558718266 ("idpf: initialize interrupts and enable vport") 95af467d9a4e ("idpf: configure resources for RX queues") 1c325aac10a8 ("idpf: configure resources for TX queues") ce1b75d0635c ("idpf: add ptypes and MAC filter support") 0fe45467a104 ("idpf: add create vport and netdev configuration") 4930fbf419a7 ("idpf: add core init and interrupt request") 8077c727561a ("idpf: add controlq init and reset checks") e850efed5e15 ("idpf: add module register and probe functionality") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 059a49aa2e25c58f90b50151f109dd3c4cdb3a47 Mon Sep 17 00:00:00 2001 From: Breno Leitao <leitao(a)debian.org> Date: Wed, 3 Apr 2024 08:43:12 -0700 Subject: [PATCH] virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device. Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") Cc: stable(a)vger.kernel.org Cc: qemu-devel(a)nongnu.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Heng Qi <hengqi(a)linux.alibaba.com> Reviewed-by: Xuan Zhuo <xuanzhuo(a)linux.alibaba.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index c22d1118a133..115c3c5414f2 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -3807,6 +3807,7 @@ static int virtnet_set_rxfh(struct net_device *dev, struct netlink_ext_ack *extack) { struct virtnet_info *vi = netdev_priv(dev); + bool update = false; int i; if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE && @@ -3814,13 +3815,28 @@ static int virtnet_set_rxfh(struct net_device *dev, return -EOPNOTSUPP; if (rxfh->indir) { + if (!vi->has_rss) + return -EOPNOTSUPP; + for (i = 0; i < vi->rss_indir_table_size; ++i) vi->ctrl->rss.indirection_table[i] = rxfh->indir[i]; + update = true; } - if (rxfh->key) - memcpy(vi->ctrl->rss.key, rxfh->key, vi->rss_key_size); - virtnet_commit_rss_command(vi); + if (rxfh->key) { + /* If either _F_HASH_REPORT or _F_RSS are negotiated, the + * device provides hash calculation capabilities, that is, + * hash_key is configured. + */ + if (!vi->has_rss && !vi->has_rss_hash_report) + return -EOPNOTSUPP; + + memcpy(vi->ctrl->rss.key, rxfh->key, vi->rss_key_size); + update = true; + } + + if (update) + virtnet_commit_rss_command(vi); return 0; } @@ -4729,13 +4745,15 @@ static int virtnet_probe(struct virtio_device *vdev) if (virtio_has_feature(vdev, VIRTIO_NET_F_HASH_REPORT)) vi->has_rss_hash_report = true; - if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS)) + if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS)) { vi->has_rss = true; - if (vi->has_rss || vi->has_rss_hash_report) { vi->rss_indir_table_size = virtio_cread16(vdev, offsetof(struct virtio_net_config, rss_max_indirection_table_length)); + } + + if (vi->has_rss || vi->has_rss_hash_report) { vi->rss_key_size = virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));

8 months, 2 weeks

3
2
0 0

[PATCH 0/4] Please apply these MT7530 DSA subdriver patches to 6.1

by Arınç ÜNAL via B4 Relay

Hello. These are the remaining bugfix patches for the MT7530 DSA subdriver. They didn't apply as is to the 6.1 stable tree so I have submitted the adjusted versions in this thread. Please apply them in the order they were submitted. Signed-off-by: Arınç ÜNAL <arinc.unal(a)arinc9.com> --- Arınç ÜNAL (3): net: dsa: mt7530: set all CPU ports in MT7531_CPU_PMAP net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530 net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards Vladimir Oltean (1): net: dsa: introduce preferred_default_local_cpu_port and use on MT7530 drivers/net/dsa/mt7530.c | 52 ++++++++++++++++++++++++++++++++++-------------- drivers/net/dsa/mt7530.h | 2 ++ include/net/dsa.h | 8 ++++++++ net/dsa/dsa2.c | 24 +++++++++++++++++++++- 4 files changed, 70 insertions(+), 16 deletions(-) --- base-commit: 6741e066ec7633450d3186946035c1f80c4226b8 change-id: 20240420-for-stable-6-1-backports-54c939276879 Best regards, -- Arınç ÜNAL <arinc.unal(a)arinc9.com>

8 months, 2 weeks

2
5
0 0

[PATCH 0/2] Please apply these MT7530 DSA subdriver patches to 6.8

by Arınç ÜNAL via B4 Relay

Hello. These are the remaining bugfix patches for the MT7530 DSA subdriver. They didn't apply as is to the 6.8 stable tree so I have submitted the adjusted versions in this thread. Please apply them in the order they were submitted. Signed-off-by: Arınç ÜNAL <arinc.unal(a)arinc9.com> --- Arınç ÜNAL (2): net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530 net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards drivers/net/dsa/mt7530.c | 22 +++++++++++++++------- drivers/net/dsa/mt7530.h | 1 + 2 files changed, 16 insertions(+), 7 deletions(-) --- base-commit: 12dadc409c2bd8538c6ee0e56e191efde6d92007 change-id: 20240420-for-stable-6-8-backports-5a210f6cfb0c Best regards, -- Arınç ÜNAL <arinc.unal(a)arinc9.com>

8 months, 2 weeks

3
4
0 0

FAILED: patch "[PATCH] random: handle creditable entropy from atomic process context" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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-4.19.y git checkout FETCH_HEAD git cherry-pick -x e871abcda3b67d0820b4182ebe93435624e9c6a4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024041908-ethically-floss-e1ea@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: e871abcda3b6 ("random: handle creditable entropy from atomic process context") bbc7e1bed1f5 ("random: add back async readiness notifier") 9148de3196ed ("random: reseed in delayed work rather than on-demand") f62384995e4c ("random: split initialization into early step and later step") 745558f95885 ("random: use hwgenerator randomness more frequently at early boot") 228dfe98a313 ("Merge tag 'char-misc-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e871abcda3b67d0820b4182ebe93435624e9c6a4 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Wed, 17 Apr 2024 13:38:29 +0200 Subject: [PATCH] random: handle creditable entropy from atomic process context The entropy accounting changes a static key when the RNG has initialized, since it only ever initializes once. Static key changes, however, cannot be made from atomic context, so depending on where the last creditable entropy comes from, the static key change might need to be deferred to a worker. Previously the code used the execute_in_process_context() helper function, which accounts for whether or not the caller is in_interrupt(). However, that doesn't account for the case where the caller is actually in process context but is holding a spinlock. This turned out to be the case with input_handle_event() in drivers/input/input.c contributing entropy: [<ffffffd613025ba0>] die+0xa8/0x2fc [<ffffffd613027428>] bug_handler+0x44/0xec [<ffffffd613016964>] brk_handler+0x90/0x144 [<ffffffd613041e58>] do_debug_exception+0xa0/0x148 [<ffffffd61400c208>] el1_dbg+0x60/0x7c [<ffffffd61400c000>] el1h_64_sync_handler+0x38/0x90 [<ffffffd613011294>] el1h_64_sync+0x64/0x6c [<ffffffd613102d88>] __might_resched+0x1fc/0x2e8 [<ffffffd613102b54>] __might_sleep+0x44/0x7c [<ffffffd6130b6eac>] cpus_read_lock+0x1c/0xec [<ffffffd6132c2820>] static_key_enable+0x14/0x38 [<ffffffd61400ac08>] crng_set_ready+0x14/0x28 [<ffffffd6130df4dc>] execute_in_process_context+0xb8/0xf8 [<ffffffd61400ab30>] _credit_init_bits+0x118/0x1dc [<ffffffd6138580c8>] add_timer_randomness+0x264/0x270 [<ffffffd613857e54>] add_input_randomness+0x38/0x48 [<ffffffd613a80f94>] input_handle_event+0x2b8/0x490 [<ffffffd613a81310>] input_event+0x6c/0x98 According to Guoyong, it's not really possible to refactor the various drivers to never hold a spinlock there. And in_atomic() isn't reliable. So, rather than trying to be too fancy, just punt the change in the static key to a workqueue always. There's basically no drawback of doing this, as the code already needed to account for the static key not changing immediately, and given that it's just an optimization, there's not exactly a hurry to change the static key right away, so deferal is fine. Reported-by: Guoyong Wang <guoyong.wang(a)mediatek.com> Cc: stable(a)vger.kernel.org Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> diff --git a/drivers/char/random.c b/drivers/char/random.c index 456be28ba67c..2597cb43f438 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -702,7 +702,7 @@ static void extract_entropy(void *buf, size_t len) static void __cold _credit_init_bits(size_t bits) { - static struct execute_work set_ready; + static DECLARE_WORK(set_ready, crng_set_ready); unsigned int new, orig, add; unsigned long flags; @@ -718,8 +718,8 @@ static void __cold _credit_init_bits(size_t bits) if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { crng_reseed(NULL); /* Sets crng_init to CRNG_READY under base_crng.lock. */ - if (static_key_initialized) - execute_in_process_context(crng_set_ready, &set_ready); + if (static_key_initialized && system_unbound_wq) + queue_work(system_unbound_wq, &set_ready); atomic_notifier_call_chain(&random_ready_notifier, 0, NULL); wake_up_interruptible(&crng_init_wait); kill_fasync(&fasync, SIGIO, POLL_IN); @@ -890,8 +890,8 @@ void __init random_init(void) /* * If we were initialized by the cpu or bootloader before jump labels - * are initialized, then we should enable the static branch here, where - * it's guaranteed that jump labels have been initialized. + * or workqueues are initialized, then we should enable the static + * branch here, where it's guaranteed that these have been initialized. */ if (!static_branch_likely(&crng_is_ready) && crng_init >= CRNG_READY) crng_set_ready(NULL);

8 months, 2 weeks

3
2
0 0

[PATCH] workqueue: Fix divide error in wq_update_node_max_active()

by Lai Jiangshan

From: Lai Jiangshan <jiangshan.ljs(a)antgroup.com> Yue Sun and xingwei lee reported a divide error bug in wq_update_node_max_active(): divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 21 Comm: cpuhp/1 Not tainted 6.9.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:wq_update_node_max_active+0x369/0x6b0 kernel/workqueue.c:1605 Code: 24 bf 00 00 00 80 44 89 fe e8 83 27 33 00 41 83 fc ff 75 0d 41 81 ff 00 00 00 80 0f 84 68 01 00 00 e8 fb 22 33 00 44 89 f8 99 <41> f7 fc 89 c5 89 c7 44 89 ee e8 a8 24 33 00 89 ef 8b 5c 24 04 89 RSP: 0018:ffffc9000018fbb0 EFLAGS: 00010293 RAX: 00000000000000ff RBX: 0000000000000001 RCX: ffff888100ada500 RDX: 0000000000000000 RSI: 00000000000000ff RDI: 0000000080000000 RBP: 0000000000000001 R08: ffffffff815b1fcd R09: 1ffff1100364ad72 R10: dffffc0000000000 R11: ffffed100364ad73 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000000 R15: 00000000000000ff FS: 0000000000000000(0000) GS:ffff888135c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb8c06ca6f8 CR3: 000000010d6c6000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> workqueue_offline_cpu+0x56f/0x600 kernel/workqueue.c:6525 cpuhp_invoke_callback+0x4e1/0x870 kernel/cpu.c:194 cpuhp_thread_fun+0x411/0x7d0 kernel/cpu.c:1092 smpboot_thread_fn+0x544/0xa10 kernel/smpboot.c:164 kthread+0x2ed/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- After analysis, it happens when all of the CPUs in a workqueue's affinity get offine. The problem can be easily reproduced by: # echo 8 > /sys/devices/virtual/workqueue/<any-wq-name>/cpumask # echo 0 > /sys/devices/system/cpu/cpu3/online Force the calculation of total_cpus which is used to be the divisor to be at least 1 to fix the problem. Link: https://lore.kernel.org/lkml/CAEkJfYPGS1_4JqvpSo0=FM0S1ytB8CEbyreLTtWpR900d… Cc: stable(a)vger.kernel.org Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues") Reported-by: Yue Sun <samsun1006219(a)gmail.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Signed-off-by: Lai Jiangshan <jiangshan.ljs(a)antgroup.com> --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 0066c8f6c154..b31cd7faeb9f 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1591,7 +1591,7 @@ static void wq_update_node_max_active(struct workqueue_struct *wq, int off_cpu) off_cpu = -1; total_cpus = cpumask_weight_and(effective, cpu_online_mask); - if (off_cpu >= 0) + if (off_cpu >= 0 && total_cpus > 1) total_cpus--; for_each_node(node) { -- 2.19.1.6.gb485710b

8 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] serial: stm32: Return IRQ_NONE in the ISR if no handling" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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.15.y git checkout FETCH_HEAD git cherry-pick -x 13c785323b36b845300b256d0e5963c3727667d7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024042344-phonics-simile-0b3c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 13c785323b36 ("serial: stm32: Return IRQ_NONE in the ISR if no handling happend") c5d06662551c ("serial: stm32: Use port lock wrappers") a01ae50d7eae ("serial: stm32: replace access to DMAR bit by dmaengine_pause/resume") 7f28bcea824e ("serial: stm32: group dma pause/resume error handling into single function") 00d1f9c6af0d ("serial: stm32: modify parameter and rename stm32_usart_rx_dma_enabled") db89728abad5 ("serial: stm32: avoid clearing DMAT bit during transfer") 3f6c02fa712b ("serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler") d7c76716169d ("serial: stm32: Use TC interrupt to deassert GPIO RTS in RS485 mode") 3bcea529b295 ("serial: stm32: Factor out GPIO RTS toggling into separate function") 037b91ec7729 ("serial: stm32: fix software flow control transfer") d3d079bde07e ("serial: stm32: prevent TDR register overwrite when sending x_char") 195437d14fb4 ("serial: stm32: correct loop for dma error handling") 2a3bcfe03725 ("serial: stm32: fix flow control transfer in DMA mode") 9a135f16d228 ("serial: stm32: rework TX DMA state condition") 56a23f9319e8 ("serial: stm32: move tx dma terminate DMA to shutdown") 6333a4850621 ("serial: stm32: push DMA RX data before suspending") 6eeb348c8482 ("serial: stm32: terminate / restart DMA transfer at suspend / resume") e0abc903deea ("serial: stm32: rework RX dma initialization and release") d1ec8a2eabe9 ("serial: stm32: update throttle and unthrottle ops for dma mode") 33bb2f6ac308 ("serial: stm32: rework RX over DMA") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 13c785323b36b845300b256d0e5963c3727667d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de> Date: Wed, 17 Apr 2024 11:03:27 +0200 Subject: [PATCH] serial: stm32: Return IRQ_NONE in the ISR if no handling happend MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If there is a stuck irq that the handler doesn't address, returning IRQ_HANDLED unconditionally makes it impossible for the irq core to detect the problem and disable the irq. So only return IRQ_HANDLED if an event was handled. A stuck irq is still problematic, but with this change at least it only makes the UART nonfunctional instead of occupying the (usually only) CPU by 100% and so stall the whole machine. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Link: https://lore.kernel.org/r/5f92603d0dfd8a5b8014b2b10a902d91e0bb881f.17133441… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c index 58d169e5c1db..d60cbac69194 100644 --- a/drivers/tty/serial/stm32-usart.c +++ b/drivers/tty/serial/stm32-usart.c @@ -861,6 +861,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs; u32 sr; unsigned int size; + irqreturn_t ret = IRQ_NONE; sr = readl_relaxed(port->membase + ofs->isr); @@ -869,11 +870,14 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) (sr & USART_SR_TC)) { stm32_usart_tc_interrupt_disable(port); stm32_usart_rs485_rts_disable(port); + ret = IRQ_HANDLED; } - if ((sr & USART_SR_RTOF) && ofs->icr != UNDEF_REG) + if ((sr & USART_SR_RTOF) && ofs->icr != UNDEF_REG) { writel_relaxed(USART_ICR_RTOCF, port->membase + ofs->icr); + ret = IRQ_HANDLED; + } if ((sr & USART_SR_WUF) && ofs->icr != UNDEF_REG) { /* Clear wake up flag and disable wake up interrupt */ @@ -882,6 +886,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_WUFIE); if (irqd_is_wakeup_set(irq_get_irq_data(port->irq))) pm_wakeup_event(tport->tty->dev, 0); + ret = IRQ_HANDLED; } /* @@ -896,6 +901,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) uart_unlock_and_check_sysrq(port); if (size) tty_flip_buffer_push(tport); + ret = IRQ_HANDLED; } } @@ -903,6 +909,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) uart_port_lock(port); stm32_usart_transmit_chars(port); uart_port_unlock(port); + ret = IRQ_HANDLED; } /* Receiver timeout irq for DMA RX */ @@ -912,9 +919,10 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr) uart_unlock_and_check_sysrq(port); if (size) tty_flip_buffer_push(tport); + ret = IRQ_HANDLED; } - return IRQ_HANDLED; + return ret; } static void stm32_usart_set_mctrl(struct uart_port *port, unsigned int mctrl)

8 months, 2 weeks

2
1
0 0

[PATCH v4 2/2] PCI: of: Attach created of_node to existing device

by Herve Codina

The commit 407d1a51921e ("PCI: Create device tree node for bridge") creates of_node for PCI devices. During the insertion handling of these new DT nodes done by of_platform, new devices (struct device) are created. For each PCI devices a struct device is already present (created and handled by the PCI core). Having a second struct device to represent the exact same PCI device is not correct. On the of_node creation: - tell the of_platform that there is no need to create a device for this node (OF_POPULATED flag), - link this newly created of_node to the already present device, - tell fwnode that the device attached to this of_node is ready using fwnode_dev_initialized(). On the of_node removal, revert the operations. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/pci/of.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/pci/of.c b/drivers/pci/of.c index 51e3dd0ea5ab..5afd2731e876 100644 --- a/drivers/pci/of.c +++ b/drivers/pci/of.c @@ -615,7 +615,8 @@ void of_pci_remove_node(struct pci_dev *pdev) np = pci_device_to_OF_node(pdev); if (!np || !of_node_check_flag(np, OF_DYNAMIC)) return; - pdev->dev.of_node = NULL; + + device_remove_of_node(&pdev->dev); of_changeset_revert(np->data); of_changeset_destroy(np->data); @@ -668,12 +669,22 @@ void of_pci_make_dev_node(struct pci_dev *pdev) if (ret) goto out_free_node; + /* + * This of_node will be added to an existing device. + * Avoid any device creation and use the existing device + */ + of_node_set_flag(np, OF_POPULATED); + np->fwnode.dev = &pdev->dev; + fwnode_dev_initialized(&np->fwnode, true); + ret = of_changeset_apply(cset); if (ret) goto out_free_node; np->data = cset; - pdev->dev.of_node = np; + + /* Add the of_node to the existing device */ + device_add_of_node(&pdev->dev, np); kfree(name); return; -- 2.44.0

8 months, 2 weeks

1
0
0 0

[PATCH v4 1/2] driver core: Introduce device_{add,remove}_of_node()

by Herve Codina

An of_node can be set to a device using device_set_node(). This function cannot prevent any of_node and/or fwnode overwrites. When adding an of_node on an already present device, the following operations need to be done: - Attach the of_node if no of_node were already attached - Attach the of_node as a fwnode if no fwnode were already attached This is the purpose of device_add_of_node(). device_remove_of_node() reverts the operations done by device_add_of_node(). Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/base/core.c | 52 ++++++++++++++++++++++++++++++++++++++++++ include/linux/device.h | 2 ++ 2 files changed, 54 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 521757408fc0..098ae335cb0a 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -5127,6 +5127,58 @@ void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode) } EXPORT_SYMBOL_GPL(set_secondary_fwnode); +/** + * device_remove_of_node - Remove an of_node from a device + * @dev: device whose device-tree node is being removed + */ +void device_remove_of_node(struct device *dev) +{ + dev = get_device(dev); + if (!dev) + return; + + if (!dev->of_node) + goto end; + + if (dev->fwnode == of_fwnode_handle(dev->of_node)) + dev->fwnode = NULL; + + of_node_put(dev->of_node); + dev->of_node = NULL; + +end: + put_device(dev); +} +EXPORT_SYMBOL_GPL(device_remove_of_node); + +/** + * device_add_of_node - Add an of_node to an existing device + * @dev: device whose device-tree node is being added + * @of_node: of_node to add + */ +void device_add_of_node(struct device *dev, struct device_node *of_node) +{ + if (!of_node) + return; + + dev = get_device(dev); + if (!dev) + return; + + if (WARN(dev->of_node, "%s: Cannot replace node %pOF with %pOF\n", + dev_name(dev), dev->of_node, of_node)) + goto end; + + dev->of_node = of_node_get(of_node); + + if (!dev->fwnode) + dev->fwnode = of_fwnode_handle(of_node); + +end: + put_device(dev); +} +EXPORT_SYMBOL_GPL(device_add_of_node); + /** * device_set_of_node_from_dev - reuse device-tree node of another device * @dev: device whose device-tree node is being set diff --git a/include/linux/device.h b/include/linux/device.h index 97c4b046c09d..1795121dee9a 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -1127,6 +1127,8 @@ int device_offline(struct device *dev); int device_online(struct device *dev); void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode); void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode); +void device_add_of_node(struct device *dev, struct device_node *of_node); +void device_remove_of_node(struct device *dev); void device_set_of_node_from_dev(struct device *dev, const struct device *dev2); void device_set_node(struct device *dev, struct fwnode_handle *fwnode); -- 2.44.0

8 months, 2 weeks

1
0
0 0

[PATCH] btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks()

by Dominique Martinet

From: Dominique Martinet <dominique.martinet(a)atmark-techno.com> The previous patch forgot to unlock in the error path Link: https://lore.kernel.org/all/Zh%2fHpAGFqa7YAFuM@duo.ucw.cz Reported-by: Pavel Machek <pavel(a)denx.de> Cc: stable(a)vger.kernel.org Fixes: 7411055db5ce ("btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()") Signed-off-by: Dominique Martinet <dominique.martinet(a)atmark-techno.com> --- Note for stable: the mutex has been renamed from delete_unused_bgs_mutex in 5.13, so the 5.10 and 4.19 backports need a trivial rename: s/reclaim_bgs_lock/delete_unused_bgs_mutex/ If required I'll send branch-specific patches after this is merged. --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index f15591f3e54f..ef6bd2f4251b 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -3455,6 +3455,7 @@ static int btrfs_relocate_sys_chunks(struct btrfs_fs_info *fs_info) * alignment and size). */ ret = -EUCLEAN; + mutex_unlock(&fs_info->reclaim_bgs_lock); goto error; } --- base-commit: 2668e3ae2ef36d5e7c52f818ad7d90822c037de4 change-id: 20240419-btrfs_unlock-95e0b3e2e2fc Best regards, -- Dominique Martinet | Asmadeus

8 months, 2 weeks

3
2
0 0

[PATCH] arch/Kconfig: Move SPECULATION_MITIGATIONS to arch/Kconfig

by Song Liu

SPECULATION_MITIGATIONS is currently defined only for x86. As a result, IS_ENABLED(CONFIG_SPECULATION_MITIGATIONS) is always false for other archs. f337a6a21e2f effectively set "mitigations=off" by default on non-x86 archs, which is not desired behavior. Jakub observed this change when running bpf selftests on s390 and arm64. Fix this by moving SPECULATION_MITIGATIONS to arch/Kconfig so that it is available in all archs and thus can be used safely in kernel/cpu.c Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n") Cc: stable(a)vger.kernel.org Cc: Sean Christopherson <seanjc(a)google.com> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Daniel Sneddon <daniel.sneddon(a)linux.intel.com> Cc: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Song Liu <song(a)kernel.org> --- arch/Kconfig | 10 ++++++++++ arch/x86/Kconfig | 10 ---------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 9f066785bb71..8f4af75005f8 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1609,4 +1609,14 @@ config CC_HAS_SANE_FUNCTION_ALIGNMENT # strict alignment always, even with -falign-functions. def_bool CC_HAS_MIN_FUNCTION_ALIGNMENT || CC_IS_CLANG +menuconfig SPECULATION_MITIGATIONS + bool "Mitigations for speculative execution vulnerabilities" + default y + help + Say Y here to enable options which enable mitigations for + speculative execution hardware vulnerabilities. + + If you say N, all mitigations will be disabled. You really + should know what you are doing to say so. + endmenu diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 39886bab943a..50c890fce5e0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2486,16 +2486,6 @@ config PREFIX_SYMBOLS def_bool y depends on CALL_PADDING && !CFI_CLANG -menuconfig SPECULATION_MITIGATIONS - bool "Mitigations for speculative execution vulnerabilities" - default y - help - Say Y here to enable options which enable mitigations for - speculative execution hardware vulnerabilities. - - If you say N, all mitigations will be disabled. You really - should know what you are doing to say so. - if SPECULATION_MITIGATIONS config MITIGATION_PAGE_TABLE_ISOLATION -- 2.43.0

8 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024