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

[PATCH v3 01/22] drm/xe/svm: Fix a debug printout

by Thomas Hellström

Avoid spamming the log with drm_info(). Use drm_dbg() instead. Fixes: cc795e041034 ("drm/xe/svm: Make xe_svm_range_needs_migrate_to_vram() public") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.17+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> --- drivers/gpu/drm/xe/xe_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c index 46977ec1e0de..36634c84d148 100644 --- a/drivers/gpu/drm/xe/xe_svm.c +++ b/drivers/gpu/drm/xe/xe_svm.c @@ -948,7 +948,7 @@ bool xe_svm_range_needs_migrate_to_vram(struct xe_svm_range *range, struct xe_vm xe_assert(vm->xe, IS_DGFX(vm->xe)); if (xe_svm_range_in_vram(range)) { - drm_info(&vm->xe->drm, "Range is already in VRAM\n"); + drm_dbg(&vm->xe->drm, "Range is already in VRAM\n"); return false; } -- 2.51.1

1 day, 18 hours

1
0
0 0

[PATCH 4/5] media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors

by Hans de Goede

The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor the _PLD for the sensor (both report a rotation of 0°). Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries to the DMI quirk list for these 2 laptops. Note the OV02C10 driver was originally developed on a XPS 16 9640 which resulted in inverted vflip + hflip settings making it look like the sensor was upright on the XPS 16 9640 and upside down elsewhere this has been fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip"). This makes this commit a regression fix since now the video is upside down on these Dell XPS models where it was not before. Fixes: 69fe27173396 ("media: ov02c10: Fix default vertical flip") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c index 58ea01d40c0d..6463b2a47d78 100644 --- a/drivers/media/pci/intel/ipu-bridge.c +++ b/drivers/media/pci/intel/ipu-bridge.c @@ -5,6 +5,7 @@ #include <acpi/acpi_bus.h> #include <linux/cleanup.h> #include <linux/device.h> +#include <linux/dmi.h> #include <linux/i2c.h> #include <linux/mei_cl_bus.h> #include <linux/platform_device.h> @@ -99,6 +100,28 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = { IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000), }; +/* + * DMI matches for laptops which have their sensor mounted upside-down + * without reporting a rotation of 180° in neither the SSDB nor the _PLD. + */ +static const struct dmi_system_id upside_down_sensor_dmi_ids[] = { + { + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"), + }, + .driver_data = "OVTI02C1", + }, + { + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 16 9640"), + }, + .driver_data = "OVTI02C1", + }, + {} /* Terminating entry */ +}; + static const struct ipu_property_names prop_names = { .clock_frequency = "clock-frequency", .rotation = "rotation", @@ -249,6 +272,12 @@ static int ipu_bridge_read_acpi_buffer(struct acpi_device *adev, char *id, static u32 ipu_bridge_parse_rotation(struct acpi_device *adev, struct ipu_sensor_ssdb *ssdb) { + const struct dmi_system_id *dmi_id; + + dmi_id = dmi_first_match(upside_down_sensor_dmi_ids); + if (dmi_id && acpi_dev_hid_match(adev, dmi_id->driver_data)) + return 180; + switch (ssdb->degree) { case IPU_SENSOR_ROTATION_NORMAL: return 0; -- 2.52.0

1 day, 19 hours

3
2
0 0

[PATCH] fjes: Add missing iounmap in fjes_hw_init()

by Haoxiang Li

In error paths, add fjes_hw_iounmap() to release the resource acquired by fjes_hw_iomap(). Fixes: 8cdc3f6c5d22 ("fjes: Hardware initialization routine") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/net/fjes/fjes_hw.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/fjes/fjes_hw.c b/drivers/net/fjes/fjes_hw.c index b9b5554ea862..a2e89ffa6f70 100644 --- a/drivers/net/fjes/fjes_hw.c +++ b/drivers/net/fjes/fjes_hw.c @@ -333,8 +333,10 @@ int fjes_hw_init(struct fjes_hw *hw) return -EIO; ret = fjes_hw_reset(hw); - if (ret) + if (ret) { + fjes_hw_iounmap(hw); return ret; + } fjes_hw_set_irqmask(hw, REG_ICTL_MASK_ALL, true); @@ -347,8 +349,10 @@ int fjes_hw_init(struct fjes_hw *hw) hw->max_epid = fjes_hw_get_max_epid(hw); hw->my_epid = fjes_hw_get_my_epid(hw); - if ((hw->max_epid == 0) || (hw->my_epid >= hw->max_epid)) + if ((hw->max_epid == 0) || (hw->my_epid >= hw->max_epid)) { + fjes_hw_iounmap(hw); return -ENXIO; + } ret = fjes_hw_setup(hw); -- 2.25.1

1 day, 19 hours

2
1
0 0

lists.linaro.org Password for linux-stable-mirror@lists.linaro.org Expires today!!

by Lists

1 day, 20 hours

1
0
0 0

[PATCH v3] net/handshake: restore destructor on submit failure

by caoping

handshake_req_submit() replaces sk->sk_destruct but never restores it when submission fails before the request is hashed. handshake_sk_destruct() then returns early and the original destructor never runs, leaking the socket. Restore sk_destruct on the error path. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Reviewed-by: Chuck Lever <chuck.lever(a)oracle.com> Cc: stable(a)vger.kernel.org Signed-off-by: caoping <caoping(a)cmss.chinamobile.com> --- net/handshake/request.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/handshake/request.c b/net/handshake/request.c index 274d2c89b6b2..89435ed755cd 100644 --- a/net/handshake/request.c +++ b/net/handshake/request.c @@ -276,6 +276,8 @@ int handshake_req_submit(struct socket *sock, struct handshake_req *req, out_unlock: spin_unlock(&hn->hn_lock); out_err: + /* Restore original destructor so socket teardown still runs on failure */ + req->hr_sk->sk_destruct = req->hr_odestruct; trace_handshake_submit_err(net, req, req->hr_sk, ret); handshake_req_destroy(req); return ret; base-commit: 4a26e7032d7d57c998598c08a034872d6f0d3945 -- 2.47.3

1 day, 20 hours

3
2
0 0

[PATCH] drm/xe/bo: Don't include the CCS metadata in the dma-buf sg-table

by Thomas Hellström

Some Xe bos are allocated with extra backing-store for the CCS metadata. It's never been the intention to share the CCS metadata when exporting such bos as dma-buf. Don't include it in the dma-buf sg-table. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/xe/xe_dma_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c index 54e42960daad..7c74a31d4486 100644 --- a/drivers/gpu/drm/xe/xe_dma_buf.c +++ b/drivers/gpu/drm/xe/xe_dma_buf.c @@ -124,7 +124,7 @@ static struct sg_table *xe_dma_buf_map(struct dma_buf_attachment *attach, case XE_PL_TT: sgt = drm_prime_pages_to_sg(obj->dev, bo->ttm.ttm->pages, - bo->ttm.ttm->num_pages); + obj->size >> PAGE_SHIFT); if (IS_ERR(sgt)) return sgt; -- 2.51.1

1 day, 20 hours

3
2
0 0

[PATCH v2] media: cx25821: Add missing unmap in snd_cx25821_hw_params()

by Haoxiang Li

In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: 8d8e6d6005de ("[media] cx28521: drop videobuf abuse in cx25821-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- Changes in v2: - Fix the "Fixes" tag error. --- drivers/media/pci/cx25821/cx25821-alsa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c b/drivers/media/pci/cx25821/cx25821-alsa.c index a42f0c03a7ca..f463365163b7 100644 --- a/drivers/media/pci/cx25821/cx25821-alsa.c +++ b/drivers/media/pci/cx25821/cx25821-alsa.c @@ -535,6 +535,7 @@ static int snd_cx25821_hw_params(struct snd_pcm_substream *substream, chip->period_size, chip->num_periods, 1); if (ret < 0) { pr_info("DEBUG: ERROR after cx25821_risc_databuffer_audio()\n"); + cx25821_alsa_dma_unmap(chip); goto error; } -- 2.25.1

1 day, 21 hours

1
0
0 0

[PATCH net 2/2] can: gs_usb: gs_can_open(): fix error handling

by Marc Kleine-Budde

Commit 2603be9e8167 ("can: gs_usb: gs_can_open(): improve error handling") added missing error handling to the gs_can_open() function. The driver uses 2 USB anchors to track the allocated URBs: the TX URBs in struct gs_can::tx_submitted for each netdev and the RX URBs in struct gs_usb::rx_submitted for the USB device. gs_can_open() allocates the RX URBs, while TX URBs are allocated during gs_can_start_xmit(). The cleanup in gs_can_open() kills all anchored dev->tx_submitted URBs (which is not necessary since the netdev is not yet registered), but misses the parent->rx_submitted URBs. Fix the problem by killing the rx_submitted instead of the tx_submitted. Fixes: 2603be9e8167 ("can: gs_usb: gs_can_open(): improve error handling") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251210-gs_usb-fix-error-handling-v1-1-d6a5a03f10… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/usb/gs_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index e29e85b67fd4..a0233e550a5a 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -1074,7 +1074,7 @@ static int gs_can_open(struct net_device *netdev) usb_free_urb(urb); out_usb_kill_anchored_urbs: if (!parent->active_channels) { - usb_kill_anchored_urbs(&dev->tx_submitted); + usb_kill_anchored_urbs(&parent->rx_submitted); if (dev->feature & GS_CAN_FEATURE_HW_TIMESTAMP) gs_usb_timestamp_stop(parent); -- 2.51.0

1 day, 21 hours

1
0
0 0

[PATCH can] can: gs_usb: gs_can_open(): fix error handling

by Marc Kleine-Budde

Commit 2603be9e8167 ("can: gs_usb: gs_can_open(): improve error handling") added missing error handling to the gs_can_open() function. The driver uses 2 USB anchors to track the allocated URBs: the TX URBs in struct gs_can::tx_submitted for each netdev and the RX URBs in struct gs_usb::rx_submitted for the USB device. gs_can_open() allocates the RX URBs, while TX URBs are allocated during gs_can_start_xmit(). The cleanup in gs_can_open() kills all anchored dev->tx_submitted URBs (which is not necessary since the netdev is not yet registered), but misses the parent->rx_submitted URBs. Fix the problem by killing the rx_submitted instead of the tx_submitted. Fixes: 2603be9e8167 ("can: gs_usb: gs_can_open(): improve error handling") Cc: stable(a)vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/usb/gs_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index e29e85b67fd4..a0233e550a5a 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -1074,7 +1074,7 @@ static int gs_can_open(struct net_device *netdev) usb_free_urb(urb); out_usb_kill_anchored_urbs: if (!parent->active_channels) { - usb_kill_anchored_urbs(&dev->tx_submitted); + usb_kill_anchored_urbs(&parent->rx_submitted); if (dev->feature & GS_CAN_FEATURE_HW_TIMESTAMP) gs_usb_timestamp_stop(parent); --- base-commit: 186468c67fc687650b7fb713d8c627d5c8566886 change-id: 20251210-gs_usb-fix-error-handling-4f980294424c Best regards, -- Marc Kleine-Budde <mkl(a)pengutronix.de>

1 day, 21 hours

1
0
0 0

[PATCH v2] net: nfc: nci: Fix parameter validation for packet data

by Michael Thalmeier

Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). For these cases it is only possible to check for minimum packet length. Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") Cc: stable(a)vger.kernel.org Signed-off-by: Michael Thalmeier <michael.thalmeier(a)hale.at> --- Changes in v2: - Reference correct commit hash --- net/nfc/nci/ntf.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c index 418b84e2b260..5161e94f067f 100644 --- a/net/nfc/nci/ntf.c +++ b/net/nfc/nci/ntf.c @@ -58,7 +58,8 @@ static int nci_core_conn_credits_ntf_packet(struct nci_dev *ndev, struct nci_conn_info *conn_info; int i; - if (skb->len < sizeof(struct nci_core_conn_credit_ntf)) + /* Minimal packet size for num_entries=1 is 1 x __u8 + 1 x conn_credit_entry */ + if (skb->len < (sizeof(__u8) + sizeof(struct conn_credit_entry))) return -EINVAL; ntf = (struct nci_core_conn_credit_ntf *)skb->data; @@ -364,7 +365,8 @@ static int nci_rf_discover_ntf_packet(struct nci_dev *ndev, const __u8 *data; bool add_target = true; - if (skb->len < sizeof(struct nci_rf_discover_ntf)) + /* Minimal packet size is 5 if rf_tech_specific_params_len=0 */ + if (skb->len < (5 * sizeof(__u8))) return -EINVAL; data = skb->data; @@ -596,7 +598,10 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev, const __u8 *data; int err = NCI_STATUS_OK; - if (skb->len < sizeof(struct nci_rf_intf_activated_ntf)) + /* Minimal packet size is 11 if + * f_tech_specific_params_len=0 and activation_params_len=0 + */ + if (skb->len < (11 * sizeof(__u8))) return -EINVAL; data = skb->data; -- 2.52.0

1 day, 21 hours

1
0
0 0

[PATCH] net: nfc: nci: Fix parameter validation for packet data

by Michael Thalmeier

Since commit 8fcc7315a10a ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). For these cases it is only possible to check for minimum packet length. Fixes: 8fcc7315a10a ("net: nfc: nci: Add parameter validation for packet data") Cc: stable(a)vger.kernel.org Signed-off-by: Michael Thalmeier <michael.thalmeier(a)hale.at> --- net/nfc/nci/ntf.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c index 418b84e2b260..5161e94f067f 100644 --- a/net/nfc/nci/ntf.c +++ b/net/nfc/nci/ntf.c @@ -58,7 +58,8 @@ static int nci_core_conn_credits_ntf_packet(struct nci_dev *ndev, struct nci_conn_info *conn_info; int i; - if (skb->len < sizeof(struct nci_core_conn_credit_ntf)) + /* Minimal packet size for num_entries=1 is 1 x __u8 + 1 x conn_credit_entry */ + if (skb->len < (sizeof(__u8) + sizeof(struct conn_credit_entry))) return -EINVAL; ntf = (struct nci_core_conn_credit_ntf *)skb->data; @@ -364,7 +365,8 @@ static int nci_rf_discover_ntf_packet(struct nci_dev *ndev, const __u8 *data; bool add_target = true; - if (skb->len < sizeof(struct nci_rf_discover_ntf)) + /* Minimal packet size is 5 if rf_tech_specific_params_len=0 */ + if (skb->len < (5 * sizeof(__u8))) return -EINVAL; data = skb->data; @@ -596,7 +598,10 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev, const __u8 *data; int err = NCI_STATUS_OK; - if (skb->len < sizeof(struct nci_rf_intf_activated_ntf)) + /* Minimal packet size is 11 if + * f_tech_specific_params_len=0 and activation_params_len=0 + */ + if (skb->len < (11 * sizeof(__u8))) return -EINVAL; data = skb->data; -- 2.52.0

1 day, 21 hours

2
2
0 0

Re: Patch "dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope" has been added to the 6.17-stable tree

by Nathan Chancellor

On Sun, Dec 07, 2025 at 10:07:49PM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope > > to the 6.17-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: > dma-mapping-allow-use-of-dma_bit_mask-64-in-global-s.patch > and it can be found in the queue-6.17 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 51a1912d46ceb70602de50c167e440966b9836f1 > Author: James Clark <james.clark(a)linaro.org> > Date: Thu Oct 30 14:05:27 2025 +0000 > > dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope > > [ Upstream commit a50f7456f853ec3a6f07cbe1d16ad8a8b2501320 ] This change has a pending bug fix, consider waiting to apply this to the stable trees. https://lore.kernel.org/20251207184756.97904-1-johannes.goede@oss.qualcomm.… Cheers, Nathan

1 day, 22 hours

2
1
0 0

[PATCH AUTOSEL 6.18-5.10] serial: sprd: Return -EPROBE_DEFER when uart clock is not ready

by Sasha Levin

From: Wenhua Lin <Wenhua.Lin(a)unisoc.com> [ Upstream commit 29e8a0c587e328ed458380a45d6028adf64d7487 ] In sprd_clk_init(), when devm_clk_get() returns -EPROBE_DEFER for either uart or source clock, we should propagate the error instead of just warning and continuing with NULL clocks. Currently the driver only emits a warning when clock acquisition fails and proceeds with NULL clock pointers. This can lead to issues later when the clocks are actually needed. More importantly, when the clock provider is not ready yet and returns -EPROBE_DEFER, we should return this error to allow deferred probing. This change adds explicit checks for -EPROBE_DEFER after both: 1. devm_clk_get(uport->dev, uart) 2. devm_clk_get(uport->dev, source) When -EPROBE_DEFER is encountered, the function now returns -EPROBE_DEFER to let the driver framework retry probing later when the clock dependencies are resolved. Signed-off-by: Wenhua Lin <Wenhua.Lin(a)unisoc.com> Link: https://patch.msgid.link/20251022030840.956589-1-Wenhua.Lin@unisoc.com Reviewed-by: Cixi Geng <cixi.geng(a)linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Commit Analysis: serial: sprd: Return -EPROBE_DEFER when uart clock is not ready ### 1. COMMIT MESSAGE ANALYSIS **Subject**: Fixes incorrect handling of `-EPROBE_DEFER` error from `devm_clk_get()` **Key observations**: - No `Cc: stable(a)vger.kernel.org` tag present - No `Fixes:` tag pointing to when the bug was introduced - Has `Reviewed-by:` from Cixi Geng - Accepted by Greg Kroah-Hartman (serial subsystem maintainer) ### 2. CODE CHANGE ANALYSIS The change adds two checks in `sprd_clk_init()`: ```c clk_uart = devm_clk_get(uport->dev, "uart"); if (IS_ERR(clk_uart)) { + if (PTR_ERR(clk_uart) == -EPROBE_DEFER) + return -EPROBE_DEFER; dev_warn(...); clk_uart = NULL; } clk_parent = devm_clk_get(uport->dev, "source"); if (IS_ERR(clk_parent)) { + if (PTR_ERR(clk_parent) == -EPROBE_DEFER) + return -EPROBE_DEFER; dev_warn(...); clk_parent = NULL; } ``` **Technical bug mechanism**: When clock providers aren't ready yet, `devm_clk_get()` returns `-EPROBE_DEFER`. The existing code ignores this error, sets the clock pointer to NULL, and continues. This bypasses the kernel's deferred probing mechanism which exists precisely to handle this dependency ordering scenario. **Existing pattern**: The function already has identical handling for the "enable" clock (visible in the context lines). This fix makes the handling consistent for all three clocks. ### 3. CLASSIFICATION **Type**: Bug fix (not a feature addition) This fixes incorrect error handling. The `-EPROBE_DEFER` mechanism is a fundamental kernel feature for handling driver load order dependencies. Not propagating this error is a bug. ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed**: 6 lines added (two 3-line checks) - **Files touched**: 1 file (`drivers/tty/serial/sprd_serial.c`) - **Complexity**: Very low - follows identical pattern already in the same function - **Subsystem**: Hardware-specific serial driver for Spreadtrum/Unisoc UARTs **Risk**: Very low - Pattern is already established and proven in the same function - Only affects error handling during probe - No changes to normal operation when clocks are available - Worst case: probe failure happens earlier/more explicitly ### 5. USER IMPACT **Affected users**: Users of Spreadtrum/Unisoc UART hardware (embedded devices, some Android phones) **Severity**: Medium-High for affected users - without this fix, the serial port may not work correctly on systems where clock providers load after the serial driver. This is common in embedded systems with device tree-based configurations. **Real bug**: This is a practical issue in probe ordering scenarios. The driver would proceed with NULL clocks instead of waiting for dependencies to be ready. ### 6. STABILITY INDICATORS - Reviewed-by tag indicates code review - Maintainer accepted the change - Simple, straightforward change following existing code patterns - No complex logic introduced ### 7. DEPENDENCY CHECK - **Dependencies**: None - self-contained fix - **Code existence in stable**: The sprd_serial driver has existed since ~2015 (commit 3e1f2029a4b40), so it's present in all active stable trees ### SUMMARY **What it fixes**: Incorrect handling of `-EPROBE_DEFER` from `devm_clk_get()` for two clocks ("uart" and "source"), causing the driver to proceed with NULL clocks instead of deferring probe when clock providers aren't ready. **Stable kernel criteria**: - ✅ Obviously correct (follows identical pattern already in function) - ✅ Fixes a real bug (broken deferred probing) - ✅ Small and contained (6 lines, 1 file) - ✅ No new features - ✅ Low risk of regression **Concerns**: - No explicit `Cc: stable` tag (author/maintainer didn't flag for stable) - Relatively niche driver (Spreadtrum hardware) **Risk vs Benefit**: The fix is minimal risk (identical pattern to existing code) and addresses a real bug that could leave serial hardware non-functional on embedded systems. The benefit outweighs the minimal risk. The lack of `Cc: stable` tag is notable but not determinative - this is a straightforward bug fix that meets all stable criteria. The fix is small, obviously correct, and addresses a real probe ordering issue that embedded system users could encounter. **YES** drivers/tty/serial/sprd_serial.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c index 8c9366321f8e7..092755f356836 100644 --- a/drivers/tty/serial/sprd_serial.c +++ b/drivers/tty/serial/sprd_serial.c @@ -1133,6 +1133,9 @@ static int sprd_clk_init(struct uart_port *uport) clk_uart = devm_clk_get(uport->dev, "uart"); if (IS_ERR(clk_uart)) { + if (PTR_ERR(clk_uart) == -EPROBE_DEFER) + return -EPROBE_DEFER; + dev_warn(uport->dev, "uart%d can't get uart clock\n", uport->line); clk_uart = NULL; @@ -1140,6 +1143,9 @@ static int sprd_clk_init(struct uart_port *uport) clk_parent = devm_clk_get(uport->dev, "source"); if (IS_ERR(clk_parent)) { + if (PTR_ERR(clk_parent) == -EPROBE_DEFER) + return -EPROBE_DEFER; + dev_warn(uport->dev, "uart%d can't get source clock\n", uport->line); clk_parent = NULL; -- 2.51.0

1 day, 23 hours

1
7
0 0

[PATCH v2] media: dw2102: validate I2C messages in su3000_i2c_transfer()

by Dharanitharan R

syzbot reports a general protection fault caused by su3000_i2c_transfer() dereferencing msg->buf without validating the message length or buffer pointer. Although i2c-dev blocks zero-length messages, malformed I²C messages can still reach the driver through the DVB USB subsystem. Add strict validation of each message to prevent NULL-pointer dereferences. Reported-by: syzbot+d99f3a288cc7d8ef60fb(a)syzkaller.appspotmail.com Fixes: 0e148a522b84 ("media: dw2102: Don't translate i2c read into write") Closes: https://syzkaller.appspot.com/bug?extid=d99f3a288cc7d8ef60fb Cc: stable(a)vger.kernel.org Signed-off-by: Dharanitharan R <dharanitharan725(a)gmail.com> --- drivers/media/usb/dvb-usb/dw2102.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dw2102.c b/drivers/media/usb/dvb-usb/dw2102.c index 4fecf2f965e9..0dd210ea16f3 100644 --- a/drivers/media/usb/dvb-usb/dw2102.c +++ b/drivers/media/usb/dvb-usb/dw2102.c @@ -733,6 +733,36 @@ static int su3000_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[], return -EAGAIN; } + /* Validate incoming I²C messages */ + if (!msg || num <= 0) { + mutex_unlock(&d->data_mutex); + mutex_unlock(&d->i2c_mutex); + return -EINVAL; + } + + for (j = 0; j < num; j++) { + /* msg buffer must exist */ + if (!msg[j].buf) { + mutex_unlock(&d->data_mutex); + mutex_unlock(&d->i2c_mutex); + return -EINVAL; + } + + /* zero or negative length is invalid */ + if (msg[j].len <= 0) { + mutex_unlock(&d->data_mutex); + mutex_unlock(&d->i2c_mutex); + return -EINVAL; + } + + /* protect against unreasonable sizes */ + if (msg[j].len > 256) { + mutex_unlock(&d->data_mutex); + mutex_unlock(&d->i2c_mutex); + return -EOPNOTSUPP; + } + } + j = 0; while (j < num) { switch (msg[j].addr) { -- 2.43.0

1 day, 23 hours

1
0
0 0

[PATCH v2] powerpc: Add reloc_offset() to font bitmap pointer used for bootx_printf()

by Finn Thain

Since Linux v6.7, booting using BootX on an Old World PowerMac produces an early crash. Stan Johnson writes, "the symptoms are that the screen goes blank and the backlight stays on, and the system freezes (Linux doesn't boot)." Further testing revealed that the failure can be avoided by disabling CONFIG_BOOTX_TEXT. Bisection revealed that the regression was caused by a change to the font bitmap pointer that's used when btext_init() begins painting characters on the display, early in the boot process. Christophe Leroy explains, "before kernel text is relocated to its final location ... data is addressed with an offset which is added to the Global Offset Table (GOT) entries at the start of bootx_init() by function reloc_got2(). But the pointers that are located inside a structure are not referenced in the GOT and are therefore not updated by reloc_got2(). It is therefore needed to apply the offset manually by using PTRRELOC() macro." Cc: Cedar Maxwell <cedarmaxwell(a)mac.com> Cc: Stan Johnson <userm57(a)yahoo.com> Cc: "Dr. David Alan Gilbert" <linux(a)treblig.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: stable(a)vger.kernel.org Link: https://lists.debian.org/debian-powerpc/2025/10/msg00111.html Link: https://lore.kernel.org/linuxppc-dev/d81ddca8-c5ee-d583-d579-02b19ed95301@y… Reported-by: Cedar Maxwell <cedarmaxwell(a)mac.com> Closes: https://lists.debian.org/debian-powerpc/2025/09/msg00031.html Bisected-by: Stan Johnson <userm57(a)yahoo.com> Tested-by: Stan Johnson <userm57(a)yahoo.com> Fixes: 0ebc7feae79a ("powerpc: Use shared font data") Suggested-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> --- Changed since v1: - Improved commit log entry to better explain the need for PTRRELOC(). --- arch/powerpc/kernel/btext.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index 7f63f1cdc6c3..ca00c4824e31 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -20,6 +20,7 @@ #include <asm/io.h> #include <asm/processor.h> #include <asm/udbg.h> +#include <asm/setup.h> #define NO_SCROLL @@ -463,7 +464,7 @@ static noinline void draw_byte(unsigned char c, long locX, long locY) { unsigned char *base = calc_base(locX << 3, locY << 4); unsigned int font_index = c * 16; - const unsigned char *font = font_sun_8x16.data + font_index; + const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index; int rb = dispDeviceRowBytes; rmci_maybe_on(); -- 2.49.1

2 days, 1 hour

3
3
0 0

[PATCH AUTOSEL 6.18-6.17] functionfs: fix the open/removal races

by Sasha Levin

From: Al Viro <viro(a)zeniv.linux.org.uk> [ Upstream commit e5bf5ee266633cb18fff6f98f0b7d59a62819eee ] ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object. There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write(). The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along. To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE. Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Summary ### What the Commit Fixes This commit fixes a **Use-After-Free (UAF)** vulnerability in USB gadget functionfs. The race condition occurs between `ffs_epfile_open()` and file removal: 1. Thread A is in `ffs_epfile_open()` but hasn't incremented `ffs->opened` yet 2. Thread B closes the last file handle, triggering removal (since `opened` is 0) 3. Thread A's open succeeds with `file->private_data` pointing to freed memory 4. Subsequent `read()`/`write()` operations cause UAF ### Fix Mechanism The fix implements proper synchronization: - Serializes openers using `ffs->mutex` - Uses `atomic_inc_not_zero()` to fail if counter already zero - Uses `smp_load_acquire()`/`smp_store_release()` for memory ordering - Clears `i_private` during removal via `simple_recursive_removal()` callback - Uses `file->private_data` instead of `inode->i_private` in release path ### Stable Kernel Criteria Assessment | Criterion | Assessment | |-----------|------------| | Obviously correct | ✅ Uses standard kernel primitives, proper locking patterns | | Fixes real bug | ✅ UAF vulnerability, security-relevant | | Important issue | ✅ Security bug, potential for crashes/exploitation | | Small and contained | ✅ Single file, +43/-10 lines, localized changes | | No new features | ✅ Pure bug fix, no new APIs | ### Risk vs Benefit **Benefits:** - Fixes serious UAF vulnerability - USB gadget functionfs used in Android, embedded systems - Reviewed by Greg Kroah-Hartman (USB maintainer, stable maintainer) - Written by Al Viro (highly respected kernel developer) **Risks:** - Moderate complexity (changes locking behavior) - Recent commit (November 2025), limited mainline soak time - No explicit `Cc: stable(a)vger.kernel.org` tag ### Dependencies - `ffs_mutex_lock()` - exists in functionfs since early versions - `simple_recursive_removal()` with callback - available since ~5.x kernels - Standard kernel APIs (`atomic_inc_not_zero`, memory barriers) - universally available ### Concerns 1. **No Fixes: tag** - Makes it harder to determine which stable trees need this fix 2. **No Cc: stable tag** - May indicate maintainers wanted soak time, or an oversight given Greg KH reviewed it 3. **Backport effort** - May need adjustment for older stable trees depending on functionfs evolution ### Conclusion This is a legitimate UAF security fix that affects real-world users (Android, embedded USB gadgets). Despite moderate complexity, the fix: - Addresses a serious vulnerability class (UAF) - Uses correct synchronization patterns - Has been reviewed by the appropriate maintainer who also maintains stable trees - Is self-contained with no feature additions The lack of explicit stable tags appears to be an oversight given the security nature of the bug and Greg KH's review. UAF vulnerabilities typically warrant expedited backporting. **YES** drivers/usb/gadget/function/f_fs.c | 53 ++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 47cfbe41fdff8..69f6e3c0f7e00 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -640,13 +640,22 @@ static ssize_t ffs_ep0_read(struct file *file, char __user *buf, static int ffs_ep0_open(struct inode *inode, struct file *file) { - struct ffs_data *ffs = inode->i_private; + struct ffs_data *ffs = inode->i_sb->s_fs_info; + int ret; - if (ffs->state == FFS_CLOSING) - return -EBUSY; + /* Acquire mutex */ + ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK); + if (ret < 0) + return ret; - file->private_data = ffs; ffs_data_opened(ffs); + if (ffs->state == FFS_CLOSING) { + ffs_data_closed(ffs); + mutex_unlock(&ffs->mutex); + return -EBUSY; + } + mutex_unlock(&ffs->mutex); + file->private_data = ffs; return stream_open(inode, file); } @@ -1193,14 +1202,33 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data) static int ffs_epfile_open(struct inode *inode, struct file *file) { - struct ffs_epfile *epfile = inode->i_private; + struct ffs_data *ffs = inode->i_sb->s_fs_info; + struct ffs_epfile *epfile; + int ret; - if (WARN_ON(epfile->ffs->state != FFS_ACTIVE)) + /* Acquire mutex */ + ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK); + if (ret < 0) + return ret; + + if (!atomic_inc_not_zero(&ffs->opened)) { + mutex_unlock(&ffs->mutex); + return -ENODEV; + } + /* + * we want the state to be FFS_ACTIVE; FFS_ACTIVE alone is + * not enough, though - we might have been through FFS_CLOSING + * and back to FFS_ACTIVE, with our file already removed. + */ + epfile = smp_load_acquire(&inode->i_private); + if (unlikely(ffs->state != FFS_ACTIVE || !epfile)) { + mutex_unlock(&ffs->mutex); + ffs_data_closed(ffs); return -ENODEV; + } + mutex_unlock(&ffs->mutex); file->private_data = epfile; - ffs_data_opened(epfile->ffs); - return stream_open(inode, file); } @@ -1332,7 +1360,7 @@ static void ffs_dmabuf_put(struct dma_buf_attachment *attach) static int ffs_epfile_release(struct inode *inode, struct file *file) { - struct ffs_epfile *epfile = inode->i_private; + struct ffs_epfile *epfile = file->private_data; struct ffs_dmabuf_priv *priv, *tmp; struct ffs_data *ffs = epfile->ffs; @@ -2352,6 +2380,11 @@ static int ffs_epfiles_create(struct ffs_data *ffs) return 0; } +static void clear_one(struct dentry *dentry) +{ + smp_store_release(&dentry->d_inode->i_private, NULL); +} + static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count) { struct ffs_epfile *epfile = epfiles; @@ -2359,7 +2392,7 @@ static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count) for (; count; --count, ++epfile) { BUG_ON(mutex_is_locked(&epfile->mutex)); if (epfile->dentry) { - simple_recursive_removal(epfile->dentry, NULL); + simple_recursive_removal(epfile->dentry, clear_one); epfile->dentry = NULL; } } -- 2.51.0

2 days, 2 hours

1
19
0 0

回复:6.12.50 regression: netem: cannot mix duplicating netems with other netems in tree.

by zyc zyc

Hello, Resend my last email without HTML. ---- zyc zyc <zyc199902(a)zohomail.cn> 在 Sat, 2025-11-29 18:57:01 写到：--- > Hello, maintainer > > I would like to report what appears to be a regression in 6.12.50 kernel release related to netem. > It rejects our configuration with the message: > Error: netem: cannot mix duplicating netems with other netems in tree. > > This breaks setups that previously worked correctly for many years. > > > Our team uses multiple netem qdiscs in the same HTB branch, arranged in a parallel fashion using a prio fan-out. Each branch of the prio qdisc has its own distinct netem instance with different duplication characteristics. > > This is used to emulate our production conditions where a single logical path fans out into two downstream segments, for example: > > two ECMP next hops with different misbehaviour characteristics, or > > > an HA firewall cluster where only one node is replaying frames, or > > > two LAG / ToR paths where one path intermittently duplicates packets. > > > In our environments, only a subset of flows are affected, and different downstream devices may cause different styles of duplication. > This regression breaks existing automated tests, training environments, and network simulation pipelines. > > I would be happy to provide our reproducer if needed. > > Thank you for your time and for maintaining Linux kernel. > > > > Best regards, > zyc > > >

2 days, 2 hours

3
6
0 0

[PATCH v2] pmdomain: imx: Fix reference count leak in imx_gpc_probe()

by Wentao Liang

of_get_child_by_name() returns a node pointer with refcount incremented, we should use the __free() attribute to manage the pgc_node reference. This ensures automatic of_node_put() cleanup when pgc_node goes out of scope, eliminating the need for explicit error handling paths and avoiding reference count leaks. Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- Change in V2: - Use __free() attribute instead of explicit of_node_put() calls --- drivers/pmdomain/imx/gpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c index f18c7e6e75dd..89d5d68c055d 100644 --- a/drivers/pmdomain/imx/gpc.c +++ b/drivers/pmdomain/imx/gpc.c @@ -403,7 +403,7 @@ static int imx_gpc_old_dt_init(struct device *dev, struct regmap *regmap, static int imx_gpc_probe(struct platform_device *pdev) { const struct imx_gpc_dt_data *of_id_data = device_get_match_data(&pdev->dev); - struct device_node *pgc_node; + struct device_node *pgc_node __free(pgc_node); struct regmap *regmap; void __iomem *base; int ret; -- 2.34.1

2 days, 2 hours

3
2
0 0

[PATCH] media: cx23885: Add missing unmap in snd_cx23885_hw_params()

by Haoxiang Li

In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map(). Fixes: 9529a4b0cf49 ("[media] cx23885: drop videobuf abuse in cx23885-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx23885/cx23885-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx23885/cx23885-alsa.c b/drivers/media/pci/cx23885/cx23885-alsa.c index 25dc8d4dc5b7..717fc6c9ef21 100644 --- a/drivers/media/pci/cx23885/cx23885-alsa.c +++ b/drivers/media/pci/cx23885/cx23885-alsa.c @@ -392,8 +392,10 @@ static int snd_cx23885_hw_params(struct snd_pcm_substream *substream, ret = cx23885_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx23885_alsa_dma_unmap(chip); goto error; + } /* Loop back to start of program */ buf->risc.jmp[0] = cpu_to_le32(RISC_JUMP|RISC_IRQ1|RISC_CNT_INC); -- 2.25.1

2 days, 2 hours

1
0
0 0

[PATCH] media: cx88: Add missing unmap in snd_cx88_hw_params()

by Haoxiang Li

In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx88/cx88-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx88/cx88-alsa.c b/drivers/media/pci/cx88/cx88-alsa.c index 29fb1311e443..4e574d8390b4 100644 --- a/drivers/media/pci/cx88/cx88-alsa.c +++ b/drivers/media/pci/cx88/cx88-alsa.c @@ -483,8 +483,10 @@ static int snd_cx88_hw_params(struct snd_pcm_substream *substream, ret = cx88_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx88_alsa_dma_unmap(chip); goto error; + } /* Loop back to start of program */ buf->risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_IRQ1 | RISC_CNT_INC); -- 2.25.1

2 days, 3 hours

1
0
0 0

[PATCH] media: cx25821: Add missing unmap in snd_cx25821_hw_params()

by Haoxiang Li

In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx25821/cx25821-alsa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c b/drivers/media/pci/cx25821/cx25821-alsa.c index a42f0c03a7ca..f463365163b7 100644 --- a/drivers/media/pci/cx25821/cx25821-alsa.c +++ b/drivers/media/pci/cx25821/cx25821-alsa.c @@ -535,6 +535,7 @@ static int snd_cx25821_hw_params(struct snd_pcm_substream *substream, chip->period_size, chip->num_periods, 1); if (ret < 0) { pr_info("DEBUG: ERROR after cx25821_risc_databuffer_audio()\n"); + cx25821_alsa_dma_unmap(chip); goto error; } -- 2.25.1

2 days, 3 hours

1
0
0 0

[PATCH v2] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

by yongxin.liu＠windriver.com

From: Yongxin Liu <yongxin.liu(a)windriver.com> Zero can be a valid value of num_records. For example, on Intel Atom x6425RE, only x87 and SSE are supported (features 0, 1), and fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop only iterates feature 2, which is not enabled, so num_records = 0. This is valid and should not cause core dump failure. The issue is that dump_xsave_layout_desc() returns 0 for both genuine errors (dump_emit() failure) and valid cases (no extended features). Use negative return values for errors and only abort on genuine failures. Cc: stable(a)vger.kernel.org Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86 core files") Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- V2: Keep error checking but use negative value for genuine error V1: Remove error checking entirely --- arch/x86/kernel/fpu/xstate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..76153dfb58c9 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1946,7 +1946,7 @@ static int dump_xsave_layout_desc(struct coredump_params *cprm) }; if (!dump_emit(cprm, &xc, sizeof(xc))) - return 0; + return -1; num_records++; } @@ -1984,7 +1984,7 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm) return 1; num_records = dump_xsave_layout_desc(cprm); - if (!num_records) + if (num_records < 0) return 1; /* Total size should be equal to the number of records */ -- 2.46.2

2 days, 5 hours

1
0
0 0

[PATCH] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

by yongxin.liu＠windriver.com

From: Yongxin Liu <yongxin.liu(a)windriver.com> Zero can be a valid value of num_records. For example, on Intel Atom x6425RE, only x87 and SSE are supported (features 0, 1), and fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop only iterates feature 2, which is not enabled, so num_records = 0. This is valid and should not cause core dump failure. The size check already validates consistency: if num_records = 0, then en.n_descsz = 0, so the check passes. Cc: stable(a)vger.kernel.org Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86 core files") Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- arch/x86/kernel/fpu/xstate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..b1dd30eb21a8 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1984,8 +1984,6 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm) return 1; num_records = dump_xsave_layout_desc(cprm); - if (!num_records) - return 1; /* Total size should be equal to the number of records */ if ((sizeof(struct x86_xfeat_component) * num_records) != en.n_descsz) -- 2.46.2

2 days, 6 hours

3
2
0 0

[PATCH v5 1/6] drm/amdgpu: Fix gfx9 update PTE mtype flag

by Philip Yang

Fix copy&paste error, that should have been an assignment instead of an or, otherwise MTYPE_UC 0x3 can not be updated to MTYPE_RW 0x1. CC stables. cc: stable(a)vger.kernel.org Signed-off-by: Philip Yang <Philip.Yang(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c index 97a04e3171f2..205c34eb8d11 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -1204,16 +1204,16 @@ static void gmc_v9_0_get_vm_pte(struct amdgpu_device *adev, *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_NC); break; case AMDGPU_VM_MTYPE_WC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_WC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_WC); break; case AMDGPU_VM_MTYPE_RW: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_RW); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_RW); break; case AMDGPU_VM_MTYPE_CC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_CC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_CC); break; case AMDGPU_VM_MTYPE_UC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_UC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_UC); break; } -- 2.50.1

2 days, 6 hours

1
0
0 0

[PATCH] lib/crypto: riscv: Depend on RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS

by Eric Biggers

Replace the RISCV_ISA_V dependency of the RISC-V crypto code with RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS, which implies RISCV_ISA_V as well as vector unaligned accesses being efficient. This is necessary because this code assumes that vector unaligned accesses are supported and are efficient. (It does so to avoid having to use lots of extra vsetvli instructions to switch the element width back and forth between 8 and either 32 or 64.) This was omitted from the code originally just because the RISC-V kernel support for detecting this feature didn't exist yet. Support has now been added, but it's fragmented into per-CPU runtime detection, a command-line parameter, and a kconfig option. The kconfig option is the only reasonable way to do it, though, so let's just rely on that. Fixes: eb24af5d7a05 ("crypto: riscv - add vector crypto accelerated AES-{ECB,CBC,CTR,XTS}") Fixes: bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20") Fixes: 600a3853dfa0 ("crypto: riscv - add vector crypto accelerated GHASH") Fixes: 8c8e40470ffe ("crypto: riscv - add vector crypto accelerated SHA-{256,224}") Fixes: b3415925a08b ("crypto: riscv - add vector crypto accelerated SHA-{512,384}") Fixes: 563a5255afa2 ("crypto: riscv - add vector crypto accelerated SM3") Fixes: b8d06352bbf3 ("crypto: riscv - add vector crypto accelerated SM4") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- arch/riscv/crypto/Kconfig | 12 ++++++++---- lib/crypto/Kconfig | 9 ++++++--- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/riscv/crypto/Kconfig b/arch/riscv/crypto/Kconfig index a75d6325607b..14c5acb935e9 100644 --- a/arch/riscv/crypto/Kconfig +++ b/arch/riscv/crypto/Kconfig @@ -2,11 +2,12 @@ menu "Accelerated Cryptographic Algorithms for CPU (riscv)" config CRYPTO_AES_RISCV64 tristate "Ciphers: AES, modes: ECB, CBC, CTS, CTR, XTS" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_ALGAPI select CRYPTO_LIB_AES select CRYPTO_SKCIPHER help Block cipher: AES cipher algorithms @@ -18,21 +19,23 @@ config CRYPTO_AES_RISCV64 - Zvkb vector crypto extension (CTR) - Zvkg vector crypto extension (XTS) config CRYPTO_GHASH_RISCV64 tristate "Hash functions: GHASH" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_GCM help GCM GHASH function (NIST SP 800-38D) Architecture: riscv64 using: - Zvkg vector crypto extension config CRYPTO_SM3_RISCV64 tristate "Hash functions: SM3 (ShangMi 3)" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_HASH select CRYPTO_LIB_SM3 help SM3 (ShangMi 3) secure hash function (OSCCA GM/T 0004-2012) @@ -40,11 +43,12 @@ config CRYPTO_SM3_RISCV64 - Zvksh vector crypto extension - Zvkb vector crypto extension config CRYPTO_SM4_RISCV64 tristate "Ciphers: SM4 (ShangMi 4)" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_ALGAPI select CRYPTO_SM4 help SM4 block cipher algorithm (OSCCA GB/T 32907-2016, ISO/IEC 18033-3:2010/Amd 1:2021) diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig index a3647352bff6..6871a41e5069 100644 --- a/lib/crypto/Kconfig +++ b/lib/crypto/Kconfig @@ -59,11 +59,12 @@ config CRYPTO_LIB_CHACHA_ARCH depends on CRYPTO_LIB_CHACHA && !UML && !KMSAN default y if ARM default y if ARM64 && KERNEL_MODE_NEON default y if MIPS && CPU_MIPS32_R2 default y if PPC64 && CPU_LITTLE_ENDIAN && VSX - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS default y if S390 default y if X86_64 config CRYPTO_LIB_CURVE25519 tristate @@ -182,11 +183,12 @@ config CRYPTO_LIB_SHA256_ARCH depends on CRYPTO_LIB_SHA256 && !UML default y if ARM && !CPU_V7M default y if ARM64 default y if MIPS && CPU_CAVIUM_OCTEON default y if PPC && SPE - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS default y if S390 default y if SPARC64 default y if X86_64 config CRYPTO_LIB_SHA512 @@ -200,11 +202,12 @@ config CRYPTO_LIB_SHA512_ARCH bool depends on CRYPTO_LIB_SHA512 && !UML default y if ARM && !CPU_V7M default y if ARM64 default y if MIPS && CPU_CAVIUM_OCTEON - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS default y if S390 default y if SPARC64 default y if X86_64 config CRYPTO_LIB_SHA3 base-commit: 43dfc13ca972988e620a6edb72956981b75ab6b0 -- 2.52.0

2 days, 6 hours

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror