- Linux-stable-mirror - lists.linaro.org

[PATCH] arm64: dts: ti: k3-j721e-sk: Fix pinmux for power regulator

by Siddharth Vadapalli

Commit under Fixes added support for power regulators on the J721E SK board. However, while doing so, it incorrectly assigned a non-existent pinmux within the WKUP Pinmux region (pinctrl@4301c000) instead of using the MAIN Pinmux region (pinctrl@11c000). This leads to the following silent failure: pinctrl-single 4301c000.pinctrl: mux offset out of range: 0x1dc (0x178) The datasheet for the J721E SoC [0] specifies on page 142 that the pinmux of interest which is Ball Y1 is PADCONFIG119 and the address corresponding to it is 0x00011C1DC which belongs to the MAIN Pinmux region. Hence, fix this. [0]: https://www.ti.com/lit/ds/symlink/tda4vm.pdf Fixes: 97b67cc102dc ("arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators") Cc: <stable(a)vger.kernel.org> Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- Hello, This patch is based on commit e7c375b18160 Merge tag 'vfs-6.18-rc7.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs of Mainline Linux. Regards, Siddharth. arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts index 5e5784ef6f85..77dcc160eda3 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts @@ -474,6 +474,12 @@ rpi_header_gpio1_pins_default: rpi-header-gpio1-default-pins { J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */ >; }; + + vdd_sd_dv_pins_default: vdd-sd-dv-default-pins { + pinctrl-single,pins = < + J721E_IOPAD(0x1dc, PIN_OUTPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */ + >; + }; }; &wkup_pmx0 { @@ -536,12 +542,6 @@ J721E_WKUP_IOPAD(0xd4, PIN_OUTPUT, 7) /* (G26) WKUP_GPIO0_9 */ >; }; - vdd_sd_dv_pins_default: vdd-sd-dv-default-pins { - pinctrl-single,pins = < - J721E_IOPAD(0x1dc, PIN_OUTPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */ - >; - }; - wkup_uart0_pins_default: wkup-uart0-default-pins { pinctrl-single,pins = < J721E_WKUP_IOPAD(0xa0, PIN_INPUT, 0) /* (J29) WKUP_UART0_RXD */ -- 2.51.1

3 days, 7 hours

3
5
0 0

[PATCH 6.12] uio_hv_generic: Set event for all channels on the device

by Naman Jain

From: Long Li <longli(a)microsoft.com> Hyper-V may offer a non latency sensitive device with subchannels without monitor bit enabled. The decision is entirely on the Hyper-V host not configurable within guest. When a device has subchannels, also signal events for the subchannel if its monitor bit is disabled. This patch also removes the memory barrier when monitor bit is enabled as it is not necessary. The memory barrier is only needed between setting up interrupt mask and calling vmbus_set_event() when monitor bit is disabled. This is a backport of the upstream commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device") with minor modifications to resolve merge conflicts. Original change was not a fix, but it needs to be backported to fix a NULL pointer crash resulting from missing interrupt mask setting. Commit 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt mask") removed the default setting of interrupt_mask for channels (including subchannels) in the uio_hv_generic driver, as it relies on the user space to take care of managing it. This approach works fine when user space can control this setting using the irqcontrol interface provided for uio devices. Support for setting the interrupt mask through this interface for subchannels came only after commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device"). On older kernels, this change is not present. With uio_hv_generic no longer setting the interrupt_mask, and userspace not having the capability to set it, it remains unset, and interrupts can come for the subchannels, which can result in a crash in hv_uio_channel_cb. Backport the change to older kernels, where this change was not present, to allow userspace to set the interrupt mask properly for subchannels. Additionally, this patch also adds certain checks for primary vs subchannels in the hv_uio_channel_cb, which can gracefully handle these two cases and prevent the NULL pointer crashes. Signed-off-by: Long Li <longli(a)microsoft.com> Reviewed-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> Fixes: 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt mask") Cc: <stable(a)vger.kernel.org> # 6.12.x Signed-off-by: Naman Jain <namjain(a)linux.microsoft.com> --- drivers/uio/uio_hv_generic.c | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 0b414d1168dd..aa7593cea2e3 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -65,6 +65,16 @@ struct hv_uio_private_data { char send_name[32]; }; +static void set_event(struct vmbus_channel *channel, s32 irq_state) +{ + channel->inbound.ring_buffer->interrupt_mask = !irq_state; + if (!channel->offermsg.monitor_allocated && irq_state) { + /* MB is needed for host to see the interrupt mask first */ + virt_mb(); + vmbus_set_event(channel); + } +} + /* * This is the irqcontrol callback to be registered to uio_info. * It can be used to disable/enable interrupt from user space processes. @@ -79,12 +89,15 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) { struct hv_uio_private_data *pdata = info->priv; struct hv_device *dev = pdata->device; + struct vmbus_channel *primary, *sc; - dev->channel->inbound.ring_buffer->interrupt_mask = !irq_state; - virt_mb(); + primary = dev->channel; + set_event(primary, irq_state); - if (!dev->channel->offermsg.monitor_allocated && irq_state) - vmbus_setevent(dev->channel); + mutex_lock(&vmbus_connection.channel_mutex); + list_for_each_entry(sc, &primary->sc_list, sc_list) + set_event(sc, irq_state); + mutex_unlock(&vmbus_connection.channel_mutex); return 0; } @@ -95,11 +108,18 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) static void hv_uio_channel_cb(void *context) { struct vmbus_channel *chan = context; - struct hv_device *hv_dev = chan->device_obj; - struct hv_uio_private_data *pdata = hv_get_drvdata(hv_dev); + struct hv_device *hv_dev; + struct hv_uio_private_data *pdata; virt_mb(); + /* + * The callback may come from a subchannel, in which case look + * for the hv device in the primary channel + */ + hv_dev = chan->primary_channel ? + chan->primary_channel->device_obj : chan->device_obj; + pdata = hv_get_drvdata(hv_dev); uio_event_notify(&pdata->info); } -- 2.34.1

