* Re: [PATCH v2] Docs: iio: ad7191 Correct clock configuration
From: Geert Uytterhoeven @ 2026-03-30 8:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ammar Mustafa, Alisa-Dariana Roman, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, linux-doc, linux-kernel
In-Reply-To: <aaLIhgJjrNlp3oTy@ashevche-desk.local>
On Sat, 28 Feb 2026 at 11:51, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
> On Fri, Feb 27, 2026 at 02:08:33PM -0500, Ammar Mustafa wrote:
> > Correct the ad7191 documentation to match the datasheet:
> > - Fix inverted CLKSEL pin logic: device uses external clock when pin is
> > inactive, and internal CMOS/crystal when high.
>
> high --> active
Thanks for your patch, which is now commit d2a4ec19d2a2e54c ("Docs:
iio: ad7191 Correct clock configuration") in char-misc-next and
iio/togreg.
That commit message still says "inactive" and "high", thus adding to
the confustion.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] mm/memory-failure: add panic_on_unrecoverable_memory_failure sysctl
From: Miaohe Lin @ 2026-03-30 7:55 UTC (permalink / raw)
To: Breno Leitao
Cc: linux-mm, linux-kernel, linux-doc, kernel-team, Naoya Horiguchi,
Andrew Morton, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260323-ecc_panic-v1-1-72a1921726c5@debian.org>
On 2026/3/23 23:29, Breno Leitao wrote:
> When memory_failure() encounters an in-use kernel page that cannot be
> recovered (slab, page tables, kernel stacks, reserved, vmalloc, etc.),
> it currently logs MF_IGNORED and continues. This leaves corrupted data
> accessible to the kernel, risking silent data corruption or a delayed
> crash when the poisoned cache line is next accessed.
>
> For example, a multi-bit ECC error on a dentry cache slab page was
> ignored by memory_failure(), and 67 seconds later d_lookup() accessed
> the poisoned cache line, causing a synchronous external abort:
>
> [88690.479680] [Hardware Error]: error_type: 3, multi-bit ECC
> [88690.498473] Memory failure: 0x40272d: unhandlable page.
> [88690.498619] Memory failure: 0x40272d: recovery action for
> get hwpoison page: Ignored
> ...
> [88757.847126] Internal error: synchronous external abort:
> 0000000096000410 [#1] SMP
> [88758.061075] pc : d_lookup+0x5c/0x220
>
> Add a new sysctl vm.panic_on_unrecoverable_memory_failure (default 0)
> that, when set to 1, panics immediately on unrecoverable memory
> failures. This provides a clean crash dump at the time of the error
> rather than a delayed crash with potential silent corruption in between.
>
> The panic is placed in action_result() so that all call sites that log
> MF_MSG_GET_HWPOISON with MF_IGNORED are covered, including the hugetlb
> path in try_memory_failure_hugetlb().
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> mm/memory-failure.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index ee42d43613097..25bd043497195 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -74,6 +74,8 @@ static int sysctl_memory_failure_recovery __read_mostly = 1;
>
> static int sysctl_enable_soft_offline __read_mostly = 1;
>
> +static int sysctl_panic_on_unrecoverable_mf __read_mostly;
> +
> atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
>
> static bool hw_memory_failure __read_mostly = false;
> @@ -155,6 +157,15 @@ static const struct ctl_table memory_failure_table[] = {
> .proc_handler = proc_dointvec_minmax,
> .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_ONE,
> + },
> + {
> + .procname = "panic_on_unrecoverable_memory_failure",
> + .data = &sysctl_panic_on_unrecoverable_mf,
> + .maxlen = sizeof(sysctl_panic_on_unrecoverable_mf),
> + .mode = 0644,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_ONE,
> }
> };
>
> @@ -1298,6 +1309,10 @@ static int action_result(unsigned long pfn, enum mf_action_page_type type,
> pr_err("%#lx: recovery action for %s: %s\n",
> pfn, action_page_types[type], action_name[result]);
>
> + if (sysctl_panic_on_unrecoverable_mf &&
> + type == MF_MSG_GET_HWPOISON && result == MF_IGNORED)
> + panic("Memory failure: %#lx: unrecoverable page", pfn);
MF_MSG_GET_HWPOISON contains some other scenarios. For example, an isolated folio will
make get_hwpoison_page return -EIO so we will see MF_MSG_GET_HWPOISON and MF_IGNORED in
action_result. But that's recoverable if folio is used by userspace thus panic will be
unacceptable.
Will it better to check type against MF_MSG_KERNEL_HIGH_ORDER?
Thanks.
.
^ permalink raw reply
* Re: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
From: kernel test robot @ 2026-03-30 7:49 UTC (permalink / raw)
To: Jim Mattson, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, kvm, linux-doc,
linux-kernel, linux-kselftest, Yosry Ahmed
Cc: oe-kbuild-all, Jim Mattson
In-Reply-To: <20260327234023.2659476-2-jmattson@google.com>
Hi Jim,
kernel test robot noticed the following build errors:
[auto build test ERROR on 3d6cdcc8883b5726513d245eef0e91cabfc397f7]
url: https://github.com/intel-lab-lkp/linux/commits/Jim-Mattson/KVM-x86-Define-KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT/20260328-110805
base: 3d6cdcc8883b5726513d245eef0e91cabfc397f7
patch link: https://lore.kernel.org/r/20260327234023.2659476-2-jmattson%40google.com
patch subject: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
config: x86_64-randconfig-016-20260330 (https://download.01.org/0day-ci/archive/20260330/202603301501.N2sdlIQ9-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260330/202603301501.N2sdlIQ9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603301501.N2sdlIQ9-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/kvm/svm/svm_onhyperv.c:11:
arch/x86/kvm/svm/svm.h: In function 'l2_has_separate_pat':
>> arch/x86/kvm/svm/svm.h:626:18: error: implicit declaration of function 'kvm_check_has_quirk'; did you mean 'kvm_check_request'? [-Wimplicit-function-declaration]
626 | !kvm_check_has_quirk(svm->vcpu.kvm,
| ^~~~~~~~~~~~~~~~~~~
| kvm_check_request
In file included from arch/x86/kvm/svm/svm_ops.h:7,
from arch/x86/kvm/svm/svm_onhyperv.c:12:
arch/x86/kvm/x86.h: At top level:
>> arch/x86/kvm/x86.h:429:20: error: conflicting types for 'kvm_check_has_quirk'; have 'bool(struct kvm *, u64)' {aka '_Bool(struct kvm *, long long unsigned int)'}
429 | static inline bool kvm_check_has_quirk(struct kvm *kvm, u64 quirk)
| ^~~~~~~~~~~~~~~~~~~
arch/x86/kvm/svm/svm.h:626:18: note: previous implicit declaration of 'kvm_check_has_quirk' with type 'int()'
626 | !kvm_check_has_quirk(svm->vcpu.kvm,
| ^~~~~~~~~~~~~~~~~~~
--
In file included from kvm/svm/svm_onhyperv.c:11:
kvm/svm/svm.h: In function 'l2_has_separate_pat':
kvm/svm/svm.h:626:18: error: implicit declaration of function 'kvm_check_has_quirk'; did you mean 'kvm_check_request'? [-Wimplicit-function-declaration]
626 | !kvm_check_has_quirk(svm->vcpu.kvm,
| ^~~~~~~~~~~~~~~~~~~
| kvm_check_request
In file included from kvm/svm/svm_ops.h:7,
from kvm/svm/svm_onhyperv.c:12:
arch/x86/kvm/x86.h: At top level:
>> arch/x86/kvm/x86.h:429:20: error: conflicting types for 'kvm_check_has_quirk'; have 'bool(struct kvm *, u64)' {aka '_Bool(struct kvm *, long long unsigned int)'}
429 | static inline bool kvm_check_has_quirk(struct kvm *kvm, u64 quirk)
| ^~~~~~~~~~~~~~~~~~~
kvm/svm/svm.h:626:18: note: previous implicit declaration of 'kvm_check_has_quirk' with type 'int()'
626 | !kvm_check_has_quirk(svm->vcpu.kvm,
| ^~~~~~~~~~~~~~~~~~~
vim +626 arch/x86/kvm/svm/svm.h
618
619 static inline bool l2_has_separate_pat(struct vcpu_svm *svm)
620 {
621 /*
622 * If KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT is disabled while a vCPU
623 * is running, the L2 IA32_PAT semantics for that vCPU are undefined.
624 */
625 return nested_npt_enabled(svm) &&
> 626 !kvm_check_has_quirk(svm->vcpu.kvm,
627 KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT);
628 }
629
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v11 01/11] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Guo Ren @ 2026-03-30 7:49 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, cfsworks, osandov,
jbohac, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, chenjiahao16, hbathini,
takahiro.akashi, james.morse, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <baa90080-9e6e-c1e5-13a1-b17496c690b4@huawei.com>
On Mon, Mar 30, 2026 at 3:11 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
>
>
> On 2026/3/30 11:49, Guo Ren wrote:
> > On Sat, Mar 28, 2026 at 3:41 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> >>
> >> As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
> >> and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
> >> crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
> >> riscv should have excluded the "crashk_low_res" reserved ranges from
> >> the crash kernel memory to prevent them from being exported through
> >> /proc/vmcore, and the exclusion would need an extra crash_mem range.
> >>
> >> Cc: Guo Ren <guoren@kernel.org>
> >> Cc: Baoquan He <bhe@redhat.com>
> >> Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
> >> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> >> ---
> >> arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
> >> 1 file changed, 11 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> >> index 54e2d9552e93..3f7766057cac 100644
> >> --- a/arch/riscv/kernel/machine_kexec_file.c
> >> +++ b/arch/riscv/kernel/machine_kexec_file.c
> >> @@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
> >> unsigned int nr_ranges;
> >> int ret;
> >>
> >> - nr_ranges = 1; /* For exclusion of crashkernel region */
> >> + nr_ranges = 2; /* For exclusion of crashkernel region */
> >> walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> >>
> >> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> >> @@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
> >>
> >> /* Exclude crashkernel region */
> >> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> >> - if (!ret)
> >> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + if (crashk_low_res.end) {
> >> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> > Exclude crashk_low_res is reasonable, but have you tested this?
>
> Just simply tested on qemu with crashkernel=4G with following kexec
> mentioned in
> https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/.
> And the second kernel can be started normally.
>
> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>
> # dmesg | grep crash
> [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000
> (128 MB)
> [ 0.000000] crashkernel reserved: 0x000000017fe00000 -
> 0x000000027fe00000 (4096 MB)
Adding a test log to the commit log makes the patch more trustworthy.
Reviewed-by: Guo Ren <guoren@kernel.org>
>
>
>
> >
> >> + if (ret)
> >> + goto out;
> >> + }
> >> +
> >> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> >>
> >> out:
> >> kfree(cmem);
> >> --
> >> 2.34.1
> >>
> >
> >
--
Best Regards
Guo Ren
^ permalink raw reply
* Re: [PATCH v14 00/12] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Bartosz Golaszewski @ 2026-03-30 7:48 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, dmaengine, linux-doc,
linux-kernel, linux-arm-msm, linux-crypto, linux-arm-kernel,
Bartosz Golaszewski, Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-0-f323af411274@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 4:17 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> This iteration is quite similar to v12 but uses the BAM's NWD bit on
> data descriptors as suggested by Stephan. To that end, there are some
> more changes like reversing the order of command and data descriptors
> queuedy by the QCE driver.
>
> Currently the QCE crypto driver accesses the crypto engine registers
> directly via CPU. Trust Zone may perform crypto operations simultaneously
> resulting in a race condition. To remedy that, let's introduce support
> for BAM locking/unlocking to the driver. The BAM driver will now wrap
> any existing issued descriptor chains with additional descriptors
> performing the locking when the client starts the transaction
> (dmaengine_issue_pending()). The client wanting to profit from locking
> needs to switch to performing register I/O over DMA and communicate the
> address to which to perform the dummy writes via a call to
> dmaengine_desc_attach_metadata().
>
> In the specific case of the BAM DMA this translates to sending command
> descriptors performing dummy writes with the relevant flags set. The BAM
> will then lock all other pipes not related to the current pipe group, and
> keep handling the current pipe only until it sees the the unlock bit.
>
Hi Vinod et al!
Any chance of this making v7.1? Stephan, Mani: any objections to the
current approach?
Bart
^ permalink raw reply
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Krzysztof Kozlowski @ 2026-03-30 7:15 UTC (permalink / raw)
To: Cristian Marussi, Rob Herring (Arm)
Cc: etienne.carriere, Krzysztof Kozlowski, d-gole, linux-fsdevel,
Conor Dooley, linux-doc, f.fainelli, vincent.guittot,
philip.radford, souvik.chakravarty, peng.fan, dan.carpenter,
lukasz.luba, arm-scmi, sudeep.holla, michal.simek, linux-kernel,
jonathan.cameron, elif.topuz, linux-arm-kernel, james.quinlan,
devicetree, brauner
In-Reply-To: <aclo1laTrsQFSan6@pluto>
On 29/03/2026 20:00, Cristian Marussi wrote:
>>
>> My bot found errors running 'make dt_binding_check' on your patch:
>>
>> yamllint warnings/errors:
>>
>> dtschema/dtc warnings/errors:
>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/arm,scmi.example.dtb: scmi (arm,scmi): protocol@19: Unevaluated properties are not allowed ('i2c2-pins', 'keys-pins', 'mdio-pins' were unexpected)
>> from schema $id: http://devicetree.org/schemas/firmware/arm,scmi.yaml
>>
>> doc reference errors (make refcheckdocs):
>>
>> See https://patchwork.kernel.org/project/devicetree/patch/20260329163337.637393-7-cristian.marussi@arm.com
>>
>> The base for the series is generally the latest rc1. A different dependency
>> should be noted in *this* patch.
>>
>> If you already ran 'make dt_binding_check' and didn't see the above
>> error(s), then make sure 'yamllint' is installed and dt-schema is up to
>> date:
>>
>> pip3 install dtschema --upgrade
>>
>
> Yes...the new protocol block definition ended up intermixed with the
> previous protocol block...totally wrong.
This is not a problem. Problem was that you did not test it and sent
completely untested code to mailing list.
Add "RFC" prefix you subjects so we know that we can ignore the patchset
in the future.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Krzysztof Kozlowski @ 2026-03-30 7:11 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, arm-scmi, linux-fsdevel,
linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, d-gole, jonathan.cameron, elif.topuz, lukasz.luba,
philip.radford, brauner, souvik.chakravarty, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260329163337.637393-7-cristian.marussi@arm.com>
On Sun, Mar 29, 2026 at 05:33:17PM +0100, Cristian Marussi wrote:
> Add new SCMI v4.0 Telemetry protocol bindings definitions.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> ---
> Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index be817fd9cc34..e936ae7c0fb9 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -298,6 +298,14 @@ properties:
> reg:
> const: 0x19
>
> + protocol@1B:
It's always lowercase hex in DTS.
> + $ref: '#/$defs/protocol-node'
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + const: 0x1B
Here as well.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 01/11] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-03-30 7:11 UTC (permalink / raw)
To: Guo Ren
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, cfsworks, osandov,
jbohac, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, chenjiahao16, hbathini,
takahiro.akashi, james.morse, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <CAJF2gTRN=RpgzQsQ7QDbwjDmyQZP9anQZ+CaK2r-Mrz9dQbohQ@mail.gmail.com>
On 2026/3/30 11:49, Guo Ren wrote:
> On Sat, Mar 28, 2026 at 3:41 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>
>> As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
>> and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
>> crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
>> riscv should have excluded the "crashk_low_res" reserved ranges from
>> the crash kernel memory to prevent them from being exported through
>> /proc/vmcore, and the exclusion would need an extra crash_mem range.
>>
>> Cc: Guo Ren <guoren@kernel.org>
>> Cc: Baoquan He <bhe@redhat.com>
>> Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
>> index 54e2d9552e93..3f7766057cac 100644
>> --- a/arch/riscv/kernel/machine_kexec_file.c
>> +++ b/arch/riscv/kernel/machine_kexec_file.c
>> @@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>> unsigned int nr_ranges;
>> int ret;
>>
>> - nr_ranges = 1; /* For exclusion of crashkernel region */
>> + nr_ranges = 2; /* For exclusion of crashkernel region */
>> walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
>>
>> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>> @@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>>
>> /* Exclude crashkernel region */
>> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>> - if (!ret)
>> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> + if (ret)
>> + goto out;
>> +
>> + if (crashk_low_res.end) {
>> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> Exclude crashk_low_res is reasonable, but have you tested this?
Just simply tested on qemu with crashkernel=4G with following kexec
mentioned in
https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/.
And the second kernel can be started normally.
https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000
(128 MB)
[ 0.000000] crashkernel reserved: 0x000000017fe00000 -
0x000000027fe00000 (4096 MB)
>
>> + if (ret)
>> + goto out;
>> + }
>> +
>> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>>
>> out:
>> kfree(cmem);
>> --
>> 2.34.1
>>
>
>
^ permalink raw reply
* Re: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
From: Andrew Morton @ 2026-03-30 6:39 UTC (permalink / raw)
To: Greg KH
Cc: SeongJae Park, Liam R. Howlett, # 5 . 19 . x, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm, Roman Gushchin
In-Reply-To: <2026033013-drainage-stylized-43d6@gregkh>
On Mon, 30 Mar 2026 07:47:54 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
> > And anyway I'm supposed to share at least my review of AI reviews, in mm
> > community. If I ignore, I will only make Andrew have to reply asking that.
Actually no. I see you're using Sashiko extensively so great, you'll
hear nothing more on Sashiko-vs-DAMON from me!
^ permalink raw reply
* Re: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
From: Greg KH @ 2026-03-30 5:47 UTC (permalink / raw)
To: SeongJae Park
Cc: Andrew Morton, Liam R. Howlett, # 5 . 19 . x, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm, Roman Gushchin
In-Reply-To: <20260329193226.59025-1-sj@kernel.org>
On Sun, Mar 29, 2026 at 12:32:26PM -0700, SeongJae Park wrote:
> + Roman for a case he has any opinion about my sashiko usage.
>
> Hello Greg,
>
> On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > On Sun, Mar 29, 2026 at 08:49:16AM -0700, SeongJae Park wrote:
> > > Forwarding sashiko.dev review status for this thread.
> > >
> > > # review url: https://sashiko.dev/#/patchset/20260329153052.46657-1-sj@kernel.org
> >
> > Why are you doing this? If we want to see the review, can't we just go
> > and look at the tool itself?
>
> We can. But it is bit cumbersome to opening web browser and moving my focus to
> there. Reading everything on the mailing tool is easier for some people like
> me. Like some test bots send reports are replying to patches, or we sometimes
> forwarding bugzilla reports to mailing lists in a form of a plain text mail.
Sure, but are you going to now forward all random tool reviews that are
run on your subsystem to all of these lists (your distribution cc: is
quite large here)?
> Secondly, I have to share my opinions about the reviews, as many times AI
> reviews need human's opinions. There is no good way to do that on the web ui
> of the tool (sashiko) for now, and I think this mail based flow is the best.
That is assuming that you can fix up the AI reviews, is that happening
here?
> And anyway I'm supposed to share at least my review of AI reviews, in mm
> community. If I ignore, I will only make Andrew have to reply asking that.
>
> I used to share only my review of the AI reviews as replies, instead of
> forwarding AI reviews and then replies to those. But it was
> 1. cumbersome for me (should summarize AI review and then my review; feeling
> doing work twice), and
> 2. feeling not optimal at sharing all concerning comments with others. My
> summary might miss some points of AI review but other reviewers might just
> believe me and don't read the full review due to the additional web browser
> opening work. Also some other reivewers might kindly review AI reviews
> before I do, and save my (or their) time.
>
> Hence I ended up to do this bit odd workflow: Forwarding the full AI review on
> the mailing list first, then reply my responses.
>
> > sending it back to all of us feels odd,
>
> If this is polluting your inbox and/or distract you, I'm so sorry for that.
> Please let me know if this is distracting you. Maybe I can filtering people
> who don't want this kind of replies out of the recipients for the forwarding
> mails. Or, if you have a suggestion about what need to be changed, please let
> me know.
It just seemed odd, and might get crazy over time if this happens for
all random AI tools that happen to be popping up now, right? If this is
the "official" one for -mm, that's fine, but consider the distribution
and intended audience a bit please.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 3/3] docs: add left padding to C API signature rows
From: Rito Rhymes @ 2026-03-30 5:21 UTC (permalink / raw)
To: corbet, skhan; +Cc: linux-doc, linux-kernel, Rito Rhymes
In-Reply-To: <20260330052159.11284-1-rito@ritovision.com>
Add a small amount of left padding to rendered C API signature
rows.
This improves readability because the signature row and its
container use different background colors, and when the first
character sits too close to that contrasting edge it is harder to
read.
Signed-off-by: Rito Rhymes <rito@ritovision.com>
Assisted-by: Codex:GPT-5.4
---
Documentation/sphinx-static/custom.css | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index 64ea94879..41413b683 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -40,6 +40,7 @@ li { text-indent: 0em; }
dl.function, dl.struct, dl.enum { margin-top: 2em; background-color: #ecf0f3; }
/* indent lines 2+ of multi-line function prototypes */
dl.function dt { margin-left: 10em; text-indent: -10em; }
+dl.c > dt { padding-left: 10px; }
dt.sig-object { font-size: larger; }
div.kernelindent { margin-left: 2em; margin-right: 4em; }
--
2.51.0
^ permalink raw reply related
* [PATCH 2/3] docs: restore left padding in preformatted blocks
From: Rito Rhymes @ 2026-03-30 5:21 UTC (permalink / raw)
To: corbet, skhan; +Cc: linux-doc, linux-kernel, Rito Rhymes
In-Reply-To: <20260330052159.11284-1-rito@ritovision.com>
Restore a small amount of left padding to preformatted blocks.
This improves readability because the preformatted block and its
container use different background colors, and when the first
character sits too close to that contrasting edge it is harder to
read.
This only changes the rendered left padding around the block. It
does not change the code itself or what gets copied from it.
Signed-off-by: Rito Rhymes <rito@ritovision.com>
Assisted-by: Codex:GPT-5.4
---
Documentation/sphinx-static/custom.css | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index 6ba3e48bf..64ea94879 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -50,7 +50,8 @@ div.kernelindent { margin-left: 2em; margin-right: 4em; }
dl.py { margin-top: 2em; background-color: #ecf0f3; }
dl.py.class { margin-left: 2em; text-indent: -2em; padding-left: 2em; }
dl.py.method, dl.py.attribute { margin-left: 2em; text-indent: -2em; }
-dl.py li, pre { text-indent: 0em; padding-left: 0 !important; }
+dl.py li { text-indent: 0em; }
+pre { text-indent: 0em; padding-left: 10px !important; }
/*
* Tweaks for our local TOC
--
2.51.0
^ permalink raw reply related
* [PATCH 1/3] docs: add left padding to TOC lists
From: Rito Rhymes @ 2026-03-30 5:21 UTC (permalink / raw)
To: corbet, skhan; +Cc: linux-doc, linux-kernel, Rito Rhymes
In-Reply-To: <20260330052159.11284-1-rito@ritovision.com>
Add a small amount of left padding to the kernel TOC lists.
This improves readability because the TOC lists and their
container use different background colors, and when the first
character sits too close to that contrasting edge it is harder to
read.
Signed-off-by: Rito Rhymes <rito@ritovision.com>
Assisted-by: Codex:GPT-5.4
---
Documentation/sphinx-static/custom.css | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index db24f4344..6ba3e48bf 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -64,6 +64,7 @@ div.kerneltoc li.toctree-l2,li.toctree-l3 { font-size: small;
margin-left: 1em;
list-style-type: none;
}
+div.kerneltoc ul { padding-left: 10px; }
div.kerneltoc li.current ul { margin-left: 0; }
div.kerneltoc { background-color: #eeeeee; }
div.kerneltoc li.current ul { background-color: white; }
--
2.51.0
^ permalink raw reply related
* [PATCH 0/3] docs: improve readability with left padding adjustments
From: Rito Rhymes @ 2026-03-30 5:21 UTC (permalink / raw)
To: corbet, skhan; +Cc: linux-doc, linux-kernel, Rito Rhymes
These changes address a few different places where the first
character of rendered text sits too close to the left edge of a
contrasting container, which affects readability.
Add a small amount of left padding to those areas to create
clearer visual separation from the contrasting edge and improve
readability.
Demo site example (all changes visible here):
https://kernel-docs-pl.ritovision.com/userspace-api/liveupdate.html
Screenshots for this series are here:
https://github.com/ritovision/linux-kernel-docs/issues/5
For convenience, anyone is welcome to post additional screenshots
in that GitHub issue for hosting and reference them in discussion
of this series.
TOC lists - before:
https://github.com/user-attachments/assets/994ec5b6-c044-4f5a-bb58-fbf561481ffe
TOC lists - after:
https://github.com/user-attachments/assets/2bced41d-d0b6-44e8-ae28-3e4f721f47d5
Pre and signature - before:
https://github.com/user-attachments/assets/ec063580-9f5c-460d-afc6-3498917c863c
Pre and signature - after:
https://github.com/user-attachments/assets/b5f87275-e4cc-4687-8ca2-42fabb767c2d
Rito Rhymes (3):
docs: add left padding to TOC lists
docs: restore left padding in preformatted blocks
docs: add left padding to C API signature rows
Documentation/sphinx-static/custom.css | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
2.51.0
^ permalink raw reply
* Re: 答复: [外部邮件] Re: [PATCH] docs: kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
From: Randy Dunlap @ 2026-03-30 4:18 UTC (permalink / raw)
To: Li,Rongqing(ACG CCN), Jonathan Corbet, Shuah Khan, Andrew Morton,
Borislav Petkov, Peter Zijlstra, Feng Tang, Pawan Gupta,
Dapeng Mi, Kees Cook, Marco Elver, Paul E . McKenney, Askar Safin,
Bjorn Helgaas, Sohil Mehta, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <16386e7715284b22b5f72e7106ed5619@baidu.com>
On 3/29/26 8:08 PM, Li,Rongqing(ACG CCN) wrote:
>
>
>> -----邮件原件-----
>> 发件人: Randy Dunlap <rdunlap@infradead.org>
>> 发送时间: 2026年3月27日 0:08
>> 收件人: Li,Rongqing(ACG CCN) <lirongqing@baidu.com>; Jonathan Corbet
>> <corbet@lwn.net>; Shuah Khan <skhan@linuxfoundation.org>; Andrew Morton
>> <akpm@linux-foundation.org>; Borislav Petkov <bp@alien8.de>; Peter Zijlstra
>> <peterz@infradead.org>; Feng Tang <feng.tang@linux.alibaba.com>; Pawan
>> Gupta <pawan.kumar.gupta@linux.intel.com>; Dapeng Mi
>> <dapeng1.mi@linux.intel.com>; Kees Cook <kees@kernel.org>; Marco Elver
>> <elver@google.com>; Paul E . McKenney <paulmck@kernel.org>; Askar Safin
>> <safinaskar@gmail.com>; Bjorn Helgaas <bhelgaas@google.com>; Sohil Mehta
>> <sohil.mehta@intel.com>; linux-doc@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> 主题: [外部邮件] Re: [PATCH] docs: kernel-parameters: fix architecture
>> alignment for pt, nopt, and nobypass
>>
>> Hi,
>>
>> On 3/26/26 12:46 AM, lirongqing wrote:
>>> From: Li RongQing <lirongqing@baidu.com>
>>>
>>> Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options
>>> doc into kernel-parameters.txt") introduced a formatting regression
>>> where architecture tags were placed on separate lines with broken
>> indentation.
>>> This caused the 'nopt' [X86] parameter to appear as if it belonged to
>>> the [PPC/POWERNV] section.
>>>
>>> Fix the formatting by placing the architecture tags on the same line
>>> as their respective parameters ('pt', 'nopt', and 'nobypass') and
>>> restoring proper indentation.
>>>
>>> Fixes: ab0e7f20768a ("Documentation: Merge x86-specific boot options
>>> doc into kernel-parameters.txt")
>>> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>>> ---
>>> Documentation/admin-guide/kernel-parameters.txt | 9 +++------
>>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>> b/Documentation/admin-guide/kernel-parameters.txt
>>> index 03a5506..dc1c5bd 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -2615,12 +2615,9 @@ Kernel parameters
>>> Intel machines). This can be used to prevent the usage
>>> of an available hardware IOMMU.
>>>
>>> - [X86]
>>> - pt
>>> - [X86]
>>> - nopt
>>> - [PPC/POWERNV]
>>> - nobypass
>>> + pt [X86]
>>> + nopt [X86]
>>> + nobypass [PPC/POWERNV]
>>> Disable IOMMU bypass, using IOMMU for PCI devices.
>>>
>>> [X86]
>>
>> This looks good as far as it goes, but there are still some problems IMO.
>>
>> These are all iommu= options, but iommu says that it's for [X86,EARLY].
>> No PPC/POWERNV mentioned there.
>
> I think [PPC/POWERNV] should not be added to the main iommu= header. Since that header is already tagged as [X86, EARLY], adding PowerPC there would imply all subsequent options are cross-platform. Instead, it is cleaner to keep the main header as X86-specific and explicitly tag the individual nobypass option for [PPC/POWERNV]. This avoids the need to redundantly label every other X86-only option (like pt or nopt) within the section.
>
>>
>> Then immediately following nobypass, there is this:
>> [X86]
>> AMD Gart HW IOMMU-specific options:
>>
>> which is also in questionable format. The [X86] isn't needed at all IMO, or if it's
>> desirable, those 2 lines should be on one line.
>>
> You are right , [X86] isn't needed , How about to remove the [X86], like below
>
> Documentation/kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
>
> Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options doc
> into kernel-parameters.txt") introduced a formatting regression where
> architecture tags were placed on separate lines with broken indentation.
> This caused the 'nopt' [X86] parameter to appear as if it belonged to
> the [PPC/POWERNV] section.
>
> Furthermore, since the main 'iommu=' parameter heading already specifies
> it is for [X86, EARLY], the subsequent standalone [X86] tags for 'pt',
> 'nopt', and the AMD GART options are redundant and clutter the
> documentation.
>
> Clean up the formatting by removing these redundant tags and properly
> attributing the 'nobypass' option to [PPC/POWERNV].
>
> Fixes: ab0e7f20768a ("Documentation: Merge x86-specific boot options doc into kernel-parameters.txt")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 03a5506..5253c23 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2615,15 +2615,11 @@ Kernel parameters
> Intel machines). This can be used to prevent the usage
> of an available hardware IOMMU.
>
> - [X86]
> pt
> - [X86]
> nopt
> - [PPC/POWERNV]
> - nobypass
> + nobypass [PPC/POWERNV]
> Disable IOMMU bypass, using IOMMU for PCI devices.
>
> - [X86]
> AMD Gart HW IOMMU-specific options:
>
> <size>
> [Li,Rongqing]
>
Yes, LGTM. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* Re: [PATCH v11 01/11] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Guo Ren @ 2026-03-30 3:49 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, cfsworks, osandov,
jbohac, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, chenjiahao16, hbathini,
takahiro.akashi, james.morse, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <20260328074013.3589544-2-ruanjinjie@huawei.com>
On Sat, Mar 28, 2026 at 3:41 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
> and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
> crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
> riscv should have excluded the "crashk_low_res" reserved ranges from
> the crash kernel memory to prevent them from being exported through
> /proc/vmcore, and the exclusion would need an extra crash_mem range.
>
> Cc: Guo Ren <guoren@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 54e2d9552e93..3f7766057cac 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
> unsigned int nr_ranges;
> int ret;
>
> - nr_ranges = 1; /* For exclusion of crashkernel region */
> + nr_ranges = 2; /* For exclusion of crashkernel region */
> walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
>
> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> @@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>
> /* Exclude crashkernel region */
> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> - if (!ret)
> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> + if (ret)
> + goto out;
> +
> + if (crashk_low_res.end) {
> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
Exclude crashk_low_res is reasonable, but have you tested this?
> + if (ret)
> + goto out;
> + }
> +
> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>
> out:
> kfree(cmem);
> --
> 2.34.1
>
--
Best Regards
Guo Ren
^ permalink raw reply
* Re: [PATCH v11 05/11] riscv: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
From: Guo Ren @ 2026-03-30 3:47 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, cfsworks, osandov,
jbohac, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, chenjiahao16, hbathini,
takahiro.akashi, james.morse, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <20260328074013.3589544-6-ruanjinjie@huawei.com>
On Sat, Mar 28, 2026 at 3:41 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> There is a race condition between the kexec_load() system call
> (crash kernel loading path) and memory hotplug operations that can lead
> to buffer overflow and potential kernel crash.
riscv left no margin for hotplug in prepare_elf_headers(). Actually,
this check has been in crash_exclude_mem_range(); this patch makes it
happen earlier.
Although this patch has no real effect for riscv for the current. I
still give an acked-by, because it's a proper check step in this
callback.
Reviewed-by: Guo Ren <guoren@kernel.org>
--
Best Regards
Guo Ren
^ permalink raw reply
* Re: [PATCH v8 00/10] VMSCAPE optimization for BHI variant
From: Jon Kohler @ 2026-03-30 3:16 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86@kernel.org, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Asit Mallick, Tao Zhang, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260324-vmscape-bhb-v8-0-68bb524b3ab9@linux.intel.com>
> On Mar 24, 2026, at 2:16 PM, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
>
> v8:
> - Use helper in KVM to convey the mitigation status. (PeterZ/Borisov)
> - Fix the documentation for default vmscape mitigation. (BPF bot)
> - Remove the stray lines in bug.c (BPF bot).
> - Updated commit messages and comments.
> - Rebased to v7.0-rc5.
>
> v7: https://lore.kernel.org/r/20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com
> - s/This allows/Allow/ and s/This does adds/This adds/ in patch 1/10 commit
> message (Borislav).
> - Minimize register usage in BHB clearing seq. (David Laight)
> - Instead of separate ecx/eax counters, use al/ah.
> - Adjust the alignment of RET due to register size change.
> - save/restore rax in the seq itself.
> - Remove the save/restore of rax/rcx for BPF callers.
> - Rename clear_bhb_loop() to clear_bhb_loop_nofence() to make it
> obvious that the LFENCE is not part of the sequence (Borislav).
> - Fix Kconfig: s/select/depends on/ HAVE_STATIC_CALL (PeterZ).
> - Rebased to v7.0-rc4.
>
> v6: https://lore.kernel.org/r/20251201-vmscape-bhb-v6-0-d610dd515714@linux.intel.com
> - Remove semicolon at the end of asm in ALTERNATIVE (Uros).
> - Fix build warning in vmscape_select_mitigation() (LKP).
> - Rebased to v6.18.
>
> v5: https://lore.kernel.org/r/20251126-vmscape-bhb-v5-2-02d66e423b00@linux.intel.com
> - For BHI seq, limit runtime-patching to loop counts only (Dave).
> Dropped 2 patches that moved the BHB seq to a macro.
> - Remove redundant switch cases in vmscape_select_mitigation() (Nikolay).
> - Improve commit message (Nikolay).
> - Collected tags.
>
> v4: https://lore.kernel.org/r/20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com
> - Move LFENCE to the callsite, out of clear_bhb_loop(). (Dave)
> - Make clear_bhb_loop() work for larger BHB. (Dave)
> This now uses hardware enumeration to determine the BHB size to clear.
> - Use write_ibpb() instead of indirect_branch_prediction_barrier() when
> IBPB is known to be available. (Dave)
> - Use static_call() to simplify mitigation at exit-to-userspace. (Dave)
> - Refactor vmscape_select_mitigation(). (Dave)
> - Fix vmscape=on which was wrongly behaving as AUTO. (Dave)
> - Split the patches. (Dave)
> - Patch 1-4 prepares for making the sequence flexible for VMSCAPE use.
> - Patch 5 trivial rename of variable.
> - Patch 6-8 prepares for deploying BHB mitigation for VMSCAPE.
> - Patch 9 deploys the mitigation.
> - Patch 10-11 fixes ON Vs AUTO mode.
>
> v3: https://lore.kernel.org/r/20251027-vmscape-bhb-v3-0-5793c2534e93@linux.intel.com
> - s/x86_pred_flush_pending/x86_predictor_flush_exit_to_user/ (Sean).
> - Removed IBPB & BHB-clear mutual exclusion at exit-to-userspace.
> - Collected tags.
>
> v2: https://lore.kernel.org/r/20251015-vmscape-bhb-v2-0-91cbdd9c3a96@linux.intel.com
> - Added check for IBPB feature in vmscape_select_mitigation(). (David)
> - s/vmscape=auto/vmscape=on/ (David)
> - Added patch to remove LFENCE from VMSCAPE BHB-clear sequence.
> - Rebased to v6.18-rc1.
>
> v1: https://lore.kernel.org/r/20250924-vmscape-bhb-v1-0-da51f0e1934d@linux.intel.com
>
> Hi All,
>
> These patches aim to improve the performance of a recent mitigation for
> VMSCAPE[1] vulnerability. This improvement is relevant for BHI variant of
> VMSCAPE that affect Alder Lake and newer processors.
>
> The current mitigation approach uses IBPB on kvm-exit-to-userspace for all
> affected range of CPUs. This is an overkill for CPUs that are only affected
> by the BHI variant. On such CPUs clearing the branch history is sufficient
> for VMSCAPE, and also more apt as the underlying issue is due to poisoned
> branch history.
>
> Below is the iPerf data for transfer between guest and host, comparing IBPB
> and BHB-clear mitigation. BHB-clear shows performance improvement over IBPB
> in most cases.
>
> Platform: Emerald Rapids
> Baseline: vmscape=off
> Target: IBPB at VMexit-to-userspace Vs the new BHB-clear at
> VMexit-to-userspace mitigation (both compared against baseline).
>
> (pN = N parallel connections)
>
> | iPerf user-net | IBPB | BHB Clear |
> |----------------|---------|-----------|
> | UDP 1-vCPU_p1 | -12.5% | 1.3% |
> | TCP 1-vCPU_p1 | -10.4% | -1.5% |
> | TCP 1-vCPU_p1 | -7.5% | -3.0% |
> | UDP 4-vCPU_p16 | -3.7% | -3.7% |
> | TCP 4-vCPU_p4 | -2.9% | -1.4% |
> | UDP 4-vCPU_p4 | -0.6% | 0.0% |
> | TCP 4-vCPU_p4 | 3.5% | 0.0% |
>
> | iPerf bridge-net | IBPB | BHB Clear |
> |------------------|---------|-----------|
> | UDP 1-vCPU_p1 | -9.4% | -0.4% |
> | TCP 1-vCPU_p1 | -3.9% | -0.5% |
> | UDP 4-vCPU_p16 | -2.2% | -3.8% |
> | TCP 4-vCPU_p4 | -1.0% | -1.0% |
> | TCP 4-vCPU_p4 | 0.5% | 0.5% |
> | UDP 4-vCPU_p4 | 0.0% | 0.9% |
> | TCP 1-vCPU_p1 | 0.0% | 0.9% |
>
> | iPerf vhost-net | IBPB | BHB Clear |
> |-----------------|---------|-----------|
> | UDP 1-vCPU_p1 | -4.3% | 1.0% |
> | TCP 1-vCPU_p1 | -3.8% | -0.5% |
> | TCP 1-vCPU_p1 | -2.7% | -0.7% |
> | UDP 4-vCPU_p16 | -0.7% | -2.2% |
> | TCP 4-vCPU_p4 | -0.4% | 0.8% |
> | UDP 4-vCPU_p4 | 0.4% | -0.7% |
> | TCP 4-vCPU_p4 | 0.0% | 0.6% |
>
> [1] https://comsec.ethz.ch/research/microarch/vmscape-exposing-and-exploiting-incomplete-branch-predictor-isolation-in-cloud-environments/
> ---
> Pawan Gupta (10):
> x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
> x86/bhi: Make clear_bhb_loop() effective on newer CPUs
> x86/bhi: Rename clear_bhb_loop() to clear_bhb_loop_nofence()
> x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user
> x86/vmscape: Move mitigation selection to a switch()
> x86/vmscape: Use write_ibpb() instead of indirect_branch_prediction_barrier()
> x86/vmscape: Use static_call() for predictor flush
> x86/vmscape: Deploy BHB clearing mitigation
> x86/vmscape: Resolve conflict between attack-vectors and vmscape=force
> x86/vmscape: Add cmdline vmscape=on to override attack vector controls
>
> Documentation/admin-guide/hw-vuln/vmscape.rst | 15 ++++-
> Documentation/admin-guide/kernel-parameters.txt | 6 +-
> arch/x86/Kconfig | 1 +
> arch/x86/entry/entry_64.S | 34 +++++++----
> arch/x86/include/asm/cpufeatures.h | 2 +-
> arch/x86/include/asm/entry-common.h | 9 ++-
> arch/x86/include/asm/nospec-branch.h | 13 +++--
> arch/x86/include/asm/processor.h | 1 +
> arch/x86/kernel/cpu/bugs.c | 76 ++++++++++++++++++++-----
> arch/x86/kvm/x86.c | 4 +-
> arch/x86/net/bpf_jit_comp.c | 11 +---
> 11 files changed, 127 insertions(+), 45 deletions(-)
> ---
> base-commit: c369299895a591d96745d6492d4888259b004a9e
> change-id: 20250916-vmscape-bhb-d7d469977f2f
>
> Best regards,
> --
> Thanks,
> Pawan
Tested the v7 of this series with 6.18.y and one of our performance
suites, where we had previously bisected a significant regression to
the enablement of the VMSCAPE mitigation. This particular suite looks
at synthetic performance using KVM virtualized Windows guests.
Long story short, this suite tries to derive what end user experience
would be in these virtual machines while performing a standardized set
of synthetic tasks on real apps.
VMSCAPE hits especially hard when enabling Windows HVCI, which drives
a much higher VMExit count, all else equals.
Tested on an Intel Xeon 6444Y (SPR)
TLDR, we're really happy with the results. The following was with
Intel MBEC *enabled*, so even with that speedup (and drastic reduction
in VMExits), this optimization makes a significant difference.
- CPU‑ready time drops ~70 % across all steady‑state and log‑on metrics
with this series, indicating more efficient context switching even
though overall hypervisor CPU rises ~14 % (steady) to ~12 % (max).
Basically, we're getting more actual work done.
- Read/write IOPS increase by ~18–37 % and 14–20 % respectively, while
average IO latency remains largely unchanged or slightly lower in
steady metrics.
- Power consumption falls 5–11 % in every category
- Login times improve by 4–6 % on average.
- Application start‑up times are generally better (Word, Excel,
PowerPoint, Outlook), especially Outlook max time drops 67 %, a clear
win for end‑user experience.
Tested-By: Jon Kohler <jon@nutanix.com>
^ permalink raw reply
* 答复: [外部邮件] Re: [PATCH] docs: kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
From: Li,Rongqing(ACG CCN) @ 2026-03-30 3:08 UTC (permalink / raw)
To: Randy Dunlap, Jonathan Corbet, Shuah Khan, Andrew Morton,
Borislav Petkov, Peter Zijlstra, Feng Tang, Pawan Gupta,
Dapeng Mi, Kees Cook, Marco Elver, Paul E . McKenney, Askar Safin,
Bjorn Helgaas, Sohil Mehta, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b72c938d-1690-49f4-b617-916f24c3c53c@infradead.org>
> -----邮件原件-----
> 发件人: Randy Dunlap <rdunlap@infradead.org>
> 发送时间: 2026年3月27日 0:08
> 收件人: Li,Rongqing(ACG CCN) <lirongqing@baidu.com>; Jonathan Corbet
> <corbet@lwn.net>; Shuah Khan <skhan@linuxfoundation.org>; Andrew Morton
> <akpm@linux-foundation.org>; Borislav Petkov <bp@alien8.de>; Peter Zijlstra
> <peterz@infradead.org>; Feng Tang <feng.tang@linux.alibaba.com>; Pawan
> Gupta <pawan.kumar.gupta@linux.intel.com>; Dapeng Mi
> <dapeng1.mi@linux.intel.com>; Kees Cook <kees@kernel.org>; Marco Elver
> <elver@google.com>; Paul E . McKenney <paulmck@kernel.org>; Askar Safin
> <safinaskar@gmail.com>; Bjorn Helgaas <bhelgaas@google.com>; Sohil Mehta
> <sohil.mehta@intel.com>; linux-doc@vger.kernel.org;
> linux-kernel@vger.kernel.org
> 主题: [外部邮件] Re: [PATCH] docs: kernel-parameters: fix architecture
> alignment for pt, nopt, and nobypass
>
> Hi,
>
> On 3/26/26 12:46 AM, lirongqing wrote:
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options
> > doc into kernel-parameters.txt") introduced a formatting regression
> > where architecture tags were placed on separate lines with broken
> indentation.
> > This caused the 'nopt' [X86] parameter to appear as if it belonged to
> > the [PPC/POWERNV] section.
> >
> > Fix the formatting by placing the architecture tags on the same line
> > as their respective parameters ('pt', 'nopt', and 'nobypass') and
> > restoring proper indentation.
> >
> > Fixes: ab0e7f20768a ("Documentation: Merge x86-specific boot options
> > doc into kernel-parameters.txt")
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 9 +++------
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 03a5506..dc1c5bd 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2615,12 +2615,9 @@ Kernel parameters
> > Intel machines). This can be used to prevent the usage
> > of an available hardware IOMMU.
> >
> > - [X86]
> > - pt
> > - [X86]
> > - nopt
> > - [PPC/POWERNV]
> > - nobypass
> > + pt [X86]
> > + nopt [X86]
> > + nobypass [PPC/POWERNV]
> > Disable IOMMU bypass, using IOMMU for PCI devices.
> >
> > [X86]
>
> This looks good as far as it goes, but there are still some problems IMO.
>
> These are all iommu= options, but iommu says that it's for [X86,EARLY].
> No PPC/POWERNV mentioned there.
I think [PPC/POWERNV] should not be added to the main iommu= header. Since that header is already tagged as [X86, EARLY], adding PowerPC there would imply all subsequent options are cross-platform. Instead, it is cleaner to keep the main header as X86-specific and explicitly tag the individual nobypass option for [PPC/POWERNV]. This avoids the need to redundantly label every other X86-only option (like pt or nopt) within the section.
>
> Then immediately following nobypass, there is this:
> [X86]
> AMD Gart HW IOMMU-specific options:
>
> which is also in questionable format. The [X86] isn't needed at all IMO, or if it's
> desirable, those 2 lines should be on one line.
>
You are right , [X86] isn't needed , How about to remove the [X86], like below
Documentation/kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options doc
into kernel-parameters.txt") introduced a formatting regression where
architecture tags were placed on separate lines with broken indentation.
This caused the 'nopt' [X86] parameter to appear as if it belonged to
the [PPC/POWERNV] section.
Furthermore, since the main 'iommu=' parameter heading already specifies
it is for [X86, EARLY], the subsequent standalone [X86] tags for 'pt',
'nopt', and the AMD GART options are redundant and clutter the
documentation.
Clean up the formatting by removing these redundant tags and properly
attributing the 'nobypass' option to [PPC/POWERNV].
Fixes: ab0e7f20768a ("Documentation: Merge x86-specific boot options doc into kernel-parameters.txt")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a5506..5253c23 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2615,15 +2615,11 @@ Kernel parameters
Intel machines). This can be used to prevent the usage
of an available hardware IOMMU.
- [X86]
pt
- [X86]
nopt
- [PPC/POWERNV]
- nobypass
+ nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
- [X86]
AMD Gart HW IOMMU-specific options:
<size>
[Li,Rongqing]
> Anyway, for this patch:
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks.
>
> --
> ~Randy
^ permalink raw reply related
* [PATCH net-next v3 3/3] selftests: net: add bridge STP mode selection test
From: Andy Roulin @ 2026-03-30 2:21 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
Donald Hunter, Jonas Gorski, linux-doc, linux-kselftest,
linux-kernel, Andy Roulin
In-Reply-To: <20260330022107.670566-1-aroulin@nvidia.com>
Add a selftest for the IFLA_BR_STP_MODE bridge attribute that verifies:
1. stp_mode defaults to auto on new bridges
2. stp_mode can be toggled between user, kernel, and auto
3. Changing stp_mode while STP is active is rejected with -EBUSY
4. Re-setting the same stp_mode while STP is active succeeds
5. stp_mode user in a network namespace yields userspace STP (stp_state=2)
6. stp_mode kernel forces kernel STP (stp_state=1)
7. stp_mode auto in a netns preserves traditional fallback to kernel STP
8. stp_mode and stp_state can be set atomically in a single message
9. stp_mode persists across STP disable/enable cycles
Test 5 is the key use case: it demonstrates that userspace STP can now
be enabled in non-init network namespaces by setting stp_mode to user
before enabling STP.
Test 8 verifies the atomic usage pattern where both attributes are set
in a single netlink message, which is supported because br_changelink()
processes IFLA_BR_STP_MODE before IFLA_BR_STP_STATE.
The test gracefully skips if the installed iproute2 does not support
the stp_mode attribute.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
---
Notes:
v2:
* Fix shellcheck CI: add SC2329 suppression.
* Add idempotent stp_mode test.
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/bridge_stp_mode.sh | 281 ++++++++++++++++++
2 files changed, 282 insertions(+)
create mode 100755 tools/testing/selftests/net/bridge_stp_mode.sh
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 6bced3ed798b0..053c7b83c76dd 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -15,6 +15,7 @@ TEST_PROGS := \
big_tcp.sh \
bind_bhash.sh \
bpf_offload.py \
+ bridge_stp_mode.sh \
bridge_vlan_dump.sh \
broadcast_ether_dst.sh \
broadcast_pmtu.sh \
diff --git a/tools/testing/selftests/net/bridge_stp_mode.sh b/tools/testing/selftests/net/bridge_stp_mode.sh
new file mode 100755
index 0000000000000..5737a10f002f0
--- /dev/null
+++ b/tools/testing/selftests/net/bridge_stp_mode.sh
@@ -0,0 +1,281 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# shellcheck disable=SC2034,SC2154,SC2317,SC2329
+#
+# Test for bridge STP mode selection (IFLA_BR_STP_MODE).
+#
+# Verifies that:
+# - stp_mode defaults to auto on new bridges
+# - stp_mode can be toggled between user, kernel, and auto
+# - stp_mode change is rejected while STP is active (-EBUSY)
+# - stp_mode user in a netns yields userspace STP (stp_state=2)
+# - stp_mode kernel forces kernel STP (stp_state=1)
+# - stp_mode auto preserves traditional fallback to kernel STP
+# - stp_mode and stp_state can be set atomically in one message
+# - stp_mode persists across STP disable/enable cycles
+
+source lib.sh
+
+require_command jq
+
+ALL_TESTS="
+ test_default_auto
+ test_set_modes
+ test_reject_change_while_stp_active
+ test_idempotent_mode_while_stp_active
+ test_user_mode_in_netns
+ test_kernel_mode
+ test_auto_mode
+ test_atomic_mode_and_state
+ test_mode_persistence
+"
+
+bridge_info_get()
+{
+ ip -n "$NS1" -d -j link show "$1" | \
+ jq -r ".[0].linkinfo.info_data.$2"
+}
+
+check_stp_mode()
+{
+ local br=$1; shift
+ local expected=$1; shift
+ local msg=$1; shift
+ local val
+
+ val=$(bridge_info_get "$br" stp_mode)
+ [ "$val" = "$expected" ]
+ check_err $? "$msg: expected $expected, got $val"
+}
+
+check_stp_state()
+{
+ local br=$1; shift
+ local expected=$1; shift
+ local msg=$1; shift
+ local val
+
+ val=$(bridge_info_get "$br" stp_state)
+ [ "$val" = "$expected" ]
+ check_err $? "$msg: expected $expected, got $val"
+}
+
+# Create a bridge in NS1, bring it up, and defer its deletion.
+bridge_create()
+{
+ ip -n "$NS1" link add "$1" type bridge
+ ip -n "$NS1" link set "$1" up
+ defer ip -n "$NS1" link del "$1"
+}
+
+setup_prepare()
+{
+ setup_ns NS1
+}
+
+cleanup()
+{
+ defer_scopes_cleanup
+ cleanup_all_ns
+}
+
+# Check that stp_mode defaults to auto when creating a bridge.
+test_default_auto()
+{
+ RET=0
+
+ ip -n "$NS1" link add br-test type bridge
+ defer ip -n "$NS1" link del br-test
+
+ check_stp_mode br-test auto "stp_mode default"
+
+ log_test "stp_mode defaults to auto"
+}
+
+# Test setting stp_mode to user, kernel, and back to auto.
+test_set_modes()
+{
+ RET=0
+
+ ip -n "$NS1" link add br-test type bridge
+ defer ip -n "$NS1" link del br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ check_err $? "Failed to set stp_mode to user"
+ check_stp_mode br-test user "after set user"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode kernel
+ check_err $? "Failed to set stp_mode to kernel"
+ check_stp_mode br-test kernel "after set kernel"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode auto
+ check_err $? "Failed to set stp_mode to auto"
+ check_stp_mode br-test auto "after set auto"
+
+ log_test "stp_mode set user/kernel/auto"
+}
+
+# Verify that stp_mode cannot be changed while STP is active.
+test_reject_change_while_stp_active()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode kernel
+ check_err $? "Failed to set stp_mode to kernel"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ # Changing stp_mode while STP is active should fail.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode auto 2>/dev/null
+ check_fail $? "Changing stp_mode should fail while STP is active"
+
+ check_stp_mode br-test kernel "mode unchanged after rejected change"
+
+ # Disable STP, then change should succeed.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 0
+ check_err $? "Failed to disable STP"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode auto
+ check_err $? "Changing stp_mode should succeed after STP is disabled"
+
+ log_test "reject stp_mode change while STP is active"
+}
+
+# Verify that re-setting the same stp_mode while STP is active succeeds.
+test_idempotent_mode_while_stp_active()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user stp_state 1
+ check_err $? "Failed to enable STP with user mode"
+
+ # Re-setting the same mode while STP is active should succeed.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ check_err $? "Idempotent stp_mode set should succeed while STP is active"
+
+ check_stp_state br-test 2 "stp_state after idempotent set"
+
+ log_test "idempotent stp_mode set while STP is active"
+}
+
+# Test that stp_mode user in a non-init netns yields userspace STP
+# (stp_state == 2). This is the key use case: userspace STP without
+# needing /sbin/bridge-stp or being in init_net.
+test_user_mode_in_netns()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ check_err $? "Failed to set stp_mode to user"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ check_stp_state br-test 2 "stp_state with user mode"
+
+ log_test "stp_mode user in netns yields userspace STP"
+}
+
+# Test that stp_mode kernel forces kernel STP (stp_state == 1)
+# regardless of whether /sbin/bridge-stp exists.
+test_kernel_mode()
+{
+ RET=0
+
+ bridge_create br-test
+
+ ip -n "$NS1" link set dev br-test type bridge stp_mode kernel
+ check_err $? "Failed to set stp_mode to kernel"
+
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ check_stp_state br-test 1 "stp_state with kernel mode"
+
+ log_test "stp_mode kernel forces kernel STP"
+}
+
+# Test that stp_mode auto preserves traditional behavior: in a netns
+# (non-init_net), bridge-stp is not called and STP falls back to
+# kernel mode (stp_state == 1).
+test_auto_mode()
+{
+ RET=0
+
+ bridge_create br-test
+
+ # Auto mode is the default; enable STP in a netns.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP"
+
+ # In a netns with auto mode, bridge-stp is skipped (init_net only),
+ # so STP should fall back to kernel mode (stp_state == 1).
+ check_stp_state br-test 1 "stp_state with auto mode in netns"
+
+ log_test "stp_mode auto preserves traditional behavior"
+}
+
+# Test that stp_mode and stp_state can be set in a single netlink
+# message. This is the intended atomic usage pattern.
+test_atomic_mode_and_state()
+{
+ RET=0
+
+ bridge_create br-test
+
+ # Set both stp_mode and stp_state in one command.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user stp_state 1
+ check_err $? "Failed to set stp_mode user and stp_state 1 atomically"
+
+ check_stp_state br-test 2 "stp_state after atomic set"
+
+ log_test "atomic stp_mode user + stp_state 1 in single message"
+}
+
+# Test that stp_mode persists across STP disable/enable cycles.
+test_mode_persistence()
+{
+ RET=0
+
+ bridge_create br-test
+
+ # Set user mode and enable STP.
+ ip -n "$NS1" link set dev br-test type bridge stp_mode user
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to enable STP with user mode"
+
+ # Disable STP.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 0
+ check_err $? "Failed to disable STP"
+
+ # Verify mode is still user.
+ check_stp_mode br-test user "stp_mode after STP disable"
+
+ # Re-enable STP -- should use user mode again.
+ ip -n "$NS1" link set dev br-test type bridge stp_state 1
+ check_err $? "Failed to re-enable STP"
+
+ check_stp_state br-test 2 "stp_state after re-enable"
+
+ log_test "stp_mode persists across STP disable/enable cycles"
+}
+
+# Check iproute2 support before setting up resources.
+if ! ip link add type bridge help 2>&1 | grep -q "stp_mode"; then
+ echo "SKIP: iproute2 too old, missing stp_mode support"
+ exit "$ksft_skip"
+fi
+
+trap cleanup EXIT
+
+setup_prepare
+tests_run
+
+exit "$EXIT_STATUS"
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 2/3] docs: net: bridge: document stp_mode attribute
From: Andy Roulin @ 2026-03-30 2:21 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
Donald Hunter, Jonas Gorski, linux-doc, linux-kselftest,
linux-kernel, Andy Roulin
In-Reply-To: <20260330022107.670566-1-aroulin@nvidia.com>
Add documentation for the IFLA_BR_STP_MODE bridge attribute in the
"User space STP helper" section of the bridge documentation. Reference
the BR_STP_MODE_* values via kernel-doc and describe the use case for
network namespace environments.
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
---
Documentation/networking/bridge.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/networking/bridge.rst b/Documentation/networking/bridge.rst
index ef8b73e157b26..c1e6ea52c9e59 100644
--- a/Documentation/networking/bridge.rst
+++ b/Documentation/networking/bridge.rst
@@ -148,6 +148,28 @@ called by the kernel when STP is enabled/disabled on a bridge
stp_state <0|1>``). The kernel enables user_stp mode if that command returns
0, or enables kernel_stp mode if that command returns any other value.
+STP mode selection
+------------------
+
+The ``IFLA_BR_STP_MODE`` bridge attribute allows explicit control over how
+STP operates when enabled, bypassing the ``/sbin/bridge-stp`` helper
+entirely for the ``user`` and ``kernel`` modes.
+
+.. kernel-doc:: include/uapi/linux/if_link.h
+ :doc: Bridge STP mode values
+
+The default mode is ``BR_STP_MODE_AUTO``, which preserves the traditional
+behavior of invoking the ``/sbin/bridge-stp`` helper. The ``user`` and
+``kernel`` modes are particularly useful in network namespace environments
+where the helper mechanism is not available, as ``call_usermodehelper()``
+is restricted to the initial network namespace.
+
+Example::
+
+ ip link set dev br0 type bridge stp_mode user stp_state 1
+
+The mode can only be changed while STP is disabled.
+
VLAN
====
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 1/3] net: bridge: add stp_mode attribute for STP mode selection
From: Andy Roulin @ 2026-03-30 2:21 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
Donald Hunter, Jonas Gorski, linux-doc, linux-kselftest,
linux-kernel, Andy Roulin
In-Reply-To: <20260330022107.670566-1-aroulin@nvidia.com>
The bridge-stp usermode helper is currently restricted to the initial
network namespace, preventing userspace STP daemons (e.g. mstpd) from
operating on bridges in other network namespaces. Since commit
ff62198553e4 ("bridge: Only call /sbin/bridge-stp for the initial
network namespace"), bridges in non-init namespaces silently fall
back to kernel STP with no way to use userspace STP.
Add a new bridge attribute IFLA_BR_STP_MODE that allows explicit
per-bridge control over STP mode selection:
BR_STP_MODE_AUTO (default) - Existing behavior: invoke the
/sbin/bridge-stp helper in init_net only; fall back to kernel STP
if it fails or in non-init namespaces.
BR_STP_MODE_USER - Directly enable userspace STP (BR_USER_STP)
without invoking the helper. Works in any network namespace.
Userspace is responsible for ensuring an STP daemon manages the
bridge.
BR_STP_MODE_KERNEL - Directly enable kernel STP (BR_KERNEL_STP)
without invoking the helper.
The mode can only be changed while STP is disabled, or set to the
same value (-EBUSY otherwise). IFLA_BR_STP_MODE is processed before
IFLA_BR_STP_STATE in br_changelink(), so both can be set atomically
in a single netlink message.
This eliminates the need for call_usermodehelper() in user/kernel
modes, addressing the security concerns discussed in the thread at
https://lore.kernel.org/netdev/565B7F7D.80208@nod.at/ and providing
a cleaner alternative to extending the helper into namespaces.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
---
Notes:
v2:
* Add rt-link.yaml netlink spec update.
* Allow idempotent stp_mode set while STP is active.
* Move stp_mode next to root_port to fill a struct hole.
* Rephrase BR_STP_MODE_USER doc.
v3:
* Name enum br_stp_mode for YNL codegen.
* Add enum-name to rt-link.yaml spec.
Documentation/netlink/specs/rt-link.yaml | 12 ++++++++
include/uapi/linux/if_link.h | 39 ++++++++++++++++++++++++
net/bridge/br_device.c | 1 +
net/bridge/br_netlink.c | 18 ++++++++++-
net/bridge/br_private.h | 1 +
net/bridge/br_stp_if.c | 17 ++++++-----
6 files changed, 80 insertions(+), 8 deletions(-)
diff --git a/Documentation/netlink/specs/rt-link.yaml b/Documentation/netlink/specs/rt-link.yaml
index df4b56beb8187..495836a569e8f 100644
--- a/Documentation/netlink/specs/rt-link.yaml
+++ b/Documentation/netlink/specs/rt-link.yaml
@@ -833,6 +833,14 @@ definitions:
entries:
- p2p
- mp
+ -
+ name: br-stp-mode
+ type: enum
+ enum-name: br-stp-mode
+ entries:
+ - auto
+ - user
+ - kernel
attribute-sets:
-
@@ -1543,6 +1551,10 @@ attribute-sets:
-
name: fdb-max-learned
type: u32
+ -
+ name: stp-mode
+ type: u32
+ enum: br-stp-mode
-
name: linkinfo-brport-attrs
name-prefix: ifla-brport-
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 83a96c56b8cad..f159be39a6e78 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -744,6 +744,11 @@ enum in6_addr_gen_mode {
* @IFLA_BR_FDB_MAX_LEARNED
* Set the number of max dynamically learned FDB entries for the current
* bridge.
+ *
+ * @IFLA_BR_STP_MODE
+ * Set the STP mode for the bridge, which controls how the bridge
+ * selects between userspace and kernel STP. The valid values are
+ * documented below in the ``BR_STP_MODE_*`` constants.
*/
enum {
IFLA_BR_UNSPEC,
@@ -796,11 +801,45 @@ enum {
IFLA_BR_MCAST_QUERIER_STATE,
IFLA_BR_FDB_N_LEARNED,
IFLA_BR_FDB_MAX_LEARNED,
+ IFLA_BR_STP_MODE,
__IFLA_BR_MAX,
};
#define IFLA_BR_MAX (__IFLA_BR_MAX - 1)
+/**
+ * DOC: Bridge STP mode values
+ *
+ * @BR_STP_MODE_AUTO
+ * Default. The kernel invokes the ``/sbin/bridge-stp`` helper to hand
+ * the bridge to a userspace STP daemon (e.g. mstpd). Only attempted in
+ * the initial network namespace; in other namespaces this falls back to
+ * kernel STP.
+ *
+ * @BR_STP_MODE_USER
+ * Directly enable userspace STP (``BR_USER_STP``) without invoking the
+ * ``/sbin/bridge-stp`` helper. Works in any network namespace.
+ * Userspace is responsible for ensuring an STP daemon manages the
+ * bridge.
+ *
+ * @BR_STP_MODE_KERNEL
+ * Directly enable kernel STP (``BR_KERNEL_STP``) without invoking the
+ * helper.
+ *
+ * The mode controls how the bridge selects between userspace and kernel
+ * STP when STP is enabled via ``IFLA_BR_STP_STATE``. It can only be
+ * changed while STP is disabled (``IFLA_BR_STP_STATE`` == 0), returns
+ * ``-EBUSY`` otherwise. The default value is ``BR_STP_MODE_AUTO``.
+ */
+enum br_stp_mode {
+ BR_STP_MODE_AUTO,
+ BR_STP_MODE_USER,
+ BR_STP_MODE_KERNEL,
+ __BR_STP_MODE_MAX
+};
+
+#define BR_STP_MODE_MAX (__BR_STP_MODE_MAX - 1)
+
struct ifla_bridge_id {
__u8 prio[2];
__u8 addr[6]; /* ETH_ALEN */
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index f7502e62dd357..a35ceae0a6f2c 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -518,6 +518,7 @@ void br_dev_setup(struct net_device *dev)
ether_addr_copy(br->group_addr, eth_stp_addr);
br->stp_enabled = BR_NO_STP;
+ br->stp_mode = BR_STP_MODE_AUTO;
br->group_fwd_mask = BR_GROUPFWD_DEFAULT;
br->group_fwd_mask_required = BR_GROUPFWD_DEFAULT;
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 0264730938f4b..f5b462a040b92 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1270,6 +1270,9 @@ static const struct nla_policy br_policy[IFLA_BR_MAX + 1] = {
NLA_POLICY_EXACT_LEN(sizeof(struct br_boolopt_multi)),
[IFLA_BR_FDB_N_LEARNED] = { .type = NLA_REJECT },
[IFLA_BR_FDB_MAX_LEARNED] = { .type = NLA_U32 },
+ [IFLA_BR_STP_MODE] = NLA_POLICY_RANGE(NLA_U32,
+ BR_STP_MODE_AUTO,
+ BR_STP_MODE_MAX),
};
static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
@@ -1306,6 +1309,17 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
return err;
}
+ if (data[IFLA_BR_STP_MODE]) {
+ u32 mode = nla_get_u32(data[IFLA_BR_STP_MODE]);
+
+ if (br->stp_enabled != BR_NO_STP && mode != br->stp_mode) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Can't change STP mode while STP is enabled");
+ return -EBUSY;
+ }
+ br->stp_mode = mode;
+ }
+
if (data[IFLA_BR_STP_STATE]) {
u32 stp_enabled = nla_get_u32(data[IFLA_BR_STP_STATE]);
@@ -1634,6 +1648,7 @@ static size_t br_get_size(const struct net_device *brdev)
nla_total_size(sizeof(u8)) + /* IFLA_BR_NF_CALL_ARPTABLES */
#endif
nla_total_size(sizeof(struct br_boolopt_multi)) + /* IFLA_BR_MULTI_BOOLOPT */
+ nla_total_size(sizeof(u32)) + /* IFLA_BR_STP_MODE */
0;
}
@@ -1686,7 +1701,8 @@ static int br_fill_info(struct sk_buff *skb, const struct net_device *brdev)
nla_put(skb, IFLA_BR_MULTI_BOOLOPT, sizeof(bm), &bm) ||
nla_put_u32(skb, IFLA_BR_FDB_N_LEARNED,
atomic_read(&br->fdb_n_learned)) ||
- nla_put_u32(skb, IFLA_BR_FDB_MAX_LEARNED, br->fdb_max_learned))
+ nla_put_u32(skb, IFLA_BR_FDB_MAX_LEARNED, br->fdb_max_learned) ||
+ nla_put_u32(skb, IFLA_BR_STP_MODE, br->stp_mode))
return -EMSGSIZE;
#ifdef CONFIG_BRIDGE_VLAN_FILTERING
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 6dbca845e625d..03e9f20181175 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -523,6 +523,7 @@ struct net_bridge {
unsigned char topology_change;
unsigned char topology_change_detected;
u16 root_port;
+ u32 stp_mode;
unsigned long max_age;
unsigned long hello_time;
unsigned long forward_delay;
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index cc4b27ff1b088..fa2271c5d84fe 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -149,7 +149,9 @@ static void br_stp_start(struct net_bridge *br)
{
int err = -ENOENT;
- if (net_eq(dev_net(br->dev), &init_net))
+ /* AUTO mode: try bridge-stp helper in init_net only */
+ if (br->stp_mode == BR_STP_MODE_AUTO &&
+ net_eq(dev_net(br->dev), &init_net))
err = br_stp_call_user(br, "start");
if (err && err != -ENOENT)
@@ -162,7 +164,7 @@ static void br_stp_start(struct net_bridge *br)
else if (br->bridge_forward_delay > BR_MAX_FORWARD_DELAY)
__br_set_forward_delay(br, BR_MAX_FORWARD_DELAY);
- if (!err) {
+ if (br->stp_mode == BR_STP_MODE_USER || !err) {
br->stp_enabled = BR_USER_STP;
br_debug(br, "userspace STP started\n");
} else {
@@ -180,12 +182,13 @@ static void br_stp_start(struct net_bridge *br)
static void br_stp_stop(struct net_bridge *br)
{
- int err;
-
if (br->stp_enabled == BR_USER_STP) {
- err = br_stp_call_user(br, "stop");
- if (err)
- br_err(br, "failed to stop userspace STP (%d)\n", err);
+ if (br->stp_mode == BR_STP_MODE_AUTO) {
+ int err = br_stp_call_user(br, "stop");
+
+ if (err)
+ br_err(br, "failed to stop userspace STP (%d)\n", err);
+ }
/* To start timers on any ports left in blocking */
spin_lock_bh(&br->lock);
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 0/3] net: bridge: add stp_mode attribute for STP mode selection
From: Andy Roulin @ 2026-03-30 2:21 UTC (permalink / raw)
To: netdev
Cc: bridge, Nikolay Aleksandrov, Ido Schimmel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Petr Machata,
Donald Hunter, Jonas Gorski, linux-doc, linux-kselftest,
linux-kernel, Andy Roulin
The bridge-stp usermode helper is currently restricted to the initial
network namespace, preventing userspace STP daemons like mstpd from
operating on bridges in other namespaces. Since commit ff62198553e4
("bridge: Only call /sbin/bridge-stp for the initial network
namespace"), bridges in non-init namespaces silently fall back to
kernel STP with no way to request userspace STP.
This series adds a new IFLA_BR_STP_MODE bridge attribute that allows
explicit per-bridge control over STP mode selection. Three modes are
supported:
- auto (default): existing behavior, try /sbin/bridge-stp in
init_net, fall back to kernel STP otherwise
- user: directly enable BR_USER_STP without invoking the helper,
works in any network namespace
- kernel: directly enable BR_KERNEL_STP without invoking the helper
The user and kernel modes bypass call_usermodehelper() entirely,
addressing the security concerns discussed at [1]. Userspace is
responsible for ensuring an STP daemon manages the bridge, rather
than relying on the kernel to invoke /sbin/bridge-stp.
Patch 1 adds the kernel support. The mode can only be changed while
STP is disabled and is processed before IFLA_BR_STP_STATE in
br_changelink() so both can be set atomically in a single netlink
message.
Patch 2 adds documentation for the new attribute in the bridge docs.
Patch 3 adds a selftest with 9 test cases. The test requires iproute2
with IFLA_BR_STP_MODE support and can be run with virtme-ng:
vng --run arch/x86/boot/bzImage --skip-modules \
--overlay-rwdir /sbin --overlay-rwdir /tmp --overlay-rwdir /bin \
--exec 'cp /path/to/iproute2-next/ip/ip /bin/ip && \
cd tools/testing/selftests/net && \
bash bridge_stp_mode.sh'
iproute2 support can be found here [2].
[1] https://lore.kernel.org/netdev/565B7F7D.80208@nod.at/
[2] https://github.com/aroulin/iproute2-next/tree/bridge-stp-mode
v3:
Patch #1:
* Name enum br_stp_mode for YNL codegen.
* Add enum-name to rt-link.yaml spec.
v2:
Patch #1:
* Add rt-link.yaml netlink spec update.
* Allow idempotent stp_mode set while STP is active.
* Move stp_mode next to root_port to fill a struct
hole.
* Rephrase BR_STP_MODE_USER doc.
Patch #3:
* Fix shellcheck CI: add SC2329 suppression.
* Add idempotent stp_mode test.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
Andy Roulin (3):
net: bridge: add stp_mode attribute for STP mode selection
docs: net: bridge: document stp_mode attribute
selftests: net: add bridge STP mode selection test
Documentation/netlink/specs/rt-link.yaml | 12 +
Documentation/networking/bridge.rst | 22 ++
include/uapi/linux/if_link.h | 39 +++
net/bridge/br_device.c | 1 +
net/bridge/br_netlink.c | 18 +-
net/bridge/br_private.h | 1 +
net/bridge/br_stp_if.c | 17 +-
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/bridge_stp_mode.sh | 281 ++++++++++++++++++
9 files changed, 384 insertions(+), 8 deletions(-)
create mode 100755 tools/testing/selftests/net/bridge_stp_mode.sh
--
2.43.0
^ permalink raw reply
* [PATCH net-next v02 6/6] hinic3: Remove unneed coalesce parameters
From: Fan Gong @ 2026-03-30 1:03 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <cover.1774684571.git.zhuyikai1@h-partners.com>
Remove unneed coalesce parameters in irq handling.
Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com>
Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com>
Signed-off-by: Fan Gong <gongfan1@huawei.com>
---
drivers/net/ethernet/huawei/hinic3/hinic3_irq.c | 6 +-----
drivers/net/ethernet/huawei/hinic3/hinic3_rx.h | 3 ---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c b/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
index d3b3927b5408..42464c007174 100644
--- a/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
+++ b/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
@@ -156,13 +156,9 @@ static int hinic3_set_interrupt_moder(struct net_device *netdev, u16 q_id,
spin_unlock_irqrestore(&nic_dev->channel_res_lock, flags);
err = hinic3_set_interrupt_cfg(nic_dev->hwdev, info);
- if (err) {
+ if (err)
netdev_err(netdev,
"Failed to modify moderation for Queue: %u\n", q_id);
- } else {
- nic_dev->rxqs[q_id].last_coalesc_timer_cfg = coalesc_timer_cfg;
- nic_dev->rxqs[q_id].last_pending_limit = pending_limit;
- }
return err;
}
diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_rx.h b/drivers/net/ethernet/huawei/hinic3/hinic3_rx.h
index cd2dcaab6cf7..a64a51d766c5 100644
--- a/drivers/net/ethernet/huawei/hinic3/hinic3_rx.h
+++ b/drivers/net/ethernet/huawei/hinic3/hinic3_rx.h
@@ -112,9 +112,6 @@ struct hinic3_rxq {
dma_addr_t cqe_start_paddr;
struct dim dim;
-
- u8 last_coalesc_timer_cfg;
- u8 last_pending_limit;
} ____cacheline_aligned;
struct hinic3_dyna_rxq_res {
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v02 5/6] hinic3: Configure netdev->watchdog_timeo to set nic tx timeout
From: Fan Gong @ 2026-03-30 1:03 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <cover.1774684571.git.zhuyikai1@h-partners.com>
Configure netdev watchdog timeout to improve transmission reliability.
Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com>
Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com>
Signed-off-by: Fan Gong <gongfan1@huawei.com>
---
drivers/net/ethernet/huawei/hinic3/hinic3_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_main.c b/drivers/net/ethernet/huawei/hinic3/hinic3_main.c
index 60834f8dffcd..4742c881b7a6 100644
--- a/drivers/net/ethernet/huawei/hinic3/hinic3_main.c
+++ b/drivers/net/ethernet/huawei/hinic3/hinic3_main.c
@@ -33,6 +33,8 @@
#define HINIC3_RX_PENDING_LIMIT_LOW 2
#define HINIC3_RX_PENDING_LIMIT_HIGH 8
+#define HINIC3_WATCHDOG_TIMEOUT 5
+
static void init_intr_coal_param(struct net_device *netdev)
{
struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
@@ -247,6 +249,8 @@ static void hinic3_assign_netdev_ops(struct net_device *netdev)
{
hinic3_set_netdev_ops(netdev);
hinic3_set_ethtool_ops(netdev);
+
+ netdev->watchdog_timeo = HINIC3_WATCHDOG_TIMEOUT * HZ;
}
static void netdev_feature_init(struct net_device *netdev)
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox