December 2024 - Linux-stable-mirror

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

1 month, 1 week

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

1 month, 1 week

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

1 month, 1 week

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>

1 month, 1 week

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

1 month, 1 week

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

1 month, 1 week

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

1 month, 1 week

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

1 month, 1 week

2
1
0 0

Performance Degradation After Upgrading to Kernel 6.8

by Chenbo Lu

Hello, I am experiencing a significant performance degradation after upgrading my kernel from version 6.6 to 6.8 and would appreciate any insights or suggestions. I am running a high-load simulation system that spawns more than 1000 threads and the overall CPU usage is 30%+ . Most of the threads are using real-time scheduling (SCHED_RR), and the threads of a model are using SCHED_DEADLINE. After upgrading the kernel, I noticed that the execution time of my model has increased from 4.5ms to 6ms. What I Have Done So Far: 1. I found this [bug report](https://bugzilla.kernel.org/show_bug.cgi?id=219366#c7) and reverted the commit efa7df3e3bb5da8e6abbe37727417f32a37fba47 mentioned in the post. Unfortunately, this did not resolve the issue. 2. I performed a git bisect and found that after these two commits related to scheduling (RT and deadline) were merged, the problem happened. They are 612f769edd06a6e42f7cd72425488e68ddaeef0a, 5fe7765997b139e2d922b58359dea181efe618f9 After reverting these two commits, the model execution time improved to around 5 ms. 3. I revert two more commits, and the execution time is back to 4.7ms: 63ba8422f876e32ee564ea95da9a7313b13ff0a1, efa7df3e3bb5da8e6abbe37727417f32a37fba47 My questions are: 1.Has anyone else experienced similar performance degradation after upgrading to kernel 6.8? 2.Can anyone explain why these two commits are causing the problem? I am not very familiar with the kernel code and would appreciate any insights. 3.Are there any additional settings or configurations I need to apply when using kernel 6.8 to avoid this issue? My CPU is AMD Ryzen Threadripper 3970X, and my desktop uses Ubuntu 24.04. Thanks again for any insights or suggestions. Please let me know if any other information is needed. Best, Chenbo -- This email and any relevant attachments may include confidential and/or proprietary information. Any distribution or use by anyone other than the intended recipient(s) or other than for the intended purpose(s) is prohibited and may be unlawful. If you are not the intended recipient of this message, please notify the sender by replying to this message and then delete it from your system.

1 month, 1 week

4
5
0 0

[PATCH v5.10-v6.1] driver core: bus: Fix double free in driver API bus_register()

by Brennan Lamoreaux

From: Zijun Hu <quic_zijuhu(a)quicinc.com> [ Upstream commit bfa54a793ba77ef696755b66f3ac4ed00c7d1248 ] For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free. Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> Link: https://lore.kernel.org/r/20240727-bus_register_fix-v1-1-fed8dd0dba7a@quici… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [ Brennan : Backport requires bus->p = NULL instead of priv = NULL ] Signed-off-by: Brennan Lamoreaux <brennan.lamoreaux(a)broadcom.com> --- drivers/base/bus.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/bus.c b/drivers/base/bus.c index 339a9edcde5f..941532ddfdc6 100644 --- a/drivers/base/bus.c +++ b/drivers/base/bus.c @@ -853,6 +853,8 @@ int bus_register(struct bus_type *bus) bus_remove_file(bus, &bus_attr_uevent); bus_uevent_fail: kset_unregister(&bus->p->subsys); + /* Above kset_unregister() will kfree @bus->p */ + bus->p = NULL; out: kfree(bus->p); bus->p = NULL; -- 2.39.4

1 month, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024