3 days, 8 hours

2
2
0 0

Buyers Of Petroleum Products Needed

by HR

Dear Sir/Madam, Are you in need of petroleum products, or do you represent a buyer? We currently have available allocations for EN590 10PPM, Aviation Fuel, D6 Virgin Fuel, LNG, LPG, PETCOKE, Jet Fuel A1, and more. These can be loaded in Kazakhstan, Fujairah, Rotterdam, Houston, and various locations within the Middle East. We offer flexible delivery options on CIF or FOB terms. We would be pleased to discuss your requirements further. Best regards, Krystian Misiaszek Email: hr(a)trlgas.com mailto:hr@trlgas.com WhatsApp: +48732104293

3 days, 10 hours

1
0
0 0

[PATCH v2] arm64: dts: rockchip: orangepi-5: fix PCIe 3.3V regulator voltage

by Mykola Kvach

The vcc3v3_pcie20 fixed regulator powers the PCIe device-side 3.3V rail for pcie2x1l2 via vpcie3v3-supply. The DTS mistakenly set its regulator-min/max-microvolt to 1800000 (1.8 V). Correct both to 3300000 (3.3 V) to match the rail name, the PCIe/M.2 power requirement, and the actual hardware wiring on Orange Pi 5. Fixes: b6bc755d806e ("arm64: dts: rockchip: Add Orange Pi 5") Signed-off-by: Mykola Kvach <xakep.amatop(a)gmail.com> Reviewed-by: Michael Riesch <michael.riesch(a)collabora.com> --- Changes in v2: - add Fixes tag and Cc stable list as requested during review. --- arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts index ad6d04793b0a..83b9b6645a1e 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts @@ -14,8 +14,8 @@ vcc3v3_pcie20: regulator-vcc3v3-pcie20 { gpios = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>; regulator-name = "vcc3v3_pcie20"; regulator-boot-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; startup-delay-us = <50000>; vin-supply = <&vcc5v0_sys>; }; -- 2.43.0

3 days, 11 hours

3
4
0 0

[PATCH v3 0/3] phy: qcom: edp: Add missing ref clock to x1e80100

by Abel Vesa

According to documentation, the DP PHY on x1e80100 has another clock called ref. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, when it comes to power management, this clock needs to be also disabled on suspend. So even though this change breaks the ABI, it is needed in order to make we disable this clock on runtime PM, when that is going to be enabled in the driver. So rework the driver to allow different number of clocks, fix the dt-bindings schema and add the clock to the DT node as well. Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Changes in v3: - Use dev_err_probe() on clocks parsing failure. - Explain why the ABI break is necessary. - Drop the extra 'clk' suffix from the clock name. So ref instead of refclk. - Link to v2: https://lore.kernel.org/r/20250903-phy-qcom-edp-add-missing-refclk-v2-0-d88… Changes in v2: - Fix schema by adding the minItems, as suggested by Krzysztof. - Use devm_clk_bulk_get_all, as suggested by Konrad. - Rephrase the commit messages to reflect the flexible number of clocks. - Link to v1: https://lore.kernel.org/r/20250730-phy-qcom-edp-add-missing-refclk-v1-0-6f7… --- Abel Vesa (3): dt-bindings: phy: qcom-edp: Add missing clock for X Elite phy: qcom: edp: Make the number of clocks flexible arm64: dts: qcom: Add missing TCSR ref clock to the DP PHYs .../devicetree/bindings/phy/qcom,edp-phy.yaml | 28 +++++++++++++++++++++- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 12 ++++++---- drivers/phy/qualcomm/phy-qcom-edp.c | 16 ++++++------- 3 files changed, 43 insertions(+), 13 deletions(-) --- base-commit: 65dd046ef55861190ecde44c6d9fcde54b9fb77d change-id: 20250730-phy-qcom-edp-add-missing-refclk-5ab82828f8e7 Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

