* Re: [PATCH v5 0/4] arm64: Work around C1-Pro erratum 4193714 (CVE-2026-0995)
From: Will Deacon @ 2026-04-10 12:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-arm-kernel, James Morse, Mark Rutland, Mark Brown
In-Reply-To: <20260407102848.2266988-1-catalin.marinas@arm.com>
On Tue, Apr 07, 2026 at 11:28:40AM +0100, Catalin Marinas wrote:
> That's version 5 of the C1-Pro workaround. Version 3 here:
>
> https://lore.kernel.org/r/20260402101246.3870036-1-catalin.marinas@arm.com
I left a nit on the final patch but, regardless, this looks good to me
so:
Reviewed-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: errata: Work around early CME DVMSync acknowledgement
From: Will Deacon @ 2026-04-10 12:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-arm-kernel, James Morse, Mark Rutland, Mark Brown
In-Reply-To: <20260407102848.2266988-5-catalin.marinas@arm.com>
On Tue, Apr 07, 2026 at 11:28:44AM +0100, Catalin Marinas wrote:
> C1-Pro acknowledges DVMSync messages before completing the SME/CME
> memory accesses. Work around this by issuing an IPI to the affected CPUs
> if they are running in EL0 with SME enabled.
>
> Note that we avoid the local DSB in the IPI handler as the kernel runs
> with SCTLR_EL1.IESB=1. This is sufficient to complete SME memory
> accesses at EL0 on taking an exception to EL1. On the return to user
> path, no barrier is necessary either. See the comment in
> sme_set_active() and the more detailed explanation in the link below.
>
> To avoid a potential IPI flood from malicious applications (e.g.
> madvise(MADV_PAGEOUT) in a tight loop), track where a process is active
> via mm_cpumask() and only interrupt those CPUs.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Link: https://lore.kernel.org/r/ablEXwhfKyJW1i7l@J2N7QTR9R3
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Mark Brown <broonie@kernel.org>
> ---
> Documentation/arch/arm64/silicon-errata.rst | 2 +
> arch/arm64/Kconfig | 12 ++++
> arch/arm64/include/asm/cpucaps.h | 2 +
> arch/arm64/include/asm/fpsimd.h | 21 ++++++
> arch/arm64/include/asm/tlbbatch.h | 10 ++-
> arch/arm64/include/asm/tlbflush.h | 72 ++++++++++++++++++-
> arch/arm64/kernel/cpu_errata.c | 30 ++++++++
> arch/arm64/kernel/entry-common.c | 3 +
> arch/arm64/kernel/fpsimd.c | 79 +++++++++++++++++++++
> arch/arm64/kernel/process.c | 36 ++++++++++
> arch/arm64/tools/cpucaps | 1 +
> 11 files changed, 264 insertions(+), 4 deletions(-)
[...]
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 489554931231..4c328b7c79ba 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -26,6 +26,7 @@
> #include <linux/reboot.h>
> #include <linux/interrupt.h>
> #include <linux/init.h>
> +#include <linux/cpumask.h>
> #include <linux/cpu.h>
> #include <linux/elfcore.h>
> #include <linux/pm.h>
> @@ -339,8 +340,41 @@ void flush_thread(void)
> flush_gcs();
> }
>
> +#ifdef CONFIG_ARM64_ERRATUM_4193714
> +
> +static void arch_dup_tlbbatch_mask(struct task_struct *dst)
> +{
> + /*
> + * Clear the inherited cpumask with memset() to cover both cases where
> + * cpumask_var_t is a pointer or an array. It will be allocated lazily
> + * in sme_dvmsync_add_pending() if CPUMASK_OFFSTACK=y.
> + */
> + if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714))
> + memset(&dst->tlb_ubc.arch.cpumask, 0,
> + sizeof(dst->tlb_ubc.arch.cpumask));
nit: use cpumask_clear() instead?
Will
^ permalink raw reply
* Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Robin Murphy @ 2026-04-10 12:07 UTC (permalink / raw)
To: Peng Fan
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mark Rutland, linux-arm-kernel, iommu, devicetree,
linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <adZcaEKm3vIYSy3N@shlinux89>
On 08/04/2026 2:47 pm, Peng Fan wrote:
> On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>> On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>>> This patch series adds proper support for describing and probing the
>>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>>>
>>> The SMMU v3 architecture allows an optional PMCG block, typically
>>> associated with TCUs, to be implemented within the SMMU register
>>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>>> TCU page 0.
>>
>> But what's wrong with the existing binding? Especially given that it even has
>> an upstream user already:
>>
>> https://git.kernel.org/torvalds/c/aef9703dcbf8
>>
>>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>>> referencing the existing arm,smmu-v3-pmcg binding.
>>>
>>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>>> child nodes described in DT once the SMMU probe succeeds.
>>>
>>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>>> of the parent SMMU MMIO window, which is already requested by the SMMU
>>
>> That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>> reserve implementation defined register space") nearly 6 years ago, where the
>> whole purpose was to support Arm's PMCG implementation properly. What kernel
>> is this based on?
>
> Seems I am wrong. I thought PMCG is in page 0, so there were resource
> conflicts. I just retest without this patchset, all goes well.
>
> But from dt perspective, should the TCU PMCG node be child node of
> SMMU node?
No. PMCGs can be used entirely independently of the SMMU itself, and
while most of the events do relate to SMMU translation and thus aren't
necessarily meaningful if it's not in use, there are still some which
can be useful for basic traffic counting, monitoring GPT/translation
activity from _other_ security states (if observation is delegated to
Non-Secure) and possibly other things, even if the "main" Non-Secure
SMMU interface isn't advertised at all. It would be unreasonable to
require the SMMU node to be present and enabled *and* have a driver to
populate PMCGs, to monitor events which are outside the scope of that
driver.
Thanks,
Robin.
^ permalink raw reply
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Usama Arif @ 2026-04-10 12:05 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack, ajd,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, ziy, hannes, kas,
shakeel.butt, leitao, kernel-team
In-Reply-To: <adjkCOiLgZ_-zovg@lucifer>
On 10/04/2026 12:55, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
>>
>>
>> On 02/04/2026 19:08, Usama Arif wrote:
>>> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
>>> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
>>> to HPAGE_PMD_SIZE limited to 2M (Rui)
>>> - Reviewed-by tags for patch 1 from Kiryl and Jan
>>> - Remove preferred_exec_order() (Jan)
>>> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
>>> otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
>>> do_sync_mmap_readahead().
>>> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
>>> page size for arm64.
>>> - remove bprm->file NULL check (Matthew)
>>> - Change filp to file (Matthew)
>>> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
>>>
>>
>> Hello!
>>
>> Just wanted to check if there was any feedback/review on the latest
>> revision?
>
> It's -rc7, this is definitely something for next cycle :)
>
Yeah no worries! Just wanted to check what people thought about it!
> On my part, my upstream bandwidth has drastically reduced, and review is
> probably going to have to be a hobbyist thing at least for now.
>
> Also, not to be mean but:
>
> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> 21
>
> So... :)
>
> Review in mm is very lop-sided, let's try to balance it out a bit!
>
Ah yeah actually I have been reviewing a lot over the last few months.
I dont ack patches that have already been acked-by/reviewed-by maintainers.
as I am not sure if it adds anything. I never really cared about Reviewed/Acked
by/patch count but I can start adding tags if it helps in stats.
The reviews I have done over the last week alone:
https://lore.kernel.org/all/20260408122307.1360475-1-usama.arif@linux.dev/
https://lore.kernel.org/all/20260408123700.1596800-1-usama.arif@linux.dev/
https://lore.kernel.org/all/20260409142256.131676-1-usama.arif@linux.dev/
https://lore.kernel.org/all/20260410114809.3592720-1-usama.arif@linux.dev/
https://lore.kernel.org/all/20260410112433.3248586-1-usama.arif@linux.dev/
https://lore.kernel.org/all/20260331103451.1070175-1-usama.arif@linux.dev/T/#t
https://lore.kernel.org/all/20260401152343.3294686-1-usama.arif@linux.dev/
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-04-10 12:05 UTC (permalink / raw)
To: Tian, Kevin
Cc: Nicolin Chen, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, miko.lenczewski@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Williams, Dan J, jonathan.cameron@huawei.com, Vikram Sethi,
linux-cxl@vger.kernel.org
In-Reply-To: <BL1PR11MB527184E183703E14F6C861118C592@BL1PR11MB5271.namprd11.prod.outlook.com>
On Fri, Apr 10, 2026 at 03:13:59AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Friday, April 10, 2026 6:53 AM
> >
> > On Thu, Apr 09, 2026 at 03:45:26PM -0700, Nicolin Chen wrote:
> >
> > > One question regarding VM case: if a device is ats_always_on, while
> > > VM somehow doesn't set nested_domain->enable_ats. Should the kernel
> > > at least spit a warning, given that it would surely fail the device?
> >
> > No, just let break, the resulting failure has to be contained to the
> > VM or the platform is broken..
> >
> > The HV can't turn on ATS because we it can't know what invalidations
> > to push so not much other choice.
> >
>
> Taking about in theory - host can append a devtlb invalidation cmd
> after iotlb invalidation (if vcmdq is not used)?
It can't map an ASID to a BDF without shadowing all the STE and CD
tables which we don't do for nesting.
Jason
^ permalink raw reply
* Re: [PATCH] arm64: Kconfig: fix duplicate word in CMDLINE help text
From: Catalin Marinas @ 2026-04-10 11:58 UTC (permalink / raw)
To: Will Deacon, Michael Ugrin; +Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <20260409162413.1120-1-mugrinphoto@gmail.com>
On Thu, 09 Apr 2026 09:24:12 -0700, Michael Ugrin wrote:
> Remove duplicate 'the' in the CMDLINE config help text.
>
>
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Kconfig: fix duplicate word in CMDLINE help text
https://git.kernel.org/arm64/c/74b63934abf5
^ permalink raw reply
* Re: [PATCH] arm64: rsi: use linear-map alias for realm config buffer
From: Catalin Marinas @ 2026-04-10 11:57 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, Aneesh Kumar K.V (Arm)
Cc: Will Deacon, Suzuki K Poulose, Steven Price, Gavin Shan
In-Reply-To: <20260407152900.396431-1-aneesh.kumar@kernel.org>
On Tue, 07 Apr 2026 20:59:00 +0530, Aneesh Kumar K.V (Arm) wrote:
> rsi_get_realm_config() passes its argument to virt_to_phys(), but
> &config is a kernel image address and not a linear-map alias.
> On arm64 this triggers the below warning:
>
> virt_to_phys used for non-linear address: (____ptrval____) (config+0x0/0x1000)
> WARNING: arch/arm64/mm/physaddr.c:15 at __virt_to_phys+0x50/0x70, CPU#0: swapper/0
> Modules linked in:
> .....
> Hardware name: linux,dummy-virt (DT)
> pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : __virt_to_phys+0x50/0x70
> lr : __virt_to_phys+0x4c/0x70
> .....
> ......
> Call trace:
> __virt_to_phys+0x50/0x70 (P)
> arm64_rsi_init+0xa0/0x1b8
> setup_arch+0x13c/0x1a0
> start_kernel+0x68/0x398
> __primary_switched+0x88/0x90
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: rsi: use linear-map alias for realm config buffer
https://git.kernel.org/arm64/c/34e563947c76
I did not add a Fixes tag, it's just a debug warning, otherwise it
functions correctly.
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Lorenzo Stoakes @ 2026-04-10 11:57 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack, ajd,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, ziy, hannes, kas,
shakeel.butt, leitao, kernel-team
In-Reply-To: <adjkCOiLgZ_-zovg@lucifer>
On Fri, Apr 10, 2026 at 12:55:42PM +0100, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
> >
> >
> > On 02/04/2026 19:08, Usama Arif wrote:
> > > v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> > > - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> > > to HPAGE_PMD_SIZE limited to 2M (Rui)
> > > - Reviewed-by tags for patch 1 from Kiryl and Jan
> > > - Remove preferred_exec_order() (Jan)
> > > - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> > > otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> > > do_sync_mmap_readahead().
> > > - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> > > page size for arm64.
> > > - remove bprm->file NULL check (Matthew)
> > > - Change filp to file (Matthew)
> > > - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> > >
> >
> > Hello!
> >
> > Just wanted to check if there was any feedback/review on the latest
> > revision?
>
> It's -rc7, this is definitely something for next cycle :)
>
> On my part, my upstream bandwidth has drastically reduced, and review is
> probably going to have to be a hobbyist thing at least for now.
>
> Also, not to be mean but:
>
> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> 21
>
> So... :)
>
> Review in mm is very lop-sided, let's try to balance it out a bit!
>
> >
> > Thanks!
> >
>
> Thanks, Lorenzo
(Note that we're in a 'quiet period' from here until -rc1 of next cycle and
won't be taking anything new until then. We plan to do this from around rc5 or
rc6 of each cycle in future).
^ permalink raw reply
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Lorenzo Stoakes @ 2026-04-10 11:55 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack, ajd,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, ziy, hannes, kas,
shakeel.butt, leitao, kernel-team
In-Reply-To: <803a0c15-0a6a-4c00-b6b3-eaae56d5fc15@linux.dev>
On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
>
>
> On 02/04/2026 19:08, Usama Arif wrote:
> > v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> > - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> > to HPAGE_PMD_SIZE limited to 2M (Rui)
> > - Reviewed-by tags for patch 1 from Kiryl and Jan
> > - Remove preferred_exec_order() (Jan)
> > - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> > otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> > do_sync_mmap_readahead().
> > - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> > page size for arm64.
> > - remove bprm->file NULL check (Matthew)
> > - Change filp to file (Matthew)
> > - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> >
>
> Hello!
>
> Just wanted to check if there was any feedback/review on the latest
> revision?
It's -rc7, this is definitely something for next cycle :)
On my part, my upstream bandwidth has drastically reduced, and review is
probably going to have to be a hobbyist thing at least for now.
Also, not to be mean but:
$ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
21
So... :)
Review in mm is very lop-sided, let's try to balance it out a bit!
>
> Thanks!
>
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks
From: Lorenzo Bianconi @ 2026-04-10 11:52 UTC (permalink / raw)
To: Benjamin Larsson
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <bd486b55-a8d7-4811-965a-aa1f3dc98e30@genexis.eu>
[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]
> On 10/04/2026 04:57, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email says "For your consideration."
> > ---
> > net: airoha: Introduce WAN device flag
> >
> > This commit introduces a WAN flag to specify whether a device is used to
> > transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
> > devices but limits the configuration to a single WAN device.
> >
>
> [...]
>
> > > + fallthrough;
> > > + }
> > > + case AIROHA_GDM2_IDX:
> > > + /* GDM2 is always used as wan */
> > > + dev->flags |= PRIV_FLAG_WAN;
> > > break;
> > > default:
> > > break;
> > > }
> > > - for (i = 0; i < eth->soc->num_ppe; i++)
> > > - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
> > > + airoha_dev_set_qdma(dev);
> > > + airoha_set_macaddr(dev, netdev->dev_addr);
> >
> > Since the commit message notes it is possible to specify multiple LAN
> > devices, does unconditionally calling airoha_set_macaddr() for each
> > device overwrite the single shared hardware LAN MAC register?
> >
> > If so, could this cause only the last initialized LAN device to have its MAC
> > correctly programmed into the hardware, leading to dropped unicast
> > packets for the other LAN interfaces?
> >
> > > +
> > > + if (!airoha_is_lan_gdm_dev(dev) &&
> > > + (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
> > > + int err;
> >
> > [ ... ]
>
> Hi, the frame engine can be configured with a range of wan mac addresses and
> a range of lan mac addresses via registers that set the top 24 bits and then
> 2 registers that form a range of the low 24 bits.
>
> Documentation says that packets that fall into this mac address range either
> on the lan side or the wan side are to be treated as layer 3 packages and if
> a packet is not then it will be handled as a layer 2 packet.
>
> The exact implication of this and if it actually matters is unknown. But
> traffic that comes in on an interface that is not matched by an acceleration
> flow is usually forwarded to the cpu for further processing.
The assumption here is the mac addresses are read from the SNAND or eMMC and
they all share the upper bits. I will fix the issue with a separated patch for
net tree.
Regards,
Lorenzo
>
> MvH
> Benjamin Larsson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks
From: Lorenzo Bianconi @ 2026-04-10 11:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025722.1809973-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Introduce WAN device flag
>
> This commit introduces a WAN flag to specify whether a device is used to
> transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
> devices but limits the configuration to a single WAN device.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index 5b0cd37b155e4..9988011dca53f 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> > @@ -1796,36 +1796,77 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
>
> [ ... ]
>
> > +static int airoha_dev_init(struct net_device *netdev)
> > +{
> > + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > + struct airoha_gdm_port *port = dev->port;
> >
> > switch (port->id) {
> > case AIROHA_GDM3_IDX:
> > - case AIROHA_GDM4_IDX:
> > - /* If GDM2 is active we can't enable loopback */
> > - if (!eth->ports[1]) {
> > - int err;
> > + case AIROHA_GDM4_IDX: {
> > + struct airoha_eth *eth = dev->eth;
> >
> > - err = airoha_set_gdm2_loopback(dev);
> > - if (err)
> > - return err;
> > - }
> > + if (eth->ports[1] || airoha_get_wan_gdm_dev(eth))
> > + break;
>
> If a board's Device Tree enables both GDM3 and GDM4, and GDM2 is not present,
> does this sequence permanently assign the WAN role to GDM3 since it is
> initialized first? Is there a Device Tree property or fallback configuration
> mechanism to allow users to specify GDM4 as the WAN port instead?
This issue will be fixed with following series that allows to dynamically
select LAN or WAN configuration at runtime.
>
> > + fallthrough;
> > + }
> > + case AIROHA_GDM2_IDX:
> > + /* GDM2 is always used as wan */
> > + dev->flags |= PRIV_FLAG_WAN;
> > break;
> > default:
> > break;
> > }
> >
> > - for (i = 0; i < eth->soc->num_ppe; i++)
> > - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
> > + airoha_dev_set_qdma(dev);
> > + airoha_set_macaddr(dev, netdev->dev_addr);
>
> Since the commit message notes it is possible to specify multiple LAN
> devices, does unconditionally calling airoha_set_macaddr() for each
> device overwrite the single shared hardware LAN MAC register?
>
> If so, could this cause only the last initialized LAN device to have its MAC
> correctly programmed into the hardware, leading to dropped unicast
> packets for the other LAN interfaces?
>
> > +
> > + if (!airoha_is_lan_gdm_dev(dev) &&
> > + (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
> > + int err;
>
> [ ... ]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [RFC PATCH] test: mm/arm: pgtable: remove young bit check for pte_valid_user
From: Brian Ruley @ 2026-04-10 11:43 UTC (permalink / raw)
To: Russell King
Cc: Russell King, Will Deacon, Steve Capper, linux-arm-kernel,
linux-kernel, Brian Ruley
In-Reply-To: <adjcc7QvquXI3G0Q@shell.armlinux.org.uk>
Instrumentation to print recently migrated pages in undefined
instruction handler. This was used to determine if the faulting address
was migrated earlier.
Signed-off-by: Brian Ruley <brian.ruley@gehealthcare.com>
---
Not intended for integration. This is just to share the testing details.
---
arch/arm/kernel/traps.c | 5 ++++
mm/migrate.c | 53 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index afbd2ebe5c39..64ef872f1555 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -28,6 +28,8 @@
#include <linux/irq.h>
#include <linux/vmalloc.h>
+void migrate_exec_log_dump(unsigned long fault_addr);
+
#include <linux/atomic.h>
#include <asm/cacheflush.h>
#include <asm/exception.h>
@@ -490,6 +492,9 @@ asmlinkage void do_undefinstr(struct pt_regs *regs)
dump_instr(KERN_INFO, regs);
}
#endif
+ if (user_mode(regs))
+ migrate_exec_log_dump((unsigned long)pc);
+
arm_notify_die("Oops - undefined instruction", regs,
SIGILL, ILL_ILLOPC, pc, 0, 6);
}
diff --git a/mm/migrate.c b/mm/migrate.c
index 2c3d489ecf51..987d0376b433 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -48,6 +48,54 @@
#include <trace/events/migrate.h>
+
+/* Debug: track recent exec page migrations */
+#define MIGRATE_EXEC_LOG_SIZE 8
+struct migrate_exec_entry {
+ unsigned long addr;
+ unsigned long old_pfn;
+ unsigned long new_pfn;
+ unsigned int pid;
+ bool flushed;
+};
+static DEFINE_PER_CPU(struct migrate_exec_entry[MIGRATE_EXEC_LOG_SIZE], migrate_exec_log);
+static DEFINE_PER_CPU(unsigned int, migrate_exec_idx);
+
+void migrate_exec_log_add(unsigned long addr, unsigned long old_pfn,
+ unsigned long new_pfn, bool flushed)
+{
+ unsigned int idx = __this_cpu_read(migrate_exec_idx);
+ struct migrate_exec_entry *log = this_cpu_ptr(migrate_exec_log);
+ struct migrate_exec_entry *e = &log[idx];
+
+ e->addr = addr;
+ e->old_pfn = old_pfn;
+ e->new_pfn = new_pfn;
+ e->pid = current->pid;
+ e->flushed = flushed;
+ __this_cpu_write(migrate_exec_idx, (idx + 1) % MIGRATE_EXEC_LOG_SIZE);
+}
+
+void migrate_exec_log_dump(unsigned long fault_addr)
+{
+ int cpu;
+
+ pr_err("SIGILL at %lx pid %d, recent exec migrations:\n",
+ fault_addr, current->pid);
+ for_each_online_cpu(cpu) {
+ struct migrate_exec_entry *log = per_cpu(migrate_exec_log, cpu);
+ int i;
+ for (i = 0; i < MIGRATE_EXEC_LOG_SIZE; i++) {
+ if (log[i].addr == 0)
+ continue;
+ pr_err(" cpu%d: addr=%lx old_pfn=%lx new_pfn=%lx pid=%d flushed=%d%s\n",
+ cpu, log[i].addr, log[i].old_pfn, log[i].new_pfn,
+ log[i].pid, log[i].flushed,
+ (PAGE_ALIGN(fault_addr) == PAGE_ALIGN(log[i].addr)) ?
+ " *** MATCH ***" : "");
+ }
+ }
+}
#include "internal.h"
#include "swap.h"
@@ -434,6 +482,11 @@ static bool remove_migration_pte(struct folio *folio,
else
folio_add_file_rmap_pte(folio, new, vma);
set_pte_at(vma->vm_mm, pvmw.address, pvmw.pte, pte);
+
+ if (vma->vm_flags & VM_EXEC)
+ migrate_exec_log_add(pvmw.address,
+ swp_offset(entry), page_to_pfn(new),
+ pte_young(pte));
}
if (READ_ONCE(vma->vm_flags) & VM_LOCKED)
mlock_drain_local();
--
2.47.3
^ permalink raw reply related
* Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks
From: Benjamin Larsson @ 2026-04-10 11:29 UTC (permalink / raw)
To: Jakub Kicinski, lorenzo
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, linux-arm-kernel, linux-mediatek, netdev, devicetree
In-Reply-To: <20260410025722.1809973-1-kuba@kernel.org>
On 10/04/2026 04:57, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Introduce WAN device flag
>
> This commit introduces a WAN flag to specify whether a device is used to
> transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
> devices but limits the configuration to a single WAN device.
>
[...]
>> + fallthrough;
>> + }
>> + case AIROHA_GDM2_IDX:
>> + /* GDM2 is always used as wan */
>> + dev->flags |= PRIV_FLAG_WAN;
>> break;
>> default:
>> break;
>> }
>>
>> - for (i = 0; i < eth->soc->num_ppe; i++)
>> - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
>> + airoha_dev_set_qdma(dev);
>> + airoha_set_macaddr(dev, netdev->dev_addr);
>
> Since the commit message notes it is possible to specify multiple LAN
> devices, does unconditionally calling airoha_set_macaddr() for each
> device overwrite the single shared hardware LAN MAC register?
>
> If so, could this cause only the last initialized LAN device to have its MAC
> correctly programmed into the hardware, leading to dropped unicast
> packets for the other LAN interfaces?
>
>> +
>> + if (!airoha_is_lan_gdm_dev(dev) &&
>> + (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
>> + int err;
>
> [ ... ]
Hi, the frame engine can be configured with a range of wan mac addresses
and a range of lan mac addresses via registers that set the top 24 bits
and then 2 registers that form a range of the low 24 bits.
Documentation says that packets that fall into this mac address range
either on the lan side or the wan side are to be treated as layer 3
packages and if a packet is not then it will be handled as a layer 2 packet.
The exact implication of this and if it actually matters is unknown. But
traffic that comes in on an interface that is not matched by an
acceleration flow is usually forwarded to the cpu for further processing.
MvH
Benjamin Larsson
^ permalink raw reply
* Aw: Re: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Frank Wunderlich @ 2026-04-10 11:23 UTC (permalink / raw)
To: brgl
Cc: bartosz.golaszewski, linux, sean.wang, linusw, matthias.bgg,
angelogioacchino.delregno, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <CAMRc=Md1pC_a8zSQqWWcubNG-1ret8Lf9sajVDnU8nw2gnXZiA@mail.gmail.com>
> > > Reported-by: Frank Wunderlich <linux@fw-web.de>
> >
> > please use the email i used for SoB in my linked patch (closes link below), the other email i use only for sending patches due to mail provider limitation.
> >
>
> Linus: Can you fix this when applying, please?
>
> Frank: Can you also leave your Tested-by under the patch?
if my testcase is enough (just accessing /sys/kernel/debug/gpio via cat)
Tested-By: Frank Wunderlich <frank-w@public-files.de>
> Thanks,
> Bartosz
^ permalink raw reply
* Re: [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user
From: Russell King (Oracle) @ 2026-04-10 11:18 UTC (permalink / raw)
To: Brian Ruley; +Cc: Will Deacon, Steve Capper, linux-arm-kernel, linux-kernel
In-Reply-To: <adjYlUk8_JjPivNi@zoo11.fihel.lab.ge-healthcare.net>
On Fri, Apr 10, 2026 at 02:01:41PM +0300, Brian Ruley wrote:
> Thank you for the clarification, this is very educational for me.
> I understand your scepticism, and I can't explain what's going on based
> on what you replied. However, I do honestly believe there is a problem
> here. I'll share the exact testing details and the instrumentation
> we added that convinced us to reach out at the end. One idea we also
> had was that could cache aliasing be happening here.
>
> To clarify any potential misunderstanding, we've observed the
> following:
>
> - Sporadic SIGILL and SIGSEGV under memory pressure
> - Scales with core count, i.e., quad core more likely to reproduce
> than dual core. We haven't observed an issue on single core.
> - Coredumps show valid instructions at the faulting PC.
> The CPU executed something different from what's in memory.
> This pointed us to stale I-cache.
> - Instrumentation indicates a correlation.
> A per-CPU ring buffer tracking exec page migrations was dumped on
> SIGILL. The faulting PC matched a recently migrated pages.
> - We started seeing this after upgrade 6.1->6.12->6.18. We bisected
> two commits which had an impact, but we weren't convinced that
> either was the root cause: 5dfab109d5193e6c224d96cabf90e9cc2c039884
> and 6faea3422e3b4e8de44a55aa3e6e843320da66d2.
> - Failed processes include systemd, tar, bash, ...
> - Debug options, e.g., page poisoning, seems to hide the bug
>
>
> > So you're saying that stress-ng doesn't reproduce this bug but
> triggers the OOM-killer... confused.
>
> Apologies for the confusion. I meant that with `stress-ng' we created
> the memory pressure and OOM might have played a role in exposing the
> "bug" as we (at the time) believed that anything that would trigger
> memory free/reclaims and page migration was the key. One note I'll add
> is that in our test we invoked stress-ng for 2 minutes (--timeout 2m)
> and after each we would reboot the device. We had observed that reboots
> seemed to have a discernible effect on the occurence in earlier testing
> so we kept that in. I'm beginning to doubt if it had an effect now,
> and unfortunately it's all anecdotal.
>
> One more thing, even if you don't accept the patch, is this patch
> harmful in any way or is it just sub-optimal?
>
> I'll send the instrumentation patch as a follow-up, migh be there's a
> flaw in it.
I'll try it - I have Cortex A9 systems (some which I rely on...)
Please can you also try to track the history of what happens for
the PTEs corresponding to the old and new PFN?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses
From: Catalin Marinas @ 2026-04-10 11:06 UTC (permalink / raw)
To: Kameron Carr
Cc: will, suzuki.poulose, steven.price, ryan.roberts, dev.jain, yang,
shijie, kevin.brodsky, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406213317.216171-1-kameroncarr@linux.microsoft.com>
On Mon, Apr 06, 2026 at 02:33:17PM -0700, Kameron Carr wrote:
> Currently __set_memory_enc_dec() only handles linear map (lm) addresses
> and returns -EINVAL for anything else. This means callers using
> vmalloc'd buffers cannot mark memory as shared/protected with the RMM
> via set_memory_decrypted()/set_memory_encrypted().
>
> Extend the implementation to handle vmalloc (non-linear-map) addresses
> by introducing __set_va_addr_enc_dec(). For vmalloc addresses, the page
> table entries are not contiguous in the physical address space, so the
> function walks the vm_area's pages array and issues per-page RSI calls
> to transition each page between shared and protected states.
>
> The original linear-map path is factored out into __set_lm_addr_enc_dec(),
> and __set_memory_enc_dec() now dispatches to the appropriate helper based
> on whether the address is a linear map address.
Could you give more details about the user of set_memory_decrypted() on
vmalloc()'ed addresses? I think this came up in the past and I wondered
whether something like GFP_DECRYPTED would be simpler to implement (even
posted a hack but without vmalloc() support). If it is known upfront
that the memory will be decrypted, it's easier/cheaper to do this on the
page allocation time to change the linear map and just use
pgprot_decrypted() for vmap(). No need to rewrite the page table after
mapping the pages.
--
Catalin
^ permalink raw reply
* [PATCH] perf arm-spe: Don't warn about the discard bit if it doesn't exist
From: James Clark @ 2026-04-10 11:05 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark
Opening an SPE event shows a warning that doesn't concern the user:
$ perf record -e arm_spe
Unknown/empty format name: discard
Perf only wants to know if the discard bit is set for configuring the
event, not in response to anything the user has done. Fix it by adding
another helper that returns if a config bit exists without warning.
We should probably keep the warning in evsel__get_config_val() to avoid
having every caller having to do it, and most format bits should never
be missing.
Add a test for the new helper. Rename the parent test function to be
more generic rather than adding a new one as it requires a lot of
boilerplate.
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
tools/perf/tests/pmu.c | 11 +++++++++--
tools/perf/util/evsel.c | 6 ++++++
tools/perf/util/evsel.h | 1 +
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index f00d72d087fc..91bb28cad79a 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -428,7 +428,8 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
evlist__for_each_entry_safe(evlist, tmp, evsel) {
if (evsel__is_aux_event(evsel)) {
arm_spe_setup_evsel(evsel, cpus);
- if (!evsel__get_config_val(evsel, "discard", &discard_bit))
+ if (evsel__config_exists(evsel, "discard") &&
+ !evsel__get_config_val(evsel, "discard", &discard_bit))
discard = !!discard_bit;
}
}
diff --git a/tools/perf/tests/pmu.c b/tools/perf/tests/pmu.c
index 0ebf2d7b2cb4..d7be9d1c6f52 100644
--- a/tools/perf/tests/pmu.c
+++ b/tools/perf/tests/pmu.c
@@ -201,7 +201,8 @@ static int test__pmu_format(struct test_suite *test __maybe_unused, int subtest
return ret;
}
-static int test__pmu_usr_chgs(struct test_suite *test __maybe_unused, int subtest __maybe_unused)
+static int test__pmu_config_helpers(struct test_suite *test __maybe_unused,
+ int subtest __maybe_unused)
{
const char *event = "perf-pmu-test/config=15,config1=4,krava02=170,"
"krava03=1,krava11=27,krava12=1/";
@@ -236,6 +237,12 @@ static int test__pmu_usr_chgs(struct test_suite *test __maybe_unused, int subtes
}
evsel = evlist__first(evlist);
+ /* Test evsel__config_exists() */
+ TEST_ASSERT_EQUAL("krava01 should exist",
+ evsel__config_exists(evsel, "krava01"), true);
+ TEST_ASSERT_EQUAL("krava99 should not exist",
+ evsel__config_exists(evsel, "krava99"), false);
+
/*
* Set via config=15, krava01 bits 0-1
* Set via config1=4, krava11 bit 1
@@ -629,7 +636,7 @@ static struct test_case tests__pmu[] = {
TEST_CASE("PMU name combining", name_len),
TEST_CASE("PMU name comparison", name_cmp),
TEST_CASE("PMU cmdline match", pmu_match),
- TEST_CASE("PMU user config changes", pmu_usr_chgs),
+ TEST_CASE("PMU config helpers", pmu_config_helpers),
{ .name = NULL, }
};
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 2ee87fd84d3e..685c4118aef3 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1396,6 +1396,12 @@ void evsel__set_config_if_unset(struct evsel *evsel, const char *config_name,
perf_pmu__format_pack(format->bits, val, vp, /*zero=*/true);
}
+bool evsel__config_exists(const struct evsel *evsel, const char *config_name)
+{
+ struct perf_pmu_format *format = pmu_find_format(&evsel->pmu->format, config_name);
+
+ return format && !bitmap_empty(format->bits, PERF_PMU_FORMAT_BITS);
+}
int evsel__get_config_val(const struct evsel *evsel, const char *config_name,
u64 *val)
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 339b5c08a33d..a255ae2b1f8e 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -578,6 +578,7 @@ void evsel__uniquify_counter(struct evsel *counter);
((((src) >> (pos)) & ((1ull << (size)) - 1)) << (63 - ((pos) + (size) - 1)))
u64 evsel__bitfield_swap_branch_flags(u64 value);
+bool evsel__config_exists(const struct evsel *evsel, const char *config_name);
int evsel__get_config_val(const struct evsel *evsel, const char *config_name,
u64 *val);
void evsel__set_config_if_unset(struct evsel *evsel, const char *config_name,
---
base-commit: 4cf1f549bbcdfea9c20df52994bb342677472dcd
change-id: 20260410-james-spe-discard-warning-049b27a53aac
Best regards,
--
James Clark <james.clark@linaro.org>
^ permalink raw reply related
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Usama Arif @ 2026-04-10 11:03 UTC (permalink / raw)
To: Andrew Morton, david, willy, ryan.roberts, linux-mm
Cc: r, jack, ajd, apopple, baohua, baolin.wang, brauner,
catalin.marinas, dev.jain, kees, kevin.brodsky, lance.yang,
Liam.Howlett, linux-arm-kernel, linux-fsdevel, linux-kernel,
Lorenzo Stoakes, mhocko, npache, pasha.tatashin, rmclure, rppt,
surenb, vbabka, Al Viro, ziy, hannes, kas, shakeel.butt, leitao,
kernel-team
In-Reply-To: <20260402181326.3107102-1-usama.arif@linux.dev>
On 02/04/2026 19:08, Usama Arif wrote:
> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> to HPAGE_PMD_SIZE limited to 2M (Rui)
> - Reviewed-by tags for patch 1 from Kiryl and Jan
> - Remove preferred_exec_order() (Jan)
> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> do_sync_mmap_readahead().
> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> page size for arm64.
> - remove bprm->file NULL check (Matthew)
> - Change filp to file (Matthew)
> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
>
Hello!
Just wanted to check if there was any feedback/review on the latest
revision?
Thanks!
^ permalink raw reply
* Re: [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user
From: Brian Ruley @ 2026-04-10 11:01 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Will Deacon, Steve Capper, linux-arm-kernel, linux-kernel
In-Reply-To: <adfNN33QIOP3VfDm@shell.armlinux.org.uk>
On Apr 09, Russell King (Oracle) wrote:
>
> On Thu, Apr 09, 2026 at 06:17:36PM +0300, Brian Ruley wrote:
> > However, in the case I describe, if VA_B is mapped immediately to pfn_q
> > after it been has unmapped and freed for VA_A, then it's quite possible
> > that the page is still indexed in the cache.
>
> True.
>
> > The hypothesis is that if
> > VA_A and VA_B land in the same I-cache set and VA_A old cache entry
> > still exists (tagged with pfn_q), then the CPU can fetch stale
> > instructions because the tag will match. That's one reason why we need
> > to invalidate the cache, but that will be skipped in the path:
> >
> > migrate_pages
> > migrate_pages_batch
> > migrate_folio_move
> > remove_migration_ptes
> > remove_migration_pte
> > set_pte_at
> > set_ptes
> > __sync_icache_dcache (skipped if !young)
> > set_pte_ext
>
> In this case, if the old PTE was marked !young, then the new PTE will
> have:
> pte = pte_mkold(pte);
>
> on it, which marks it !young. As you say, __sync_icache_dcache() will
> be skipped. While a PTE entry will be set for the kernel, the code in
> set_pte_ext() will *not* establish a hardware PTE entry. For the
> 2-level pte code:
>
> tst r1, #L_PTE_YOUNG @ <- results in Z being set
> tstne r1, #L_PTE_VALID @ <- not executed
> eorne r1, r1, #L_PTE_NONE @ <- not executed
> tstne r1, #L_PTE_NONE @ <- not executed
> moveq r3, #0 @ <- hardware PTE value
> ARM( str r3, [r0, #2048]! ) @ <- writes hardware PTE
>
> So, for a !young PTE, the hardware PTE entry is written as zero,
> which means accesses should fault, which will then cause the PTE to
> be marked young.
>
> For the 3-level case, the L_PTE_YOUNG bit corresponds with the AF bit
> in the PTE, and there aren't split Linux / hardware PTE entries. AF
> being clear should result in a page fault being generated for the
> kernel to handle making the PTE young.
>
> In both of these cases, set_ptes() will need to be called with the
> updated PTE which will now be marked young, and that will result in
> the I-cache being flushed.
Hi Russell,
Thank you for the clarification, this is very educational for me.
I understand your scepticism, and I can't explain what's going on based
on what you replied. However, I do honestly believe there is a problem
here. I'll share the exact testing details and the instrumentation
we added that convinced us to reach out at the end. One idea we also
had was that could cache aliasing be happening here.
To clarify any potential misunderstanding, we've observed the
following:
- Sporadic SIGILL and SIGSEGV under memory pressure
- Scales with core count, i.e., quad core more likely to reproduce
than dual core. We haven't observed an issue on single core.
- Coredumps show valid instructions at the faulting PC.
The CPU executed something different from what's in memory.
This pointed us to stale I-cache.
- Instrumentation indicates a correlation.
A per-CPU ring buffer tracking exec page migrations was dumped on
SIGILL. The faulting PC matched a recently migrated pages.
- We started seeing this after upgrade 6.1->6.12->6.18. We bisected
two commits which had an impact, but we weren't convinced that
either was the root cause: 5dfab109d5193e6c224d96cabf90e9cc2c039884
and 6faea3422e3b4e8de44a55aa3e6e843320da66d2.
- Failed processes include systemd, tar, bash, ...
- Debug options, e.g., page poisoning, seems to hide the bug
> So you're saying that stress-ng doesn't reproduce this bug but
triggers the OOM-killer... confused.
Apologies for the confusion. I meant that with `stress-ng' we created
the memory pressure and OOM might have played a role in exposing the
"bug" as we (at the time) believed that anything that would trigger
memory free/reclaims and page migration was the key. One note I'll add
is that in our test we invoked stress-ng for 2 minutes (--timeout 2m)
and after each we would reboot the device. We had observed that reboots
seemed to have a discernible effect on the occurence in earlier testing
so we kept that in. I'm beginning to doubt if it had an effect now,
and unfortunately it's all anecdotal.
One more thing, even if you don't accept the patch, is this patch
harmful in any way or is it just sub-optimal?
I'll send the instrumentation patch as a follow-up, migh be there's a
flaw in it.
Best regards,
Brian
###TESTING###
1. stress-ng --vm 4 --vm-bytes 2G --vm-method zero-one --verify \
--timeout 2m
2. reboot
3. repeat
Cleaned up logs of instrumentation:
```
kernel: [ 104.610248] SIGILL at b6e6f1c0 pid 896, recent exec migrations:
kernel: [ 104.610313] cpu0: addr=b6e6f000 old_pfn=467d3 new_pfn=577fe pid=34 flushed=0
[...]
kernel: [ 456.066661] SIGILL at b6d99f40 pid 455, recent exec migrations:
[...]
kernel: [ 456.066963] cpu0: addr=b6d99000 old_pfn=44270 new_pfn=7c9ea pid=34 flushed=0
[...]
```
^ permalink raw reply
* Re: [PATCH v1 1/7] dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
From: Krzysztof Kozlowski @ 2026-04-10 10:56 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-2-francesco@dolcini.it>
On Thu, Apr 09, 2026 at 11:58:47AM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> Add Toradex Verdin Zinnia carrier board mated with Verdin
> iMX8M Plus, Verdin iMX8M Mini and Verdin iMX95.
>
> Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 10:47 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adjQl37-6a--_y3Y@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
Hello Andrea,
On Fri, Apr 10, 2026 at 12:27:35PM +0200, Andrea della Porta wrote:
> On 08:27 Fri 10 Apr , Uwe Kleine-König wrote:
> > On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> > > On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > > > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > > > +{
> > > > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > > > + u32 value;
> > > > > +
> > > > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > > + value &= ~PWM_MODE_MASK;
> > > > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > > +
> > > > > + rp1_pwm_apply_config(chip, pwm);
> > > >
> > > > What is the purpose of this call?
> > >
> > > To update the configuration on the next PWM strobe in order to avoid
> > > glitches. I'll add a short comment in the code.
> >
> > .pwm_free() should not touch the hardware configuration. Changing the
> > pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
> > somewhat a grey area. If that saves energy, that's okish. Otherwise
> > not interfering with the operation of the PWM (e.g. to keep a display on
> > during kexec or so) is preferred.
>
> Sorry I should've been more clear on this. The pinmux/conf is not changed
> at all by this mask, only the PWM output mode is. The controller can output
> several type of waveforms and clearing PWM_MODE_MASK is just setting the
> controller to output a 0, which is the reset default i.e. the same value
> as just before exporting the channel.
> I guess this is the expected behaviour in case of a fan, it should stop
> spinning in case you unexport the pwm channel, but I see it could be
> different with displays.
> Honestly I don't have a strong opinion about that, please just let me
> know if I should drop that pwm_free entirely.
Yes, in this case drop the function completely. It's the responsibility
of the consumer to stop the PWM before releasing it.
> > > > > +static int rp1_pwm_resume(struct device *dev)
> > > > > +{
> > > > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > > > +
> > > > > + return clk_prepare_enable(rp1->clk);
> > > >
> > > > Hmm, if this fails and then the driver is unbound, the clk operations
> > > > are not balanced.
> > >
> > > I'll add some flags to check if the clock is really enabled or not.
> >
> > To be honest, I guess that is a problem of several drivers, not only in
> > drivers/pwm. If this complicates the driver, I guess addressing this
> > isn't very critical.
>
> I'll come up with something, we can always drop this check if deemed
> too 'noisy'.
Great, thanks
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2 8/9] pmdomain: renesas: rcar-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
Due to the new fine grained sync_state support for onecell genpd provider
drivers, we should no longer need use the legacy behaviour. Therefore,
let's drop GENPD_FLAG_NO_STAY_ON.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/renesas/rcar-sysc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pmdomain/renesas/rcar-sysc.c b/drivers/pmdomain/renesas/rcar-sysc.c
index bd7bb9cbd9da..e4608c657629 100644
--- a/drivers/pmdomain/renesas/rcar-sysc.c
+++ b/drivers/pmdomain/renesas/rcar-sysc.c
@@ -241,7 +241,6 @@ static int __init rcar_sysc_pd_setup(struct rcar_sysc_pd *pd)
}
}
- genpd->flags |= GENPD_FLAG_NO_STAY_ON;
genpd->power_off = rcar_sysc_pd_power_off;
genpd->power_on = rcar_sysc_pd_power_on;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/9] pmdomain: core: Export a common function for ->queue_sync_state()
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
Along with of_genpd_sync_state() that genpd provider drivers may use to
manage sync_state, let's add and export of_genpd_queue_sync_state() for
those that may need it. It's expected that the genpd provider driver
assigns it's own ->queue_sync_state() callback and invoke the new helper
from there.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 14 +++++++++-----
include/linux/pm_domain.h | 2 ++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index f11dc2110737..49e60cb67b3e 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2764,7 +2764,7 @@ static void genpd_parse_for_consumer(struct device_node *sup,
}
}
-static void _genpd_queue_sync_state(struct device_node *np)
+static void genpd_queue_sync_state(struct device_node *np)
{
struct generic_pm_domain *genpd;
@@ -2782,11 +2782,14 @@ static void _genpd_queue_sync_state(struct device_node *np)
mutex_unlock(&gpd_list_lock);
}
-static void genpd_queue_sync_state(struct device *dev)
+void of_genpd_queue_sync_state(struct device *dev)
{
struct device_node *np = dev->of_node;
struct device_link *link;
+ if (!np)
+ return;
+
if (!genpd_should_wait_for_consumer(np))
return;
@@ -2810,8 +2813,9 @@ static void genpd_queue_sync_state(struct device *dev)
genpd_parse_for_consumer(np, consumer->of_node);
}
- _genpd_queue_sync_state(np);
+ genpd_queue_sync_state(np);
}
+EXPORT_SYMBOL_GPL(of_genpd_queue_sync_state);
static void genpd_sync_state(struct device *dev)
{
@@ -2922,7 +2926,7 @@ int of_genpd_add_provider_onecell(struct device_node *np,
sync_state = true;
} else if (!dev_has_sync_state(dev)) {
dev_set_drv_sync_state(dev, genpd_sync_state);
- dev_set_drv_queue_sync_state(dev, genpd_queue_sync_state);
+ dev_set_drv_queue_sync_state(dev, of_genpd_queue_sync_state);
}
put_device(dev);
@@ -3654,7 +3658,7 @@ static void genpd_provider_queue_sync_state(struct device *dev)
if (genpd->sync_state != GENPD_SYNC_STATE_ONECELL)
return;
- genpd_queue_sync_state(dev);
+ of_genpd_queue_sync_state(dev);
}
static void genpd_provider_sync_state(struct device *dev)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 7aa49721cde5..d428dd805c46 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -467,6 +467,7 @@ int of_genpd_remove_subdomain(const struct of_phandle_args *parent_spec,
struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
int of_genpd_parse_idle_states(struct device_node *dn,
struct genpd_power_state **states, int *n);
+void of_genpd_queue_sync_state(struct device *dev);
void of_genpd_sync_state(struct device_node *np);
int genpd_dev_pm_attach(struct device *dev);
@@ -513,6 +514,7 @@ static inline int of_genpd_parse_idle_states(struct device_node *dn,
return -ENODEV;
}
+static inline void of_genpd_queue_sync_state(struct device *dev) {}
static inline void of_genpd_sync_state(struct device_node *np) {}
static inline int genpd_dev_pm_attach(struct device *dev)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 9/9] pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
Rmobile-sysc is not a onecell provider and didn't really needed
the GENPD_FLAG_NO_STAY_ON flag in the first place. Let's drop it.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/renesas/rmobile-sysc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pmdomain/renesas/rmobile-sysc.c b/drivers/pmdomain/renesas/rmobile-sysc.c
index 93103ff33d6e..e36f5d763c91 100644
--- a/drivers/pmdomain/renesas/rmobile-sysc.c
+++ b/drivers/pmdomain/renesas/rmobile-sysc.c
@@ -100,8 +100,7 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
struct generic_pm_domain *genpd = &rmobile_pd->genpd;
struct dev_power_governor *gov = rmobile_pd->gov;
- genpd->flags |= GENPD_FLAG_PM_CLK | GENPD_FLAG_ACTIVE_WAKEUP |
- GENPD_FLAG_NO_STAY_ON;
+ genpd->flags |= GENPD_FLAG_PM_CLK | GENPD_FLAG_ACTIVE_WAKEUP;
genpd->attach_dev = cpg_mstp_attach_dev;
genpd->detach_dev = cpg_mstp_detach_dev;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 7/9] pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
Due to the new fine grained sync_state support for onecell genpd provider
drivers, we should no longer need use the legacy behaviour. Therefore,
let's drop GENPD_FLAG_NO_STAY_ON.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/renesas/rcar-gen4-sysc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pmdomain/renesas/rcar-gen4-sysc.c b/drivers/pmdomain/renesas/rcar-gen4-sysc.c
index 0c6c639a91d0..81b154da725f 100644
--- a/drivers/pmdomain/renesas/rcar-gen4-sysc.c
+++ b/drivers/pmdomain/renesas/rcar-gen4-sysc.c
@@ -251,7 +251,6 @@ static int __init rcar_gen4_sysc_pd_setup(struct rcar_gen4_sysc_pd *pd)
genpd->detach_dev = cpg_mssr_detach_dev;
}
- genpd->flags |= GENPD_FLAG_NO_STAY_ON;
genpd->power_off = rcar_gen4_sysc_pd_power_off;
genpd->power_on = rcar_gen4_sysc_pd_power_on;
--
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