September 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] ASoC: meson: axg-card: fix 'use-after-free'" 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 4f9a71435953f941969a4f017e2357db62d85a86 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024091554-obtain-sibling-75bf@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 4f9a71435953 ("ASoC: meson: axg-card: fix 'use-after-free'") aa9c3b7273a5 ("ASoC: meson: axg: extract sound card utils") 9c29fd9bdf92 ("ASoC: meson: g12a: extract codec-to-codec utils") dd28d54c248f ("Merge branch 'asoc-5.3' into asoc-5.4") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 4f9a71435953f941969a4f017e2357db62d85a86 Mon Sep 17 00:00:00 2001 From: Arseniy Krasnov <avkrasnov(a)salutedevices.com> Date: Wed, 11 Sep 2024 17:24:25 +0300 Subject: [PATCH] ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Cc: Stable(a)vger.kernel.org Signed-off-by: Arseniy Krasnov <avkrasnov(a)salutedevices.com> Reviewed-by: Jerome Brunet <jbrunet(a)baylibre.com> Link: https://patch.msgid.link/20240911142425.598631-1-avkrasnov@salutedevices.com Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/meson/axg-card.c b/sound/soc/meson/axg-card.c index 8c5605c1e34e..eb0302f20740 100644 --- a/sound/soc/meson/axg-card.c +++ b/sound/soc/meson/axg-card.c @@ -104,7 +104,7 @@ static int axg_card_add_tdm_loopback(struct snd_soc_card *card, int *index) { struct meson_card *priv = snd_soc_card_get_drvdata(card); - struct snd_soc_dai_link *pad = &card->dai_link[*index]; + struct snd_soc_dai_link *pad; struct snd_soc_dai_link *lb; struct snd_soc_dai_link_component *dlc; int ret; @@ -114,6 +114,7 @@ static int axg_card_add_tdm_loopback(struct snd_soc_card *card, if (ret) return ret; + pad = &card->dai_link[*index]; lb = &card->dai_link[*index + 1]; lb->name = devm_kasprintf(card->dev, GFP_KERNEL, "%s-lb", pad->name);

8 months

1
0
0 0

FAILED: patch "[PATCH] ASoC: meson: axg-card: fix 'use-after-free'" 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 4f9a71435953f941969a4f017e2357db62d85a86 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024091552-croak-destruct-a0ea@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 4f9a71435953 ("ASoC: meson: axg-card: fix 'use-after-free'") aa9c3b7273a5 ("ASoC: meson: axg: extract sound card utils") 9c29fd9bdf92 ("ASoC: meson: g12a: extract codec-to-codec utils") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 4f9a71435953f941969a4f017e2357db62d85a86 Mon Sep 17 00:00:00 2001 From: Arseniy Krasnov <avkrasnov(a)salutedevices.com> Date: Wed, 11 Sep 2024 17:24:25 +0300 Subject: [PATCH] ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Cc: Stable(a)vger.kernel.org Signed-off-by: Arseniy Krasnov <avkrasnov(a)salutedevices.com> Reviewed-by: Jerome Brunet <jbrunet(a)baylibre.com> Link: https://patch.msgid.link/20240911142425.598631-1-avkrasnov@salutedevices.com Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/meson/axg-card.c b/sound/soc/meson/axg-card.c index 8c5605c1e34e..eb0302f20740 100644 --- a/sound/soc/meson/axg-card.c +++ b/sound/soc/meson/axg-card.c @@ -104,7 +104,7 @@ static int axg_card_add_tdm_loopback(struct snd_soc_card *card, int *index) { struct meson_card *priv = snd_soc_card_get_drvdata(card); - struct snd_soc_dai_link *pad = &card->dai_link[*index]; + struct snd_soc_dai_link *pad; struct snd_soc_dai_link *lb; struct snd_soc_dai_link_component *dlc; int ret; @@ -114,6 +114,7 @@ static int axg_card_add_tdm_loopback(struct snd_soc_card *card, if (ret) return ret; + pad = &card->dai_link[*index]; lb = &card->dai_link[*index + 1]; lb->name = devm_kasprintf(card->dev, GFP_KERNEL, "%s-lb", pad->name);

8 months

1
0
0 0

[PATCH 2/2] mm/hugetlb.c: Fix UAF of vma in hugetlb fault pathway

by Vishal Moola (Oracle)

Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read(). Reported-by: syzbot+2dab93857ee95f2eeb08(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/00000000000067c20b06219fbc26@google.com/ Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()") Signed-off-by: Vishal Moola (Oracle) <vishal.moola(a)gmail.com> Cc: <stable(a)vger.kernel.org> --- mm/hugetlb.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 5c77defad295..190fa05635f4 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5915,7 +5915,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_folio, * When the original hugepage is shared one, it does not have * anon_vma prepared. */ - ret = vmf_anon_prepare(vmf); + ret = __vmf_anon_prepare(vmf); if (unlikely(ret)) goto out_release_all; @@ -6114,7 +6114,7 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, } if (!(vma->vm_flags & VM_MAYSHARE)) { - ret = vmf_anon_prepare(vmf); + ret = __vmf_anon_prepare(vmf); if (unlikely(ret)) goto out; } @@ -6245,6 +6245,14 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, folio_unlock(folio); out: hugetlb_vma_unlock_read(vma); + + /* + * We must check to release the per-VMA lock. __vmf_anon_prepare() is + * the only way ret can be set to VM_FAULT_RETRY. + */ + if (unlikely(ret & VM_FAULT_RETRY)) + vma_end_read(vma); + mutex_unlock(&hugetlb_fault_mutex_table[hash]); return ret; @@ -6466,6 +6474,14 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, } out_mutex: hugetlb_vma_unlock_read(vma); + + /* + * We must check to release the per-VMA lock. __vmf_anon_prepare() in + * hugetlb_wp() is the only way ret can be set to VM_FAULT_RETRY. + */ + if (unlikely(ret & VM_FAULT_RETRY)) + vma_end_read(vma); + mutex_unlock(&hugetlb_fault_mutex_table[hash]); /* * Generally it's safe to hold refcount during waiting page lock. But -- 2.45.0

8 months

1
0
0 0

[PATCH net] netkit: Ensure current->bpf_net_context is set in netkit_xmit()

by Jordan Rife

When operating Cilium in netkit mode with BPF-based host routing, calls to bpf_redirect() cause a kernel panic. [ 52.247646] BUG: kernel NULL pointer dereference, address: 0000000000000038 ... [ 52.247727] RIP: 0010:bpf_redirect+0x18/0x80 ... [ 52.247986] Call Trace: [ 52.247990] <TASK> [ 52.248002] ? show_regs+0x6c/0x80 [ 52.248024] ? __die+0x24/0x80 [ 52.248029] ? page_fault_oops+0x155/0x570 [ 52.248047] ? fib_rules_lookup+0x112/0x270 [ 52.248056] ? do_user_addr_fault+0x4b2/0x870 [ 52.248063] ? exc_page_fault+0x82/0x1b0 [ 52.248090] ? asm_exc_page_fault+0x27/0x30 [ 52.248103] ? bpf_redirect+0x18/0x80 [ 52.248109] bpf_prog_f0698aabaf44c832_tail_handle_ipv4+0x173f/0x2707 [ 52.248119] ? sbitmap_find_bit+0xe3/0x270 [ 52.248129] netkit_xmit+0x177/0x3c0 [ 52.248139] dev_hard_start_xmit+0x62/0x1d0 [ 52.248149] __dev_queue_xmit+0x241/0xf30 [ 52.248155] ? alloc_skb_with_frags+0x60/0x280 [ 52.248164] ? __check_object_size+0x2a2/0x310 [ 52.248173] ? ip_generic_getfrag+0x63/0x110 [ 52.248181] ip_finish_output2+0x2cf/0x560 [ 52.248187] __ip_finish_output+0xb6/0x180 [ 52.248193] ip_finish_output+0x29/0x120 [ 52.248198] ip_output+0x5f/0x100 [ 52.248204] ? __pfx_ip_finish_output+0x10/0x10 [ 52.248210] ip_send_skb+0x98/0xb0 [ 52.248215] udp_send_skb+0x146/0x370 Setting a breakpoint inside bpf_net_ctx_get_ri() confirms that current->bpf_net_context is NULL right before the panic. (gdb) p $lx_current().bpf_net_context $4 = (struct bpf_net_context *) 0x0 <fixed_percpu_data> (gdb) disassemble bpf_redirect Dump of assembler code for function bpf_redirect: 0xffffffff81f085e0 <+0>: nopl 0x0(%rax,%rax,1) 0xffffffff81f085e5 <+5>: mov %gs:0x7e12d593(%rip),%rax 0xffffffff81f085ed <+13>: push %rbp 0xffffffff81f085ee <+14>: mov 0x23d0(%rax),%rax => 0xffffffff81f085f5 <+21>: mov %rsp,%rbp 0xffffffff81f085f8 <+24>: mov 0x38(%rax),%edx ... (gdb) continue Continuing. Thread 1 hit Breakpoint 1, panic ... 288 { (gdb) commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") recently moved bpf_redirect_info into bpf_net_context, a new member of task_struct. Currently, current->bpf_net_context is set and then cleared inside sch_handle_egress() where tcx_run() and tc_run() execute, but it looks like netkit_xmit() was missed leaving current->bpf_net_context uninitialized when it runs. This patch ensures that current->bpf_net_context is initialized while running netkit_xmit(). Signed-off-by: Jordan Rife <jrife(a)google.com> Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Cc: stable(a)vger.kernel.org --- drivers/net/netkit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c index d0036a856039..92ac0cb5a327 100644 --- a/drivers/net/netkit.c +++ b/drivers/net/netkit.c @@ -65,6 +65,7 @@ static struct netkit *netkit_priv(const struct net_device *dev) static netdev_tx_t netkit_xmit(struct sk_buff *skb, struct net_device *dev) { + struct bpf_net_context __bpf_net_ctx, *bpf_net_ctx; struct netkit *nk = netkit_priv(dev); enum netkit_action ret = READ_ONCE(nk->policy); netdev_tx_t ret_dev = NET_XMIT_SUCCESS; @@ -73,6 +74,7 @@ static netdev_tx_t netkit_xmit(struct sk_buff *skb, struct net_device *dev) int len = skb->len; rcu_read_lock(); + bpf_net_ctx = bpf_net_ctx_set(&__bpf_net_ctx); peer = rcu_dereference(nk->peer); if (unlikely(!peer || !(peer->flags & IFF_UP) || !pskb_may_pull(skb, ETH_HLEN) || @@ -109,6 +111,7 @@ static netdev_tx_t netkit_xmit(struct sk_buff *skb, struct net_device *dev) ret_dev = NET_XMIT_DROP; break; } + bpf_net_ctx_clear(bpf_net_ctx); rcu_read_unlock(); return ret_dev; } -- 2.46.0.662.g92d0881bb0-goog

8 months

2
1
0 0

[PATCH v2] i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition

by Kaixin Wang

In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove. Fixes: 0f74f8b6675c ("i3c: Make i3c_master_unregister() return void") Signed-off-by: Kaixin Wang <kxwang23(a)m.fudan.edu.cn> Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- v2: - add fixes tag and cc stable, suggested by Frank - add Reviewed-by label from Miquel - Link to v1: https://lore.kernel.org/r/20240911150135.839946-1-kxwang23@m.fudan.edu.cn --- drivers/i3c/master/svc-i3c-master.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c index 0a68fd1b81d4..e084ba648b4a 100644 --- a/drivers/i3c/master/svc-i3c-master.c +++ b/drivers/i3c/master/svc-i3c-master.c @@ -1775,6 +1775,7 @@ static void svc_i3c_master_remove(struct platform_device *pdev) { struct svc_i3c_master *master = platform_get_drvdata(pdev); + cancel_work_sync(&master->hj_work); i3c_master_unregister(&master->base); pm_runtime_dont_use_autosuspend(&pdev->dev); -- 2.39.1.windows.1

8 months

2
1
0 0

[PATCH 0/7] iio: light: veml6030: fix issues and add support for veml6035

by Javier Carrasco

This series updates the driver for the veml6030 ALS and adds support for the veml6035, which shares most of its functionality with the former. The most relevant updates for the veml6030 are the resolution correction to meet the datasheet update that took place with Rev 1.7, 28-Nov-2023, and a fix to avoid a segmentation fault when reading the in_illuminance_period_available attribute. Vishay does not host the Product Information Notification where the resolution correction was introduced, but it can still be found online[1], and the corrected value is the one listed on the latest version of the datasheet[2] (Rev. 1.7, 28-Nov-2023) and application note[3] (Rev. 17-Jan-2024). Link: https://www.farnell.com/datasheets/4379688.pdf [1] Link: https://www.vishay.com/docs/84366/veml6030.pdf [2] Link: https://www.vishay.com/docs/84367/designingveml6030.pdf [3] Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Javier Carrasco (7): dt-bindings: iio: light: veml6030: rename to add manufacturer dt-bindings: iio: light: veml6030: add veml6035 iio: light: veml6030: fix IIO device retrieval from embedded device iio: light: veml6030: make use of regmap_set_bits() iio: light: veml6030: update sensor resolution iio: light: veml6030: add set up delay after any power on sequence iio: light: veml6030: add support for veml6035 .../light/{veml6030.yaml => vishay,veml6030.yaml} | 42 ++- drivers/iio/light/veml6030.c | 323 ++++++++++++++++++--- 2 files changed, 319 insertions(+), 46 deletions(-) --- base-commit: 5acd9952f95fb4b7da6d09a3be39195a80845eb6 change-id: 20240903-veml6035-7a91bc088c6f Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

8 months

2
2
0 0

[PATCH] power: supply: sysfs: enable is_writeable check during sysfs creation

by Andreas Kemnade

The files in sysfs are created during device_add(). psy->use_cnt is not incremented yet. So attributes are created readonly without checking desc->property_is_writeable() and writeable files are readonly. To fix this, revert back to calling desc->property_is_writeable() directly without using the helper. Fixes: be6299c6e55e ("power: supply: sysfs: use power_supply_property_is_writeable()") Signed-off-by: Andreas Kemnade <andreas(a)kemnade.info> Cc: stable(a)vger.kernel.org # 6.11 --- drivers/power/supply/power_supply_sysfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c index 3e63d165b2f70..b86e11bdc07ef 100644 --- a/drivers/power/supply/power_supply_sysfs.c +++ b/drivers/power/supply/power_supply_sysfs.c @@ -379,7 +379,8 @@ static umode_t power_supply_attr_is_visible(struct kobject *kobj, int property = psy->desc->properties[i]; if (property == attrno) { - if (power_supply_property_is_writeable(psy, property) > 0) + if (psy->desc->property_is_writeable && + psy->desc->property_is_writeable(psy, property) > 0) mode |= S_IWUSR; return mode; -- 2.39.2

8 months

2
1
0 0

[PATCH v3 3/3] block: fix ordering between checking BLK_MQ_S_STOPPED and adding requests

by Muchun Song

Supposing first scenario with a virtio_blk driver. CPU0 CPU1 blk_mq_try_issue_directly() __blk_mq_issue_directly() q->mq_ops->queue_rq() virtio_queue_rq() blk_mq_stop_hw_queue() virtblk_done() blk_mq_request_bypass_insert() 1) store blk_mq_start_stopped_hw_queue() clear_bit(BLK_MQ_S_STOPPED) 3) store blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_sched_dispatch_requests() blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) return blk_mq_sched_dispatch_requests() if (blk_mq_hctx_stopped()) 2) load return __blk_mq_sched_dispatch_requests() Supposing another scenario. CPU0 CPU1 blk_mq_requeue_work() blk_mq_insert_request() 1) store virtblk_done() blk_mq_start_stopped_hw_queue() blk_mq_run_hw_queues() clear_bit(BLK_MQ_S_STOPPED) 3) store blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_sched_dispatch_requests() if (blk_mq_hctx_stopped()) 2) load continue blk_mq_run_hw_queue() Both scenarios are similar, the full memory barrier should be inserted between 1) and 2), as well as between 3) and 4) to make sure that either CPU0 sees BLK_MQ_S_STOPPED is cleared or CPU1 sees dispatch list. Otherwise, either CPU will not rerun the hardware queue causing starvation of the request. The easy way to fix it is to add the essential full memory barrier into helper of blk_mq_hctx_stopped(). In order to not affect the fast path (hardware queue is not stopped most of the time), we only insert the barrier into the slow path. Actually, only slow path needs to care about missing of dispatching the request to the low-level device driver. Fixes: 320ae51feed5 ("blk-mq: new multi-queue block IO queueing mechanism") Cc: stable(a)vger.kernel.org Cc: Muchun Song <muchun.song(a)linux.dev> Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 6 ++++++ block/blk-mq.h | 13 +++++++++++++ 2 files changed, 19 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index ff6df6c7eeb25..b90c1680cb780 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2413,6 +2413,12 @@ void blk_mq_start_stopped_hw_queue(struct blk_mq_hw_ctx *hctx, bool async) return; clear_bit(BLK_MQ_S_STOPPED, &hctx->state); + /* + * Pairs with the smp_mb() in blk_mq_hctx_stopped() to order the + * clearing of BLK_MQ_S_STOPPED above and the checking of dispatch + * list in the subsequent routine. + */ + smp_mb__after_atomic(); blk_mq_run_hw_queue(hctx, async); } EXPORT_SYMBOL_GPL(blk_mq_start_stopped_hw_queue); diff --git a/block/blk-mq.h b/block/blk-mq.h index 260beea8e332c..f36f3bff70d86 100644 --- a/block/blk-mq.h +++ b/block/blk-mq.h @@ -228,6 +228,19 @@ static inline struct blk_mq_tags *blk_mq_tags_from_data(struct blk_mq_alloc_data static inline bool blk_mq_hctx_stopped(struct blk_mq_hw_ctx *hctx) { + /* Fast path: hardware queue is not stopped most of the time. */ + if (likely(!test_bit(BLK_MQ_S_STOPPED, &hctx->state))) + return false; + + /* + * This barrier is used to order adding of dispatch list before and + * the test of BLK_MQ_S_STOPPED below. Pairs with the memory barrier + * in blk_mq_start_stopped_hw_queue() so that dispatch code could + * either see BLK_MQ_S_STOPPED is cleared or dispatch list is not + * empty to avoid missing dispatching requests. + */ + smp_mb(); + return test_bit(BLK_MQ_S_STOPPED, &hctx->state); } -- 2.20.1

8 months

1
0
0 0

[PATCH v3 2/3] block: fix ordering between checking QUEUE_FLAG_QUIESCED and adding requests

by Muchun Song

Supposing the following scenario. CPU0 CPU1 blk_mq_insert_request() 1) store blk_mq_unquiesce_queue() blk_queue_flag_clear() 3) store blk_mq_run_hw_queues() blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_run_hw_queue() if (blk_queue_quiesced()) 2) load return blk_mq_sched_dispatch_requests() The full memory barrier should be inserted between 1) and 2), as well as between 3) and 4) to make sure that either CPU0 sees QUEUE_FLAG_QUIESCED is cleared or CPU1 sees dispatch list or setting of bitmap of software queue. Otherwise, either CPU will not rerun the hardware queue causing starvation. So the first solution is to 1) add a pair of memory barrier to fix the problem, another solution is to 2) use hctx->queue->queue_lock to synchronize QUEUE_FLAG_QUIESCED. Here, we chose 2) to fix it since memory barrier is not easy to be maintained. Fixes: f4560ffe8cec ("blk-mq: use QUEUE_FLAG_QUIESCED to quiesce queue") Cc: stable(a)vger.kernel.org Cc: Muchun Song <muchun.song(a)linux.dev> Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 47 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 34 insertions(+), 13 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index b2d0f22de0c7f..ff6df6c7eeb25 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2202,6 +2202,24 @@ void blk_mq_delay_run_hw_queue(struct blk_mq_hw_ctx *hctx, unsigned long msecs) } EXPORT_SYMBOL(blk_mq_delay_run_hw_queue); +static inline bool blk_mq_hw_queue_need_run(struct blk_mq_hw_ctx *hctx) +{ + bool need_run; + + /* + * When queue is quiesced, we may be switching io scheduler, or + * updating nr_hw_queues, or other things, and we can't run queue + * any more, even blk_mq_hctx_has_pending() can't be called safely. + * + * And queue will be rerun in blk_mq_unquiesce_queue() if it is + * quiesced. + */ + __blk_mq_run_dispatch_ops(hctx->queue, false, + need_run = !blk_queue_quiesced(hctx->queue) && + blk_mq_hctx_has_pending(hctx)); + return need_run; +} + /** * blk_mq_run_hw_queue - Start to run a hardware queue. * @hctx: Pointer to the hardware queue to run. @@ -2222,20 +2240,23 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async) might_sleep_if(!async && hctx->flags & BLK_MQ_F_BLOCKING); - /* - * When queue is quiesced, we may be switching io scheduler, or - * updating nr_hw_queues, or other things, and we can't run queue - * any more, even __blk_mq_hctx_has_pending() can't be called safely. - * - * And queue will be rerun in blk_mq_unquiesce_queue() if it is - * quiesced. - */ - __blk_mq_run_dispatch_ops(hctx->queue, false, - need_run = !blk_queue_quiesced(hctx->queue) && - blk_mq_hctx_has_pending(hctx)); + need_run = blk_mq_hw_queue_need_run(hctx); + if (!need_run) { + unsigned long flags; - if (!need_run) - return; + /* + * Synchronize with blk_mq_unquiesce_queue(), because we check + * if hw queue is quiesced locklessly above, we need the use + * ->queue_lock to make sure we see the up-to-date status to + * not miss rerunning the hw queue. + */ + spin_lock_irqsave(&hctx->queue->queue_lock, flags); + need_run = blk_mq_hw_queue_need_run(hctx); + spin_unlock_irqrestore(&hctx->queue->queue_lock, flags); + + if (!need_run) + return; + } if (async || !cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask)) { blk_mq_delay_run_hw_queue(hctx, 0); -- 2.20.1

8 months

1
0
0 0

[PATCH v3 1/3] block: fix missing dispatching request when queue is started or unquiesced

by Muchun Song

Supposing the following scenario with a virtio_blk driver. CPU0 CPU1 CPU2 blk_mq_try_issue_directly() __blk_mq_issue_directly() q->mq_ops->queue_rq() virtio_queue_rq() blk_mq_stop_hw_queue() virtblk_done() blk_mq_try_issue_directly() if (blk_mq_hctx_stopped()) blk_mq_request_bypass_insert() blk_mq_run_hw_queue() blk_mq_run_hw_queue() blk_mq_run_hw_queue() blk_mq_insert_request() return After CPU0 has marked the queue as stopped, CPU1 will see the queue is stopped. But before CPU1 puts the request on the dispatch list, CPU2 receives the interrupt of completion of request, so it will run the hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also runs the same hardware queue. After both CPU1 and CPU2 complete blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware queue and returns. It misses dispatching a request. Fix it by running the hardware queue explicitly. And blk_mq_request_issue_directly() should handle a similar situation. Fix it as well. Fixes: d964f04a8fde ("blk-mq: fix direct issue") Cc: stable(a)vger.kernel.org Cc: Muchun Song <muchun.song(a)linux.dev> Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index e3c3c0c21b553..b2d0f22de0c7f 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2619,6 +2619,7 @@ static void blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx, if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(rq->q)) { blk_mq_insert_request(rq, 0); + blk_mq_run_hw_queue(hctx, false); return; } @@ -2649,6 +2650,7 @@ static blk_status_t blk_mq_request_issue_directly(struct request *rq, bool last) if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(rq->q)) { blk_mq_insert_request(rq, 0); + blk_mq_run_hw_queue(hctx, false); return BLK_STS_OK; } -- 2.20.1

8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024