3 days, 13 hours

6
11
0 0

[PATCH] be2net: Use the wrb_params instead the NULL pointer

by Ваторопин Андрей

From: Andrey Vatoropin <a.vatoropin(a)crpt.ru> be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states. The correct way would be to pass the wrb_params from be_xmit(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 760c295e0e8d ("be2net: Support for OS2BMC."). Cc: stable(a)vger.kernel.org Signed-off-by: Andrey Vatoropin <a.vatoropin(a)crpt.ru> --- drivers/net/ethernet/emulex/benet/be_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c index cb004fd16252..631045590d40 100644 --- a/drivers/net/ethernet/emulex/benet/be_main.c +++ b/drivers/net/ethernet/emulex/benet/be_main.c @@ -1296,7 +1296,7 @@ static void be_xmit_flush(struct be_adapter *adapter, struct be_tx_obj *txo) (adapter->bmc_filt_mask & BMC_FILT_MULTICAST) static bool be_send_pkt_to_bmc(struct be_adapter *adapter, - struct sk_buff **skb) + struct sk_buff **skb, struct be_wrb_params *wrb_params) { struct ethhdr *eh = (struct ethhdr *)(*skb)->data; bool os2bmc = false; @@ -1360,7 +1360,7 @@ static bool be_send_pkt_to_bmc(struct be_adapter *adapter, * to BMC, asic expects the vlan to be inline in the packet. */ if (os2bmc) - *skb = be_insert_vlan_in_pkt(adapter, *skb, NULL); + *skb = be_insert_vlan_in_pkt(adapter, *skb, wrb_params); return os2bmc; } @@ -1387,7 +1387,7 @@ static netdev_tx_t be_xmit(struct sk_buff *skb, struct net_device *netdev) /* if os2bmc is enabled and if the pkt is destined to bmc, * enqueue the pkt a 2nd time with mgmt bit set. */ - if (be_send_pkt_to_bmc(adapter, &skb)) { + if (be_send_pkt_to_bmc(adapter, &skb, &wrb_params)) { BE_WRB_F_SET(wrb_params.features, OS2BMC, 1); wrb_cnt = be_xmit_enqueue(adapter, txo, skb, &wrb_params); if (unlikely(!wrb_cnt)) -- 2.43.0

3 days, 14 hours

1
0
0 0

[PATCH] arm64: dts: intel: agilex5: Add fallback compatible for XGMAC

by MUHAMMAD AMIRUL ASYRAF MOHAMAD JAMIAN

From: muhamm120 <muhammad.amirul.asyraf.mohamad.jamian(a)intel.com> Add "snps,dwxgmac" as fallback compatible string to all three gmac nodes (gmac0, gmac1, gmac2) in Agilex5 DTSI. With the fallback present, the generic dwmac driver can properly initialize the XGMAC2 hardware, allowing ethernet to function correctly. This fixes ethernet regression test failures on Agilex3/Agilex5 SOCDK platforms. Fixes: 343ea11a2fe3 ("arm64: dts: Agilex5 Add gmac nodes to DTSI for Agilex5") Cc: stable(a)vger.kernel.org # 6.18+ Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian <muhammad.amirul. asyraf.mohamad.jamian(a)altera.com> --- arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi index a5c2025a616e..942773e96d02 100644 --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi @@ -544,7 +544,8 @@ qspi: spi@108d2000 { gmac0: ethernet@10810000 { compatible = "altr,socfpga-stmmac-agilex5", - "snps,dwxgmac-2.10"; + "snps,dwxgmac-2.10", + "snps,dwxgmac"; reg = <0x10810000 0x3500>; interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq"; @@ -656,7 +657,8 @@ queue7 { gmac1: ethernet@10820000 { compatible = "altr,socfpga-stmmac-agilex5", - "snps,dwxgmac-2.10"; + "snps,dwxgmac-2.10", + "snps,dwxgmac"; reg = <0x10820000 0x3500>; interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq"; @@ -768,7 +770,8 @@ queue7 { gmac2: ethernet@10830000 { compatible = "altr,socfpga-stmmac-agilex5", - "snps,dwxgmac-2.10"; + "snps,dwxgmac-2.10", + "snps,dwxgmac"; reg = <0x10830000 0x3500>; interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq"; -- 2.43.7

3 days, 14 hours

2
1
0 0

[PATCH] drm/mediatek: Fix device node reference leak in mtk_dp_dt_parse()

by Miaoqian Lin

The function mtk_dp_dt_parse() calls of_graph_get_endpoint_by_regs() to get the endpoint device node, but fails to call of_node_put() to release the reference when the function returns. This results in a device node reference leak. Fix this by adding the missing of_node_put() call before returning from the function. Found via static analysis and code review. Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/mediatek/mtk_dp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c index bef6eeb30d3e..b0b1e158600f 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -2087,6 +2087,7 @@ static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp, endpoint = of_graph_get_endpoint_by_regs(pdev->dev.of_node, 1, -1); len = of_property_count_elems_of_size(endpoint, "data-lanes", sizeof(u32)); + of_node_put(endpoint); if (len < 0 || len > 4 || len == 3) { dev_err(dev, "invalid data lane size: %d\n", len); return -EINVAL; -- 2.39.5 (Apple Git-154)

3 days, 16 hours

3
2
0 0

[PATCH] crypto: padlock-sha - Disable broken driver

by Eric Biggers

This driver is known broken, as it computes the wrong SHA-1 and SHA-256 hashes. Correctness needs to be the first priority for cryptographic code. Just disable it, allowing the standard (and actually correct) SHA-1 and SHA-256 implementations to take priority. Reported-by: larryw3i <larryw3i(a)yeah.net> Closes: https://lore.kernel.org/r/3af01fec-b4d3-4d0c-9450-2b722d4bbe39@yeah.net/ Closes: https://lists.debian.org/debian-kernel/2025/09/msg00019.html Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113996 Cc: stable(a)vger.kernel.org Cc: AlanSong-oc(a)zhaoxin.com Cc: CobeChen(a)zhaoxin.com Cc: GeorgeXue(a)zhaoxin.com Cc: HansHu(a)zhaoxin.com Cc: LeoLiu-oc(a)zhaoxin.com Cc: TonyWWang-oc(a)zhaoxin.com Cc: YunShen(a)zhaoxin.com Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- This patch is targeting crypto/master drivers/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index a6688d54984c..16ea3e741350 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -38,11 +38,11 @@ config CRYPTO_DEV_PADLOCK_AES If unsure say M. The compiled module will be called padlock-aes. config CRYPTO_DEV_PADLOCK_SHA tristate "PadLock driver for SHA1 and SHA256 algorithms" - depends on CRYPTO_DEV_PADLOCK + depends on CRYPTO_DEV_PADLOCK && BROKEN select CRYPTO_HASH select CRYPTO_SHA1 select CRYPTO_SHA256 help Use VIA PadLock for SHA1/SHA256 algorithms. base-commit: 59b0afd01b2ce353ab422ea9c8375b03db313a21 -- 2.51.2

3 days, 18 hours

4
6
0 0

[PATCH v2] drm/xe/exec: Validate num_syncs to prevent oversized allocations

by Shuicheng Lin

The exec ioctl allows userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below. Introduce XE_EXEC_MAX_SYNCS (set to 64) and reject any request exceeding this limit. " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace: <TASK> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416 ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388 kmalloc_noprof include/linux/slab.h:909 [inline] kmalloc_array_noprof include/linux/slab.h:948 [inline] xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158 drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797 drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894 xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... " v2: Add "Reported-by" and Cc stable kernels. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6450 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Koen Koning <koen.koning(a)intel.com> Reported-by: Peter Senna Tschudin <peter.senna(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Cc: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin(a)intel.com> --- drivers/gpu/drm/xe/xe_exec.c | 5 +++++ include/uapi/drm/xe_drm.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c index 4d81210e41f5..01c56fd95d5b 100644 --- a/drivers/gpu/drm/xe/xe_exec.c +++ b/drivers/gpu/drm/xe/xe_exec.c @@ -162,6 +162,11 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file) } if (args->num_syncs) { + if (XE_IOCTL_DBG(xe, args->num_syncs > XE_EXEC_MAX_SYNCS)) { + err = -EINVAL; + goto err_exec_queue; + } + syncs = kcalloc(args->num_syncs, sizeof(*syncs), GFP_KERNEL); if (!syncs) { err = -ENOMEM; diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h index 47853659a705..1901ca26621a 100644 --- a/include/uapi/drm/xe_drm.h +++ b/include/uapi/drm/xe_drm.h @@ -1463,6 +1463,7 @@ struct drm_xe_exec { /** @exec_queue_id: Exec queue ID for the batch buffer */ __u32 exec_queue_id; +#define XE_EXEC_MAX_SYNCS 64 /** @num_syncs: Amount of struct drm_xe_sync in array. */ __u32 num_syncs; -- 2.49.0

3 days, 18 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror