December 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device" 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 e9649129d33dca561305fc590a7c4ba8c3e5675a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120347-pursuable-garment-d644@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e9649129d33dca561305fc590a7c4ba8c3e5675a Mon Sep 17 00:00:00 2001 From: Kunkun Jiang <jiangkunkun(a)huawei.com> Date: Thu, 7 Nov 2024 13:41:36 -0800 Subject: [PATCH] KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device vgic_its_save_device_tables will traverse its->device_list to save DTE for each device. vgic_its_restore_device_tables will traverse each entry of device table and check if it is valid. Restore if valid. But when MAPD unmaps a device, it does not invalidate the corresponding DTE. In the scenario of continuous saves and restores, there may be a situation where a device's DTE is not saved but is restored. This is unreasonable and may cause restore to fail. This patch clears the corresponding DTE when MAPD unmaps a device. Cc: stable(a)vger.kernel.org Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore") Co-developed-by: Shusen Li <lishusen2(a)huawei.com> Signed-off-by: Shusen Li <lishusen2(a)huawei.com> Signed-off-by: Kunkun Jiang <jiangkunkun(a)huawei.com> [Jing: Update with entry write helper] Signed-off-by: Jing Zhang <jingzhangos(a)google.com> Link: https://lore.kernel.org/r/20241107214137.428439-5-jingzhangos@google.com Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c index 68ba7e2453cd..b77fa99eafed 100644 --- a/arch/arm64/kvm/vgic/vgic-its.c +++ b/arch/arm64/kvm/vgic/vgic-its.c @@ -1139,9 +1139,11 @@ static int vgic_its_cmd_handle_mapd(struct kvm *kvm, struct vgic_its *its, bool valid = its_cmd_get_validbit(its_cmd); u8 num_eventid_bits = its_cmd_get_size(its_cmd); gpa_t itt_addr = its_cmd_get_ittaddr(its_cmd); + int dte_esz = vgic_its_get_abi(its)->dte_esz; struct its_device *device; + gpa_t gpa; - if (!vgic_its_check_id(its, its->baser_device_table, device_id, NULL)) + if (!vgic_its_check_id(its, its->baser_device_table, device_id, &gpa)) return E_ITS_MAPD_DEVICE_OOR; if (valid && num_eventid_bits > VITS_TYPER_IDBITS) @@ -1162,7 +1164,7 @@ static int vgic_its_cmd_handle_mapd(struct kvm *kvm, struct vgic_its *its, * is an error, so we are done in any case. */ if (!valid) - return 0; + return vgic_its_write_entry_lock(its, gpa, 0, dte_esz); device = vgic_its_alloc_device(its, device_id, itt_addr, num_eventid_bits);

6 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device" 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 e9649129d33dca561305fc590a7c4ba8c3e5675a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120346-busload-asleep-c2d8@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e9649129d33dca561305fc590a7c4ba8c3e5675a Mon Sep 17 00:00:00 2001 From: Kunkun Jiang <jiangkunkun(a)huawei.com> Date: Thu, 7 Nov 2024 13:41:36 -0800 Subject: [PATCH] KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device vgic_its_save_device_tables will traverse its->device_list to save DTE for each device. vgic_its_restore_device_tables will traverse each entry of device table and check if it is valid. Restore if valid. But when MAPD unmaps a device, it does not invalidate the corresponding DTE. In the scenario of continuous saves and restores, there may be a situation where a device's DTE is not saved but is restored. This is unreasonable and may cause restore to fail. This patch clears the corresponding DTE when MAPD unmaps a device. Cc: stable(a)vger.kernel.org Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore") Co-developed-by: Shusen Li <lishusen2(a)huawei.com> Signed-off-by: Shusen Li <lishusen2(a)huawei.com> Signed-off-by: Kunkun Jiang <jiangkunkun(a)huawei.com> [Jing: Update with entry write helper] Signed-off-by: Jing Zhang <jingzhangos(a)google.com> Link: https://lore.kernel.org/r/20241107214137.428439-5-jingzhangos@google.com Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c index 68ba7e2453cd..b77fa99eafed 100644 --- a/arch/arm64/kvm/vgic/vgic-its.c +++ b/arch/arm64/kvm/vgic/vgic-its.c @@ -1139,9 +1139,11 @@ static int vgic_its_cmd_handle_mapd(struct kvm *kvm, struct vgic_its *its, bool valid = its_cmd_get_validbit(its_cmd); u8 num_eventid_bits = its_cmd_get_size(its_cmd); gpa_t itt_addr = its_cmd_get_ittaddr(its_cmd); + int dte_esz = vgic_its_get_abi(its)->dte_esz; struct its_device *device; + gpa_t gpa; - if (!vgic_its_check_id(its, its->baser_device_table, device_id, NULL)) + if (!vgic_its_check_id(its, its->baser_device_table, device_id, &gpa)) return E_ITS_MAPD_DEVICE_OOR; if (valid && num_eventid_bits > VITS_TYPER_IDBITS) @@ -1162,7 +1164,7 @@ static int vgic_its_cmd_handle_mapd(struct kvm *kvm, struct vgic_its *its, * is an error, so we are done in any case. */ if (!valid) - return 0; + return vgic_its_write_entry_lock(its, gpa, 0, dte_esz); device = vgic_its_alloc_device(its, device_id, itt_addr, num_eventid_bits);

