October 2023 - Linux-stable-mirror

[PATCH][6.5, 6.1, 5.15] iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

by Nicolin Chen

commit d5afb4b47e13161b3f33904d45110f9e6463bad6 upstream. When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too since arm_smmu_mm_invalidate_range() is typically called next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_invalidate_range { arm_smmu_mm_invalidate_range { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. Signed-off-by: Nicolin Chen <nicolinc(a)nvidia.com> Link: https://lore.kernel.org/r/20230920052257.8615-1-nicolinc@nvidia.com Signed-off-by: Will Deacon <will(a)kernel.org> --- .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 27 ++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c index a5a63b1c947e..98d3ba7f9487 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c @@ -186,6 +186,15 @@ static void arm_smmu_free_shared_cd(struct arm_smmu_ctx_desc *cd) } } +/* + * Cloned from the MAX_TLBI_OPS in arch/arm64/include/asm/tlbflush.h, this + * is used as a threshold to replace per-page TLBI commands to issue in the + * command queue with an address-space TLBI command, when SMMU w/o a range + * invalidation feature handles too many per-page TLBI commands, which will + * otherwise result in a soft lockup. + */ +#define CMDQ_MAX_TLBI_OPS (1 << (PAGE_SHIFT - 3)) + static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn, struct mm_struct *mm, unsigned long start, unsigned long end) @@ -200,10 +209,22 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn, * range. So do a simple translation here by calculating size correctly. */ size = end - start; + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_RANGE_INV)) { + if (size >= CMDQ_MAX_TLBI_OPS * PAGE_SIZE) + size = 0; + } + + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) { + if (!size) + arm_smmu_tlb_inv_asid(smmu_domain->smmu, + smmu_mn->cd->asid); + else + arm_smmu_tlb_inv_range_asid(start, size, + smmu_mn->cd->asid, + PAGE_SIZE, false, + smmu_domain); + } - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) - arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid, - PAGE_SIZE, false, smmu_domain); arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size); } -- 2.42.0

2 years, 2 months

3
3
0 0

Request to cherry-pick a few Smack fixes

by Munehisa Kamata

Hi stable maintainers, The following upstream commits fix a couple of overlayfs handling problems in Smack. Could you please cherry-pick them for 4.19.y, 5.4.y, 5.10.y, 5.15.y and 6.1.y? #3 2c085f3a8f23 smack: Record transmuting in smk_transmuted #2 3a3d8fce31a4 smack: Retrieve transmuting information in smack_inode_getsecurity() #1 387ef964460f Smack:- Use overlay inode label in smack_inode_copy_up() # not needed for 6.1.y Note that 4.19.y needs some adjustments. I'll send backported patches separately. I'm not an author of these commits, but have been hitting the problems with multiple kernels based on the trees and it seems worth cherry-picking. Perhaps, it's better to add a tag in cherry-picked commits: Fixes: d6d80cb57be4 ("Smack: Base support for overlayfs") Regards, Munehisa

2 years, 2 months

2
7
0 0

[PATCH v3] can: sja1000: Always restart the Tx queue after an overrun

by Miquel Raynal

Upstream commit 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") fixes an issue with Renesas own SJA1000 CAN controller reception: the Rx buffer is only 5 messages long, so when the bus loaded (eg. a message every 50us), overrun may easily happen. Upon an overrun situation, due to a possible internal crosstalk situation, the controller enters a frozen state which only can be unlocked with a soft reset (experimentally). The solution was to offload a call to sja1000_start() in a threaded handler. This needs to happen in process context as this operation requires to sleep. sja1000_start() basically enters "reset mode", performs a proper software reset and returns back into "normal mode". Since this fix was introduced, we no longer observe any stalls in reception. However it was sporadically observed that the transmit path would now freeze. Further investigation blamed the fix mentioned above, and especially the reset operation. Reproducing the reset in a loop helped identifying what could possibly go wrong. The sja1000 is a single Tx queue device, which leverages the netdev helpers to process one Tx message at a time. The logic is: the queue is stopped, the message sent to the transceiver, once properly transmitted the controller sets a status bit which triggers an interrupt, in the interrupt handler the transmission status is checked and the queue woken up. Unfortunately, if an overrun happens, we might perform the soft reset precisely between the transmission of the buffer to the transceiver and the advent of the transmission status bit. We would then stop the transmission operation without re-enabling the queue, leading to all further transmissions to be ignored. The reset interrupt can only happen while the device is "open", and after a reset we anyway want to resume normal operations, no matter if a packet to transmit got dropped in the process, so we shall wake up the queue. Restarting the device and waking-up the queue is exactly what sja1000_set_mode(CAN_MODE_START) does. In order to be consistent about the queue state, we must acquire a lock both in the reset handler and in the transmit path to ensure serialization of both operations. It turns out, a lock is already held when entering the transmit path, so we can just acquire/release it as well with the regular net helpers inside the threaded interrupt handler and this way we should be safe. As the reset handler might still be called after the transmission of a frame to the transceiver but before it actually gets transmitted, we must ensure we don't leak the skb, so we free it (the behavior is consistent, no matter if there was an skb on the stack or not). Fixes: 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- Changes in v3: * Fix new implementation by just acquiring the tx lock when required. Changes in v2: * As Marc sugested, use netif_tx_{,un}lock() instead of our own spin_lock. drivers/net/can/sja1000/sja1000.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c index ae47fc72aa96..9531684d47cd 100644 --- a/drivers/net/can/sja1000/sja1000.c +++ b/drivers/net/can/sja1000/sja1000.c @@ -396,7 +396,13 @@ static irqreturn_t sja1000_reset_interrupt(int irq, void *dev_id) struct net_device *dev = (struct net_device *)dev_id; netdev_dbg(dev, "performing a soft reset upon overrun\n"); - sja1000_start(dev); + + netif_tx_lock(dev); + + can_free_echo_skb(dev, 0); + sja1000_set_mode(dev, CAN_MODE_START); + + netif_tx_unlock(dev); return IRQ_HANDLED; } -- 2.34.1

2 years, 2 months

2
2
0 0

[PATCH 13/16] drm/amd/display: Don't set dpms_off for seamless boot

by Tom Chung

From: Daniel Miess <daniel.miess(a)amd.com> [Why] eDPs fail to light up with seamless boot enabled [How] When seamless boot is enabled don't configure dpms_off in disable_vbios_mode_if_required. Reviewed-by: Charlene Liu <charlene.liu(a)amd.com> Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Daniel Miess <daniel.miess(a)amd.com> --- drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index bd4834f921c1..88d41bf6d53a 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -1230,6 +1230,9 @@ static void disable_vbios_mode_if_required( if (stream == NULL) continue; + if (stream->apply_seamless_boot_optimization) + continue; + // only looking for first odm pipe if (pipe->prev_odm_pipe) continue; -- 2.25.1

2 years, 2 months

1
0
0 0

[PATCH 05/16] drm/amd/display: Revert "drm/amd/display: remove duplicated edp relink to fastboot"

by Tom Chung

From: Aric Cyr <aric.cyr(a)amd.com> Revert commit a0b8a2c85d1b ("drm/amd/display: remove duplicated edp relink to fastboot") Because it cause 4k EDP not light up on boot Reviewed-by: Tom Chung <chiahsuan.chung(a)amd.com> Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Aric Cyr <aric.cyr(a)amd.com> --- drivers/gpu/drm/amd/display/dc/core/dc.c | 59 ++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index 63e97fb0a478..17a36953d3a9 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -1213,6 +1213,64 @@ static void disable_dangling_plane(struct dc *dc, struct dc_state *context) dc_release_state(current_ctx); } +static void disable_vbios_mode_if_required( + struct dc *dc, + struct dc_state *context) +{ + unsigned int i, j; + + /* check if timing_changed, disable stream*/ + for (i = 0; i < dc->res_pool->pipe_count; i++) { + struct dc_stream_state *stream = NULL; + struct dc_link *link = NULL; + struct pipe_ctx *pipe = NULL; + + pipe = &context->res_ctx.pipe_ctx[i]; + stream = pipe->stream; + if (stream == NULL) + continue; + + // only looking for first odm pipe + if (pipe->prev_odm_pipe) + continue; + + if (stream->link->local_sink && + stream->link->local_sink->sink_signal == SIGNAL_TYPE_EDP) { + link = stream->link; + } + + if (link != NULL && link->link_enc->funcs->is_dig_enabled(link->link_enc)) { + unsigned int enc_inst, tg_inst = 0; + unsigned int pix_clk_100hz; + + enc_inst = link->link_enc->funcs->get_dig_frontend(link->link_enc); + if (enc_inst != ENGINE_ID_UNKNOWN) { + for (j = 0; j < dc->res_pool->stream_enc_count; j++) { + if (dc->res_pool->stream_enc[j]->id == enc_inst) { + tg_inst = dc->res_pool->stream_enc[j]->funcs->dig_source_otg( + dc->res_pool->stream_enc[j]); + break; + } + } + + dc->res_pool->dp_clock_source->funcs->get_pixel_clk_frequency_100hz( + dc->res_pool->dp_clock_source, + tg_inst, &pix_clk_100hz); + + if (link->link_status.link_active) { + uint32_t requested_pix_clk_100hz = + pipe->stream_res.pix_clk_params.requested_pix_clk_100hz; + + if (pix_clk_100hz != requested_pix_clk_100hz) { + dc->link_srv->set_dpms_off(pipe); + pipe->stream->dpms_off = false; + } + } + } + } + } +} + static void wait_for_no_pipes_pending(struct dc *dc, struct dc_state *context) { int i; @@ -1782,6 +1840,7 @@ static enum dc_status dc_commit_state_no_check(struct dc *dc, struct dc_state *c dc_streams[i] = context->streams[i]; if (!dcb->funcs->is_accelerated_mode(dcb)) { + disable_vbios_mode_if_required(dc, context); dc->hwss.enable_accelerated_mode(dc, context); } -- 2.25.1

2 years, 2 months

1
0
0 0

v6.5 backport request: 6d2779ecaeb56f92 ("locking/atomic: scripts: fix fallback ifdeffery")

by Mark Rutland

Hi, Could we please backport commit: 6d2779ecaeb56f92d7105c56772346c71c88c278 ("locking/atomic: scripts: fix fallback ifdeffery") ... to the 6.5.y stable tree? I forgot to Cc stable when I submitted the original patch, and had (mistakenly) assumed that the Fixes tag was sufficient. The patch fixes a dentry cache corruption issue observed on arm64 and which is in theory possible on other architectures. I've recevied an off-list report from someone who's hit the issue on the v6.5.y tree specifically. Thanks, Mark

2 years, 2 months

2
2
0 0

Re: [PATCH] usb: core: add bos NULL pointer checking condition

by Greg KH

On Wed, Oct 04, 2023 at 03:26:42PM +0900, Woo-kwang Lee wrote: > This issue occurs when connecting Galaxy S22 and abnormal SEC Dex Adapter. > When the abnormal adapter is connected, kernel panic always occurs after a > few seconds. > This occurs due to unable to get BOS descriptor, usb_release_bos_descriptor > set dev->bos = NULL. > > - usb_reset_and_verify_device > - hub_port_init > - usb_release_bos_descriptor > - dev->bos = NULL; > > hub_port_connect_change() calls portspeed(), and portspeed() calls hub_is_s > uperspeedplus(). > Finally, hub_is_superspeedplus() calls hdev->bos->ssp_cap. > It needs to check hdev->bos is NULL to prevent a kernel panic. > > usb 3-1: new SuperSpeed Gen 1 USB device number 16 using xhci-hcd-exynos > usb 3-1: unable to get BOS descriptor set > usb 3-1: Product: USB3.0 Hub > Unable to handle kernel NULL pointer dereference at virtual address 0000018 > > Call trace: > hub_port_connect_change+0x8c/0x538 > port_event+0x244/0x764 > hub_event+0x158/0x474 > process_one_work+0x204/0x550 > worker_thread+0x28c/0x580 > kthread+0x13c/0x178 > ret_from_fork+0x10/0x30 > > - hub_port_connect_change > - portspeed > - hub_is_superspeedplus > > Fixes: 0cdd49a1d1a4 ("usb: Support USB 3.1 extended port status request") > Signed-off-by: Woo-kwang Lee <wookwang.lee(a)samsung.com> > --- > drivers/usb/core/hub.h | 2 ++ > 1 file changed, 2 insertions(+) Are you sure this isn't already fixed by commit f74a7afc224a ("usb: hub: Guard against accesses to uninitialized BOS descriptors") in linux-next? thanks, greg k-h

2 years, 2 months

3
3
0 0

[PATCH] drm/mediatek: Correctly free sg_table in gem prime vmap

by Chen-Yu Tsai

The MediaTek DRM driver implements GEM PRIME vmap by fetching the sg_table for the object, iterating through the pages, and then vmapping them. In essence, unlike the GEM DMA helpers which vmap when the object is first created or imported, the MediaTek version does it on request. Unfortunately, the code never correctly frees the sg_table contents. This results in a kernel memory leak. On a Hayato device with a text console on the internal display, this results in the system running out of memory in a few days from all the console screen cursor updates. Add sg_free_table() to correctly free the contents of the sg_table. This was missing despite explicitly required by mtk_gem_prime_get_sg_table(). Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap function") Cc: <stable(a)vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wenst(a)chromium.org> --- Please merge for v6.6 fixes. Also, I was wondering why the MediaTek DRM driver implements a lot of the GEM functionality itself, instead of using the GEM DMA helpers. From what I could tell, the code closely follows the DMA helpers, except that it vmaps the buffers only upon request. drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c index 9f364df52478..297ee090e02e 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c @@ -239,6 +239,7 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map) npages = obj->size >> PAGE_SHIFT; mtk_gem->pages = kcalloc(npages, sizeof(*mtk_gem->pages), GFP_KERNEL); if (!mtk_gem->pages) { + sg_free_table(sgt); kfree(sgt); return -ENOMEM; } @@ -248,11 +249,13 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map) mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP, pgprot_writecombine(PAGE_KERNEL)); if (!mtk_gem->kvaddr) { + sg_free_table(sgt); kfree(sgt); kfree(mtk_gem->pages); return -ENOMEM; } out: + sg_free_table(sgt); kfree(sgt); iosys_map_set_vaddr(map, mtk_gem->kvaddr); -- 2.42.0.582.g8ccd20d70d-goog

2 years, 2 months

3
3
0 0

bluetooth issues since kernel 6.4 - not discovering other bt devices - /linux/drivers/bluetooth/btusb.c

by Erik Dobák

Hello! I bought a new laptop fujitsu life book and everything is going fine on artix just the bt makes trouble: /var/log/error.log Sep 30 18:43:48 nexus bluetoothd[2266]: src/adapter.c:reset_adv_monitors_complete() Failed to reset Adv Monitors: Failed (0x03) Sep 30 18:43:48 nexus bluetoothd[2266]: Failed to clear UUIDs: Failed (0x03) Sep 30 18:43:48 nexus bluetoothd[2266]: Failed to add UUID: Failed (0x03) Sep 30 18:43:48 nexus bluetoothd[2266]: Failed to add UUID: Failed (0x03) i searched a bit the webs and found a new commit at kernel org that does do the trouble: https://bugs.archlinux.org/task/78980 follow the linkeys inside the commits there or read this one: ---------------before------------------------------------ /* interface numbers are hardcoded in the spec */ if (intf->cur_altsetting->desc.bInterfaceNumber != 0) { if (!(id->driver_info & BTUSB_IFNUM_2)) return -ENODEV; if (intf->cur_altsetting->desc.bInterfaceNumber != 2) return -ENODEV; } -----------after---------------------------------------------------- if ((id->driver_info & BTUSB_IFNUM_2) && (intf->cur_altsetting->desc.bInterfaceNumber != 0) && (intf->cur_altsetting->desc.bInterfaceNumber != 2)) return -ENODEV; -------------------------------------------------------- the dude just hooked up 3 conditions in a row with && where before it was 2 conditions in 1 condition. + the comment was removed. please reconsider this commit. Yours E

2 years, 2 months

5
10
0 0

Re: [PATCH] usb: core: add bos NULL pointer checking condition

by kernel test robot

Hi, Thanks for your patch. FYI: kernel test robot notices the stable kernel rule is not satisfied. The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html/#op… Rule: add the tag "Cc: stable(a)vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree. Subject: [PATCH] usb: core: add bos NULL pointer checking condition Link: https://lore.kernel.org/stable/20231004062642.16431-1-wookwang.lee%40samsun… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023