July 2025 - Linux-stable-mirror

[PATCH v2] iommu/amd: Fix geometry.aperture_end for V2 tables

by Jason Gunthorpe

The AMD IOMMU documentation seems pretty clear that the V2 table follows the normal CPU expectation of sign extension. This is shown in Figure 25: AMD64 Long Mode 4-Kbyte Page Address Translation Where bits Sign-Extend [63:57] == [56]. This is typical for x86 which would have three regions in the page table: lower, non-canonical, upper. The manual describes that the V1 table does not sign extend in section 2.2.4 Sharing AMD64 Processor and IOMMU Page Tables GPA-to-SPA Further, Vasant has checked this and indicates the HW has an addtional behavior that the manual does not yet describe. The AMDv2 table does not have the sign extended behavior when attached to PASID 0, which may explain why this has gone unnoticed. The iommu domain geometry does not directly support sign extended page tables. The driver should report only one of the lower/upper spaces. Solve this by removing the top VA bit from the geometry to use only the lower space. This will also make the iommu_domain work consistently on all PASID 0 and PASID != 1. Adjust dma_max_address() to remove the top VA bit. It now returns: 5 Level: Before 0x1ffffffffffffff After 0x0ffffffffffffff 4 Level: Before 0xffffffffffff After 0x7fffffffffff Fixes: 11c439a19466 ("iommu/amd/pgtbl_v2: Fix domain max address") Link: https://lore.kernel.org/all/8858d4d6-d360-4ef0-935c-bfd13ea54f42@amd.com/ Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/iommu/amd/iommu.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) v2: - Revise the commit message and comment with the new information from Vasant. v1: https://patch.msgid.link/r/0-v1-6925ece6b623+296-amdv2_geo_jgg@nvidia.com diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 3117d99cf83d0d..1baa9d3583f369 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -2526,8 +2526,21 @@ static inline u64 dma_max_address(enum protection_domain_mode pgtable) if (pgtable == PD_MODE_V1) return ~0ULL; - /* V2 with 4/5 level page table */ - return ((1ULL << PM_LEVEL_SHIFT(amd_iommu_gpt_level)) - 1); + /* + * V2 with 4/5 level page table. Note that "2.2.6.5 AMD64 4-Kbyte Page + * Translation" shows that the V2 table sign extends the top of the + * address space creating a reserved region in the middle of the + * translation, just like the CPU does. Further Vasant says the docs are + * incomplete and this only applies to non-zero PASIDs. If the AMDv2 + * page table is assigned to the 0 PASID then there is no sign extension + * check. + * + * Since the IOMMU must have a fixed geometry, and the core code does + * not understand sign extended addressing, we have to chop off the high + * bit to get consistent behavior with attachments of the domain to any + * PASID. + */ + return ((1ULL << (PM_LEVEL_SHIFT(amd_iommu_gpt_level) - 1)) - 1); } static bool amd_iommu_hd_support(struct amd_iommu *iommu) base-commit: eb328711b15b17987021dbb674f446b7b008dca5 -- 2.43.0

1 month, 1 week

4
8
0 0