6 months, 2 weeks

1
0
0 0

Re: Patch "staging: greybus: uart: Fix atomicity violation in get_serial_info()" has been added to the 6.12-stable tree

by Johan Hovold

Hi Sasha, On Sun, Dec 01, 2024 at 07:36:20AM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > staging: greybus: uart: Fix atomicity violation in get_serial_info() > > to the 6.12-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: > staging-greybus-uart-fix-atomicity-violation-in-get_.patch > and it can be found in the queue-6.12 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 61937fd741031632e0a1337553e51b754748ca0d > Author: Qiu-ji Chen <chenqiuji666(a)gmail.com> > Date: Thu Nov 7 19:33:37 2024 +0800 > > staging: greybus: uart: Fix atomicity violation in get_serial_info() > > [ Upstream commit fe0ebeafc3b723b2f8edf27ecec6d353b08397df ] > > Our static checker found a bug where set_serial_info() uses a mutex, but > get_serial_info() does not. Fortunately, the impact of this is relatively > minor. It doesn't cause a crash or any other serious issues. However, if a > race condition occurs between set_serial_info() and get_serial_info(), > there is a chance that the data returned by get_serial_info() will be > meaningless. > > Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> > Fixes: 0aad5ad563c8 ("greybus/uart: switch to ->[sg]et_serial()") > Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> > Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> > Reviewed-by: Alex Elder <elder(a)riscstar.com> > Link: https://lore.kernel.org/r/20241107113337.402042-1-chenqiuji666@gmail.com > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> The CC stable tag was omitted on purpose here so please drop this one and any dependencies from all stable queues. Johan

6 months, 2 weeks

2
1
0 0

Strengthen Your SEO with Unique Domain Links

by Unique Links

Hi There, Looking to improve your website's SEO and authority? Our () Unique Domain Links Service delivers high-quality backlinks from diverse and credible sources to boost your rankings. Here’s what you get: ✅ Links from 100% unique domains ✅ Improved domain authority and visibility ✅ A natural and diverse backlink profile Enhance your SEO strategy with links that make a difference. Get Unique Domain Links Now: https://www.uniquelinks.top/more-info/ (https://www.uniquelinks.top/more-info/) Or chat with us on Whatsapp: https://www.uniquelinks.top/whatsapp-with-us/ (https://www.uniquelinks.top/whatsapp-with-us/) Cheers, Mike Harris Get a free SEO Consultation (//www.uniquelinks.top/free-seo-consultaition/) Unsubscribe (https://click.uniquelinks.top/?na=u&nk=362618-cb53092a81&nek=15-5c54bed135) | Manage your subscription (https://click.uniquelinks.top/?na=p&nk=362618-cb53092a81&nek=15-5c54bed135) | View online (https://click.uniquelinks.top/?na=v&nk=362618-cb53092a81&id=15) whatsapp

6 months, 2 weeks

1
0
0 0

