* Re: [v2 1/2] soc: fsl: dpio: Use scope-based resource management in dpaa2_io_store_create()
From: Markus Elfring @ 2026-07-28 6:55 UTC (permalink / raw)
To: Ioana Ciornei, linux-arm-kernel, linuxppc-dev
Cc: Christophe Leroy, Dan Carpenter, James Bottomley, Peter Zijlstra,
Roy Pledge, Steven Rostedt, LKML, kernel-janitors
In-Reply-To: <55dkpjlibtfurmrrzxzznq6e3dhxvo76rsrjnokkaquwktl74r@omft73n4kp52>
>> https://elixir.bootlin.com/linux/v7.2-rc4/source/include/linux/cleanup.h#L142-L146
>
> The context for the recommendation linked by you is (also from
> cleanup.h):
>
> * "When multiple variables in the same scope have cleanup attributes,
> * at exit from the scope their associated cleanup functions are run in
> * reverse order of definition (last defined, first cleanup)."
> *
> * When the unwind order matters it requires that variables be defined
> * mid-function scope rather than at the top of the file. Take the
> * following example and notice the bug highlighted by "!!"::
>
> Which is not the case of these simple functions which only need a kfree.
How will development concerns evolve further also according to previous clarification attempts?
Clarifying confusion of our variable placement rules caused by cleanup.h
https://lore.kernel.org/ksummit/CAHk-=whPZoi03ZwphxiW6cuWPtC3nyKYS8_BThgztCdgPWP1WA@mail.gmail.com/
https://lkml.org/lkml/2025/11/18/1766
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Remove unused struct table in setup_areas()
From: Madhavan Srinivasan @ 2026-07-28 6:02 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), Thorsten Blum, Geoff Levand,
Michael Ellerman, Nicholas Piggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a7f327e0-072b-41c9-ba95-361c948ddfa9@kernel.org>
On 7/27/26 6:47 PM, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 12/07/2026 à 17:13, Thorsten Blum a écrit :
>> The local table structure is not used - remove it.
>>
>> Remove % in the comment while at it.
>>
>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>
> Looks like it's never been used since commit de91a5342995 ("[POWERPC]
> ps3: add spu support") that introduced it.
>
>
> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>
> I have no opinion about the %0 versus 0, is it worth the change ?
FYI.. I have added this patch as-is to my fixes-test
not waiting for v2
Maddy
>
>
>> ---
>> arch/powerpc/platforms/ps3/spu.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/ps3/spu.c
>> b/arch/powerpc/platforms/ps3/spu.c
>> index e817def7f424..c904f9fa1caa 100644
>> --- a/arch/powerpc/platforms/ps3/spu.c
>> +++ b/arch/powerpc/platforms/ps3/spu.c
>> @@ -185,13 +185,11 @@ static void spu_unmap(struct spu *spu)
>> * The current HV requires the spu shadow regs to be mapped with the
>> * PTE page protection bits set as read-only.
>> *
>> - * Returns: %0 on success or -errno on error.
>> + * Returns: 0 on success or -errno on error.
>> */
>> static int __init setup_areas(struct spu *spu)
>> {
>> - struct table {char* name; unsigned long addr; unsigned long size;};
>> -
>> spu_pdata(spu)->shadow = ioremap_prot(spu_pdata(spu)->shadow_addr,
>> sizeof(struct spe_shadow),
>> pgprot_noncached_wc(PAGE_KERNEL_RO));
>
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Shrikanth Hegde @ 2026-07-28 5:27 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), Jirka Hladky, paulmck
Cc: maddy, linuxppc-dev, mpe, npiggin, bigeasy, will, linux-kernel
In-Reply-To: <f81777c3-e341-4ec5-8d61-b333d7170b3f@kernel.org>
Hi Paul, Christophe,
On 7/27/26 11:59 PM, Christophe Leroy (CS GROUP) wrote:
> Hi Shrikanth,
>
>
> That's right with CONFIG_PREEMPT_DYNAMIC=y
>
> With CONFIG_PREEMT_DYNAMIC=n:
> - CONFIG_PREEMPT (full) implies CONFIG_PREEMPT_RCU
> - CONFIG_PREEMPT_LAZY (lazy) doesn't imply CONFIG_PREEMPT_RCU
>
> because of kernel/rcu/Kconfig,
>
> config PREEMPT_RCU
> bool
> default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> select TREE_RCU
>
> Christophe
>
>
Right.
Looks like __rcu_read_unlock can set need_resched bit if it find irq were disabled
and rcu_read_unlock_special.s is set. I don't have much clue about it.
So, after seeing __rcu_read_unlock for PREEMPT_RCU I have these concerns now.
In current upstream, lazy is a preemption mode with preempt_enable being a preemptible point,
1. If PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n, then PREEMPT_RCU=n. That seems wrong. It is supposed to
do the preemption checks, since preempt_count is actual count with lazy preemption.
2. PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n and PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y are supposed
to be similar w.r.t to performance. Promise of PREEMPT_DYNAMIC was the ability to
switch at runtime based on the user workload and his/her preference.
But with PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y, there is additional cost due to PREEMPT_RCU.
lazy being the middle ground w.r.t for decent performance, either PREEMPT_RCU should either kick in
for both cases or bail out for both.
Before 7.0
3. the same concerns would be true to PREEMPT_VOLUNTARY and PREEMPT_NONE with PREEMPT_DYNAMIC=y.
Those model never wanted a preemption, but PREEMPT_RCU could have forced a need_resched to be
set. Which is also likely wrong. No?
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Shrikanth Hegde @ 2026-07-28 5:11 UTC (permalink / raw)
To: Jirka Hladky
Cc: paulmck, maddy, linuxppc-dev, christophe.leroy, mpe, npiggin,
bigeasy, will, linux-kernel
In-Reply-To: <CAE4VaGAJ9mT8-V=GRPYj8h0RXuNf6S5icrmqeOOFDnkpPMQjaw@mail.gmail.com>
Hi Jirka,
Thanks for these experiments.
On 7/28/26 5:56 AM, Jirka Hladky wrote:
> On Mon, Jul 27, 2026 at 7:10 PM Shrikanth Hegde <sshegde@linux.ibm.com> wrote:
>> That's full preemption mode.
>>
>> When preemption mode changes preempt_enable/disable which were just a
>> barrier earlier now become real preemption points. If the code path
>> repeatedly does the exact same thing, it might pop up.
>> But, can we say is that number expected? it is difficult to put a
>> number to it.
>
> You were right -- my previous test conflated two variables. I've now
> built a third kernel to separate them. All three are from the same
> 6.15-rc6 source, same machine (POWER10 lp11), no PREEMPT_DYNAMIC:
>
> Config Mode PREEMPT_RCU
> kill bogo-ops/sec
> ------------------------------------ ---------- -----------
> -----------------
> PREEMPT_VOLUNTARY=y voluntary no 105,014
> PREEMPT_LAZY=y lazy no 86,878
> PREEMPT=y full yes 73,317
>
> voluntary -> lazy -17.3%
> lazy -> full+PREEMPT_RCU -15.6%
> voluntary -> full+PREEMPT_RCU -30.2%
>
> The regression splits roughly 55/45 between the preemption mode
> change and PREEMPT_RCU:
>
> 1) voluntary -> lazy (-17.3%): preempt_disable/enable becoming real
> preemption points, as you predicted. On ppc64le this is expensive
> because the kill() syscall path is very tight and hits these
> points heavily.
That's true for all archs. Please check your preemption mode in your x86 experiment.
If it remained same, then that small difference could PREEMPT_RCU cost.
even preempt_enable/disable has barriers.
>
> 2) lazy -> full+PREEMPT_RCU (-15.6%): __rcu_read_lock/__rcu_read_unlock
> requiring lwsync/isync barriers on ppc64le.
>
Full is more aggressive in setting in the need_resched bit and
PREEMPT_RCU doing more than just barriers specially __rcu_read_unlock.
>> What I was asking is below. (You can do this only with below 7.0)
>>
>> Config A: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=n)
>> Config B: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=y)
>
> I couldn't do this exact test because 6.15-rc6 doesn't have
> HAVE_PREEMPT_DYNAMIC_KEY for powerpc (that's your 6.16 patch), so
> CONFIG_PREEMPT_DYNAMIC=y would be silently ignored. I would need a
> 6.16-6.19 kernel for this, which is before 7dadeaa6e851 removed
> voluntary as an option.
>
> But the PREEMPT_LAZY test above achieves the same goal: it isolates
> the preemption mode cost without PREEMPT_RCU.
>
No. It doesn't confirm. I would recommend you do that case to find out
the cost of PREEMPT_RCU alone.
The reason being, lazy is a real preemption mode. All the callsites of preempt_enable
could force a context switch.
Whereas,
>> Config A: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=n)
>> Config B: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=y)
Both are expected to same/similar w.r.t preempt_enable. But as we have discovered
PREEMPT_DYNAMIC in additions enables PREEMPT_RCU. If we get the above data,
then we can quantify the cost due to PREEMPT_RCU alone.
Preemption mode cost is one thing, i.e preempt enable/disable cost,
additional cost is call to schedule itself if need resched is set, that
will likely over weigh the preemption cost.
That is observed in your experiments too.
full is more aggressive in setting the need_resched bit. Plus additional cost of
PREEMPT_RCU which too can set need_resched bits.
>> Are you saying you see regression with voluntary with
>> CONFIG_PREEMPT_DYNAMIC=y?
>
> Yes. On the ELN kernels with CONFIG_PREEMPT_DYNAMIC=y, the regression
> appears at 6.16 when HAVE_PREEMPT_DYNAMIC_KEY is added, because:
> 1) PREEMPT_DYNAMIC forces the runtime mode to lazy/full (voluntary
> is no longer available on architectures with ARCH_HAS_PREEMPT_LAZY)
1. Is not true. PREEMPT_DYNAMIC doesn't force the preemption mode switch. You can still choose
voluntary even with PREEMPT_DYNAMIC on 6.16 to 6.19 kernel.
Forced mode switch to lazy/full due to ARCH_HAS_PREEMPT_LAZY has happened in 7.0.
> 2) PREEMPT_DYNAMIC pulls in PREEMPT_RCU
>
This looks it can set need_resched bit aggressive to force a quiescent state?
Concerns i see with this config, I have put it in other thread.
> Both contribute to the ~30% total regression.
>
> Jirka
>
^ permalink raw reply
* Re: [PATCH v3 3/5] powerpc/xive: propagate IPI init errors to prevent use-after-free
From: Srikar Dronamraju @ 2026-07-28 2:47 UTC (permalink / raw)
To: Gou Hao
Cc: maddy, mpe, npiggin, chleroy, namcao, peterz, sshegde, kees,
lgs201920130244, ynorov, nilay, clg, benh, miltonm, mkchauras,
akpm, linuxppc-dev, linux-kernel, gouhaojake, kernel
In-Reply-To: <20260727104215.184786-4-gouhao@uniontech.com>
* Gou Hao <gouhao@uniontech.com> [2026-07-27 18:42:13]:
>
> static void __init pnv_smp_probe(void)
> {
> - if (xive_enabled())
> - xive_smp_probe();
> - else
> + if (xive_enabled()) {
> + if (xive_smp_probe() < 0)
> + return;
> + } else {
If xive_smp_probe() fails and we return from here, what is the IPI mechanism
that is going to be used?
Before the patch, we were not configured for IPI and we would fail.
Now we have not configured IPI mechanism, so what are the consequences?
Should we try disable xive_enabled() and try xics_smp_probe() instead?
> xics_smp_probe();
> + }
>
> if (cpu_has_feature(CPU_FTR_DBELL)) {
> ic_cause_ipi = smp_ops->cause_ipi;
> diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
> index db99725e752b..14cd0634eeca 100644
> --- a/arch/powerpc/platforms/pseries/smp.c
> +++ b/arch/powerpc/platforms/pseries/smp.c
> @@ -194,10 +194,12 @@ static int pseries_cause_nmi_ipi(int cpu)
>
> static __init void pSeries_smp_probe(void)
> {
> - if (xive_enabled())
> - xive_smp_probe();
> - else
> + if (xive_enabled()) {
> + if (xive_smp_probe() < 0)
> + return;
> + } else {
> xics_smp_probe();
> + }
>
> /* No doorbell facility, must use the interrupt controller for IPIs */
> if (!cpu_has_feature(CPU_FTR_DBELL))
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 9f80c16be23f..bbe7c85274ea 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -1267,15 +1267,17 @@ noinstr static void xive_cleanup_cpu_ipi(unsigned int cpu, struct xive_cpu *xc)
>
> int __init xive_smp_probe(void)
> {
> + int ret;
> +
> smp_ops->cause_ipi = xive_cause_ipi;
>
> /* Register the IPI */
> - xive_init_ipis();
> + ret = xive_init_ipis();
> + if (ret < 0)
> + return ret;
>
> /* Allocate and setup IPI for the boot CPU */
> - xive_setup_cpu_ipi(smp_processor_id());
> -
> - return 0;
> + return xive_setup_cpu_ipi(smp_processor_id());
> }
>
> #endif /* CONFIG_SMP */
> --
> 2.20.1
>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* [PATCH v3] soc: fsl: fix kernel-doc warnings and typos
From: Randy Dunlap @ 2026-07-28 0:49 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Li Yang, linuxppc-dev, linux-arm-kernel, Frank Li,
Guanhua Gao, Roy Pledge
Correct spelling of "list".
Fix a kernel-doc warning by describing the nested structure completely:
include/soc/fsl/dpaa2-fd.h:52: warning: Function parameter or member 'simple' not described in 'dpaa2_fd'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Li Yang <leoyang.li@nxp.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Guanhua Gao <guanhua.gao@nxp.com>
Cc: Roy Pledge <Roy.Pledge@nxp.com>
---
v2: update Cc: list, rebase
v3: rebase & resend
include/soc/fsl/dpaa2-fd.h | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
--- linux-next-20260727.orig/include/soc/fsl/dpaa2-fd.h
+++ linux-next-20260727/include/soc/fsl/dpaa2-fd.h
@@ -25,14 +25,15 @@
/**
* struct dpaa2_fd - Struct describing FDs
- * @words: for easier/faster copying the whole FD structure
- * @addr: address in the FD
- * @len: length in the FD
- * @bpid: buffer pool ID
- * @format_offset: format, offset, and short-length fields
- * @frc: frame context
- * @ctrl: control bits...including dd, sc, va, err, etc
- * @flc: flow context address
+ * @words: for easier/faster copying the whole FD structure
+ * @simple: struct for the FD fields
+ * @simple.addr: address in the FD
+ * @simple.len: length in the FD
+ * @simple.bpid: buffer pool ID
+ * @simple.format_offset: format, offset, and short-length fields
+ * @simple.frc: frame context
+ * @simple.ctrl: control bits...including dd, sc, va, err, etc
+ * @simple.flc: flow context address
*
* This structure represents the basic Frame Descriptor used in the system.
*/
@@ -497,7 +498,7 @@ static inline void dpaa2_fl_set_addr(str
* dpaa2_fl_get_frc() - Get the frame context in the FLE
* @fle: the given frame list entry
*
- * Return the frame context field in the frame lsit entry.
+ * Return the frame context field in the frame list entry.
*/
static inline u32 dpaa2_fl_get_frc(const struct dpaa2_fl_entry *fle)
{
^ permalink raw reply
* [PATCH v3] soc: fsl: dpio: fix kernel-doc typos
From: Randy Dunlap @ 2026-07-28 0:49 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Li Yang, linuxppc-dev, linux-arm-kernel, Frank Li,
Guanhua Gao, Roy Pledge
Correct spelling of 2 words.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Li Yang <leoyang.li@nxp.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Guanhua Gao <guanhua.gao@nxp.com>
Cc: Roy Pledge <Roy.Pledge@nxp.com>
---
v2: update Cc: list, rebase
v3: rebase & resend
include/soc/fsl/dpaa2-io.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20260727.orig/include/soc/fsl/dpaa2-io.h
+++ linux-next-20260727/include/soc/fsl/dpaa2-io.h
@@ -22,7 +22,7 @@ struct device;
* DOC: DPIO Service
*
* The DPIO service provides APIs for users to interact with the datapath
- * by enqueueing and dequeing frame descriptors.
+ * by enqueueing and dequeueing frame descriptors.
*
* The following set of APIs can be used to enqueue and dequeue frames
* as well as producing notification callbacks when data is available
@@ -33,7 +33,7 @@ struct device;
/**
* struct dpaa2_io_desc - The DPIO descriptor
- * @receives_notifications: Use notificaton mode. Non-zero if the DPIO
+ * @receives_notifications: Use notification mode. Non-zero if the DPIO
* has a channel.
* @has_8prio: Set to non-zero for channel with 8 priority WQs. Ignored
* unless receives_notification is TRUE.
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Jirka Hladky @ 2026-07-28 0:26 UTC (permalink / raw)
To: Shrikanth Hegde
Cc: paulmck, maddy, linuxppc-dev, christophe.leroy, mpe, npiggin,
bigeasy, will, linux-kernel
In-Reply-To: <e013e88a-6137-4de8-9dfd-925b707f2e01@linux.ibm.com>
On Mon, Jul 27, 2026 at 7:10 PM Shrikanth Hegde <sshegde@linux.ibm.com> wrote:
> That's full preemption mode.
>
> When preemption mode changes preempt_enable/disable which were just a
> barrier earlier now become real preemption points. If the code path
> repeatedly does the exact same thing, it might pop up.
> But, can we say is that number expected? it is difficult to put a
> number to it.
You were right -- my previous test conflated two variables. I've now
built a third kernel to separate them. All three are from the same
6.15-rc6 source, same machine (POWER10 lp11), no PREEMPT_DYNAMIC:
Config Mode PREEMPT_RCU
kill bogo-ops/sec
------------------------------------ ---------- -----------
-----------------
PREEMPT_VOLUNTARY=y voluntary no 105,014
PREEMPT_LAZY=y lazy no 86,878
PREEMPT=y full yes 73,317
voluntary -> lazy -17.3%
lazy -> full+PREEMPT_RCU -15.6%
voluntary -> full+PREEMPT_RCU -30.2%
The regression splits roughly 55/45 between the preemption mode
change and PREEMPT_RCU:
1) voluntary -> lazy (-17.3%): preempt_disable/enable becoming real
preemption points, as you predicted. On ppc64le this is expensive
because the kill() syscall path is very tight and hits these
points heavily.
2) lazy -> full+PREEMPT_RCU (-15.6%): __rcu_read_lock/__rcu_read_unlock
requiring lwsync/isync barriers on ppc64le.
> What I was asking is below. (You can do this only with below 7.0)
>
> Config A: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=n)
> Config B: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=y)
I couldn't do this exact test because 6.15-rc6 doesn't have
HAVE_PREEMPT_DYNAMIC_KEY for powerpc (that's your 6.16 patch), so
CONFIG_PREEMPT_DYNAMIC=y would be silently ignored. I would need a
6.16-6.19 kernel for this, which is before 7dadeaa6e851 removed
voluntary as an option.
But the PREEMPT_LAZY test above achieves the same goal: it isolates
the preemption mode cost without PREEMPT_RCU.
> Are you saying you see regression with voluntary with
> CONFIG_PREEMPT_DYNAMIC=y?
Yes. On the ELN kernels with CONFIG_PREEMPT_DYNAMIC=y, the regression
appears at 6.16 when HAVE_PREEMPT_DYNAMIC_KEY is added, because:
1) PREEMPT_DYNAMIC forces the runtime mode to lazy/full (voluntary
is no longer available on architectures with ARCH_HAS_PREEMPT_LAZY)
2) PREEMPT_DYNAMIC pulls in PREEMPT_RCU
Both contribute to the ~30% total regression.
Jirka
^ permalink raw reply
* Re: [PATCH RESEND v4 net-next 00/14] net: enetc: cleanups and improvements
From: patchwork-bot+netdevbpf @ 2026-07-27 23:40 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy,
maxime.chevallier, imx, netdev, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20260720014317.1059359-1-wei.fang@oss.nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 20 Jul 2026 09:43:02 +0800 you wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> The first group of patches (1, 2, 5-7) eliminates code duplication
> between the ENETC v1 and v4 drivers. Since both hardware generations
> share identical register layouts for MAC promiscuous mode, MAC hash
> filters, and VLAN promiscuous mode - differing only in register address
> offsets - common helper functions are extracted into enetc_pf_common.c
> and shared by both drivers.
>
> [...]
Here is the summary with links:
- [RESEND,v4,net-next,01/14] net: enetc: extract common helpers for MAC promiscuous mode setting
https://git.kernel.org/netdev/net-next/c/2557834ad0ff
- [RESEND,v4,net-next,02/14] net: enetc: extract common helpers for MAC hash filter configuration
https://git.kernel.org/netdev/net-next/c/0ce10770963e
- [RESEND,v4,net-next,03/14] net: enetc: convert ndo_set_rx_mode() to ndo_set_rx_mode_async()
https://git.kernel.org/netdev/net-next/c/debf0c7a34fa
- [RESEND,v4,net-next,04/14] net: enetc: improve MAFT entry management with bitmap tracking
https://git.kernel.org/netdev/net-next/c/6228fc9c2bbe
- [RESEND,v4,net-next,05/14] net: enetc: use PCI device name for debugfs directory
https://git.kernel.org/netdev/net-next/c/9db43e6f35db
- [RESEND,v4,net-next,06/14] net: enetc: simplify enetc4_set_port_speed()
https://git.kernel.org/netdev/net-next/c/c969fbc01d9e
- [RESEND,v4,net-next,07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC
https://git.kernel.org/netdev/net-next/c/7c9a6ae0edb2
- [RESEND,v4,net-next,08/14] net: enetc: remove invalid code from enetc4_pl_mac_link_up()
https://git.kernel.org/netdev/net-next/c/59bb3d62489c
- [RESEND,v4,net-next,09/14] net: enetc: open-code enetc4_set_default_si_vlan_promisc()
https://git.kernel.org/netdev/net-next/c/75e134261f61
- [RESEND,v4,net-next,10/14] net: enetc: refactor SI VLAN promiscuous mode configuration
https://git.kernel.org/netdev/net-next/c/f7c6dcd6444b
- [RESEND,v4,net-next,11/14] net: enetc: move enetc_set_si_vlan_promisc() to enetc_pf_common.c
https://git.kernel.org/netdev/net-next/c/ba07e3bef1b5
- [RESEND,v4,net-next,12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps
https://git.kernel.org/netdev/net-next/c/75b136cf0f6f
- [RESEND,v4,net-next,13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver
https://git.kernel.org/netdev/net-next/c/f0c1f31afd97
- [RESEND,v4,net-next,14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation
https://git.kernel.org/netdev/net-next/c/18bf0ac84334
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v4] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Gaurav Batra @ 2026-07-27 22:14 UTC (permalink / raw)
To: maddy
Cc: linuxppc-dev, sbhat, vaibhav, donettom, harshpb, ritesh.list,
Gaurav Batra, stable
In powerPC, if Dynamic DMA Window is big enough, RAM is pre-mapped. To
determine the size of RAM, a PAPR+ property "ibm,lrdr-capacity" is used.
This OF property dictates what is the max size of RAM an LPAR can have,
including DR added memory.
In PowerPC, 16GB pages can be allocated at machine level and then
assigned to LPARs. These 16GB pages are added to LPAR memory at the time
of boot. The address range for these 16GB pages is above MAX RAM an LPAR
can have (ibm,lrdr-capacity). In the current implementation, these 16GB
pages are being excluded from pre-mapped TCEs. A driver can have DMA
buffers allocated from 16GB pages. This results in platform to raise an
EEH when DMA is attempted on buffers in 16GB memory range.
commit 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly
adds TCEs for pmemory")
Prior to the above patch, memblock_end_of_DRAM() was being used to
determine the MAX memory of an LPAR. This included 16GB pages as well.
The issue with using memblock_end_of_DRAM() is that when pmemory is
converted to RAM via daxctl command, the DDW engine will incorrectly try
to add TCEs for pmemory as well.
Below is the address distribution of RAM, 16GB pages and pmemory for an
LPAR with max memory of 256GB, memory allocated 64GB, 2 16GB pages and
assigned pmemory of 8GB.
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x0000000fffffffff 64G online yes 0-255
0x0000004000000000-0x00000047ffffffff 32G online yes 1024-1151
cat /sys/bus/nd/devices/region0/resource
0x40100000000
cat /sys/bus/nd/devices/region0/size
8589934592
The approach to fix this problem is to revert back the code changes
introduced by the above patch and to stash away the MAX memory of an
LPAR, including 16GB pages, at the LPAR boot time. This value is then
used whenever TCEs are needed to be pre-mapped - enable_DDW() or,
iommu_mem_notifier()
Fixes: 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory")
Cc: stable@vger.kernel.org
Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
---
Change log:
V3 -> V4
1. Ritesh: Change pseries_ddw_max_ram to __ro_after_init;
Response: Incorporated changes
2. Ritesh: Mark function ddw_memory_hotplug_max() as __init function
Response: Incorporated changes
3. Ritesh: This patch was made in v6.15. Since we want this to be backported, I
would suggested add a CC stable tag as well.
Response: Incorporated changes
V2 -> V3
1. Harsh: Remove R-b tags from the change log
Response: Incorporated changes
2. Harsh: Change WARN_ON() to WARN_ONCE()
Response: Incorporated changes
3. Harsh: Fix indendation
Response: Incorporated changes
4. Harsh: Replace comment with a log if limit < arg->nr_pages ?
Response: Doesn't seems to be needed since the WARN_ONCE() will log this
scenario. I removed the comment instead.
V1 -> V2
1. Harsh: Not only start_pfn, but end_pfn also needs to be within allowed
range, which may require clamping arg->nr_pages if crossing the limits.
Response: Incorporated changes.
arch/powerpc/platforms/pseries/iommu.c | 60 ++++++++++++++++++--------
1 file changed, 42 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 3e1f915fe4f6..7f63adafaf91 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -69,6 +69,8 @@ static struct iommu_table *iommu_pseries_alloc_table(int node)
return tbl;
}
+static phys_addr_t pseries_ddw_max_ram __ro_after_init;
+
#ifdef CONFIG_IOMMU_API
static struct iommu_table_group_ops spapr_tce_table_group_ops;
#endif
@@ -1283,15 +1285,19 @@ struct failed_ddw_pdn {
static LIST_HEAD(failed_ddw_pdn_list);
-static phys_addr_t ddw_memory_hotplug_max(void)
+static phys_addr_t __init ddw_memory_hotplug_max(void)
{
- resource_size_t max_addr;
+ resource_size_t max_addr = memory_hotplug_max();
+ struct device_node *memory;
-#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
- max_addr = hot_add_drconf_memory_max();
-#else
- max_addr = memblock_end_of_DRAM();
-#endif
+ for_each_node_by_type(memory, "memory") {
+ struct resource res;
+
+ if (of_address_to_resource(memory, 0, &res))
+ continue;
+
+ max_addr = max_t(resource_size_t, max_addr, res.end + 1);
+ }
return max_addr;
}
@@ -1446,7 +1452,7 @@ static struct property *ddw_property_create(const char *propname, u32 liobn, u64
static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn, u64 dma_mask)
{
int len = 0, ret;
- int max_ram_len = order_base_2(ddw_memory_hotplug_max());
+ int max_ram_len = order_base_2(pseries_ddw_max_ram);
struct ddw_query_response query;
struct ddw_create_response create;
int page_shift;
@@ -1668,7 +1674,7 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn, u64 dma_mas
if (direct_mapping) {
/* DDW maps the whole partition, so enable direct DMA mapping */
- ret = walk_system_ram_range(0, ddw_memory_hotplug_max() >> PAGE_SHIFT,
+ ret = walk_system_ram_range(0, pseries_ddw_max_ram >> PAGE_SHIFT,
win64->value, tce_setrange_multi_pSeriesLP_walk);
if (ret) {
dev_info(&dev->dev, "failed to map DMA window for %pOF: %d\n",
@@ -2419,23 +2425,35 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
{
struct dma_win *window;
struct memory_notify *arg = data;
+ unsigned long limit = arg->nr_pages;
+ unsigned long max_ram_pages = pseries_ddw_max_ram >> PAGE_SHIFT;
int ret = 0;
/* This notifier can get called when onlining persistent memory as well.
* TCEs are not pre-mapped for persistent memory. Persistent memory will
- * always be above ddw_memory_hotplug_max()
+ * always be above pseries_ddw_max_ram
*/
+ if (arg->start_pfn >= max_ram_pages)
+ return NOTIFY_OK;
+
+ /* RAM is being DLPAR'ed. The range should never exceed max ram.
+ * Just in case, clamp the range and throw a warning.
+ */
+ if (arg->start_pfn + limit > max_ram_pages) {
+ limit = max_ram_pages - arg->start_pfn;
+ WARN_ONCE(1, "Limiting Page Range %lx - %lx to Max Mem Pages: %lx\n",
+ arg->start_pfn, arg->start_pfn + arg->nr_pages,
+ max_ram_pages);
+ }
switch (action) {
case MEM_GOING_ONLINE:
spin_lock(&dma_win_list_lock);
list_for_each_entry(window, &dma_win_list, list) {
- if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
- ddw_memory_hotplug_max()) {
+ if (window->direct) {
ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
- arg->nr_pages, window->prop);
+ limit, window->prop);
}
- /* XXX log error */
}
spin_unlock(&dma_win_list_lock);
break;
@@ -2443,12 +2461,10 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
case MEM_OFFLINE:
spin_lock(&dma_win_list_lock);
list_for_each_entry(window, &dma_win_list, list) {
- if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
- ddw_memory_hotplug_max()) {
+ if (window->direct) {
ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
- arg->nr_pages, window->prop);
+ limit, window->prop);
}
- /* XXX log error */
}
spin_unlock(&dma_win_list_lock);
break;
@@ -2532,6 +2548,14 @@ void __init iommu_init_early_pSeries(void)
register_memory_notifier(&iommu_mem_nb);
set_pci_dma_ops(&dma_iommu_ops);
+
+ /* During init determine the max memory an LPAR can have and set it. This
+ * will be used for pre-mapping RAM in DDW. memblock_end_of_DRAM() can
+ * change during the running of LPAR - daxctl can add pmemory as
+ * "system-ram". This memory range should not be pre-mapped in DDW since
+ * the address of pmemory can be much higher than the DDW size.
+ */
+ pseries_ddw_max_ram = ddw_memory_hotplug_max();
}
static int __init disable_multitce(char *str)
base-commit: 6d35786de28116ecf78797a62b84e6bf3c45aa5a
--
2.39.3
^ permalink raw reply related
* [PATCH v2 06/64] dmaengine: fsldma: migrate tasklet to dma_chan BH
From: Allen Pais @ 2026-07-27 20:28 UTC (permalink / raw)
To: Vinod Koul, Frank Li
Cc: Allen Pais, dmaengine, linux-kernel, Arnd Bergmann, Kees Cook,
Zhang Wei, linuxppc-dev
In-Reply-To: <cover.1785183549.git.allen.lkml@gmail.com>
Replace the per-channel tasklet with the shared dma_chan BH helper.
The handler continues to run in softirq context while dmaengine owns
the common scheduling and teardown mechanism.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/dma/fsldma.c | 10 +++++-----
drivers/dma/fsldma.h | 1 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 22d62d958abd..1cb6ce327078 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -968,18 +968,18 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
chan_err(chan, "irq: unhandled sr 0x%08x\n", stat);
/*
- * Schedule the tasklet to handle all cleanup of the current
+ * Queue the BH worker to handle all cleanup of the current
* transaction. It will start a new transaction if there is
* one pending.
*/
- tasklet_schedule(&chan->tasklet);
+ dma_chan_schedule_bh(&chan->common);
chan_dbg(chan, "irq: Exit\n");
return IRQ_HANDLED;
}
-static void dma_do_tasklet(struct tasklet_struct *t)
+static void dma_do_tasklet(struct dma_chan *c)
{
- struct fsldma_chan *chan = from_tasklet(chan, t, tasklet);
+ struct fsldma_chan *chan = to_fsl_chan(c);
chan_dbg(chan, "tasklet entry\n");
@@ -1152,7 +1152,7 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
}
fdev->chan[chan->id] = chan;
- tasklet_setup(&chan->tasklet, dma_do_tasklet);
+ dma_chan_init_bh(&chan->common, dma_do_tasklet);
snprintf(chan->name, sizeof(chan->name), "chan%d", chan->id);
/* Initialize the channel */
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index d7b7a3138b85..cab33d010d51 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -173,7 +173,6 @@ struct fsldma_chan {
struct device *dev; /* Channel device */
int irq; /* Channel IRQ */
int id; /* Raw id of this channel */
- struct tasklet_struct tasklet;
u32 feature;
bool idle; /* DMA controller is idle */
#ifdef CONFIG_PM
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Christophe Leroy (CS GROUP) @ 2026-07-27 18:29 UTC (permalink / raw)
To: Shrikanth Hegde, Jirka Hladky, paulmck
Cc: maddy, linuxppc-dev, mpe, npiggin, bigeasy, will, linux-kernel
In-Reply-To: <e013e88a-6137-4de8-9dfd-925b707f2e01@linux.ibm.com>
Hi Shrikanth,
Le 27/07/2026 à 19:10, Shrikanth Hegde a écrit :
> Hi Jirka.
>
> On 7/27/26 10:20 PM, Jirka Hladky wrote:
>> On Mon, Jul 27, 2026 at 6:16 PM Paul E. McKenney <paulmck@kernel.org>
>> wrote:
>>> Yes, non-preemptible RCU's __rcu_read_{,un}lock() are (almost) no-ops,
>>> but preemptible RCU must actually execute real code. But I would not
>>> expect *this* much overhead.
>>
>
> Thanks for doing these experiment.
>
>> I've now isolated the PREEMPT_RCU cost with a controlled experiment.
>> Built two kernels from the same 6.15-rc6 upstream source on the same
>> POWER10 machine, no CONFIG_PREEMPT_DYNAMIC in either case:
>>
>> Config A: CONFIG_PREEMPT_VOLUNTARY=y (no PREEMPT_RCU)
>> Config B: CONFIG_PREEMPT=y (PREEMPT_RCU=y)
>
> That's full preemption mode.
>
>>
>> Results (stress-ng --kill 1 -t 23, SELinux enforcing):
>>
>> Kernel PREEMPT_RCU kill bogo-ops/sec
>> --------------------------- ----------- -----------------
>> 6.15-rc6-voluntary-test no 105,014
>> 6.15-rc6-preempt-test yes 73,317
>> Delta -30.2%
>>
>
> That is voluntary -> full preemption change.
>
> When preemption mode changes preempt_enable/disable which were just a
> barrier earlier now become real preemption points. If the code path
> repeatedly does the exact same thing, it might pop up.
> But, can we say is that number expected? it is difficult to put a number
> to it.
>
> What I was asking is below. (You can do this only with below 7.0)
>
> Config A: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=n i.e no
> PREEMPT_RCU)
> Config B: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=y i.e
> PREEMPT_RCU)
>
> That should keep in voluntary preemption.
> You can confirm with dynamic preemption using /sys/kerenl/debug/sched/
> preempt.
>
> In Config B, though there is rcu_read_lock/unlock it should be just a
> barrier.
>
>
>> PREEMPT_RCU alone accounts for ~30% on this workload. The kill()
>> path hits rcu_read_lock/unlock very heavily through the SELinux AVC
>> (avc_has_perm -> avc_lookup wraps every hash table lookup in an RCU
>> read-side critical section).
>>
>> This also answers Shrikanth's question about whether the regression
>> is from the preemption mode change (voluntary -> lazy) or from
>> PREEMPT_RCU. Since no PREEMPT_DYNAMIC is involved in either build,
>> the preemption mode is not a factor. Additionally, switching between
>> full and lazy at runtime on 7.1 showed only ~1% difference (57,476
>> vs 56,892), further confirming the mode doesn't matter.
>
> Lazy/full switch is same. There will not be any additional overhead.
> The real concern is none/voluntary vs lazy/full.
That's right with CONFIG_PREEMPT_DYNAMIC=y
With CONFIG_PREEMT_DYNAMIC=n:
- CONFIG_PREEMPT (full) implies CONFIG_PREEMPT_RCU
- CONFIG_PREEMPT_LAZY (lazy) doesn't imply CONFIG_PREEMPT_RCU
because of kernel/rcu/Kconfig,
config PREEMPT_RCU
bool
default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
select TREE_RCU
Christophe
>
>>
>>> OK, if you are executing an isync or an lwsync instruction in each call
>>> to __rcu_read_{,un}lock(), that would explain the overhead.
>>
>> Yes, that's what perf shows. __rcu_read_lock and __rcu_read_unlock
>> together consume ~9% of total cycles on ppc64le with PREEMPT_RCU,
>> vs essentially 0% without.
>>
>>> CONFIG_PREEMPT_DYNAMIC=n for the win?
>>
>> That's the simplest distro workaround for ppc64le. But since commit
>> 7dadeaa6e851 ("sched: Further restrict the preemption modes")
>> removed PREEMPT_VOLUNTARY as an option for architectures with
>> ARCH_HAS_PREEMPT_LAZY (which includes powerpc), distros that want
>> voluntary preemption on ppc64le would need to disable PREEMPT_DYNAMIC
>> anyway.
>>
>> Is there any path to reducing the barrier cost in
>> __rcu_read_lock/__rcu_read_unlock on weakly-ordered architectures?
>> Or is the current implementation fundamentally constrained by the
>> memory model?
>>
>
> Are you saying you see regression with voluntary with
> CONFIG_PREEMPT_DYNAMIC=y?
>
>> Jirka
>>
>
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Shrikanth Hegde @ 2026-07-27 17:10 UTC (permalink / raw)
To: Jirka Hladky, paulmck
Cc: maddy, linuxppc-dev, christophe.leroy, mpe, npiggin, bigeasy,
will, linux-kernel
In-Reply-To: <CAE4VaGDGS8wkZj4SF5XVC3-1yDmvJxjUjThTPqVw3kxg56ssQA@mail.gmail.com>
Hi Jirka.
On 7/27/26 10:20 PM, Jirka Hladky wrote:
> On Mon, Jul 27, 2026 at 6:16 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>> Yes, non-preemptible RCU's __rcu_read_{,un}lock() are (almost) no-ops,
>> but preemptible RCU must actually execute real code. But I would not
>> expect *this* much overhead.
>
Thanks for doing these experiment.
> I've now isolated the PREEMPT_RCU cost with a controlled experiment.
> Built two kernels from the same 6.15-rc6 upstream source on the same
> POWER10 machine, no CONFIG_PREEMPT_DYNAMIC in either case:
>
> Config A: CONFIG_PREEMPT_VOLUNTARY=y (no PREEMPT_RCU)
> Config B: CONFIG_PREEMPT=y (PREEMPT_RCU=y)
That's full preemption mode.
>
> Results (stress-ng --kill 1 -t 23, SELinux enforcing):
>
> Kernel PREEMPT_RCU kill bogo-ops/sec
> --------------------------- ----------- -----------------
> 6.15-rc6-voluntary-test no 105,014
> 6.15-rc6-preempt-test yes 73,317
> Delta -30.2%
>
That is voluntary -> full preemption change.
When preemption mode changes preempt_enable/disable which were just a
barrier earlier now become real preemption points. If the code path
repeatedly does the exact same thing, it might pop up.
But, can we say is that number expected? it is difficult to put a number to it.
What I was asking is below. (You can do this only with below 7.0)
Config A: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=n i.e no PREEMPT_RCU)
Config B: CONFIG_PREEMPT_VOLUNTARY=y (CONFIG_PREEMPT_DYNAMIC=y i.e PREEMPT_RCU)
That should keep in voluntary preemption.
You can confirm with dynamic preemption using /sys/kerenl/debug/sched/preempt.
In Config B, though there is rcu_read_lock/unlock it should be just a barrier.
> PREEMPT_RCU alone accounts for ~30% on this workload. The kill()
> path hits rcu_read_lock/unlock very heavily through the SELinux AVC
> (avc_has_perm -> avc_lookup wraps every hash table lookup in an RCU
> read-side critical section).
>
> This also answers Shrikanth's question about whether the regression
> is from the preemption mode change (voluntary -> lazy) or from
> PREEMPT_RCU. Since no PREEMPT_DYNAMIC is involved in either build,
> the preemption mode is not a factor. Additionally, switching between
> full and lazy at runtime on 7.1 showed only ~1% difference (57,476
> vs 56,892), further confirming the mode doesn't matter.
Lazy/full switch is same. There will not be any additional overhead.
The real concern is none/voluntary vs lazy/full.
>
>> OK, if you are executing an isync or an lwsync instruction in each call
>> to __rcu_read_{,un}lock(), that would explain the overhead.
>
> Yes, that's what perf shows. __rcu_read_lock and __rcu_read_unlock
> together consume ~9% of total cycles on ppc64le with PREEMPT_RCU,
> vs essentially 0% without.
>
>> CONFIG_PREEMPT_DYNAMIC=n for the win?
>
> That's the simplest distro workaround for ppc64le. But since commit
> 7dadeaa6e851 ("sched: Further restrict the preemption modes")
> removed PREEMPT_VOLUNTARY as an option for architectures with
> ARCH_HAS_PREEMPT_LAZY (which includes powerpc), distros that want
> voluntary preemption on ppc64le would need to disable PREEMPT_DYNAMIC
> anyway.
>
> Is there any path to reducing the barrier cost in
> __rcu_read_lock/__rcu_read_unlock on weakly-ordered architectures?
> Or is the current implementation fundamentally constrained by the
> memory model?
>
Are you saying you see regression with voluntary with CONFIG_PREEMPT_DYNAMIC=y?
> Jirka
>
^ permalink raw reply
* Re: [PATCH 1/6] KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit
From: Yosry Ahmed @ 2026-07-27 16:51 UTC (permalink / raw)
To: Sean Christopherson
Cc: Madhavan Srinivasan, Paolo Bonzini, Nicholas Piggin, linuxppc-dev,
kvm, linux-kernel
In-Reply-To: <20260724004757.131420-2-seanjc@google.com>
On Thu, Jul 23, 2026 at 5:48 PM Sean Christopherson <seanjc@google.com> wrote:
>
> Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a
> nested VM-Exit to ensure the request is cleared, even when KVM was built
> with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the "check" to clear
> the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM
> manages to bail from VM-Enter without processing the request, and then
> emulates VMLAUNCH or VMRESUME.
>
> Fixes: b4f69df0f65e ("KVM: x86: Make Hyper-V emulation optional")
> Cc: stable@vger.kernel.org
> Reported-by: Yosry Ahmed <yosry@kernel.org>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> arch/x86/kvm/vmx/nested.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index b5460de4b1a7..f2518d67e7de 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -5066,8 +5066,9 @@ void __nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm_exit_reason,
> /* trying to cancel vmlaunch/vmresume is a bug */
> kvm_warn_on_nested_run_pending(vcpu);
>
> -#ifdef CONFIG_KVM_HYPERV
> + /* Note, "checking" the request also clears the request. */
kvm_check_request() is in dire need of a rename.
kvm_test_clear_request()? Then we wouldn't need such a comment.
Obviously not as part of the stable fix, maybe another patch or even
separate from this series? I can also send a patch if you prefer so.
For this patch:
Reviewed-by: Yosry Ahmed <yosry@kernel.org>
> if (kvm_check_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu)) {
> +#ifdef CONFIG_KVM_HYPERV
> /*
> * KVM_REQ_GET_NESTED_STATE_PAGES is also used to map
> * Enlightened VMCS after migration and we still need to
> @@ -5075,8 +5076,8 @@ void __nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm_exit_reason,
> * the first L2 run.
> */
> (void)nested_get_evmcs_page(vcpu);
> - }
> #endif
> + }
>
> /* Service pending TLB flush requests for L2 before switching to L1. */
> kvm_service_local_tlb_flush_requests(vcpu);
> --
> 2.55.0.229.g6434b31f56-goog
>
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Jirka Hladky @ 2026-07-27 16:50 UTC (permalink / raw)
To: paulmck
Cc: Shrikanth Hegde, maddy, linuxppc-dev, christophe.leroy, mpe,
npiggin, bigeasy, will, linux-kernel
In-Reply-To: <500d8e8c-088c-4e6d-ab53-868ade6b0eda@paulmck-laptop>
On Mon, Jul 27, 2026 at 6:16 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> Yes, non-preemptible RCU's __rcu_read_{,un}lock() are (almost) no-ops,
> but preemptible RCU must actually execute real code. But I would not
> expect *this* much overhead.
I've now isolated the PREEMPT_RCU cost with a controlled experiment.
Built two kernels from the same 6.15-rc6 upstream source on the same
POWER10 machine, no CONFIG_PREEMPT_DYNAMIC in either case:
Config A: CONFIG_PREEMPT_VOLUNTARY=y (no PREEMPT_RCU)
Config B: CONFIG_PREEMPT=y (PREEMPT_RCU=y)
Results (stress-ng --kill 1 -t 23, SELinux enforcing):
Kernel PREEMPT_RCU kill bogo-ops/sec
--------------------------- ----------- -----------------
6.15-rc6-voluntary-test no 105,014
6.15-rc6-preempt-test yes 73,317
Delta -30.2%
PREEMPT_RCU alone accounts for ~30% on this workload. The kill()
path hits rcu_read_lock/unlock very heavily through the SELinux AVC
(avc_has_perm -> avc_lookup wraps every hash table lookup in an RCU
read-side critical section).
This also answers Shrikanth's question about whether the regression
is from the preemption mode change (voluntary -> lazy) or from
PREEMPT_RCU. Since no PREEMPT_DYNAMIC is involved in either build,
the preemption mode is not a factor. Additionally, switching between
full and lazy at runtime on 7.1 showed only ~1% difference (57,476
vs 56,892), further confirming the mode doesn't matter.
> OK, if you are executing an isync or an lwsync instruction in each call
> to __rcu_read_{,un}lock(), that would explain the overhead.
Yes, that's what perf shows. __rcu_read_lock and __rcu_read_unlock
together consume ~9% of total cycles on ppc64le with PREEMPT_RCU,
vs essentially 0% without.
> CONFIG_PREEMPT_DYNAMIC=n for the win?
That's the simplest distro workaround for ppc64le. But since commit
7dadeaa6e851 ("sched: Further restrict the preemption modes")
removed PREEMPT_VOLUNTARY as an option for architectures with
ARCH_HAS_PREEMPT_LAZY (which includes powerpc), distros that want
voluntary preemption on ppc64le would need to disable PREEMPT_DYNAMIC
anyway.
Is there any path to reducing the barrier cost in
__rcu_read_lock/__rcu_read_unlock on weakly-ordered architectures?
Or is the current implementation fundamentally constrained by the
memory model?
Jirka
^ permalink raw reply
* Re: [PATCH v8 1/5] PCI: dwc: ep: Clear MSI iATU mapping in dw_pcie_ep_cleanup()
From: Niklas Cassel @ 2026-07-27 16:18 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel,
linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Wilfred Mallawa,
Krishna Chaitanya Chundru, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding
In-Reply-To: <20260518-pci-port-reset-v8-1-eb5a7d331dfc@oss.qualcomm.com>
On Mon, May 18, 2026 at 08:29:13PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> The MSI iATU mapping is currently only cleared when the endpoint is
> stopped via configfs or when the host updates the MSI address/size.
> This avoids redundant iATU reconfiguration every time the endpoint
> raises an MSI interrupt.
>
> However, a fundamental reset triggered by PERST# assert/deassert
> resets all iATU inbound/outbound registers without going through the
> configfs stop path. If the host also retains the same MSI address/size
> after PERST# deassert, the driver never clears the stale MSI iATU
> mapping. It then continues using this stale mapping to raise the MSI
> interrupts, which can cause IOMMU faults and MSI failures on the host.
>
> Fix this by clearing the MSI iATU mapping inside dw_pcie_ep_cleanup(),
> which is already called as part of the PERST# assert/deassert sequence.
> This unmaps the MSI iATU region and sets the msi_iatu_mapped flag to
> false, ensuring that dw_pcie_ep_raise_msi_irq() performs a fresh iATU
> mapping on its next invocation, regardless of whether the host changed
> the MSI address/size.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Doesn't this need a Fixes tag?
Side node: It seems like this series does no longer apply on pci/next.
Perhaps need to rebase and resend?
Kind regards,
Niklas
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Paul E. McKenney @ 2026-07-27 16:12 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Shrikanth Hegde, Jirka Hladky, maddy, linuxppc-dev, mpe, npiggin,
bigeasy, will, linux-kernel
In-Reply-To: <330ca432-ddb6-4eeb-8415-697e16e73c43@kernel.org>
On Mon, Jul 27, 2026 at 12:35:32PM +0200, Christophe Leroy (CS GROUP) wrote:
> Hi Shrikanth,
>
> Le 27/07/2026 à 12:28, Shrikanth Hegde a écrit :
> > Hi Jirka,
> > Please avoid top-posting.
> >
> > On 7/27/26 3:43 PM, Jirka Hladky wrote:
> > > Hi Shrikanth,
> > >
> > > Thanks for the quick response and for looping in Paul.
> > >
> > > > This is true only if user selected PREEMPT_DYNAMIC option i think.
> > >
> > > Yes, exactly. The issue is that CONFIG_PREEMPT_DYNAMIC=y has been in
> > > the Fedora/RHEL kernel config since kernel 5.16 (2021). It was
> > > silently ignored on ppc64le until your 6.16 patch added
> > > HAVE_PREEMPT_DYNAMIC_KEY, so this is the first time PREEMPT_RCU
> > > actually takes effect for all Fedora/RHEL ppc64le users.
> > >
> > > > Does your preemption mode remain the same in two cases?
> > >
> > > Verified. On 6.15-rc6 (before PREEMPT_DYNAMIC takes effect):
> > >
> > > CONFIG_PREEMPT_VOLUNTARY=y
> > > (no CONFIG_PREEMPT_DYNAMIC, no /sys/kernel/debug/sched/preempt)
> > >
> > > On both 7.1 and 7.2-rc4 (with PREEMPT_DYNAMIC active):
> > >
> > > CONFIG_PREEMPT_LAZY=y
> > > CONFIG_PREEMPT_DYNAMIC=y
> > > CONFIG_PREEMPT_RCU=y
> > > cat /sys/kernel/debug/sched/preempt: "full (lazy)"
> > >
> > > So the runtime preemption mode is the same on 7.1 and 7.2. The
> > > difference between 6.15 and 7.1+ is that the preemption model changed
> > > from voluntary (static) to full/lazy (dynamic), which is what pulls
> > > in PREEMPT_RCU.
> >
> > That means comparison is between preempt=voluntary vs preempt=lazy.
>
> As far as I can see CONFIG_PREEMPT_LAZY doesn't pull CONFIG_PREEMPT_RCU.
> CONFIG_PREEMPT_DYNAMIC does:
That is correct.
Now, PREEMPT_LAZY does add preempt_disable() to rcu_read_lock()
and preempt_enable() to rcu_read_unlock(), compared to PREEMPT_NONE.
So there might be some performance impact. But hopefully not quite as
much as an isync or lwsync instruction.
OK, OK, PREEMPT_NONE also has preempt_disable() in rcu_read_lock() and
preempt_enable() in rcu_read_unlock(). The real difference is that in
PREEMPT_NONE, both preempt_disable() and preempt_enable() are no-ops.
In contrast, in PREEMPT_LAZY these two execute real code.
Thanx, Paul
> config PREEMPT_RCU
> bool
> default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> select TREE_RCU
> help
> This option selects the RCU implementation that is
> designed for very large SMP systems with hundreds or
> thousands of CPUs, but for which real-time response
> is also required. It also scales down nicely to
> smaller systems.
>
> Select this option if you are unsure.
>
>
> Christophe
>
> >
> > If you make it full preemption in 6.15 you will likely see similar data
> > as 7.1+.
> > Only on 7.0/7.1 there is force switch to lazy/full. Can you give that a
> > try?
> >
> > If it shows same data, that implies the regression is mainly due to change
> > of preemption modes, rather than the static key stuff.
> >
> > >
> > > > Weak memory model would need barriers irrespective of
> > > > HAVE_PREEMPT_DYNAMIC_CALL or HAVE_PREEMPT_DYNAMIC_KEY.
> > > > Static key too is expected to minimal cost.
> > >
> > > You're right, I should clarify -- the overhead is not in the static
> > > key mechanism itself. The cost comes from __rcu_read_lock() and
> > > __rcu_read_unlock() which are called when CONFIG_PREEMPT_RCU=y.
> > > These need real memory barriers (lwsync/isync) on ppc64le regardless
> > > of whether the dynamic mechanism uses keys or calls.
> > >
> > > The real question is: why does enabling PREEMPT_RCU cost ~33% on
> > > ppc64le but only ~3% on x86_64? The answer is that x86_64's TSO
> > > memory model makes the barriers in __rcu_read_lock/__rcu_read_unlock
> > > essentially free, while ppc64le's weak ordering requires explicit
> > > lwsync/isync instructions, which are expensive when called thousands
> > > of times per second in the SELinux AVC hot path.
> >
> > Plus, it may call schedule in lazy/pull preemption.
> >
> > >
> > > I also have new data from SELinux isolation testing that helps
> > > quantify this. On kernel 7.1 (which already has PREEMPT_RCU=y):
> > >
> > > SELinux mode kill bogo-ops/sec vs enforcing
> > > ------------ ----------------- ------------
> > > Enforcing 69,107 baseline
> > > Permissive 70,248 +1.6%
> > > Disabled 93,566 +35.4%
> > >
> > > Permissive ~ enforcing confirms the overhead is not in SELinux policy
> > > evaluation. Disabling SELinux removes the rcu_read_lock/unlock call
> > > sites in the AVC path and recovers most of the performance -- but
> > > still leaves a ~13% gap vs 6.12 (no PREEMPT_RCU), which is the base
> > > cost of PREEMPT_RCU in the non-SELinux parts of the kill() path.
> > >
> >
> > This seems strange. How come rcu lock/unlock depends on SELinux policy?
> > One should call rcu lock/unlock if they are working with rcu updated
> > fields.
> >
> > Does the policy change itself protected with rcu lock/unlock?
> > I will check it up.
> >
> > > So the core issue is: on ppc64le, CONFIG_PREEMPT_RCU makes
> > > rcu_read_lock/unlock significantly more expensive, and the kill()
> > > syscall path hits them very heavily through SELinux AVC lookups.
> > >
> > > Thanks,
> > > Jirka
> > >
> > > On Mon, Jul 27, 2026 at 6:19 AM Shrikanth Hegde
> > > <sshegde@linux.ibm.com> wrote:
> > > >
> > > > +cc paul for any further/RCU insights.
> > > >
> > > > On 7/27/26 12:03 AM, Jirka Hladky wrote:
> > > > > Hi Shrikanth, Christophe,
> > > > >
> > > >
> > > > Hi Jirka, thanks for the report.
> > > >
> > > > > I'm seeing a significant performance regression on
> > > > > ppc64le after this
> > > > > patch landed in 6.16, caused by CONFIG_PREEMPT_RCU becoming active
> > > > > once HAVE_PREEMPT_DYNAMIC_KEY is selected.
> > > > >
> > > >
> > > > This is true only if user selected PREEMPT_DYNAMIC option i think.
> > > >
> > > > config PREEMPT_RCU
> > > > bool
> > > > default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> > > > select TREE_RCU
> > > >
> > > >
> > > > > Benchmark: stress-ng kill stressor (tight kill() syscall loop),
> > > > > single thread, POWER10 LPAR (8 vCPUs, 1 core SMT-8).
> > > > >
> > > > > Bisected across Fedora ELN kernel builds on ppc64le:
> > > > >
> > > > > kernel CONFIG_PREEMPT_RCU kill bogo-ops/sec
> > > > > --- 6.15-rc6 (eln148) no 103,207
> > > > > 6.16 (eln150) yes 70,281 (-32%)
> > > > > 6.18 (eln154) yes 72,552 (-30%)
> > > > >
> > > >
> > > > Does your preemption mode remain the same in two cases?
> > > >
> > > > > For comparison, x86_64 (AMD EPYC 9355P) with the same config change
> > > > > shows only a 2.8% regression:
> > > > >
> > > > > 6.12 x86_64 37,436
> > > > > 7.2 x86_64 36,392 (-2.8%)
> > > > >
> > > > > perf report shows the overhead comes from
> > > > > rcu_read_lock/unlock in the
> > > > > SELinux AVC path (check_kill_permission -> security_task_kill ->
> > > > > selinux_task_kill -> avc_has_perm -> avc_lookup):
> > > > >
> > > > > Function 6.15 (no PREEMPT_RCU) 6.16 (PREEMPT_RCU)
> > > > > --- avc_lookup 15.23% 24.79%
> > > > > __rcu_read_lock ~0% 4.52%
> > > > > __rcu_read_unlock ~0% 4.17%
> > > > > selinux_task_kill 6.23% 7.35%
> > > > > audit_signal_info* 0.94% 3.59%
> > > > >
> > > > > On x86_64, rcu_read_lock/unlock are cheap thanks to static calls
> > > > > (HAVE_PREEMPT_DYNAMIC_CALL). On ppc64le with the KEY-based
> > > > > implementation, the weak memory model requires real barriers
> > > > > (lwsync/isync) making each RCU read-side critical section
> > > > > significantly more expensive.
> > > >
> > > > Weak memory model would need barriers irrespective of
> > > > HAVE_PREEMPT_DYNAMIC_CALL
> > > > or HAVE_PREEMPT_DYNAMIC_KEY. That's my assumption. I will look
> > > > more into it. Also i don't know much about PREEMPT_RCU. So might
> > > > take a while.
> > > >
> > > > >
> > > > > This aligns with Christophe's earlier review comment that
> > > > > HAVE_PREEMPT_DYNAMIC_CALL should be more performant. Would
> > > > > implementing static calls for ppc64 be feasible to close this gap?
> > > > >
> > > >
> > > > Static key too is expected to minimal cost. There maybe more into this.
> > > >
> > > > > Test details:
> > > > > - Machine: IBM POWER10 (pvr 0080 0200), pHyp virtualization
> > > > > - stress-ng 0.21.03, gcc 14.3.1, glibc 2.39
> > > > > - Tuned profile: virtual-guest
> > > > > - SELinux: enforcing (permissive recovers only ~7%)
> > > > >
> > > > > Happy to run additional tests if needed.
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
^ permalink raw reply
* Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
From: Paul E. McKenney @ 2026-07-27 16:07 UTC (permalink / raw)
To: Shrikanth Hegde
Cc: Jirka Hladky, maddy, linuxppc-dev, christophe.leroy, mpe, npiggin,
bigeasy, will, linux-kernel
In-Reply-To: <c0f51eda-21c4-4e9d-95e9-75b2740c3f43@linux.ibm.com>
On Mon, Jul 27, 2026 at 09:48:25AM +0530, Shrikanth Hegde wrote:
> +cc paul for any further/RCU insights.
>
> On 7/27/26 12:03 AM, Jirka Hladky wrote:
> > Hi Shrikanth, Christophe,
> >
>
> Hi Jirka, thanks for the report.
>
> > I'm seeing a significant performance regression on ppc64le after this
> > patch landed in 6.16, caused by CONFIG_PREEMPT_RCU becoming active
> > once HAVE_PREEMPT_DYNAMIC_KEY is selected.
>
> This is true only if user selected PREEMPT_DYNAMIC option i think.
>
> config PREEMPT_RCU
> bool
> default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> select TREE_RCU
Yes, if you select PREEMPT_DYNAMIC, RCU doesn't have much choice but to
choose PREEMPT_RCU. Something about not having the guts to implement an
RCU that dynamically switches between its preemptible and non-preemptible
variants. Cowardly of me, I know!
So if you want non-preemptible RCU, you need to turn off PREEMPT_DYNAMIC.
> > Benchmark: stress-ng kill stressor (tight kill() syscall loop),
> > single thread, POWER10 LPAR (8 vCPUs, 1 core SMT-8).
> >
> > Bisected across Fedora ELN kernel builds on ppc64le:
> >
> > kernel CONFIG_PREEMPT_RCU kill bogo-ops/sec
> > --- 6.15-rc6 (eln148) no 103,207
> > 6.16 (eln150) yes 70,281 (-32%)
> > 6.18 (eln154) yes 72,552 (-30%)
> >
>
> Does your preemption mode remain the same in two cases?
>
> > For comparison, x86_64 (AMD EPYC 9355P) with the same config change
> > shows only a 2.8% regression:
> >
> > 6.12 x86_64 37,436
> > 7.2 x86_64 36,392 (-2.8%)
> >
> > perf report shows the overhead comes from rcu_read_lock/unlock in the
> > SELinux AVC path (check_kill_permission -> security_task_kill ->
> > selinux_task_kill -> avc_has_perm -> avc_lookup):
> >
> > Function 6.15 (no PREEMPT_RCU) 6.16 (PREEMPT_RCU)
> > --- avc_lookup 15.23% 24.79%
> > __rcu_read_lock ~0% 4.52%
> > __rcu_read_unlock ~0% 4.17%
Yes, non-preemptible RCU's __rcu_read_{,un}lock() are (almost) no-ops,
but preemptible RCU must actually execute real code. But I would not
expect *this* much overhead.
> > selinux_task_kill 6.23% 7.35%
> > audit_signal_info* 0.94% 3.59%
> >
> > On x86_64, rcu_read_lock/unlock are cheap thanks to static calls
> > (HAVE_PREEMPT_DYNAMIC_CALL). On ppc64le with the KEY-based
> > implementation, the weak memory model requires real barriers
> > (lwsync/isync) making each RCU read-side critical section
> > significantly more expensive.
>
> Weak memory model would need barriers irrespective of HAVE_PREEMPT_DYNAMIC_CALL
> or HAVE_PREEMPT_DYNAMIC_KEY. That's my assumption. I will look
> more into it. Also i don't know much about PREEMPT_RCU. So might take a while.
OK, if you are executing an isync or an lwsync instruction in each call
to __rcu_read_{,un}lock(), that would explain the overhead.
CONFIG_PREEMPT_DYNAMIC=n for the win?
Thanx, Paul
> > This aligns with Christophe's earlier review comment that
> > HAVE_PREEMPT_DYNAMIC_CALL should be more performant. Would
> > implementing static calls for ppc64 be feasible to close this gap?
> >
>
> Static key too is expected to minimal cost. There maybe more into this.
>
> > Test details:
> > - Machine: IBM POWER10 (pvr 0080 0200), pHyp virtualization
> > - stress-ng 0.21.03, gcc 14.3.1, glibc 2.39
> > - Tuned profile: virtual-guest
> > - SELinux: enforcing (permissive recovers only ~7%)
> >
> > Happy to run additional tests if needed.
> >
> >
^ permalink raw reply
* Re: [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors
From: Bjorn Helgaas @ 2026-07-27 15:51 UTC (permalink / raw)
To: Lukas Wunner
Cc: Yury Murashka, Matthew W Carlis, Zhenzhong Duan, Qingshun Wang,
Yicong Yang, dio.sun, linux-pci, Mahesh J Salgaonkar,
Oliver OHalloran, linuxppc-dev, Terry Bowman,
. Kuppuswamy Sathyanarayanan, Arjun Govindjee, Ashish Karkare,
Jasjeet Rangi, Meeta Saggi, rhan, sconnor, an.luo, fernando.hu,
bill.wu, xin.wang
In-Reply-To: <amdnMg_J6T3Sys45@wunner.de>
On Mon, Jul 27, 2026 at 04:12:02PM +0200, Lukas Wunner wrote:
> On Fri, Jul 24, 2026 at 05:39:03PM -0500, Bjorn Helgaas wrote:
> > On Fri, Jul 24, 2026 at 05:24:00PM +0200, Lukas Wunner wrote:
> > > PCI/AER: Fix mapping of errors to agent & layer
> > > PCI/AER: Log agent & layer for each individual error
> > > PCI/AER: Deduplicate logging of Error Source Identification
> > > PCI/AER: Emit TLP Log only for unmasked errors
> > > PCI/AER: Move retrieval of FEP and TLP Log into helper
> > > PCI/AER: Support Advisory Non-Fatal Errors
> > >
> > > drivers/pci/pci.h | 4 +
> > > drivers/pci/pcie/aer.c | 250 ++++++++++++++++++++++++++++++++---------
> > > 2 files changed, 200 insertions(+), 54 deletions(-)
> >
> > Applied to pci/aer with the intention of v7.3, thank you!
> >
> > I noticed a sashiko comment on 6/6 but haven't had time to look at it
> > yet. I left the series on pci/aer for build testing in the meantime.
>
> Below is a fixup for the first valid finding reported by sashiko.
> If you could fold that into the top-most commit on pci/aer,
> I'd be grateful!
Fixup folded into "PCI/AER: Support Advisory Non-Fatal Errors",
thanks!
> -- >8 --
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index ff6ff7abc286..2a380bb9bfcb 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -428,7 +428,7 @@ void pci_aer_init(struct pci_dev *dev)
> * Advisory Non-Fatal Errors are masked by default (PCIe r7.0, sec
> * 7.8.4.6).
> */
> - if (dev->devcap & PCI_EXP_DEVCAP_RBER)
> + if (pcie_aer_is_native(dev) && dev->devcap & PCI_EXP_DEVCAP_RBER)
> pci_clear_and_set_config_dword(dev,
> dev->aer_cap + PCI_ERR_COR_MASK,
> PCI_ERR_COR_ADV_NFAT, 0);
^ permalink raw reply
* Re: [PATCH v2 2/3] time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
From: Petr Pavlu @ 2026-07-27 14:58 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tony Luck, Borislav Petkov, Ingo Molnar, Dave Hansen, x86,
H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Pavel Machek, Len Brown, Andrew Morton,
Danilo Krummrich, Nikolay Aleksandrov, Ido Schimmel,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, David Howells, Jarkko Sakkinen, Paul Moore,
James Morris, Serge E. Hallyn, Kentaro Takeda, Tetsuo Handa,
linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <874ihmke0k.ffs@fw13>
On 7/25/26 10:31 PM, Thomas Gleixner wrote:
> On Tue, Jul 21 2026 at 15:11, Petr Pavlu wrote:
>
>> The kernel/time/jiffies.c file uses proc_int_u2k_conv_uop(),
>
> jiffies.c uses ...
>
>> proc_int_k2u_conv_kop(), proc_int_conv(), proc_dointvec_conv() and
>> proc_doulongvec_minmax_conv(), which are declared in linux/sysctl.h. It
>> currently relies on this header being included indirectly through
>> linux/module.h -> linux/kmod.h. Add the missing include in preparation for
>> removing the linux/sysctl.h include from linux/kmod.h.
>
> Can you please split that spaghetti sentence into paragraphs?
>
> https://docs.kernel.org/process/maintainer-tip.html#changelog
I will update it to:
jiffies.c uses proc_int_u2k_conv_uop(), proc_int_k2u_conv_kop(),
proc_int_conv(), proc_dointvec_conv() and proc_doulongvec_minmax_conv(),
which are declared in linux/sysctl.h. It currently gets that header
indirectly through linux/module.h -> linux/kmod.h, but the latter no longer
needs to include linux/sysctl.h.
Include linux/sysctl.h directly in jiffies.c ahead of removing the
unnecessary include from linux/kmod.h.
>
>> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
>
> Other than that.
>
> Acked-by: Thomas Gleixner <tglx@kernel.org>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors
From: Lukas Wunner @ 2026-07-27 14:12 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Yury Murashka, Matthew W Carlis, Zhenzhong Duan, Qingshun Wang,
Yicong Yang, dio.sun, linux-pci, Mahesh J Salgaonkar,
Oliver OHalloran, linuxppc-dev, Terry Bowman,
. Kuppuswamy Sathyanarayanan, Arjun Govindjee, Ashish Karkare,
Jasjeet Rangi, Meeta Saggi, rhan, sconnor, an.luo, fernando.hu,
bill.wu, xin.wang
In-Reply-To: <20260724223903.GA1073029@bhelgaas>
On Fri, Jul 24, 2026 at 05:39:03PM -0500, Bjorn Helgaas wrote:
> On Fri, Jul 24, 2026 at 05:24:00PM +0200, Lukas Wunner wrote:
> > PCI/AER: Fix mapping of errors to agent & layer
> > PCI/AER: Log agent & layer for each individual error
> > PCI/AER: Deduplicate logging of Error Source Identification
> > PCI/AER: Emit TLP Log only for unmasked errors
> > PCI/AER: Move retrieval of FEP and TLP Log into helper
> > PCI/AER: Support Advisory Non-Fatal Errors
> >
> > drivers/pci/pci.h | 4 +
> > drivers/pci/pcie/aer.c | 250 ++++++++++++++++++++++++++++++++---------
> > 2 files changed, 200 insertions(+), 54 deletions(-)
>
> Applied to pci/aer with the intention of v7.3, thank you!
>
> I noticed a sashiko comment on 6/6 but haven't had time to look at it
> yet. I left the series on pci/aer for build testing in the meantime.
Below is a fixup for the first valid finding reported by sashiko.
If you could fold that into the top-most commit on pci/aer,
I'd be grateful!
There is one other sashiko finding I need to address:
It complained that in the native case, Advisory Non-Fatal Errors are
reported with the same loglevel and ratelimiting as the accompanying
Correctable Error. But that's intentional. However in the Firmware
First case, I got that wrong in that the loglevel and ratelimiting of
non-Advisory Non-Fatal Errors is used. I'll come back with another
fixup for that!
My rebuttal of sashiko's findings:
https://lore.kernel.org/r/amdjR8LqIY0YmiG4@wunner.de
-- >8 --
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index ff6ff7abc286..2a380bb9bfcb 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -428,7 +428,7 @@ void pci_aer_init(struct pci_dev *dev)
* Advisory Non-Fatal Errors are masked by default (PCIe r7.0, sec
* 7.8.4.6).
*/
- if (dev->devcap & PCI_EXP_DEVCAP_RBER)
+ if (pcie_aer_is_native(dev) && dev->devcap & PCI_EXP_DEVCAP_RBER)
pci_clear_and_set_config_dword(dev,
dev->aer_cap + PCI_ERR_COR_MASK,
PCI_ERR_COR_ADV_NFAT, 0);
^ permalink raw reply related
* Re: [PATCH 1/5] mm: constify generic pte_get*()
From: David Hildenbrand (Arm) @ 2026-07-27 13:44 UTC (permalink / raw)
To: Pedro Falcato, Andrew Morton
Cc: Catalin Marinas, Will Deacon, James E.J. Bottomley, Helge Deller,
Madhavan Srinivasan, Michael Ellerman, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Matthew Wilcox (Oracle),
Jan Kara, Zi Yan, Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain,
Barry Song, Lance Yang, Usama Arif, Kevin Brodsky,
Muhammad Usama Anjum, linux-arm-kernel, linux-kernel,
linux-parisc, linuxppc-dev, linux-mm, linux-fsdevel
In-Reply-To: <20260724102017.141532-2-pfalcato@suse.de>
On 7/24/26 12:20, Pedro Falcato wrote:
> None of the helpers need write access to the PTE. Constifying the param
> allows for const typesafety.
>
> Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> ---
> include/linux/pgtable.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8c093c119e5a..dc418553e57a 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -490,7 +490,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma,
> #endif
>
> #ifndef ptep_get
> -static inline pte_t ptep_get(pte_t *ptep)
> +static inline pte_t ptep_get(const pte_t *ptep)
> {
> return READ_ONCE(*ptep);
> }
> @@ -739,7 +739,7 @@ static inline void ptep_clear(struct mm_struct *mm, unsigned long addr,
> * present bit set *unless* it is 'l'. Because get_user_pages_fast() only
> * operates on present ptes we're safe.
> */
> -static inline pte_t ptep_get_lockless(pte_t *ptep)
> +static inline pte_t ptep_get_lockless(const pte_t *ptep)
> {
> pte_t pte;
>
> @@ -777,7 +777,7 @@ static inline pmd_t pmdp_get_lockless(pmd_t *pmdp)
> * We require that the PTE can be read atomically.
> */
> #ifndef ptep_get_lockless
> -static inline pte_t ptep_get_lockless(pte_t *ptep)
> +static inline pte_t ptep_get_lockless(const pte_t *ptep)
> {
> return ptep_get(ptep);
> }
Yes, that's a step into the right direction.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] Connecting the SB600's i8259 controller rather in pasemi's pci.c than in pasemi's setup.c.
From: Christophe Leroy (CS GROUP) @ 2026-07-27 13:43 UTC (permalink / raw)
To: Christian Zigotzky, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Krzysztof Kozlowski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260701125941.906-2-chzigotzky@xenosoft.de>
Le 01/07/2026 à 14:59, Christian Zigotzky a écrit :
> Hello,
>
> Here is the email without HTML (Sorry):
>
> The Nemo board [1] doesn’t boot without this patch. Darren explained it really well:
>
> Originally we initialised the PCI-e ports in setup arch, this is quite early, and it seems uses some kernel functions that were not recommended (They changed a whole lot of different platforms at the same time for the same reason)
>
> After this we added the ISA bridge, then the kernel would init the IRQ contollers.
>
> The patch that broke booting on the X1000 moved the pas_pci_init to a node in the machine description, where it called later in the boot sequence. Unfortunately this is after we've tried to add the i8259 contoller from the pas_init_IRQ. Since our ISA bridge can't be found until we've connected the PCI-e ports the system tries to write to registers that aren't yet mapped - result a kernel panic, but before console I/O has been initialised so it appears to be a hang. We had a similar problem when they were introducing Radix support.
>
> My patch changes our code so that it works with the new kernel code in place. Basically I moved the code that adds the i8259 cascade to after we've scanned for the ISA bridge where I know it will work.
>
> Hopefully this makes sense, shout out if it doesn't.
>
> Regards
> Darren
>
> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAmigaOne_X1000&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cb415e9e7a26c4d8e3c6b08ded770c1b7%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639185077045605675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=EgGtT9Kj7aqkWWcIIxfPpYRulro8rUA%2F%2Bsp9bhy%2Bjqo%3D&reserved=0
>
> Signed-off-by: Christian Zigotzky <chzigotzky@xenosoft.de>
The commit message will look strange when picking-up this email, you
should resend with a cleaned commit message.
> ---
> arch/powerpc/platforms/pasemi/pci.c | 7 +++++++
> arch/powerpc/platforms/pasemi/setup.c | 7 ++++---
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
> index 2df955274652..7208c325bfc5 100644
> --- a/arch/powerpc/platforms/pasemi/pci.c
> +++ b/arch/powerpc/platforms/pasemi/pci.c
> @@ -25,6 +25,8 @@
>
> #define PA_PXP_CFA(bus, devfn, off) (((bus) << 20) | ((devfn) << 12) | (off))
>
> +extern void nemo_init_IRQ(void);
> +
Should be better in arch/powerpc/platforms/pasemi/pasemi.h
> static inline int pa_pxp_offset_valid(u8 bus, u8 devfn, int offset)
> {
> /* Device 0 Function 0 is special: It's config space spans function 1 as
> @@ -265,6 +267,11 @@ static int __init pas_add_bridge(struct device_node *dev)
> */
> isa_bridge_find_early(hose);
>
> + /*
> + * ISA brigde is now active, add the i8259 cascade (if needed)
> + */
> + nemo_init_IRQ();
> +
> return 0;
> }
>
> diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
> index d03b41336901..eec74611be46 100644
> --- a/arch/powerpc/platforms/pasemi/setup.c
> +++ b/arch/powerpc/platforms/pasemi/setup.c
> @@ -214,10 +214,12 @@ static void sb600_8259_cascade(struct irq_desc *desc)
> chip->irq_eoi(&desc->irq_data);
> }
>
> -static void __init nemo_init_IRQ(struct mpic *mpic)
> +void nemo_init_IRQ(void)
> {
> struct device_node *np;
> int gpio_virq;
> + struct mpic *mpic;
> +
> /* Connect the SB600's legacy i8259 controller */
> np = of_find_node_by_path("/pxp@0,e0000000");
> i8259_init(np, 0);
> @@ -228,6 +230,7 @@ static void __init nemo_init_IRQ(struct mpic *mpic)
> irq_set_chained_handler(gpio_virq, sb600_8259_cascade);
> mpic_unmask_irq(irq_get_irq_data(gpio_virq));
>
> + mpic = irq_get_chip_data(gpio_virq);
> irq_set_default_domain(mpic->irqhost);
> }
>
> @@ -298,8 +301,6 @@ static __init void pas_init_IRQ(void)
> mpic_unmask_irq(irq_get_irq_data(nmi_virq));
> }
>
> - nemo_init_IRQ(mpic);
> -
> of_node_put(mpic_node);
> of_node_put(root);
> }
Build fails:
CC arch/powerpc/platforms/pasemi/setup.o
arch/powerpc/platforms/pasemi/setup.c:217:6: error: no previous
prototype for 'nemo_init_IRQ' [-Werror=missing-prototypes]
217 | void nemo_init_IRQ(void)
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[5]: *** [scripts/Makefile.build:289:
arch/powerpc/platforms/pasemi/setup.o] Error 1
make[4]: *** [scripts/Makefile.build:549: arch/powerpc/platforms/pasemi]
Error 2
make[3]: *** [scripts/Makefile.build:549: arch/powerpc/platforms] Error 2
make[2]: *** [scripts/Makefile.build:549: arch/powerpc] Error 2
make[1]: *** [/home/chleroy/linux-powerpc/Makefile:2184: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
^ permalink raw reply
* Re: [PATCH v2] powerpc/ps3: Remove unused struct table in setup_areas()
From: Christophe Leroy (CS GROUP) @ 2026-07-27 13:17 UTC (permalink / raw)
To: Thorsten Blum, Geoff Levand, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin
Cc: Amit Machhiwal, Geert Uytterhoeven, linuxppc-dev, linux-kernel
In-Reply-To: <20260713091731.97212-3-thorsten.blum@linux.dev>
Le 13/07/2026 à 11:17, Thorsten Blum a écrit :
> The local table structure is not used - remove it.
>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> Changes in v2:
> - Drop the %0 change because it is valid kernel-doc markup (Amit)
> - v1: https://lore.kernel.org/r/20260712151300.3664-3-thorsten.blum@linux.dev/
> ---
> arch/powerpc/platforms/ps3/spu.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
> index e817def7f424..2c785bc72565 100644
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -190,8 +190,6 @@ static void spu_unmap(struct spu *spu)
>
> static int __init setup_areas(struct spu *spu)
> {
> - struct table {char* name; unsigned long addr; unsigned long size;};
> -
> spu_pdata(spu)->shadow = ioremap_prot(spu_pdata(spu)->shadow_addr,
> sizeof(struct spe_shadow),
> pgprot_noncached_wc(PAGE_KERNEL_RO));
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Remove unused struct table in setup_areas()
From: Christophe Leroy (CS GROUP) @ 2026-07-27 13:17 UTC (permalink / raw)
To: Thorsten Blum, Geoff Levand, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20260712151300.3664-3-thorsten.blum@linux.dev>
Le 12/07/2026 à 17:13, Thorsten Blum a écrit :
> The local table structure is not used - remove it.
>
> Remove % in the comment while at it.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Looks like it's never been used since commit de91a5342995 ("[POWERPC]
ps3: add spu support") that introduced it.
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
I have no opinion about the %0 versus 0, is it worth the change ?
> ---
> arch/powerpc/platforms/ps3/spu.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
> index e817def7f424..c904f9fa1caa 100644
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -185,13 +185,11 @@ static void spu_unmap(struct spu *spu)
> * The current HV requires the spu shadow regs to be mapped with the
> * PTE page protection bits set as read-only.
> *
> - * Returns: %0 on success or -errno on error.
> + * Returns: 0 on success or -errno on error.
> */
>
> static int __init setup_areas(struct spu *spu)
> {
> - struct table {char* name; unsigned long addr; unsigned long size;};
> -
> spu_pdata(spu)->shadow = ioremap_prot(spu_pdata(spu)->shadow_addr,
> sizeof(struct spe_shadow),
> pgprot_noncached_wc(PAGE_KERNEL_RO));
^ permalink raw reply
page: next (older)
- 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