[PATCH] ARM: AM33xx: Implement TI advisory 1.0.36 (EMU0/EMU1 pins state on reset)

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> There is an issue possible where TI AM33xx SoCs do not boot properly after a reset if EMU0/EMU1 pins were used as GPIO and have been driving low level actively prior to reset [1]. "Advisory 1.0.36 EMU0 and EMU1: Terminals Must be Pulled High Before ICEPick Samples The state of the EMU[1:0] terminals are latched during reset to determine ICEPick boot mode. For normal device operation, these terminals must be pulled up to a valid high logic level ( > VIH min) before ICEPick samples the state of these terminals, which occurs [five CLK_M_OSC clock cycles - 10 ns] after the falling edge of WARMRSTn. Many applications may not require the secondary GPIO function of the EMU[1:0] terminals. In this case, they would only be connected to pull-up resistors, which ensures they are always high when ICEPick samples. However, some applications may need to use these terminals as GPIO where they could be driven low before reset is asserted. This usage of the EMU[1:0] terminals may require special attention to ensure the terminals are allowed to return to a valid high-logic level before ICEPick samples the state of these terminals. When any device reset is asserted, the pin mux mode of EMU[1:0] terminals configured to operate as GPIO (mode 7) will change back to EMU input (mode 0) on the falling edge of WARMRSTn. This only provides a short period of time for the terminals to return high if driven low before reset is asserted... If the EMU[1:0] terminals are configured to operate as GPIO, the product should be designed such these terminals can be pulled to a valid high-logic level within 190 ns after the falling edge of WARMRSTn." We've noticed this problem with custom am335x hardware in combination with recently implemented cold reset method (commit 6521f6a195c70 ("ARM: AM33xx: PRM: Implement REBOOT_COLD")). It looks like the problem can affect other HW, for instance AM335x Chiliboard, because the latter has LEDs on GPIO3_7/GPIO3_8 as well. One option would be to check if the pins are in GPIO mode and either switch to output active high, or switch to input and poll until the external pull-ups have brought the pins to the desired high state. But fighting with GPIO driver for these pins is probably not the most straight forward approch in a reboot handler. Fortunately we can easily control pinmuxing here and rely on the external pull-ups. TI recommends 4k7 external pull up resistors [2] and even with quite conservative estimation for pin capacity (1 uF should never happen) the required delay shall not exceed 5ms. [1] Link: https://www.ti.com/lit/pdf/sprz360 [2] Link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/8… Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- arch/arm/mach-omap2/am33xx-restart.c | 36 ++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/arch/arm/mach-omap2/am33xx-restart.c b/arch/arm/mach-omap2/am33xx-restart.c index fcf3d557aa786..3cdf223addcc2 100644 --- a/arch/arm/mach-omap2/am33xx-restart.c +++ b/arch/arm/mach-omap2/am33xx-restart.c @@ -2,12 +2,46 @@ /* * am33xx-restart.c - Code common to all AM33xx machines. */ +#include <dt-bindings/pinctrl/am33xx.h> +#include <linux/delay.h> #include <linux/kernel.h> #include <linux/reboot.h> #include "common.h" +#include "control.h" #include "prm.h" +/* + * Advisory 1.0.36 EMU0 and EMU1: Terminals Must be Pulled High Before + * ICEPick Samples + * + * If EMU0/EMU1 pins have been used as GPIO outputs and actively driving low + * level, the device might not reboot in normal mode. We are in a bad position + * to override GPIO state here, so just switch the pins into EMU input mode + * (that's what reset will do anyway) and wait a bit, because the state will be + * latched 190 ns after reset. + */ +static void am33xx_advisory_1_0_36(void) +{ + u32 emu0 = omap_ctrl_readl(AM335X_PIN_EMU0); + u32 emu1 = omap_ctrl_readl(AM335X_PIN_EMU1); + + /* If both pins are in EMU mode, nothing to do */ + if (!(emu0 & 7) && !(emu1 & 7)) + return; + + /* Switch GPIO3_7/GPIO3_8 into EMU0/EMU1 modes respectively */ + omap_ctrl_writel(emu0 & ~7, AM335X_PIN_EMU0); + omap_ctrl_writel(emu1 & ~7, AM335X_PIN_EMU1); + + /* + * Give pull-ups time to load the pin/PCB trace capacity. + * 5 ms shall be enough to load 1 uF (would be huge capacity for these + * pins) with TI-recommended 4k7 external pull-ups. + */ + mdelay(5); +} + /** * am33xx_restart - trigger a software restart of the SoC * @mode: the "reboot mode", see arch/arm/kernel/{setup,process}.c @@ -18,6 +52,8 @@ */ void am33xx_restart(enum reboot_mode mode, const char *cmd) { + am33xx_advisory_1_0_36(); + /* TODO: Handle cmd if necessary */ prm_reboot_mode = mode; -- 2.50.1

1 month, 1 week

1
0
0 0

Backport 36569780b0d6 ("sched: Change nr_uninterruptible type to unsigned long") to linux-stable

by Aruna Ramakrishna

Hi maintainers, Please consider backporting this upstream commit: 36569780b0d6 ("sched: Change nr_uninterruptible type to unsigned long”) into all stable branches newer than (and including) linux-5.14.y. This fixes an overflow bug introduced in commit: e6fe3f422be1 ("sched: Make multiple runqueue task counters 32-bit”) which was merged into 5.14. I forgot to tag the original patch for inclusion into stable - I apologize for the oversight. The patch should apply cleanly to all versions - let me know if you’d like me to send a separate patch for stable. Thanks very much, Aruna

1 month, 1 week

1
0
0 0

[PATCH net] phonet/pep: Move call to pn_skb_get_dst_sockaddr() earlier in pep_sock_accept()

by Nathan Chancellor

A new warning in clang [1] points out a place in pep_sock_accept() where dst is uninitialized then passed as a const pointer to pep_find_pipe(): net/phonet/pep.c:829:37: error: variable 'dst' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 829 | newsk = pep_find_pipe(&pn->hlist, &dst, pipe_handle); | ^~~: Move the call to pn_skb_get_dst_sockaddr(), which initializes dst, to before the call to pep_find_pipe(), so that dst is consistently used initialized throughout the function. Cc: stable(a)vger.kernel.org Fixes: f7ae8d59f661 ("Phonet: allocate sock from accept syscall rather than soft IRQ") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d44… [1] Closes: https://github.com/ClangBuiltLinux/linux/issues/2101 Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- net/phonet/pep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/phonet/pep.c b/net/phonet/pep.c index 53a858478e22..62527e1ebb88 100644 --- a/net/phonet/pep.c +++ b/net/phonet/pep.c @@ -826,6 +826,7 @@ static struct sock *pep_sock_accept(struct sock *sk, } /* Check for duplicate pipe handle */ + pn_skb_get_dst_sockaddr(skb, &dst); newsk = pep_find_pipe(&pn->hlist, &dst, pipe_handle); if (unlikely(newsk)) { __sock_put(newsk); @@ -850,7 +851,6 @@ static struct sock *pep_sock_accept(struct sock *sk, newsk->sk_destruct = pipe_destruct; newpn = pep_sk(newsk); - pn_skb_get_dst_sockaddr(skb, &dst); pn_skb_get_src_sockaddr(skb, &src); newpn->pn_sk.sobject = pn_sockaddr_get_object(&dst); newpn->pn_sk.dobject = pn_sockaddr_get_object(&src); --- base-commit: 0e9418961f897be59b1fab6e31ae1b09a0bae902 change-id: 20250715-net-phonet-fix-uninit-const-pointer-64f0182b11e1 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 month, 1 week

2
1
0 0

[PATCH v9 1/4] serial: 8250: fix panic due to PSLVERR

by Yunhui Cui

When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Cc: stable(a)vger.kernel.org --- drivers/tty/serial/8250/8250_port.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 6d7b8c4667c9c..07fe818dffa34 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2376,9 +2376,10 @@ int serial8250_do_startup(struct uart_port *port) /* * Now, initialize the UART */ - serial_port_out(port, UART_LCR, UART_LCR_WLEN8); uart_port_lock_irqsave(port, &flags); + serial_port_out(port, UART_LCR, UART_LCR_WLEN8); + if (up->port.flags & UPF_FOURPORT) { if (!up->port.irq) up->port.mctrl |= TIOCM_OUT1; -- 2.39.5

1 month, 1 week

4
3
0 0

[PATCH v2 1/3] bus: mhi: host: keep bhi buffer through suspend cycle

by Muhammad Usama Anjum

When there is memory pressure, at resume time dma_alloc_coherent() returns error which in turn fails the loading of firmware and hence the driver crashes: kernel: kworker/u33:5: page allocation failure: order:7, mode:0xc04(GFP_NOIO|GFP_DMA32), nodemask=(null),cpuset=/,mems_allowed=0 kernel: CPU: 1 UID: 0 PID: 7693 Comm: kworker/u33:5 Not tainted 6.11.11-valve17-1-neptune-611-g027868a0ac03 #1 3843143b92e9da0fa2d3d5f21f51beaed15c7d59 kernel: Hardware name: Valve Galileo/Galileo, BIOS F7G0112 08/01/2024 kernel: Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi] kernel: Call Trace: kernel: <TASK> kernel: dump_stack_lvl+0x4e/0x70 kernel: warn_alloc+0x164/0x190 kernel: ? srso_return_thunk+0x5/0x5f kernel: ? __alloc_pages_direct_compact+0xaf/0x360 kernel: __alloc_pages_slowpath.constprop.0+0xc75/0xd70 kernel: __alloc_pages_noprof+0x321/0x350 kernel: __dma_direct_alloc_pages.isra.0+0x14a/0x290 kernel: dma_direct_alloc+0x70/0x270 kernel: mhi_fw_load_handler+0x126/0x340 [mhi a96cb91daba500cc77f86bad60c1f332dc3babdf] kernel: mhi_pm_st_worker+0x5e8/0xac0 [mhi a96cb91daba500cc77f86bad60c1f332dc3babdf] kernel: ? srso_return_thunk+0x5/0x5f kernel: process_one_work+0x17e/0x330 kernel: worker_thread+0x2ce/0x3f0 kernel: ? __pfx_worker_thread+0x10/0x10 kernel: kthread+0xd2/0x100 kernel: ? __pfx_kthread+0x10/0x10 kernel: ret_from_fork+0x34/0x50 kernel: ? __pfx_kthread+0x10/0x10 kernel: ret_from_fork_asm+0x1a/0x30 kernel: </TASK> kernel: Mem-Info: kernel: active_anon:513809 inactive_anon:152 isolated_anon:0 active_file:359315 inactive_file:2487001 isolated_file:0 unevictable:637 dirty:19 writeback:0 slab_reclaimable:160391 slab_unreclaimable:39729 mapped:175836 shmem:51039 pagetables:4415 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:125666 free_pcp:0 free_cma:0 In above example, if we sum all the consumed memory, it comes out to be 15.5GB and free memory is ~ 500MB from a total of 16GB RAM. Even though memory is present. But all of the dma memory has been exhausted or fragmented. Fix it by allocating it only once and then reuse the same allocated memory. As we'll allocate this memory only once, this memory will stay allocated. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6 Fixes: cd457afb1667 ("bus: mhi: core: Add support for downloading firmware over BHIe") Cc: stable(a)vger.kernel.org Cc: Krishna Chaitanya Chundru <krishna.chundru(a)oss.qualcomm.com> Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- Reported here: https://lore.kernel.org/all/ead32f5b-730a-4b81-b38f-93d822f990c6@collabora.… Still a lot of more fixes are required. Hence, I'm not adding closes tag. Changes since v1: - fix mhi_load_image_bhi() - Cc stable and fix tested on tag --- drivers/bus/mhi/host/boot.c | 25 +++++++++++++++---------- drivers/bus/mhi/host/init.c | 5 +++++ drivers/bus/mhi/host/internal.h | 2 ++ include/linux/mhi.h | 1 + 4 files changed, 23 insertions(+), 10 deletions(-) diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c index b3a85aa3c4768..9fc983bc12d49 100644 --- a/drivers/bus/mhi/host/boot.c +++ b/drivers/bus/mhi/host/boot.c @@ -302,8 +302,8 @@ static int mhi_fw_load_bhi(struct mhi_controller *mhi_cntrl, return -EIO; } -static void mhi_free_bhi_buffer(struct mhi_controller *mhi_cntrl, - struct image_info *image_info) +void mhi_free_bhi_buffer(struct mhi_controller *mhi_cntrl, + struct image_info *image_info) { struct mhi_buf *mhi_buf = image_info->mhi_buf; @@ -455,18 +455,23 @@ static enum mhi_fw_load_type mhi_fw_load_type_get(const struct mhi_controller *m static int mhi_load_image_bhi(struct mhi_controller *mhi_cntrl, const u8 *fw_data, size_t size) { - struct image_info *image; + struct image_info **image = &mhi_cntrl->bhi_image; int ret; - ret = mhi_alloc_bhi_buffer(mhi_cntrl, &image, size); - if (ret) - return ret; + if (!(*image)) { + ret = mhi_alloc_bhi_buffer(mhi_cntrl, image, size); + if (ret) + return ret; - /* Load the firmware into BHI vec table */ - memcpy(image->mhi_buf->buf, fw_data, size); + /* Load the firmware into BHI vec table */ + memcpy((*image)->mhi_buf->buf, fw_data, size); + } - ret = mhi_fw_load_bhi(mhi_cntrl, &image->mhi_buf[image->entries - 1]); - mhi_free_bhi_buffer(mhi_cntrl, image); + ret = mhi_fw_load_bhi(mhi_cntrl, &(*image)->mhi_buf[(*image)->entries - 1]); + if (ret) { + mhi_free_bhi_buffer(mhi_cntrl, *image); + *image = NULL; + } return ret; } diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c index 6e06e4efec765..2e0f18c939e68 100644 --- a/drivers/bus/mhi/host/init.c +++ b/drivers/bus/mhi/host/init.c @@ -1228,6 +1228,11 @@ void mhi_unprepare_after_power_down(struct mhi_controller *mhi_cntrl) mhi_cntrl->rddm_image = NULL; } + if (mhi_cntrl->bhi_image) { + mhi_free_bhi_buffer(mhi_cntrl, mhi_cntrl->bhi_image); + mhi_cntrl->bhi_image = NULL; + } + mhi_deinit_dev_ctxt(mhi_cntrl); } EXPORT_SYMBOL_GPL(mhi_unprepare_after_power_down); diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h index 1054e67bb450d..60b0699323375 100644 --- a/drivers/bus/mhi/host/internal.h +++ b/drivers/bus/mhi/host/internal.h @@ -324,6 +324,8 @@ int mhi_alloc_bhie_table(struct mhi_controller *mhi_cntrl, struct image_info **image_info, size_t alloc_size); void mhi_free_bhie_table(struct mhi_controller *mhi_cntrl, struct image_info *image_info); +void mhi_free_bhi_buffer(struct mhi_controller *mhi_cntrl, + struct image_info *image_info); /* Power management APIs */ enum mhi_pm_state __must_check mhi_tryset_pm_state( diff --git a/include/linux/mhi.h b/include/linux/mhi.h index 4c567907933a5..593012f779d97 100644 --- a/include/linux/mhi.h +++ b/include/linux/mhi.h @@ -391,6 +391,7 @@ struct mhi_controller { size_t reg_len; struct image_info *fbc_image; struct image_info *rddm_image; + struct image_info *bhi_image; struct mhi_chan *mhi_chan; struct list_head lpm_chans; int *irq; -- 2.39.5

1 month, 1 week

3
4
0 0

[PATCH v2 0/1] nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails

by Rick Wertenbroek

Changes from v1 : - Updated comment for nvmet_pci_epf_queue_response() per Damien's suggestion. - Fixed typo in commit message. - Added 3 tags in commit message: Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Cc: stable(a)vger.kernel.org Best regards, Rick Rick Wertenbroek (1): nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails drivers/nvme/target/pci-epf.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) -- 2.25.1

1 month, 1 week

4
4
0 0

[PATCH v2 1/1] arm64: dts: qcom: x1e80100-pmics: Disable pm8010 by default

by Aleksandrs Vinarskis

pm8010 is a camera specific PMIC, and may not be present on some devices. These may instead use a dedicated vreg for this purpose (Dell XPS 9345, Dell Inspiron..) or use USB webcam instead of a MIPI one alltogether (Lenovo Thinbook 16, Lenovo Yoga..). Disable pm8010 by default, let platforms that actually have one onboard enable it instead. Cc: <stable(a)vger.kernel.org> Fixes: 2559e61e7ef4 ("arm64: dts: qcom: x1e80100-pmics: Add the missing PMICs") Reviewed-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis(a)gmail.com> --- arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi index e3888bc143a0..621890ada153 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi @@ -475,6 +475,8 @@ pm8010: pmic@c { #address-cells = <1>; #size-cells = <0>; + status = "disabled"; + pm8010_temp_alarm: temp-alarm@2400 { compatible = "qcom,spmi-temp-alarm"; reg = <0x2400>; -- 2.48.1

1 month, 1 week

1
1
0 0

[PATCH v2] drm/sched: Remove optimization that causes hang when killing dependent jobs

by Lin.Cao

When application A submits jobs and application B submits a job with a dependency on A's fence, the normal flow wakes up the scheduler after processing each job. However, the optimization in drm_sched_entity_add_dependency_cb() uses a callback that only clears dependencies without waking up the scheduler. When application A is killed before its jobs can run, the callback gets triggered but only clears the dependency without waking up the scheduler, causing the scheduler to enter sleep state and application B to hang. Remove the optimization by deleting drm_sched_entity_clear_dep() and its usage, ensuring the scheduler is always woken up when dependencies are cleared. Fixes: 777dbd458c89 ("drm/amdgpu: drop a dummy wakeup scheduler") Cc: stable(a)vger.kernel.org # v4.6+ Signed-off-by: Lin.Cao <lincao12(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/scheduler/sched_entity.c | 21 ++------------------- 1 file changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index e671aa241720..ac678de7fe5e 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -355,17 +355,6 @@ void drm_sched_entity_destroy(struct drm_sched_entity *entity) } EXPORT_SYMBOL(drm_sched_entity_destroy); -/* drm_sched_entity_clear_dep - callback to clear the entities dependency */ -static void drm_sched_entity_clear_dep(struct dma_fence *f, - struct dma_fence_cb *cb) -{ - struct drm_sched_entity *entity = - container_of(cb, struct drm_sched_entity, cb); - - entity->dependency = NULL; - dma_fence_put(f); -} - /* * drm_sched_entity_wakeup - callback to clear the entity's dependency and * wake up the scheduler @@ -376,7 +365,8 @@ static void drm_sched_entity_wakeup(struct dma_fence *f, struct drm_sched_entity *entity = container_of(cb, struct drm_sched_entity, cb); - drm_sched_entity_clear_dep(f, cb); + entity->dependency = NULL; + dma_fence_put(f); drm_sched_wakeup(entity->rq->sched); } @@ -429,13 +419,6 @@ static bool drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity) fence = dma_fence_get(&s_fence->scheduled); dma_fence_put(entity->dependency); entity->dependency = fence; - if (!dma_fence_add_callback(fence, &entity->cb, - drm_sched_entity_clear_dep)) - return true; - - /* Ignore it when it is already scheduled */ - dma_fence_put(fence); - return false; } if (!dma_fence_add_callback(entity->dependency, &entity->cb, -- 2.46.1

1 month, 1 week

2
1
0 0

[PATCH v4 2/9] vsock/virtio: Validate length in packet header before skb_put()

by Will Deacon

When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). Cc: <stable(a)vger.kernel.org> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Signed-off-by: Will Deacon <will(a)kernel.org> --- net/vmw_vsock/virtio_transport.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index f0e48e6911fc..eb08a393413d 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -624,8 +624,9 @@ static void virtio_transport_rx_work(struct work_struct *work) do { virtqueue_disable_cb(vq); for (;;) { + unsigned int len, payload_len; + struct virtio_vsock_hdr *hdr; struct sk_buff *skb; - unsigned int len; if (!virtio_transport_more_replies(vsock)) { /* Stop rx until the device processes already @@ -642,12 +643,19 @@ static void virtio_transport_rx_work(struct work_struct *work) vsock->rx_buf_nr--; /* Drop short/long packets */ - if (unlikely(len < sizeof(struct virtio_vsock_hdr) || + if (unlikely(len < sizeof(*hdr) || len > virtio_vsock_skb_len(skb))) { kfree_skb(skb); continue; } + hdr = virtio_vsock_hdr(skb); + payload_len = le32_to_cpu(hdr->len); + if (unlikely(payload_len > len - sizeof(*hdr))) { + kfree_skb(skb); + continue; + } + virtio_vsock_skb_rx_put(skb); virtio_transport_deliver_tap_pkt(skb); virtio_transport_recv_pkt(&virtio_transport, skb); -- 2.50.0.727.gbf7dc18ff4-goog

1 month, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025