[PATCH net-next] virtio_net: drop netdev_tx_reset_queue() from virtnet_enable_queue_pair()

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") seems not sufficient to eliminate all BQL crash scenarios 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. netdev_tx_reset_queue() can actually be dropped from virtnet_open path; the device is not stopped in any case. For BQL core part, it's just like traffic nearly ceases to exist for some period. For stall detector added to BQL, even if virtnet_close could somehow lead to some TX completions delayed for long, followed by virtnet_open, we can just take it as stall as mentioned in commit 6025b9135f7a ("net: dqs: add NIC stall detector based on BQL"). Note also that users can still reset stall_max via sysfs. So, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This eliminates the BQL crashes. With this patch, virtio-net performs only one dql_reset() per probe. [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/0x70 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 ]--- Fixes: c8bd1f7f3e61 ("virtio_net: add support for Byte Queue Limits") Cc: <stable(a)vger.kernel.org> # v6.11+ Signed-off-by: Koichiro Den <koichiro.den(a)canonical.com> --- Previous attempt: https://lore.kernel.org/netdev/20241126024200.2371546-1-koichiro.den@canoni… --- drivers/net/virtio_net.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 64c87bb48a41..35a36d1289db 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -3054,7 +3054,6 @@ static int virtnet_enable_queue_pair(struct virtnet_info *vi, int qp_index) if (err < 0) goto err_xdp_reg_mem_model; - netdev_tx_reset_queue(netdev_get_tx_queue(vi->dev, qp_index)); virtnet_napi_enable(vi->rq[qp_index].vq, &vi->rq[qp_index].napi); virtnet_napi_tx_enable(vi, vi->sq[qp_index].vq, &vi->sq[qp_index].napi); -- 2.43.0

6 months, 2 weeks

3
4
0 0

[PATCH] drm/msm/dpu: fix x1e80100 intf_6 underrun/vsync interrupt

by Stephan Gerhold

The IRQ indexes for the intf_6 underrun/vsync interrupts are swapped. DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 16) is the actual underrun interrupt and DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 17) is the vsync interrupt. This causes timeout errors when using the DP2 controller, e.g. [dpu error]enc37 frame done timeout *ERROR* irq timeout id=37, intf_mode=INTF_MODE_VIDEO intf=6 wb=-1, pp=2, intr=0 *ERROR* wait disable failed: id:37 intf:6 ret:-110 Correct them to fix these errors and make DP2 work properly. Cc: stable(a)vger.kernel.org Fixes: e3b1f369db5a ("drm/msm/dpu: Add X1E80100 support") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h index a3e60ac70689..d61895bb396f 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h @@ -389,8 +389,8 @@ static const struct dpu_intf_cfg x1e80100_intf[] = { .type = INTF_DP, .controller_id = MSM_DP_CONTROLLER_2, .prog_fetch_lines_worst_case = 24, - .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 17), - .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 16), + .intr_underrun = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 16), + .intr_vsync = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 17), }, { .name = "intf_7", .id = INTF_7, .base = 0x3b000, .len = 0x280, --- base-commit: 744cf71b8bdfcdd77aaf58395e068b7457634b2c change-id: 20241115-x1e80100-dp2-fix-beb12c6dcac9 Best regards, -- Stephan Gerhold <stephan.gerhold(a)linaro.org>

6 months, 2 weeks

4
3
0 0

[PATCH net 01/15] can: dev: can_set_termination(): allow sleeping GPIOs

by Marc Kleine-Budde

In commit 6e86a1543c37 ("can: dev: provide optional GPIO based termination support") GPIO based termination support was added. For no particular reason that patch uses gpiod_set_value() to set the GPIO. This leads to the following warning, if the systems uses a sleeping GPIO, i.e. behind an I2C port expander: | WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the use of sleeping GPIOs. Cc: Nicolai Buchwitz <nb(a)tipi-net.de> Cc: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> Cc: stable(a)vger.kernel.org Reported-by: Leonard Göhrs <l.goehrs(a)pengutronix.de> Tested-by: Leonard Göhrs <l.goehrs(a)pengutronix.de> Fixes: 6e86a1543c37 ("can: dev: provide optional GPIO based termination support") Link: https://patch.msgid.link/20241121-dev-fix-can_set_termination-v1-1-41fa6e29… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/dev/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c index 6792c14fd7eb..681643ab3780 100644 --- a/drivers/net/can/dev/dev.c +++ b/drivers/net/can/dev/dev.c @@ -468,7 +468,7 @@ static int can_set_termination(struct net_device *ndev, u16 term) else set = 0; - gpiod_set_value(priv->termination_gpio, set); + gpiod_set_value_cansleep(priv->termination_gpio, set); return 0; } base-commit: 9bb88c659673003453fd42e0ddf95c9628409094 -- 2.45.2

6 months, 2 weeks

2
1
0 0

[PATCH] btrfs: do proper folio cleanup when cow_file_range() failed

by Qu Wenruo

Just like cow_file_range(), from day 1 btrfs doesn't really clean the dirty flags, if it has an ordered extent created successfully. Per error handling protocol (according to the iomap, and the btrfs handling if it failed at the beginning of the range), we should clear all dirty flags for the involved folios. Or the range of that folio will still be marked dirty, but has no EXTENT_DEALLLOC set inside the io tree. Since the folio range is still dirty, it will still be the target for the next writeback, but since there is no EXTENT_DEALLLOC, no new ordered extent will be created for it. This means the writeback of that folio range will fall back to COW fixup, which is being marked deprecated and will trigger a crash. Unlike the fix in cow_file_range(), which holds the folio and extent lock until error or a fully successfully run, here we have no such luxury as we can fallback to COW, and in that case the extent/folio range will be unlocked by cow_file_range(). So here we introduce a new helper, cleanup_dirty_folios(), to clear the dirty flags for the involved folios. Cc: stable(a)vger.kernel.org Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/inode.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e8232ac7917f..19e1b78508bd 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1969,6 +1969,46 @@ static int can_nocow_file_extent(struct btrfs_path *path, return ret < 0 ? ret : can_nocow; } +static void cleanup_dirty_folios(struct btrfs_inode *inode, + struct folio *locked_folio, + u64 start, u64 end, int error) +{ + struct btrfs_fs_info *fs_info = inode->root->fs_info; + struct address_space *mapping = inode->vfs_inode.i_mapping; + pgoff_t start_index = start >> PAGE_SHIFT; + pgoff_t end_index = end >> PAGE_SHIFT; + u32 len; + + ASSERT(end + 1 - start < U32_MAX); + len = end + 1 - start; + + /* + * Handle the locked folio first. + * btrfs_folio_clamp_*() helpers can handle range out of the folio case. + */ + btrfs_folio_clamp_clear_dirty(fs_info, locked_folio, start, len); + btrfs_folio_clamp_set_writeback(fs_info, locked_folio, start, len); + btrfs_folio_clamp_clear_writeback(fs_info, locked_folio, start, len); + + for (pgoff_t index = start_index; index <= end_index; index++) { + struct folio *folio; + + /* Already handled at the beginning. */ + if (index == locked_folio->index) + continue; + folio = __filemap_get_folio(mapping, index, FGP_LOCK, GFP_NOFS); + /* Cache already dropped, no need to do any cleanup. */ + if (IS_ERR(folio)) + continue; + btrfs_folio_clamp_clear_dirty(fs_info, folio, start, len); + btrfs_folio_clamp_set_writeback(fs_info, folio, start, len); + btrfs_folio_clamp_clear_writeback(fs_info, folio, start, len); + folio_unlock(folio); + folio_put(folio); + } + mapping_set_error(mapping, error); +} + /* * when nowcow writeback call back. This checks for snapshots or COW copies * of the extents that exist in the file, and COWs the file as required. @@ -2228,6 +2268,22 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode, return 0; error: + /* + * We have some range with ordered extent created. + * + * Ordered extents and extent maps will be cleaned up by + * btrfs_mark_ordered_io_finished() later, but we also need to cleanup + * the dirty flags of folios. + * + * Or they can be written back again, but without any EXTENT_DELALLOC flag + * in io tree. + * This will force the writeback to go COW fixup, which is being deprecated. + * + * Also such left-over dirty flags do no follow the error handling protocol. + */ + if (cur_offset > start) + cleanup_dirty_folios(inode, locked_folio, start, cur_offset - 1, ret); + /* * If an error happened while a COW region is outstanding, cur_offset * needs to be reset to cow_start to ensure the COW region is unlocked -- 2.47.1

6 months, 2 weeks

1
1
0 0

[PATCH] btrfs: do proper folio cleanup when run_delalloc_nocow() failed

by Qu Wenruo

Just like cow_file_range(), from day 1 btrfs doesn't really clean the dirty flags, if it has an ordered extent created successfully. Per error handling protocol (according to the iomap, and the btrfs handling if it failed at the beginning of the range), we should clear all dirty flags for the involved folios. Or the range of that folio will still be marked dirty, but has no EXTENT_DEALLLOC set inside the io tree. Since the folio range is still dirty, it will still be the target for the next writeback, but since there is no EXTENT_DEALLLOC, no new ordered extent will be created for it. This means the writeback of that folio range will fall back to COW fixup, which is being marked deprecated and will trigger a crash. Unlike the fix in cow_file_range(), which holds the folio and extent lock until error or a fully successfully run, here we have no such luxury as we can fallback to COW, and in that case the extent/folio range will be unlocked by cow_file_range(). So here we introduce a new helper, cleanup_dirty_folios(), to clear the dirty flags for the involved folios. Cc: stable(a)vger.kernel.org Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/inode.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e8232ac7917f..19e1b78508bd 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1969,6 +1969,46 @@ static int can_nocow_file_extent(struct btrfs_path *path, return ret < 0 ? ret : can_nocow; } +static void cleanup_dirty_folios(struct btrfs_inode *inode, + struct folio *locked_folio, + u64 start, u64 end, int error) +{ + struct btrfs_fs_info *fs_info = inode->root->fs_info; + struct address_space *mapping = inode->vfs_inode.i_mapping; + pgoff_t start_index = start >> PAGE_SHIFT; + pgoff_t end_index = end >> PAGE_SHIFT; + u32 len; + + ASSERT(end + 1 - start < U32_MAX); + len = end + 1 - start; + + /* + * Handle the locked folio first. + * btrfs_folio_clamp_*() helpers can handle range out of the folio case. + */ + btrfs_folio_clamp_clear_dirty(fs_info, locked_folio, start, len); + btrfs_folio_clamp_set_writeback(fs_info, locked_folio, start, len); + btrfs_folio_clamp_clear_writeback(fs_info, locked_folio, start, len); + + for (pgoff_t index = start_index; index <= end_index; index++) { + struct folio *folio; + + /* Already handled at the beginning. */ + if (index == locked_folio->index) + continue; + folio = __filemap_get_folio(mapping, index, FGP_LOCK, GFP_NOFS); + /* Cache already dropped, no need to do any cleanup. */ + if (IS_ERR(folio)) + continue; + btrfs_folio_clamp_clear_dirty(fs_info, folio, start, len); + btrfs_folio_clamp_set_writeback(fs_info, folio, start, len); + btrfs_folio_clamp_clear_writeback(fs_info, folio, start, len); + folio_unlock(folio); + folio_put(folio); + } + mapping_set_error(mapping, error); +} + /* * when nowcow writeback call back. This checks for snapshots or COW copies * of the extents that exist in the file, and COWs the file as required. @@ -2228,6 +2268,22 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode, return 0; error: + /* + * We have some range with ordered extent created. + * + * Ordered extents and extent maps will be cleaned up by + * btrfs_mark_ordered_io_finished() later, but we also need to cleanup + * the dirty flags of folios. + * + * Or they can be written back again, but without any EXTENT_DELALLOC flag + * in io tree. + * This will force the writeback to go COW fixup, which is being deprecated. + * + * Also such left-over dirty flags do no follow the error handling protocol. + */ + if (cur_offset > start) + cleanup_dirty_folios(inode, locked_folio, start, cur_offset - 1, ret); + /* * If an error happened while a COW region is outstanding, cur_offset * needs to be reset to cow_start to ensure the COW region is unlocked -- 2.47.1

6 months, 2 weeks

1
0
0 0

[PATCH] drm: amd: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table

by Ivan Stepchenko

The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a23eefa2f461 ("drm/amd/powerplay: enable dpm for baffin.") Cc: stable(a)vger.kernel.org Signed-off-by: Ivan Stepchenko <sid(a)itb.spb.ru> --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c index fe24219c3bf4..4bd92fd782be 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c @@ -992,6 +992,8 @@ int atomctrl_get_smc_sclk_range_table(struct pp_hwmgr *hwmgr, struct pp_atom_ctr GetIndexIntoMasterTable(DATA, SMU_Info), &size, &frev, &crev); + if (!psmu_info) + return -EINVAL; for (i = 0; i < psmu_info->ucSclkEntryNum; i++) { table->entry[i].ucVco_setting = psmu_info->asSclkFcwRangeEntry[i].ucVco_setting; -- 2.34.1

6 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024