October 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] bus: mhi: host: Detect events pointing to unexpected TREs" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 5bd398e20f0833ae8a1267d4f343591a2dd20185 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025082100-snowiness-profanity-df3a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5bd398e20f0833ae8a1267d4f343591a2dd20185 Mon Sep 17 00:00:00 2001 From: Youssef Samir <quic_yabdulra(a)quicinc.com> Date: Mon, 14 Jul 2025 18:30:39 +0200 Subject: [PATCH] bus: mhi: host: Detect events pointing to unexpected TREs When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. The host uses this pointer to process all of the TREs between it and the host's local copy of the ring's read pointer. This works when processing completion for chained transactions, but can lead to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple elements ahead of the host's read pointer. For instance, if the host accesses an event ring while the device is updating it, the pointer inside of the event might still point to an old TRE. If the host uses the channel's xfer_cb() to directly free the buffer pointed to by the TRE, the buffer will be double-freed. This behavior was observed on an ep that used upstream EP stack without 'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after buffer is written")'. Where the device updated the events ring pointer before updating the event contents, so it left a window where the host was able to access the stale data the event pointed to, before the device had the chance to update them. The usual pattern was that the host received an event pointing to a TRE that is not immediately after the last processed one, so it got treated as if it was a chained transaction, processing all of the TREs in between the two read pointers. This commit aims to harden the host by ensuring transactions where the event points to a TRE that isn't local_rp + 1 are chained. Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device") Signed-off-by: Youssef Samir <quic_yabdulra(a)quicinc.com> [mani: added stable tag and reworded commit message] Signed-off-by: Manivannan Sadhasivam <mani(a)kernel.org> Reviewed-by: Jeff Hugo <jeff.hugo(a)oss.qualcomm.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20250714163039.3438985-1-quic_yabdulra@quicinc.com diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c index 3041ee6747e3..52bef663e182 100644 --- a/drivers/bus/mhi/host/main.c +++ b/drivers/bus/mhi/host/main.c @@ -602,7 +602,7 @@ static int parse_xfer_event(struct mhi_controller *mhi_cntrl, { dma_addr_t ptr = MHI_TRE_GET_EV_PTR(event); struct mhi_ring_element *local_rp, *ev_tre; - void *dev_rp; + void *dev_rp, *next_rp; struct mhi_buf_info *buf_info; u16 xfer_len; @@ -621,6 +621,16 @@ static int parse_xfer_event(struct mhi_controller *mhi_cntrl, result.dir = mhi_chan->dir; local_rp = tre_ring->rp; + + next_rp = local_rp + 1; + if (next_rp >= tre_ring->base + tre_ring->len) + next_rp = tre_ring->base; + if (dev_rp != next_rp && !MHI_TRE_DATA_GET_CHAIN(local_rp)) { + dev_err(&mhi_cntrl->mhi_dev->dev, + "Event element points to an unexpected TRE\n"); + break; + } + while (local_rp != dev_rp) { buf_info = buf_ring->rp; /* If it's the last TRE, get length from the event */

3 weeks, 2 days

2
1
0 0

[STATUS] stable/linux-6.12.y - a9152eb181adaac576e8ac1ab79989881e0f301b

by KernelCI bot

Hello, Status summary for stable/linux-6.12.y Dashboard: https://d.kernelci.org/c/stable/linux-6.12.y/a9152eb181adaac576e8ac1ab79989… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-6.12.y commit hash: a9152eb181adaac576e8ac1ab79989881e0f301b origin: maestro test start time: 2025-10-06 09:30:07.031000+00:00 Builds: 44 ✅ 1 ❌ 0 ⚠️ Boots: 172 ✅ 4 ❌ 5 ⚠️ Tests: 10782 ✅ 945 ❌ 2510 ⚠️ ### POSSIBLE REGRESSIONS Hardware: imx6q-udoo > Config: multi_v7_defconfig - Architecture/compiler: arm/gcc-12 - kselftest.dt last run: https://d.kernelci.org/test/maestro:68e399ac9512ca5274538de3 history: > ✅ > ❌ ### FIXED REGRESSIONS No fixed regressions observed. ### UNSTABLE TESTS No unstable tests observed. This branch has 1 pre-existing build issues. See details in the dashboard. Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 2 days

1
0
0 0

[PATCH] scsi: fix shift out-of-bounds in sg_build_indirect The num variable is set to 0. The variable num gets its value from scatter_elem_sz. However the minimum value of scatter_elem_sz is PAGE_SHIFT. So setting num to PAGE_SIZE when num < PAGE_SIZE.

by Kshitij Paranjape

Cc: <stable(a)vger.kernel.org> Reported-by: syzbot+270f1c719ee7baab9941(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=270f1c719ee7baab9941 Signed-off-by: Kshitij Paranjape <kshitijvparanjape(a)gmail.com> --- drivers/scsi/sg.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index effb7e768165..9ae41bb256d7 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -1888,6 +1888,7 @@ sg_build_indirect(Sg_scatter_hold * schp, Sg_fd * sfp, int buff_size) if (num < PAGE_SIZE) { scatter_elem_sz = PAGE_SIZE; scatter_elem_sz_prev = PAGE_SIZE; + num = scatter_elem_sz; } else scatter_elem_sz_prev = num; } -- 2.43.0

3 weeks, 2 days

4
4
0 0

[PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)

by Jacob Keller

For idpf: Milena fixes a memory leak in the idpf reset logic when the driver resets with an outstanding Tx timestamp. Emil fixes a race condition in idpf_vport_stop() by using test_and_clear_bit() to ensure we execute idpf_vport_stop() once. For ixgbe and ixgbevf: Jedrzej fixes an issue with reporting link speed on E610 VFs. Jedrzej also fixes the VF mailbox API incompatibilities caused by the confusion with API v1.4, v1.5, and v1.6. The v1.4 API introduced IPSEC offload, but this was only supported on Linux hosts. The v1.5 API introduced a new mailbox API which is necessary to resolve issues on ESX hosts. The v1.6 API introduced a new link management API for E610. Jedrzej introduces a new v1.7 API with a feature negotiation which enables properly checking if features such as IPSEC or the ESX mailbox APIs are supported. This resolves issues with compatibility on different hosts, and aligns the API across hosts instead of having Linux require custom mailbox API versions for IPSEC offload. Koichiro fixes a KASAN use-after-free bug in ixgbe_remove(). Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> --- Emil Tantilov (2): idpf: convert vport state to bitmap idpf: fix possible race in idpf_vport_stop() Jedrzej Jagielski (4): ixgbevf: fix getting link speed data for E610 devices ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation ixgbevf: fix mailbox API compatibility by negotiating supported features ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd Koichiro Den (1): ixgbe: fix too early devlink_free() in ixgbe_remove() Milena Olech (1): idpf: cleanup remaining SKBs in PTP flows drivers/net/ethernet/intel/idpf/idpf.h | 12 +- drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 15 ++ drivers/net/ethernet/intel/ixgbevf/defines.h | 1 + drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 + drivers/net/ethernet/intel/ixgbevf/mbx.h | 8 + drivers/net/ethernet/intel/ixgbevf/vf.h | 1 + drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 10 +- drivers/net/ethernet/intel/idpf/idpf_lib.c | 23 ++- drivers/net/ethernet/intel/idpf/idpf_ptp.c | 3 + .../net/ethernet/intel/idpf/idpf_singleq_txrx.c | 2 +- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 4 +- .../net/ethernet/intel/idpf/idpf_virtchnl_ptp.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +- drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 79 +++++++++ drivers/net/ethernet/intel/ixgbevf/ipsec.c | 10 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 34 +++- drivers/net/ethernet/intel/ixgbevf/vf.c | 182 +++++++++++++++++---- 18 files changed, 335 insertions(+), 62 deletions(-) --- base-commit: daa26ea63c6f848159821cd9b3cbe47cddbb0a1c change-id: 20251001-jk-iwl-net-2025-10-01-92cd2a626ff7 Best regards, -- Jacob Keller <jacob.e.keller(a)intel.com>

3 weeks, 3 days

3
7
0 0

[PATCH AUTOSEL 6.17-5.4] x86/build: Remove cc-option from stack alignment flags

by Sasha Levin

From: Nathan Chancellor <nathan(a)kernel.org> [ Upstream commit d87208128a3330c0eab18301ab39bdb419647730 ] '-mpreferred-stack-boundary' (the GCC option) and '-mstack-alignment' (the clang option) have been supported in their respective compilers for some time, so it is unnecessary to check for support for them via cc-option. '-mpreferred-stack-boundary=3' had a restriction on '-mno-sse' until GCC 7.1 but that is irrelevant for most of the kernel, which includes '-mno-sse'. Move to simple Kconfig checks to avoid querying the compiler for the flags that it supports. Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Link: https://lore.kernel.org/20250814-x86-min-ver-cleanups-v1-2-ff7f19457523@ker… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my comprehensive analysis of this commit, here is my determination: ## Backport Status: NO ### Extensive Analysis **Commit Context:** - Upstream commit: d87208128a3330c0eab18301ab39bdb419647730 (August 14, 2025) - Author: Nathan Chancellor - Part of patch series: "x86-min-ver-cleanups-v1" - Already backported to 6.17 stable as 8be33f616f1c4 via AUTOSEL (Automatic Stable Election) - Target tree: linux-autosel-6.17 (kernel 6.17) **What the Commit Does:** The commit removes runtime compiler capability checks (`cc-option`) for stack alignment flags and replaces them with build-time Kconfig checks: - For GCC: Uses `CONFIG_CC_IS_GCC` to unconditionally set `-mpreferred- stack-boundary=2/3` - For Clang: Uses `CONFIG_CC_IS_CLANG` to unconditionally set `-mstack- alignment=4/8` **Code Changes Analysis:** ```makefile # OLD: Runtime check if compiler supports the flags -ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) +ifdef CONFIG_CC_IS_GCC cc_stack_align4 := -mpreferred-stack-boundary=2 cc_stack_align8 := -mpreferred-stack-boundary=3 -else ifneq ($(call cc-option, -mstack-alignment=16),) +endif +ifdef CONFIG_CC_IS_CLANG cc_stack_align4 := -mstack-alignment=4 cc_stack_align8 := -mstack-alignment=8 endif ``` **Dependency Analysis:** - Requires minimum GCC 8.1 for x86 (introduced in v6.15 via commit a3e8fe814ad1) - Requires minimum Clang 15.0.0 for x86 (commit 7861640aac52b) - Both requirements are satisfied in 6.17 stable tree (verified via scripts/min-tool-version.sh) - GCC 7.1+ supports `-mpreferred-stack-boundary=3` with `-msse` (per GCC commit 34fac449e121) **Evaluation Against Stable Kernel Rules:** According to Documentation/process/stable-kernel-rules.rst, stable patches must: 1. ✅ **Already exist in mainline**: YES - d87208128a3330c0eab18301ab39bdb419647730 2. ✅ **Obviously correct and tested**: YES - simple Makefile change, no issues found 3. ✅ **Not bigger than 100 lines**: YES - only 5 lines changed (3 insertions, 2 deletions) 4. ✅ **Follow submitting-patches.rst rules**: YES 5. ❌ **Fix a real bug or add device ID**: **NO - This is the critical failure** The rules explicitly state (lines 15-31 of stable-kernel-rules.rst): > "It must either fix a real bug that bothers people or just add a device ID." This commit: - Does **NOT** fix a bug (no oops, hang, data corruption, security issue, build error, etc.) - Is a **cleanup/optimization** to improve build performance - Provides **no user-visible bug fix** - Falls under "trivial fixes without benefit for users" category (rule line 30-31) - The original author did **NOT** tag it with `Cc: stable(a)vger.kernel.org` **Search for Issues/Regressions:** - Searched Linux kernel mailing lists: No issues found - Searched for reverts: None found - Searched for build failures: None reported - Part of systematic cleanup series with no reported problems **Risk Assessment:** - **Technical risk**: Very low - simple change, dependencies satisfied - **Regression risk**: Very low - no functionality change, just build system optimization - **Policy compliance**: **Does not meet stable kernel criteria** ### Conclusion While this commit is technically safe and provides a marginal build-time performance improvement by eliminating unnecessary runtime compiler checks, **it does not meet the fundamental requirement for stable kernel backporting**: it does not fix a bug that affects users. The commit is purely a cleanup that removes obsolete code after compiler minimum version requirements were raised. Such cleanups belong in mainline development, not stable trees, which should focus exclusively on fixing bugs that impact users. The fact that it was auto-selected by AUTOSEL does not override the documented stable kernel rules. This commit should be **rejected** from stable backporting or **reverted** if already applied. arch/x86/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 1913d342969ba..7cfc1b31f17e1 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -37,10 +37,11 @@ export RETPOLINE_VDSO_CFLAGS # For gcc stack alignment is specified with -mpreferred-stack-boundary, # clang has the option -mstack-alignment for that purpose. -ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) +ifdef CONFIG_CC_IS_GCC cc_stack_align4 := -mpreferred-stack-boundary=2 cc_stack_align8 := -mpreferred-stack-boundary=3 -else ifneq ($(call cc-option, -mstack-alignment=16),) +endif +ifdef CONFIG_CC_IS_CLANG cc_stack_align4 := -mstack-alignment=4 cc_stack_align8 := -mstack-alignment=8 endif -- 2.51.0

3 weeks, 3 days

2
29
0 0

[PATCH net v2 0/6] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)

by Jacob Keller

For idpf: Milena fixes a memory leak in the idpf reset logic when the driver resets with an outstanding Tx timestamp. For ixgbe and ixgbevf: Jedrzej fixes an issue with reporting link speed on E610 VFs. Jedrzej also fixes the VF mailbox API incompatibilities caused by the confusion with API v1.4, v1.5, and v1.6. The v1.4 API introduced IPSEC offload, but this was only supported on Linux hosts. The v1.5 API introduced a new mailbox API which is necessary to resolve issues on ESX hosts. The v1.6 API introduced a new link management API for E610. Jedrzej introduces a new v1.7 API with a feature negotiation which enables properly checking if features such as IPSEC or the ESX mailbox APIs are supported. This resolves issues with compatibility on different hosts, and aligns the API across hosts instead of having Linux require custom mailbox API versions for IPSEC offload. Koichiro fixes a KASAN use-after-free bug in ixgbe_remove(). Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> --- Changes in v2: - Drop Emil's idpf_vport_open race fix for now. - Add my signature. - Link to v1: https://lore.kernel.org/r/20251001-jk-iwl-net-2025-10-01-v1-0-49fa99e86600@… --- Jedrzej Jagielski (4): ixgbevf: fix getting link speed data for E610 devices ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation ixgbevf: fix mailbox API compatibility by negotiating supported features ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd Koichiro Den (1): ixgbe: fix too early devlink_free() in ixgbe_remove() Milena Olech (1): idpf: cleanup remaining SKBs in PTP flows drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 15 ++ drivers/net/ethernet/intel/ixgbevf/defines.h | 1 + drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 + drivers/net/ethernet/intel/ixgbevf/mbx.h | 8 + drivers/net/ethernet/intel/ixgbevf/vf.h | 1 + drivers/net/ethernet/intel/idpf/idpf_ptp.c | 3 + .../net/ethernet/intel/idpf/idpf_virtchnl_ptp.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +- drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 79 +++++++++ drivers/net/ethernet/intel/ixgbevf/ipsec.c | 10 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 34 +++- drivers/net/ethernet/intel/ixgbevf/vf.c | 182 +++++++++++++++++---- 12 files changed, 310 insertions(+), 34 deletions(-) --- base-commit: daa26ea63c6f848159821cd9b3cbe47cddbb0a1c change-id: 20251001-jk-iwl-net-2025-10-01-92cd2a626ff7 Best regards, -- Jacob Keller <jacob.e.keller(a)intel.com>

3 weeks, 3 days

2
4
0 0

[PATCH net v2] page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches

by Toke Høiland-Jørgensen

Helge reported that the introduction of PP_MAGIC_MASK let to crashes on boot on his 32-bit parisc machine. The cause of this is the mask is set too wide, so the page_pool_page_is_pp() incurs false positives which crashes the machine. Just disabling the check in page_pool_is_pp() will lead to the page_pool code itself malfunctioning; so instead of doing this, this patch changes the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel pointers for page_pool-tagged pages. The fix relies on the kernel pointers that alias with the pp_magic field always being above PAGE_OFFSET. With this assumption, we can use the lowest bit of the value of PAGE_OFFSET as the upper bound of the PP_DMA_INDEX_MASK, which should avoid the false positives. Because we cannot rely on PAGE_OFFSET always being a compile-time constant, nor on it always being >0, we fall back to disabling the dma_index storage when there are not enough bits available. This leaves us in the situation we were in before the patch in the Fixes tag, but only on a subset of architecture configurations. This seems to be the best we can do until the transition to page types in complete for page_pool pages. v2: - Make sure there's at least 8 bits available and that the PAGE_OFFSET bit calculation doesn't wrap Link: https://lore.kernel.org/all/aMNJMFa5fDalFmtn@p100/ Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Cc: stable(a)vger.kernel.org # 6.15+ Tested-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> --- include/linux/mm.h | 22 +++++++------ net/core/page_pool.c | 76 ++++++++++++++++++++++++++++++-------------- 2 files changed, 66 insertions(+), 32 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1ae97a0b8ec7..0905eb6b55ec 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -4159,14 +4159,13 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); * since this value becomes part of PP_SIGNATURE; meaning we can just use the * space between the PP_SIGNATURE value (without POISON_POINTER_DELTA), and the * lowest bits of POISON_POINTER_DELTA. On arches where POISON_POINTER_DELTA is - * 0, we make sure that we leave the two topmost bits empty, as that guarantees - * we won't mistake a valid kernel pointer for a value we set, regardless of the - * VMSPLIT setting. + * 0, we use the lowest bit of PAGE_OFFSET as the boundary if that value is + * known at compile-time. * - * Altogether, this means that the number of bits available is constrained by - * the size of an unsigned long (at the upper end, subtracting two bits per the - * above), and the definition of PP_SIGNATURE (with or without - * POISON_POINTER_DELTA). + * If the value of PAGE_OFFSET is not known at compile time, or if it is too + * small to leave at least 8 bits available above PP_SIGNATURE, we define the + * number of bits to be 0, which turns off the DMA index tracking altogether + * (see page_pool_register_dma_index()). */ #define PP_DMA_INDEX_SHIFT (1 + __fls(PP_SIGNATURE - POISON_POINTER_DELTA)) #if POISON_POINTER_DELTA > 0 @@ -4175,8 +4174,13 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); */ #define PP_DMA_INDEX_BITS MIN(32, __ffs(POISON_POINTER_DELTA) - PP_DMA_INDEX_SHIFT) #else -/* Always leave out the topmost two; see above. */ -#define PP_DMA_INDEX_BITS MIN(32, BITS_PER_LONG - PP_DMA_INDEX_SHIFT - 2) +/* Use the lowest bit of PAGE_OFFSET if there's at least 8 bits available; see above */ +#define PP_DMA_INDEX_MIN_OFFSET (1 << (PP_DMA_INDEX_SHIFT + 8)) +#define PP_DMA_INDEX_BITS ((__builtin_constant_p(PAGE_OFFSET) && \ + PAGE_OFFSET >= PP_DMA_INDEX_MIN_OFFSET && \ + !(PAGE_OFFSET & (PP_DMA_INDEX_MIN_OFFSET - 1))) ? \ + MIN(32, __ffs(PAGE_OFFSET) - PP_DMA_INDEX_SHIFT) : 0) + #endif #define PP_DMA_INDEX_MASK GENMASK(PP_DMA_INDEX_BITS + PP_DMA_INDEX_SHIFT - 1, \ diff --git a/net/core/page_pool.c b/net/core/page_pool.c index 492728f9e021..1a5edec485f1 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -468,11 +468,60 @@ page_pool_dma_sync_for_device(const struct page_pool *pool, } } +static int page_pool_register_dma_index(struct page_pool *pool, + netmem_ref netmem, gfp_t gfp) +{ + int err = 0; + u32 id; + + if (unlikely(!PP_DMA_INDEX_BITS)) + goto out; + + if (in_softirq()) + err = xa_alloc(&pool->dma_mapped, &id, netmem_to_page(netmem), + PP_DMA_INDEX_LIMIT, gfp); + else + err = xa_alloc_bh(&pool->dma_mapped, &id, netmem_to_page(netmem), + PP_DMA_INDEX_LIMIT, gfp); + if (err) { + WARN_ONCE(err != -ENOMEM, "couldn't track DMA mapping, please report to netdev@"); + goto out; + } + + netmem_set_dma_index(netmem, id); +out: + return err; +} + +static int page_pool_release_dma_index(struct page_pool *pool, + netmem_ref netmem) +{ + struct page *old, *page = netmem_to_page(netmem); + unsigned long id; + + if (unlikely(!PP_DMA_INDEX_BITS)) + return 0; + + id = netmem_get_dma_index(netmem); + if (!id) + return -1; + + if (in_softirq()) + old = xa_cmpxchg(&pool->dma_mapped, id, page, NULL, 0); + else + old = xa_cmpxchg_bh(&pool->dma_mapped, id, page, NULL, 0); + if (old != page) + return -1; + + netmem_set_dma_index(netmem, 0); + + return 0; +} + static bool page_pool_dma_map(struct page_pool *pool, netmem_ref netmem, gfp_t gfp) { dma_addr_t dma; int err; - u32 id; /* Setup DMA mapping: use 'struct page' area for storing DMA-addr * since dma_addr_t can be either 32 or 64 bits and does not always fit @@ -491,18 +540,10 @@ static bool page_pool_dma_map(struct page_pool *pool, netmem_ref netmem, gfp_t g goto unmap_failed; } - if (in_softirq()) - err = xa_alloc(&pool->dma_mapped, &id, netmem_to_page(netmem), - PP_DMA_INDEX_LIMIT, gfp); - else - err = xa_alloc_bh(&pool->dma_mapped, &id, netmem_to_page(netmem), - PP_DMA_INDEX_LIMIT, gfp); - if (err) { - WARN_ONCE(err != -ENOMEM, "couldn't track DMA mapping, please report to netdev@"); + err = page_pool_register_dma_index(pool, netmem, gfp); + if (err) goto unset_failed; - } - netmem_set_dma_index(netmem, id); page_pool_dma_sync_for_device(pool, netmem, pool->p.max_len); return true; @@ -680,8 +721,6 @@ void page_pool_clear_pp_info(netmem_ref netmem) static __always_inline void __page_pool_release_netmem_dma(struct page_pool *pool, netmem_ref netmem) { - struct page *old, *page = netmem_to_page(netmem); - unsigned long id; dma_addr_t dma; if (!pool->dma_map) @@ -690,15 +729,7 @@ static __always_inline void __page_pool_release_netmem_dma(struct page_pool *poo */ return; - id = netmem_get_dma_index(netmem); - if (!id) - return; - - if (in_softirq()) - old = xa_cmpxchg(&pool->dma_mapped, id, page, NULL, 0); - else - old = xa_cmpxchg_bh(&pool->dma_mapped, id, page, NULL, 0); - if (old != page) + if (page_pool_release_dma_index(pool, netmem)) return; dma = page_pool_get_dma_addr_netmem(netmem); @@ -708,7 +739,6 @@ static __always_inline void __page_pool_release_netmem_dma(struct page_pool *poo PAGE_SIZE << pool->p.order, pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_WEAK_ORDERING); page_pool_set_dma_addr_netmem(netmem, 0); - netmem_set_dma_index(netmem, 0); } /* Disconnects a page (from a page_pool). API users can have a need -- 2.51.0

3 weeks, 3 days

4
5
0 0

[PATCH] PCI: probe: fix typo: CONFIG_PCI_PWRCTRL -> CONFIG_PCI_PWRCTL

by Victor Paul

The commit 8c493cc91f3a ("PCI/pwrctrl: Create pwrctrl devices only when CONFIG_PCI_PWRCTRL is enabled") introduced a typo, it uses CONFIG_PCI_PWRCTRL while the correct symbol is CONFIG_PCI_PWRCTL. As reported by Daniel Martin, it causes device initialization failures on some arm boards. I encountered it on sm8250-xiaomi-pipa after rebasing from v6.15.8 to v6.15.11, with the following error: [ 6.035321] pcieport 0000:00:00.0: Failed to create device link (0x180) with supplier qca6390-pmu for /soc@0/pcie@1c00000/pcie@0/wifi@0 Fix the typo to use the correct CONFIG_PCI_PWRCTL symbol. Fixes: 8c493cc91f3a ("PCI/pwrctrl: Create pwrctrl devices only when CONFIG_PCI_PWRCTRL is enabled") Cc: stable(a)vger.kernel.org Reported-by: Daniel Martin <dmanlfc(a)gmail.com> Closes: https://lore.kernel.org/linux-pci/2025081053-expectant-observant-6268@gregk… Signed-off-by: Victor Paul <vipoll(a)mainlining.org> --- drivers/pci/probe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 19010c382864..7e97e33b3fb5 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2508,7 +2508,7 @@ bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l, } EXPORT_SYMBOL(pci_bus_read_dev_vendor_id); -#if IS_ENABLED(CONFIG_PCI_PWRCTRL) +#if IS_ENABLED(CONFIG_PCI_PWRCTL) static struct platform_device *pci_pwrctrl_create_device(struct pci_bus *bus, int devfn) { struct pci_host_bridge *host = pci_find_host_bridge(bus); -- 2.51.0

3 weeks, 3 days

3
2
0 0

Backport request for commit 5326ab737a47 ("virtio_console: fix order of fields cols and rows")

by Filip Hejsek

Hi, I would like to request backporting 5326ab737a47 ("virtio_console: fix order of fields cols and rows") to all LTS kernels. I'm working on QEMU patches that add virtio console size support. Without the fix, rows and columns will be swapped. As far as I know, there are no device implementations that use the wrong order and would by broken by the fix. Note: A previous version [1] of the patch contained "Cc: stable" and "Fixes:" tags, but they seem to have been accidentally left out from the final version. [1]: https://lore.kernel.org/all/20250320172654.624657-1-maxbr@linux.ibm.com/ Thanks, Filip Hejsek

3 weeks, 3 days

2
5
0 0

[PATCH] serial: sc16is7xx: remove useless enable of enhanced features

by Hugo Villeneuve

From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that. Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured. Fixes: 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") Cc: stable(a)vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> --- This patch was originally part of this series: https://lore.kernel.org/linux-serial/20251002145738.3250272-1-hugo@hugovil.… and it is now separate as suggested by Greg to facilitate stable backporting. --- drivers/tty/serial/sc16is7xx.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 1a2c4c14f6aac..c7435595dce13 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud) div /= prescaler; } - /* Enable enhanced features */ - sc16is7xx_efr_lock(port); - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - sc16is7xx_efr_unlock(port); - /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT, base-commit: fd94619c43360eb44d28bd3ef326a4f85c600a07 -- 2.39.5

3 weeks, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2025