* Re: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Russell King (Oracle) @ 2026-04-08 16:16 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel, iommu, linux-ext4,
Linus Torvalds, dmaengine
Cc: Marek Szyprowski, Robin Murphy, Theodore Ts'o, Andreas Dilger,
Vinod Koul, Frank Li
In-Reply-To: <adZ9grUg71f518Fg@shell.armlinux.org.uk>
On Wed, Apr 08, 2026 at 05:08:34PM +0100, Russell King (Oracle) wrote:
> The rebase is still progressing, but it's landed on:
>
> c7d812e33f3e dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction
>
> and while this boots to a login prompt, it spat out a BUG():
>
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
> in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 56, name: kworker/u24:3
> preempt_count: 0, expected: 0
> RCU nest depth: 0, expected: 0
> 3 locks held by kworker/u24:3/56:
> #0: ffff000080042148 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_one_work+0x184/0x780
> #1: ffff80008299bdf8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1ac/0x780
> #2: ffff0000808b48f8 (&dev->mutex){....}-{4:4}, at: __device_attach+0x2c/0x188
> irq event stamp: 10872
> hardirqs last enabled at (10871): [<ffff80008013a410>] ktime_get+0x130/0x180
> hardirqs last disabled at (10872): [<ffff800080d61ac8>] _raw_spin_lock_irqsave+0x84/0x88
> softirqs last enabled at (9216): [<ffff80008002807c>] fpsimd_save_and_flush_current_state+0x3c/0x80
> softirqs last disabled at (9214): [<ffff800080028098>] fpsimd_save_and_flush_current_state+0x58/0x80
> CPU: 5 UID: 0 PID: 56 Comm: kworker/u24:3 Not tainted 7.0.0-rc1-bisect+ #654 PREEMPT
> Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
> Workqueue: events_unbound deferred_probe_work_func
> Call trace:
> show_stack+0x18/0x30 (C)
> dump_stack_lvl+0x6c/0x94
> dump_stack+0x18/0x24
> __might_resched+0x154/0x220
> __might_sleep+0x48/0x80
> __mutex_lock+0x48/0x800
> mutex_lock_nested+0x24/0x30
> pinmux_disable_setting+0x9c/0x180
> pinctrl_commit_state+0x5c/0x260
> pinctrl_pm_select_idle_state+0x4c/0xa0
> tegra_i2c_runtime_suspend+0x2c/0x3c
> pm_generic_runtime_suspend+0x2c/0x44
> __rpm_callback+0x48/0x1ec
> rpm_callback+0x74/0x80
> rpm_suspend+0xec/0x630
> rpm_idle+0x2c0/0x420
> __pm_runtime_idle+0x44/0x160
> tegra_i2c_probe+0x2e4/0x640
> platform_probe+0x5c/0xa4
> really_probe+0xbc/0x2c0
> __driver_probe_device+0x78/0x120
> driver_probe_device+0x3c/0x160
> __device_attach_driver+0xbc/0x160
> bus_for_each_drv+0x70/0xb8
> __device_attach+0xa4/0x188
> device_initial_probe+0x50/0x54
> bus_probe_device+0x38/0xa4
> deferred_probe_work_func+0x90/0xcc
> process_one_work+0x204/0x780
> worker_thread+0x1c8/0x36c
> kthread+0x138/0x144
> ret_from_fork+0x10/0x20
>
> This is reproducible.
I've just realised that it's the Tegra I2C bug that is already known
about, but took ages to be fixed in mainline - it's unrelated to the
memory corruption, so can be ignored. Sorry for the noise.
--
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: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Russell King (Oracle) @ 2026-04-08 16:08 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel, iommu, linux-ext4,
Linus Torvalds, dmaengine
Cc: Marek Szyprowski, Robin Murphy, Theodore Ts'o, Andreas Dilger,
Vinod Koul, Frank Li
In-Reply-To: <adZfTi3R6jtsjXx-@shell.armlinux.org.uk>
On Wed, Apr 08, 2026 at 02:59:42PM +0100, Russell King (Oracle) wrote:
> On Wed, Apr 08, 2026 at 02:07:36PM +0100, Russell King (Oracle) wrote:
> > Hi,
> >
> > Just a heads-up that current net-next (v7.0-rc6 based) fails to boot on
> > my nVidia Jetson Xavier platform. v7.0-rc5 and v6.14 based net-next both
> > boot fine. This is an arm64 platform.
> >
> > The problem appears to be completely random in terms of its symptoms,
> > and looks like severe memory corruption - every boot seems to produce
> > a different problem. The common theme is, although the kernel gets to
> > userspace, it never gets anywhere close to a login prompt before
> > failing in some way.
> >
> > The last net-next+ boot (which is currently v7.0-rc6 based) resulted
> > in:
> >
> > tegra-mc 2c00000.memory-controller: xusb_hostw: secure write @0x00000003ffffff00: VPR violation ((null))
> > ...
> > irq 91: nobody cared (try booting with the "irqpoll" option)
> > ...
> > depmod: ERROR: could not open directory /lib/modules/7.0.0-rc6-net-next+: No such file or directory
> > ...
> > Unable to handle kernel paging request at virtual address 0003201fd50320cf
> >
> >
> > A previous boot of the exact same kernel didn't oops, but was unable
> > to find the block device to mount for /mnt via block UUID.
> >
> > A previous boot to that resulted in an oops.
> >
> >
> > The intersting thing is - the depmod error above is incorrect:
> >
> > root@tegra-ubuntu:~# ls -ld /lib/modules/7.0.0-rc6-net-next+
> > drwxrwxr-x 3 root root 4096 Apr 8 10:23 /lib/modules/7.0.0-rc6-net-next+
> >
> > The directory is definitely there, and is readable - checked after
> > booting back into net-next based on 7.0-rc5. In some of these boots,
> > stmmac hasn't probed yet, which rules out my changes.
> >
> > Rootfs is ext4, and it seems there were a lot of ext4 commits merged
> > between rc5 and rc6, but nothing for rc7.
> >
> > My current net-next head is dfecb0c5af3b. Merging rc7 on top also
> > fails, I suspect also randomly, with that I just got:
> >
> > EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
> > mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error.
> > mount: /mnt/: can't find PARTUUID=741c0777-391a-4bce-a222-455e180ece2a.
> > Unable to handle kernel paging request at virtual address f9bf0011ac0fb893
> > Mem abort info:
> > ESR = 0x0000000096000004
> > EC = 0x25: DABT (current EL), IL = 32 bits
> > SET = 0, FnV = 0
> > EA = 0, S1PTW = 0
> > FSC = 0x04: level 0 translation fault
> > Data abort info:
> > ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> > CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > [f9bf0011ac0fb893] address between user and kernel address ranges
> > Internal error: Oops: 0000000096000004 [#1] SMP
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 936 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
> > Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
> > pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : refill_objects+0x298/0x5ec
> > lr : refill_objects+0x1f0/0x5ec
> >
> > ...
> >
> > Call trace:
> > refill_objects+0x298/0x5ec (P)
> > __pcs_replace_empty_main+0x13c/0x3a8
> > kmem_cache_alloc_noprof+0x324/0x3a0
> > alloc_iova+0x3c/0x290
> > alloc_iova_fast+0x168/0x2d4
> > iommu_dma_alloc_iova+0x84/0x154
> > iommu_dma_map_sg+0x2c4/0x538
> > __dma_map_sg_attrs+0x124/0x2c0
> > dma_map_sg_attrs+0x10/0x20
> > sdhci_pre_dma_transfer+0xb8/0x164
> > sdhci_pre_req+0x38/0x44
> > mmc_blk_mq_issue_rq+0x3dc/0x920
> > mmc_mq_queue_rq+0x104/0x2b0
> > __blk_mq_issue_directly+0x38/0xb0
> > blk_mq_request_issue_directly+0x54/0xb4
> > blk_mq_issue_direct+0x84/0x180
> > blk_mq_dispatch_queue_requests+0x1a8/0x2e0
> > blk_mq_flush_plug_list+0x60/0x140
> > __blk_flush_plug+0xe0/0x11c
> > blk_finish_plug+0x38/0x4c
> > read_pages+0x158/0x260
> > page_cache_ra_unbounded+0x158/0x3e0
> > force_page_cache_ra+0xb0/0xe4
> > page_cache_sync_ra+0x88/0x480
> > filemap_get_pages+0xd8/0x850
> > filemap_read+0xdc/0x3d8
> > blkdev_read_iter+0x84/0x198
> > vfs_read+0x208/0x2d8
> > ksys_read+0x58/0xf4
> > __arm64_sys_read+0x1c/0x28
> > invoke_syscall.constprop.0+0x50/0xe0
> > do_el0_svc+0x40/0xc0
> > el0_svc+0x48/0x2a0
> > el0t_64_sync_handler+0xa0/0xe4
> > el0t_64_sync+0x19c/0x1a0
> > Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
> > ---[ end trace 0000000000000000 ]---
> > Kernel panic - not syncing: Oops: Fatal exception
> >
> > Looking at the changes between rc5 and rc6, there's one drivers/block
> > change for zram (which is used on this platform), one change in
> > drivers/base for regmap, nothing for drivers/mmc, but plenty for
> > fs/ext4. There are five DMA API changes.
> >
> > Now building straight -rc7. If that also fails, my plan is to start
> > bisecting rc5..rc6, which will likely take most of the rest of the
> > day. So, in the mean time I'm sending this as a heads-up that rc6
> > and onwards has a problem.
>
> Plain -rc7 fails (another random oops):
>
> Root device found: PARTUUID=741c0777-391a-4bce-a222-455e180ece2a
> depmod: ERROR: could not open directory /lib/modules/7.0.0-rc7-net-next+: No such file or directory
> depmod: FATAL: could not search modules: No such file or directory
> usb 2-3: new SuperSpeed Plus Gen 2x1 USB device number 2 using tegra-xusb
> hub 2-3:1.0: USB hub found
> hub 2-3:1.0: 4 ports detected
> usb 1-3: new full-speed USB device number 3 using tegra-xusb
> Unable to handle kernel paging request at virtual address 0003201fd50320cf
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [0003201fd50320cf] address between user and kernel address ranges
> Internal error: Oops: 0000000096000004 [#1] SMP
> Modules linked in:
> CPU: 1 UID: 0 PID: 917 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
> Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : refill_objects+0x298/0x5ec
> lr : refill_objects+0x1f0/0x5ec
> sp : ffff80008606b500
> x29: ffff80008606b500 x28: 0000000000000001 x27: fffffdffc20e6200
> x26: 0000000000000006 x25: 0000000000000000 x24: 000000000000003c
> x23: ffff0000809e4840 x22: ffff0000809dba00 x21: ffff80008606b5a0
> x20: ffff000081133820 x19: fffffdffc20e6220 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000100 x15: 0000000000000000
> x14: 0000000000000000 x13: 0000000000000000 x12: ffff800081e5faa8
> x11: ffff800082192c70 x10: ffff8000814074dc x9 : 0000000000000050
> x8 : ffff80008606b490 x7 : ffff000083988b40 x6 : ffff80008606b4a0
> x5 : 000000080015000f x4 : d503201fd503201f x3 : 00000000000000b0
> x2 : d503201fd503201f x1 : ffff000081133828 x0 : d503201fd503201f
> Call trace:
> refill_objects+0x298/0x5ec (P)
> __pcs_replace_empty_main+0x13c/0x3a8
> kmem_cache_alloc_noprof+0x324/0x3a0
> mempool_alloc_slab+0x1c/0x28
> mempool_alloc_noprof+0x98/0xe0
> bio_alloc_bioset+0x160/0x3e0
> do_mpage_readpage+0x3d0/0x618
> mpage_readahead+0xb8/0x144
> blkdev_readahead+0x18/0x24
> read_pages+0x58/0x260
> page_cache_ra_unbounded+0x158/0x3e0
> force_page_cache_ra+0xb0/0xe4
> page_cache_sync_ra+0x88/0x480
> filemap_get_pages+0xd8/0x850
> filemap_read+0xdc/0x3d8
> blkdev_read_iter+0x84/0x198
> vfs_read+0x208/0x2d8
> ksys_read+0x58/0xf4
> __arm64_sys_read+0x1c/0x28
> invoke_syscall.constprop.0+0x50/0xe0
> do_el0_svc+0x40/0xc0
> el0_svc+0x48/0x2a0
> el0t_64_sync_handler+0xa0/0xe4
> el0t_64_sync+0x19c/0x1a0
> Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
> ---[ end trace 0000000000000000 ]---
>
> Now starting the bisect between 7.0-rc5 and 7.0-rc6.
The rebase is still progressing, but it's landed on:
c7d812e33f3e dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction
and while this boots to a login prompt, it spat out a BUG():
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 56, name: kworker/u24:3
preempt_count: 0, expected: 0
RCU nest depth: 0, expected: 0
3 locks held by kworker/u24:3/56:
#0: ffff000080042148 ((wq_completion)events_unbound#2){+.+.}-{0:0}, at: process_one_work+0x184/0x780
#1: ffff80008299bdf8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1ac/0x780
#2: ffff0000808b48f8 (&dev->mutex){....}-{4:4}, at: __device_attach+0x2c/0x188
irq event stamp: 10872
hardirqs last enabled at (10871): [<ffff80008013a410>] ktime_get+0x130/0x180
hardirqs last disabled at (10872): [<ffff800080d61ac8>] _raw_spin_lock_irqsave+0x84/0x88
softirqs last enabled at (9216): [<ffff80008002807c>] fpsimd_save_and_flush_current_state+0x3c/0x80
softirqs last disabled at (9214): [<ffff800080028098>] fpsimd_save_and_flush_current_state+0x58/0x80
CPU: 5 UID: 0 PID: 56 Comm: kworker/u24:3 Not tainted 7.0.0-rc1-bisect+ #654 PREEMPT
Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
Workqueue: events_unbound deferred_probe_work_func
Call trace:
show_stack+0x18/0x30 (C)
dump_stack_lvl+0x6c/0x94
dump_stack+0x18/0x24
__might_resched+0x154/0x220
__might_sleep+0x48/0x80
__mutex_lock+0x48/0x800
mutex_lock_nested+0x24/0x30
pinmux_disable_setting+0x9c/0x180
pinctrl_commit_state+0x5c/0x260
pinctrl_pm_select_idle_state+0x4c/0xa0
tegra_i2c_runtime_suspend+0x2c/0x3c
pm_generic_runtime_suspend+0x2c/0x44
__rpm_callback+0x48/0x1ec
rpm_callback+0x74/0x80
rpm_suspend+0xec/0x630
rpm_idle+0x2c0/0x420
__pm_runtime_idle+0x44/0x160
tegra_i2c_probe+0x2e4/0x640
platform_probe+0x5c/0xa4
really_probe+0xbc/0x2c0
__driver_probe_device+0x78/0x120
driver_probe_device+0x3c/0x160
__device_attach_driver+0xbc/0x160
bus_for_each_drv+0x70/0xb8
__device_attach+0xa4/0x188
device_initial_probe+0x50/0x54
bus_probe_device+0x38/0xa4
deferred_probe_work_func+0x90/0xcc
process_one_work+0x204/0x780
worker_thread+0x1c8/0x36c
kthread+0x138/0x144
ret_from_fork+0x10/0x20
This is reproducible.
Adding Vinod and Frank, and dmaengine mailing list.
Bisect continuing, assuming this is a "good" commit as it isn't
producing the boot failure with random memory corruption.
--
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: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Daniel Baluta @ 2026-04-08 16:00 UTC (permalink / raw)
To: Peng Fan, Mathieu Poirier, Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PAXPR04MB8459AA009C932EB9D6139A11885BA@PAXPR04MB8459.eurprd04.prod.outlook.com>
On 4/8/26 04:30, Peng Fan wrote:
>> Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
>> SM CPU/LMM reset vector
>>
> [...]
>>> Aligning the ELF entry point with the hardware reset base on
>> Cortex‑M
>>> systems is possible, but it comes with several risks.
>> I'm not asking to align the ELF entry point with the hardware reset base.
>> All I want is to have the correct start address embedded in the ELF file
>> to avoid having to use a mask.
> I see, per my understanding:
> FreeRTOS typically exposes __isr_vector, which corresponds to the hardware
> reset / vector table base.
> Zephyr (Cortex‑M) exposes _vector_table, which serves the same purpose.
> I am not certain about other RTOSes, but the pattern seems consistent:
> the vector table base is already available as a named ELF symbol.
>
> Given that, if the preferred approach is to parse the ELF and explicitly
> retrieve the hardware reset base, I can update the implementation accordingly.
> If you prefer to parse the elf file to get the hardware reset base,
> I could update to use them.
>
> Options1: Something as below:
> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c
> 2. Use below in imx_rproc.c
> ret = rproc_elf_find_symbol(rproc, fw, "__isr_vector", &vector_base);
> if (ret)
> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table", &vector_base);
>
> if (!ret)
> rproc->bootaddr = vector_base
> else
> dev_info(dev, "no __isr_vector or __vector_table\n")
>
> This makes the hardware reset base explicit, avoids masking e_entry.
>
> Option 2: User‑provided reset symbol via sysfs
> As an alternative, we could expose a sysfs attribute,
> e.g. reset_symbol, allowing users to specify the symbol name
> to be used as the reset base:
>
> echo __isr_vector > /sys/class/remoteproc/remoteprocX/reset_symbol
>
> The remoteproc core would then resolve that symbol from
> the ELF and set rproc->bootaddr accordingly.
> This provides maximum flexibility but does introduce a new user‑visible ABI,
> so I see it more as an opt‑in or fallback mechanism.
>
> Please let me know which approach you prefer, and I will update
> this series accordingly in v3..
I would go with option 1) as this and having something like this:
#define IMX_RPROC_DEFAULT_RST_VECTOR_NAME "..."
later we can expand that with a configurable name via sysfs.
This was along my initial proposal where you would determine
the reset vector address from the elf file.
^ permalink raw reply
* [GIT PULL] KVM/arm64 updates for 7.1
From: Marc Zyngier @ 2026-04-08 15:55 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Alexandru Elisei, Arnd Bergmann, Catalin Marinas, Fuad Tabba,
James Clark, Joey Gouly, John Stultz, Jonathan Cameron,
Kalesh Singh, Leo Yan, Mark Brown, Mostafa Saleh,
Nathan Chancellor, Oliver Upton, Quentin Perret, Sascha Bischoff,
Sebastian Ene, Steven Rostedt, Suzuki K Poulose,
Vincent Donnefort, Wei-Lin Chang, Will Deacon, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
Paolo,
7.1 should be a pretty large milestone for KVM/arm64. Of note, we have:
- the hypervisor tracing infrastructure, which is pretty large on its
own, but also comes with an equally large set of tracing specific
patches (we share a branch with the tracing tree).
- the first set of patches for native GICv5 support, limited to PPIs
for the time being. I expect this to take a few kernel revisions
to reach the feature-complete state.
- some movement on the pKVM front, in the form of protected guest and
protected memory support.
The rest is a large set of fixes, cleanups and rework in order to make
some of the most hairy code more maintainable (user_mem_abort() being
the most significant example).
Please pull,
M.
The following changes since commit f338e77383789c0cae23ca3d48adcc5e9e137e3c:
Linux 7.0-rc4 (2026-03-15 13:52:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-7.1
for you to fetch changes up to 94b4ae79ebb42a8a6f2124b4d4b033b15a98e4f9:
Merge branch kvm-arm64/misc-7.1 into kvmarm-master/next (2026-04-08 12:26:11 +0100)
----------------------------------------------------------------
KVM/arm64 updates for 7.1
* New features:
- Add support for tracing in the standalone EL2 hypervisor code,
which should help both debugging and performance analysis.
This comes with a full infrastructure for 'remote' trace buffers
that can be exposed by non-kernel entities such as firmware.
- Add support for GICv5 Per Processor Interrupts (PPIs), as the
starting point for supporting the new GIC architecture in KVM.
- Finally add support for pKVM protected guests, with anonymous
memory being used as a backing store. About time!
* Improvements and bug fixes:
- Rework the dreaded user_mem_abort() function to make it more
maintainable, reducing the amount of state being exposed to
the various helpers and rendering a substantial amount of
state immutable.
- Expand the Stage-2 page table dumper to support NV shadow
page tables on a per-VM basis.
- Tidy up the pKVM PSCI proxy code to be slightly less hard
to follow.
- Fix both SPE and TRBE in non-VHE configurations so that they
do not generate spurious, out of context table walks that
ultimately lead to very bad HW lockups.
- A small set of patches fixing the Stage-2 MMU freeing in error
cases.
- Tighten-up accepted SMC immediate value to be only #0 for host
SMCCC calls.
- The usual cleanups and other selftest churn.
----------------------------------------------------------------
Arnd Bergmann (3):
tracing: add more symbols to whitelist
KVM: arm64: tracing: add ftrace dependency
KVM: arm64: avoid unused-variable warning
Fuad Tabba (14):
KVM: arm64: Extract VMA size resolution in user_mem_abort()
KVM: arm64: Introduce struct kvm_s2_fault to user_mem_abort()
KVM: arm64: Extract PFN resolution in user_mem_abort()
KVM: arm64: Isolate mmap_read_lock inside new kvm_s2_fault_get_vma_info() helper
KVM: arm64: Extract stage-2 permission logic in user_mem_abort()
KVM: arm64: Extract page table mapping in user_mem_abort()
KVM: arm64: Simplify nested VMA shift calculation
KVM: arm64: Remove redundant state variables from struct kvm_s2_fault
KVM: arm64: Simplify return logic in user_mem_abort()
KVM: arm64: Initialize struct kvm_s2_fault completely at declaration
KVM: arm64: Optimize early exit checks in kvm_s2_fault_pin_pfn()
KVM: arm64: Hoist MTE validation check out of MMU lock path
KVM: arm64: Clean up control flow in kvm_s2_fault_map()
KVM: arm64: Expose self-hosted debug regs as RAZ/WI for protected guests
Marc Zyngier (49):
tracing: Restore accidentally removed SPDX tag
KVM: arm64: pkvm: Move error handling to the end of kvm_hyp_cpu_entry
KVM: arm64: pkvm: Simplify BTI handling on CPU boot
KVM: arm64: pkvm: Turn __kvm_hyp_init_cpu into an inner label
KVM: arm64: pkvm: Use direct function pointers for cpu_{on,resume}
KVM: arm64: Remove extra ISBs when using msr_hcr_el2
KVM: arm64: Kill fault->ipa
KVM: arm64: Make fault_ipa immutable
KVM: arm64: Move fault context to const structure
KVM: arm64: Replace fault_is_perm with a helper
KVM: arm64: Constrain fault_granule to kvm_s2_fault_map()
KVM: arm64: Kill write_fault from kvm_s2_fault
KVM: arm64: Kill exec_fault from kvm_s2_fault
KVM: arm64: Kill topup_memcache from kvm_s2_fault
KVM: arm64: Move VMA-related information to kvm_s2_fault_vma_info
KVM: arm64: Kill logging_active from kvm_s2_fault
KVM: arm64: Restrict the scope of the 'writable' attribute
KVM: arm64: Move kvm_s2_fault.{pfn,page} to kvm_s2_vma_info
KVM: arm64: Replace force_pte with a max_map_size attribute
KVM: arm64: Move device mapping management into kvm_s2_fault_pin_pfn()
KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
KVM: arm64: Simplify integration of adjust_nested_*_perms()
KVM: arm64: Convert gmem_abort() to struct kvm_s2_fault_desc
KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
KVM: arm64: Don't skip per-vcpu NV initialisation
arm64: Fix field references for ICH_PPI_DVIR[01]_EL2
KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1
KVM: arm64: Account for RESx bits in __compute_fgt()
KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIs
KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2
KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behaviours
KVM: arm64: vgic-v5: Make the effective priority mask a strict limit
KVM: arm64: vgic-v5: Correctly set dist->ready once initialised
KVM: arm64: Kill arch_timer_context::direct field
KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()
KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()
KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supported
KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
Merge branch kvm-arm64/hyp-tracing into kvmarm-master/next
Merge branch kvm-arm64/vgic-v5-ppi into kvmarm-master/next
Merge branch kvm-arm64/nv-s2-debugfs into kvmarm-master/next
Merge branch kvm-arm64/pkvm-psci into kvmarm-master/next
Merge branch kvm-arm64/user_mem_abort-rework into kvmarm-master/next
Merge branch kvm-arm64/spe-trbe-nvhe into kvmarm-master/next
Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/next
Merge branch kvm-arm64/vgic-fixes-7.1 into kvmarm-master/next
Merge branch kvm-arm64/misc-7.1 into kvmarm-master/next
Nathan Chancellor (1):
tracing: Adjust cmd_check_undefined to show unexpected undefined symbols
Quentin Perret (1):
KVM: arm64: Inject SIGSEGV on illegal accesses
Sascha Bischoff (41):
KVM: arm64: vgic-v3: Drop userspace write sanitization for ID_AA64PFR0.GIC on GICv5
KVM: arm64: vgic: Rework vgic_is_v3() and add vgic_host_has_gicvX()
KVM: arm64: Return early from kvm_finalize_sys_regs() if guest has run
KVM: arm64: vgic: Split out mapping IRQs and setting irq_ops
arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support
arm64/sysreg: Add GICR CDNMIA encoding
KVM: arm64: gic-v5: Add ARM_VGIC_V5 device to KVM headers
KVM: arm64: gic: Introduce interrupt type helpers
KVM: arm64: gic-v5: Add Arm copyright header
KVM: arm64: gic-v5: Detect implemented PPIs on boot
KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE
KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs
KVM: arm64: gic-v5: Add emulation for ICC_IAFFIDR_EL1 accesses
KVM: arm64: gic-v5: Trap and emulate ICC_IDR0_EL1 accesses
KVM: arm64: gic-v5: Add vgic-v5 save/restore hyp interface
KVM: arm64: gic-v5: Implement GICv5 load/put and save/restore
KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask
KVM: arm64: gic: Introduce queue_irq_unlock to irq_ops
KVM: arm64: gic-v5: Implement PPI interrupt injection
KVM: arm64: gic-v5: Init Private IRQs (PPIs) for GICv5
KVM: arm64: gic-v5: Clear TWI if single task running
KVM: arm64: gic-v5: Check for pending PPIs
KVM: arm64: gic-v5: Trap and mask guest ICC_PPI_ENABLERx_EL1 writes
KVM: arm64: Introduce set_direct_injection irq_op
KVM: arm64: gic-v5: Implement direct injection of PPIs
KVM: arm64: gic-v5: Support GICv5 interrupts with KVM_IRQ_LINE
KVM: arm64: gic-v5: Create and initialise vgic_v5
KVM: arm64: gic-v5: Initialise ID and priority bits when resetting vcpu
irqchip/gic-v5: Introduce minimal irq_set_type() for PPIs
KVM: arm64: gic-v5: Enlighten arch timer for GICv5
KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5
KVM: arm64: gic: Hide GICv5 for protected guests
KVM: arm64: gic-v5: Hide FEAT_GCIE from NV GICv5 guests
KVM: arm64: gic-v5: Introduce kvm_arm_vgic_v5_ops and register them
KVM: arm64: gic-v5: Set ICH_VCTLR_EL2.En on boot
KVM: arm64: gic-v5: Probe for GICv5 device
Documentation: KVM: Introduce documentation for VGICv5
KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI
KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest
KVM: arm64: selftests: Add no-vgic-v5 selftest
KVM: arm64: vgic-v5: Fold PPI state for all exposed PPIs
Sebastian Ene (1):
KVM: arm64: Prevent the host from using an smc with imm16 != 0
Vincent Donnefort (35):
ring-buffer: Add page statistics to the meta-page
ring-buffer: Store bpage pointers into subbuf_ids
ring-buffer: Introduce ring-buffer remotes
ring-buffer: Add non-consuming read for ring-buffer remotes
tracing: Introduce trace remotes
tracing: Add reset to trace remotes
tracing: Add non-consuming read to trace remotes
tracing: Add init callback to trace remotes
tracing: Add events to trace remotes
tracing: Add events/ root files to trace remotes
tracing: Add helpers to create trace remote events
ring-buffer: Export buffer_data_page and macros
tracing: Introduce simple_ring_buffer
tracing: Add a trace remote module for testing
tracing: selftests: Add trace remote tests
Documentation: tracing: Add tracing remotes
tracing: load/unload page callbacks for simple_ring_buffer
tracing: Check for undefined symbols in simple_ring_buffer
KVM: arm64: Add PKVM_DISABLE_STAGE2_ON_PANIC
KVM: arm64: Add clock support to nVHE/pKVM hyp
KVM: arm64: Initialise hyp_nr_cpus for nVHE hyp
KVM: arm64: Support unaligned fixmap in the pKVM hyp
KVM: arm64: Add tracing capability for the nVHE/pKVM hyp
KVM: arm64: Add trace remote for the nVHE/pKVM hyp
KVM: arm64: Sync boot clock with the nVHE/pKVM hyp
KVM: arm64: Add trace reset to the nVHE/pKVM hyp
KVM: arm64: Add event support to the nVHE/pKVM hyp and trace remote
KVM: arm64: Add hyp_enter/hyp_exit events to nVHE/pKVM hyp
KVM: arm64: Add selftest event support to nVHE/pKVM hyp
tracing: selftests: Add hypervisor trace remote tests
KVM: arm64: Fix out-of-tree build for nVHE/pKVM tracing
tracing: Update undefined symbols allow list for simple_ring_buffer
tracing: Generate undef symbols allowlist for simple_ring_buffer
tracing: Non-consuming read for trace remotes with an offline CPU
tracing: selftests: Extend hotplug testing for trace remotes
Wei-Lin Chang (2):
KVM: arm64: ptdump: Make KVM ptdump code s2 mmu aware
KVM: arm64: nv: Expose shadow page tables in debugfs
Will Deacon (44):
KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
KVM: arm64: Disable SPE Profiling Buffer when running in guest context
KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
KVM: arm64: Remove unused PKVM_ID_FFA definition
KVM: arm64: Don't leak stage-2 page-table if VM fails to init under pKVM
KVM: arm64: Move handle check into pkvm_pgtable_stage2_destroy_range()
KVM: arm64: Rename __pkvm_pgtable_stage2_unmap()
KVM: arm64: Don't advertise unsupported features for protected guests
KVM: arm64: Remove is_protected_kvm_enabled() checks from hypercalls
KVM: arm64: Ignore MMU notifier callbacks for protected VMs
KVM: arm64: Prevent unsupported memslot operations on protected VMs
KVM: arm64: Ignore -EAGAIN when mapping in pages for the pKVM host
KVM: arm64: Split teardown hypercall into two phases
KVM: arm64: Introduce __pkvm_host_donate_guest()
KVM: arm64: Hook up donation hypercall to pkvm_pgtable_stage2_map()
KVM: arm64: Handle aborts from protected VMs
KVM: arm64: Introduce __pkvm_reclaim_dying_guest_page()
KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()
KVM: arm64: Factor out pKVM host exception injection logic
KVM: arm64: Support translation faults in inject_host_exception()
KVM: arm64: Avoid pointless annotation when mapping host-owned pages
KVM: arm64: Generalise kvm_pgtable_stage2_set_owner()
KVM: arm64: Introduce host_stage2_set_owner_metadata_locked()
KVM: arm64: Change 'pkvm_handle_t' to u16
KVM: arm64: Annotate guest donations with handle and gfn in host stage-2
KVM: arm64: Introduce hypercall to force reclaim of a protected page
KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler
KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte
KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs
KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs
KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs
KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled
KVM: arm64: Add some initial documentation for pKVM
KVM: arm64: Extend pKVM page ownership selftests to cover guest donation
KVM: arm64: Register 'selftest_vm' in the VM table
KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim
KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs
KVM: arm64: Rename PKVM_PAGE_STATE_MASK
drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL
KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
KVM: arm64: Don't leave mmu->pgt dangling on kvm_init_stage2_mmu() error
KVM: arm64: Destroy stage-2 page-table in kvm_arch_destroy_vm()
Zenghui Yu (Huawei) (2):
KVM: arm64: ptdump: Initialize parser_state before pgtable walk
KVM: arm64: selftests: Avoid testing the IMPDEF behavior
Documentation/admin-guide/kernel-parameters.txt | 4 +-
Documentation/trace/index.rst | 11 +
Documentation/trace/remotes.rst | 66 +
Documentation/virt/kvm/api.rst | 6 +-
Documentation/virt/kvm/arm/index.rst | 1 +
Documentation/virt/kvm/arm/pkvm.rst | 106 ++
Documentation/virt/kvm/devices/arm-vgic-v5.rst | 50 +
Documentation/virt/kvm/devices/index.rst | 1 +
Documentation/virt/kvm/devices/vcpu.rst | 5 +-
arch/arm64/include/asm/el2_setup.h | 4 +-
arch/arm64/include/asm/kvm_asm.h | 44 +-
arch/arm64/include/asm/kvm_define_hypevents.h | 16 +
arch/arm64/include/asm/kvm_host.h | 50 +-
arch/arm64/include/asm/kvm_hyp.h | 14 +-
arch/arm64/include/asm/kvm_hypevents.h | 60 +
arch/arm64/include/asm/kvm_hyptrace.h | 26 +
arch/arm64/include/asm/kvm_mmu.h | 4 +
arch/arm64/include/asm/kvm_pgtable.h | 45 +-
arch/arm64/include/asm/kvm_pkvm.h | 4 +-
arch/arm64/include/asm/sysreg.h | 13 +-
arch/arm64/include/asm/virt.h | 9 +
arch/arm64/include/asm/vncr_mapping.h | 3 +
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/hyp-stub.S | 1 -
arch/arm64/kernel/image-vars.h | 4 +
arch/arm64/kernel/vmlinux.lds.S | 18 +
arch/arm64/kvm/Kconfig | 64 +-
arch/arm64/kvm/Makefile | 2 +
arch/arm64/kvm/arch_timer.c | 102 +-
arch/arm64/kvm/arm.c | 69 +-
arch/arm64/kvm/config.c | 127 +-
arch/arm64/kvm/emulate-nested.c | 68 +
arch/arm64/kvm/handle_exit.c | 2 +-
arch/arm64/kvm/hyp/include/hyp/switch.h | 27 +
arch/arm64/kvm/hyp/include/nvhe/arm-smccc.h | 23 +
arch/arm64/kvm/hyp/include/nvhe/clock.h | 16 +
arch/arm64/kvm/hyp/include/nvhe/define_events.h | 14 +
arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 12 +-
arch/arm64/kvm/hyp/include/nvhe/memory.h | 12 +-
arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 7 +-
arch/arm64/kvm/hyp/include/nvhe/trace.h | 70 +
arch/arm64/kvm/hyp/include/nvhe/trap_handler.h | 2 +
arch/arm64/kvm/hyp/nvhe/Makefile | 8 +-
arch/arm64/kvm/hyp/nvhe/clock.c | 65 +
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 116 +-
arch/arm64/kvm/hyp/nvhe/events.c | 25 +
arch/arm64/kvm/hyp/nvhe/ffa.c | 28 +-
arch/arm64/kvm/hyp/nvhe/host.S | 13 +-
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 41 +-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 294 +++--
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 6 +
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 587 ++++++++-
arch/arm64/kvm/hyp/nvhe/mm.c | 4 +-
arch/arm64/kvm/hyp/nvhe/pkvm.c | 239 +++-
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 45 +-
arch/arm64/kvm/hyp/nvhe/setup.c | 4 +-
arch/arm64/kvm/hyp/nvhe/stacktrace.c | 6 +-
arch/arm64/kvm/hyp/nvhe/switch.c | 23 +-
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 18 +-
arch/arm64/kvm/hyp/nvhe/trace.c | 306 +++++
arch/arm64/kvm/hyp/pgtable.c | 33 +-
arch/arm64/kvm/hyp/vgic-v5-sr.c | 166 +++
arch/arm64/kvm/hyp/vhe/Makefile | 2 +-
arch/arm64/kvm/hyp_trace.c | 442 +++++++
arch/arm64/kvm/hyp_trace.h | 11 +
arch/arm64/kvm/mmu.c | 624 +++++----
arch/arm64/kvm/nested.c | 11 +-
arch/arm64/kvm/pkvm.c | 159 ++-
arch/arm64/kvm/pmu-emul.c | 20 +-
arch/arm64/kvm/ptdump.c | 79 +-
arch/arm64/kvm/stacktrace.c | 8 +-
arch/arm64/kvm/sys_regs.c | 188 ++-
arch/arm64/kvm/vgic/vgic-init.c | 228 +++-
arch/arm64/kvm/vgic/vgic-kvm-device.c | 107 +-
arch/arm64/kvm/vgic/vgic-mmio.c | 40 +-
arch/arm64/kvm/vgic/vgic-v3.c | 2 +-
arch/arm64/kvm/vgic/vgic-v5.c | 499 ++++++-
arch/arm64/kvm/vgic/vgic.c | 173 ++-
arch/arm64/kvm/vgic/vgic.h | 53 +-
arch/arm64/mm/fault.c | 33 +-
arch/arm64/tools/sysreg | 480 +++++++
drivers/irqchip/irq-gic-v5.c | 18 +
drivers/virt/coco/pkvm-guest/Kconfig | 2 +-
fs/tracefs/inode.c | 1 +
include/kvm/arm_arch_timer.h | 8 +-
include/kvm/arm_pmu.h | 5 +-
include/kvm/arm_vgic.h | 191 ++-
include/linux/irqchip/arm-gic-v5.h | 27 +
include/linux/kvm_host.h | 1 +
include/linux/ring_buffer.h | 58 +
include/linux/ring_buffer_types.h | 41 +
include/linux/simple_ring_buffer.h | 65 +
include/linux/trace_remote.h | 48 +
include/linux/trace_remote_event.h | 33 +
include/trace/define_remote_events.h | 73 ++
include/uapi/linux/kvm.h | 7 +
include/uapi/linux/trace_mmap.h | 8 +-
kernel/trace/Kconfig | 14 +
kernel/trace/Makefile | 59 +
kernel/trace/remote_test.c | 261 ++++
kernel/trace/remote_test_events.h | 10 +
kernel/trace/ring_buffer.c | 354 ++++-
kernel/trace/simple_ring_buffer.c | 517 ++++++++
kernel/trace/trace.c | 4 +-
kernel/trace/trace.h | 7 +
kernel/trace/trace_remote.c | 1384 ++++++++++++++++++++
tools/arch/arm64/include/uapi/asm/kvm.h | 1 +
tools/include/uapi/linux/kvm.h | 2 +
.../selftests/ftrace/test.d/remotes/buffer_size.tc | 25 +
.../selftests/ftrace/test.d/remotes/functions | 99 ++
.../selftests/ftrace/test.d/remotes/hotplug.tc | 88 ++
.../test.d/remotes/hypervisor/buffer_size.tc | 11 +
.../ftrace/test.d/remotes/hypervisor/hotplug.tc | 11 +
.../ftrace/test.d/remotes/hypervisor/reset.tc | 11 +
.../ftrace/test.d/remotes/hypervisor/trace.tc | 11 +
.../ftrace/test.d/remotes/hypervisor/trace_pipe.tc | 11 +
.../ftrace/test.d/remotes/hypervisor/unloading.tc | 11 +
.../selftests/ftrace/test.d/remotes/reset.tc | 90 ++
.../selftests/ftrace/test.d/remotes/trace.tc | 102 ++
.../selftests/ftrace/test.d/remotes/trace_pipe.tc | 102 ++
.../selftests/ftrace/test.d/remotes/unloading.tc | 41 +
tools/testing/selftests/kvm/Makefile.kvm | 3 +-
tools/testing/selftests/kvm/arm64/at.c | 14 +-
tools/testing/selftests/kvm/arm64/no-vgic-v3.c | 177 ---
tools/testing/selftests/kvm/arm64/no-vgic.c | 297 +++++
tools/testing/selftests/kvm/arm64/set_id_regs.c | 52 +-
tools/testing/selftests/kvm/arm64/vgic_v5.c | 228 ++++
tools/testing/selftests/kvm/include/arm64/gic_v5.h | 150 +++
129 files changed, 10017 insertions(+), 1086 deletions(-)
create mode 100644 Documentation/trace/remotes.rst
create mode 100644 Documentation/virt/kvm/arm/pkvm.rst
create mode 100644 Documentation/virt/kvm/devices/arm-vgic-v5.rst
create mode 100644 arch/arm64/include/asm/kvm_define_hypevents.h
create mode 100644 arch/arm64/include/asm/kvm_hypevents.h
create mode 100644 arch/arm64/include/asm/kvm_hyptrace.h
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/arm-smccc.h
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/clock.h
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/define_events.h
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trace.h
create mode 100644 arch/arm64/kvm/hyp/nvhe/clock.c
create mode 100644 arch/arm64/kvm/hyp/nvhe/events.c
create mode 100644 arch/arm64/kvm/hyp/nvhe/trace.c
create mode 100644 arch/arm64/kvm/hyp/vgic-v5-sr.c
create mode 100644 arch/arm64/kvm/hyp_trace.c
create mode 100644 arch/arm64/kvm/hyp_trace.h
create mode 100644 include/linux/ring_buffer_types.h
create mode 100644 include/linux/simple_ring_buffer.h
create mode 100644 include/linux/trace_remote.h
create mode 100644 include/linux/trace_remote_event.h
create mode 100644 include/trace/define_remote_events.h
create mode 100644 kernel/trace/remote_test.c
create mode 100644 kernel/trace/remote_test_events.h
create mode 100644 kernel/trace/simple_ring_buffer.c
create mode 100644 kernel/trace/trace_remote.c
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/buffer_size.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/functions
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hotplug.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/buffer_size.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/hotplug.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/reset.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/trace.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/trace_pipe.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/unloading.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/reset.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/trace.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/trace_pipe.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/unloading.tc
delete mode 100644 tools/testing/selftests/kvm/arm64/no-vgic-v3.c
create mode 100644 tools/testing/selftests/kvm/arm64/no-vgic.c
create mode 100644 tools/testing/selftests/kvm/arm64/vgic_v5.c
create mode 100644 tools/testing/selftests/kvm/include/arm64/gic_v5.h
^ permalink raw reply
* Re: [PATCH v3 07/13] arm64: mm: Use hierarchical XN mapping for the fixmap
From: Ard Biesheuvel @ 2026-04-08 15:48 UTC (permalink / raw)
To: Catalin Marinas, Ard Biesheuvel
Cc: linux-kernel, linux-arm-kernel, Will Deacon, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, linux-hardening
In-Reply-To: <adZ4LpvJJz-3K20O@arm.com>
On Wed, 8 Apr 2026, at 17:45, Catalin Marinas wrote:
> On Fri, Mar 20, 2026 at 03:59:42PM +0100, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>>
>> Nothing in the fixmap or in its vicinity requires executable
>> permissions, and given that it is placed at exactly 1 GiB from the end
>> of the virtual address space, we can safely set the hierarchical XN
>> attributes on the level 2 table entries covering the fixmap, without
>> running the risk of inadvertently taking away the executable permissions
>> on an adjacent mappings.
>>
>> This is a hardening measure that reduces the risk of the fixmap being
>> abused to create executable mappings in the kernel address space.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>> arch/arm64/mm/fixmap.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
>> index c5c5425791da..c3dd3c868cf5 100644
>> --- a/arch/arm64/mm/fixmap.c
>> +++ b/arch/arm64/mm/fixmap.c
>> @@ -48,7 +48,8 @@ static void __init early_fixmap_init_pte(pmd_t *pmdp, unsigned long addr)
>> if (pmd_none(pmd)) {
>> ptep = bm_pte[BM_PTE_TABLE_IDX(addr)];
>> __pmd_populate(pmdp, __pa_symbol(ptep),
>> - PMD_TYPE_TABLE | PMD_TABLE_AF);
>> + PMD_TYPE_TABLE | PMD_TABLE_AF |
>> + PMD_TABLE_PXN | PMD_TABLE_UXN);
>> }
>> }
>
> Sashiko reckons this breaks kpti. I think that's valid but I couldn't
> reproduce it on qemu (maybe it doesn't implement hierarchical
> permissions).
Yeah, I think that observation is accurate, and it doesn't really affect the rest so I was just going to drop it.
> Then I tried FVP and the whole series panics (unrelated to
> kpti). With kvm-arm.mode=protected, I think kvm_ksym_ref() is lm_alias()
> and we have kvm_hyp_init_symbols() trying to flush the bss.
>
Interesting - I'll look into this for the next respin.
> Unable to handle kernel paging request at virtual address
> fff00000748f7000
> Mem abort info:
> ESR = 0x0000000096000147
> ** replaying previous printk message **
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x07: level 3 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
> CM = 1, WnR = 1, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> swapper pgtable: 4k pages, 52-bit VAs, pgdp=00000000f40ad000
> [fff00000748f7000] pgd=18000008fffff403, p4d=18000008ffffe403,
> pud=18000008ffffd403, pmd=18000008fffe9403, pte=00e80000f48f7406
> Internal error: Oops: 0000000096000147 [#1] SMP
> Modules linked in:
> CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 7.0.0-rc3-00013-g6bb20b972b8c #2 PREEMPT
> Hardware name: FVP Base RevC (DT)
> pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> pc : dcache_clean_inval_poc+0x24/0x48
> lr : kvm_arm_init+0xb48/0x1338
> sp : ffff80008005bd20
> x29: ffff80008005bd60 x28: ffff95c63230b000 x27: 0000000000000004
> x26: 0000000000000001 x25: ffff95c631a160c0 x24: 0000000000000008
> x23: 0000000000000000 x22: 0000000000000000 x21: fff00000748f7000
> x20: 0000000000002000 x19: 0001101131111112 x18: 00000000ffffffff
> x17: ffff95c6321fdd88 x16: 0000000031427afd x15: 0000000000000100
> x14: 0000000000000000 x13: 0000000000077a9a x12: fff000087f805650
> x11: fff000087f805630 x10: ffffc1ffe005db08 x9 : 0000000000000000
> x8 : 0000000080000000 x7 : ffff80008005bc50 x6 : 000f63580145a000
> x5 : ffff95c6322f8000 x4 : 0000000000000000 x3 : 000000000000003f
> x2 : 0000000000000040 x1 : fff00000748f9000 x0 : fff00000748f7000
> Call trace:
> dcache_clean_inval_poc+0x24/0x48 (P)
> do_one_initcall+0x60/0x1d4
> kernel_init_freeable+0x24c/0x2d4
> kernel_init+0x24/0x140
> ret_from_fork+0x10/0x20
> Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
> ---[ end trace 0000000000000000 ]---
>
> --
> Catalin
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-04-08 15:46 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PAXPR04MB8459AA009C932EB9D6139A11885BA@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 01:30:16AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> > SM CPU/LMM reset vector
> >
> [...]
> >
> > >
> > > Aligning the ELF entry point with the hardware reset base on
> > Cortex‑M
> > > systems is possible, but it comes with several risks.
> >
> > I'm not asking to align the ELF entry point with the hardware reset base.
> > All I want is to have the correct start address embedded in the ELF file
> > to avoid having to use a mask.
>
> I see, per my understanding:
> FreeRTOS typically exposes __isr_vector, which corresponds to the hardware
> reset / vector table base.
> Zephyr (Cortex‑M) exposes _vector_table, which serves the same purpose.
> I am not certain about other RTOSes, but the pattern seems consistent:
> the vector table base is already available as a named ELF symbol.
>
> Given that, if the preferred approach is to parse the ELF and explicitly
> retrieve the hardware reset base, I can update the implementation accordingly.
> If you prefer to parse the elf file to get the hardware reset base,
> I could update to use them.
>
> Options1: Something as below:
> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c
> 2. Use below in imx_rproc.c
> ret = rproc_elf_find_symbol(rproc, fw, "__isr_vector", &vector_base);
> if (ret)
> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table", &vector_base);
>
> if (!ret)
> rproc->bootaddr = vector_base
> else
> dev_info(dev, "no __isr_vector or __vector_table\n")
No
>
> This makes the hardware reset base explicit, avoids masking e_entry.
>
> Option 2: User‑provided reset symbol via sysfs
> As an alternative, we could expose a sysfs attribute,
> e.g. reset_symbol, allowing users to specify the symbol name
> to be used as the reset base:
>
> echo __isr_vector > /sys/class/remoteproc/remoteprocX/reset_symbol
>
Definitely not.
The definition of e_entry in the specification is clear, i.e "the address of the
entry point from where the process starts executing". If masking is required
because the tool that puts the image together gets the wrong address, then it
should be fixed.
> The remoteproc core would then resolve that symbol from
> the ELF and set rproc->bootaddr accordingly.
> This provides maximum flexibility but does introduce a new user‑visible ABI,
> so I see it more as an opt‑in or fallback mechanism.
>
> Please let me know which approach you prefer, and I will update
> this series accordingly in v3..
>
> Thanks,
> Peng.
>
>
> >
> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2, Debuggers may
> > > attempt to set breakpoints or start execution at the entry symbol
> > >
^ permalink raw reply
* Re: [PATCH v3 07/13] arm64: mm: Use hierarchical XN mapping for the fixmap
From: Catalin Marinas @ 2026-04-08 15:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-kernel, linux-arm-kernel, will, mark.rutland,
Ard Biesheuvel, Ryan Roberts, Anshuman Khandual, Liz Prucka,
Seth Jenkins, Kees Cook, linux-hardening
In-Reply-To: <20260320145934.2349881-22-ardb+git@google.com>
On Fri, Mar 20, 2026 at 03:59:42PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Nothing in the fixmap or in its vicinity requires executable
> permissions, and given that it is placed at exactly 1 GiB from the end
> of the virtual address space, we can safely set the hierarchical XN
> attributes on the level 2 table entries covering the fixmap, without
> running the risk of inadvertently taking away the executable permissions
> on an adjacent mappings.
>
> This is a hardening measure that reduces the risk of the fixmap being
> abused to create executable mappings in the kernel address space.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/mm/fixmap.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> index c5c5425791da..c3dd3c868cf5 100644
> --- a/arch/arm64/mm/fixmap.c
> +++ b/arch/arm64/mm/fixmap.c
> @@ -48,7 +48,8 @@ static void __init early_fixmap_init_pte(pmd_t *pmdp, unsigned long addr)
> if (pmd_none(pmd)) {
> ptep = bm_pte[BM_PTE_TABLE_IDX(addr)];
> __pmd_populate(pmdp, __pa_symbol(ptep),
> - PMD_TYPE_TABLE | PMD_TABLE_AF);
> + PMD_TYPE_TABLE | PMD_TABLE_AF |
> + PMD_TABLE_PXN | PMD_TABLE_UXN);
> }
> }
Sashiko reckons this breaks kpti. I think that's valid but I couldn't
reproduce it on qemu (maybe it doesn't implement hierarchical
permissions). Then I tried FVP and the whole series panics (unrelated to
kpti). With kvm-arm.mode=protected, I think kvm_ksym_ref() is lm_alias()
and we have kvm_hyp_init_symbols() trying to flush the bss.
I'll drop it for now.
Unable to handle kernel paging request at virtual address fff00000748f7000
Mem abort info:
ESR = 0x0000000096000147
** replaying previous printk message **
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x07: level 3 translation fault
Data abort info:
ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
CM = 1, WnR = 1, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 52-bit VAs, pgdp=00000000f40ad000
[fff00000748f7000] pgd=18000008fffff403, p4d=18000008ffffe403, pud=18000008ffffd403, pmd=18000008fffe9403, pte=00e80000f48f7406
Internal error: Oops: 0000000096000147 [#1] SMP
Modules linked in:
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc3-00013-g6bb20b972b8c #2 PREEMPT
Hardware name: FVP Base RevC (DT)
pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : dcache_clean_inval_poc+0x24/0x48
lr : kvm_arm_init+0xb48/0x1338
sp : ffff80008005bd20
x29: ffff80008005bd60 x28: ffff95c63230b000 x27: 0000000000000004
x26: 0000000000000001 x25: ffff95c631a160c0 x24: 0000000000000008
x23: 0000000000000000 x22: 0000000000000000 x21: fff00000748f7000
x20: 0000000000002000 x19: 0001101131111112 x18: 00000000ffffffff
x17: ffff95c6321fdd88 x16: 0000000031427afd x15: 0000000000000100
x14: 0000000000000000 x13: 0000000000077a9a x12: fff000087f805650
x11: fff000087f805630 x10: ffffc1ffe005db08 x9 : 0000000000000000
x8 : 0000000080000000 x7 : ffff80008005bc50 x6 : 000f63580145a000
x5 : ffff95c6322f8000 x4 : 0000000000000000 x3 : 000000000000003f
x2 : 0000000000000040 x1 : fff00000748f9000 x0 : fff00000748f7000
Call trace:
dcache_clean_inval_poc+0x24/0x48 (P)
do_one_initcall+0x60/0x1d4
kernel_init_freeable+0x24c/0x2d4
kernel_init+0x24/0x140
ret_from_fork+0x10/0x20
Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
---[ end trace 0000000000000000 ]---
--
Catalin
^ permalink raw reply
* [PATCH v2] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Wentao Liang @ 2026-04-08 15:30 UTC (permalink / raw)
To: Georgi Djakov, Shawn Guo, Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, Wentao Liang, linux-pm,
imx, linux-arm-kernel, linux-kernel, stable
The function imx_icc_node_init_qos() manually manages the reference count
of struct device_node *dn using of_node_put(). However, some error paths
use dn after the put, leading to use-after-free. Convert to automatic
cleanup using __free(device_node) to ensure the reference is always
released when dn goes out of scope.
Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
Changes in v2:
- Use auto cheanup to fix the problem.
---
drivers/interconnect/imx/imx.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
index 9511f80cf041..e5fcdcb88cfb 100644
--- a/drivers/interconnect/imx/imx.c
+++ b/drivers/interconnect/imx/imx.c
@@ -120,7 +120,8 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
struct imx_icc_node *node_data = node->data;
const struct imx_icc_node_adj_desc *adj = node_data->desc->adj;
struct device *dev = provider->dev;
- struct device_node *dn = NULL;
+ struct device_node *__free(device_nod) dn = of_parse_phandle(dev->of_node,
+ adj->phandle_name, 0);
struct platform_device *pdev;
if (adj->main_noc) {
@@ -128,7 +129,6 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
dev_dbg(dev, "icc node %s[%d] is main noc itself\n",
node->name, node->id);
} else {
- dn = of_parse_phandle(dev->of_node, adj->phandle_name, 0);
if (!dn) {
dev_warn(dev, "Failed to parse %s\n",
adj->phandle_name);
@@ -138,12 +138,10 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
if (!of_device_is_available(dn)) {
dev_warn(dev, "Missing property %s, skip scaling %s\n",
adj->phandle_name, node->name);
- of_node_put(dn);
return 0;
}
pdev = of_find_device_by_node(dn);
- of_node_put(dn);
if (!pdev) {
dev_warn(dev, "node %s[%d] missing device for %pOF\n",
node->name, node->id, dn);
--
2.34.1
^ permalink raw reply related
* Status of thermal support for i.MX93
From: Stefan Wahren @ 2026-04-08 15:28 UTC (permalink / raw)
To: Jacky Bai, Alice Guo, Frank Li
Cc: Fabio Estevam, imx@lists.linux.dev, Linux ARM,
open list:GENERIC PM DOMAINS, Daniel Lezcano, Sascha Hauer
Hi,
AFAIK the thermal support for i.MX93 hasn't been mainlined yet. The last
version I can find is here [1].
Are there any plans to finish this work?
Thanks
[1] -
https://lore.kernel.org/linux-arm-kernel/d9392dbc-806a-41df-8992-28c3d6132309@linaro.org/#t
^ permalink raw reply
* Re: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Linus Torvalds @ 2026-04-08 15:22 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: netdev, linux-arm-kernel, linux-kernel, iommu, linux-ext4,
Marek Szyprowski, Robin Murphy, Theodore Ts'o, Andreas Dilger
In-Reply-To: <adZfTi3R6jtsjXx-@shell.armlinux.org.uk>
On Wed, 8 Apr 2026 at 06:59, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> > Now building straight -rc7. If that also fails, my plan is to start
> > bisecting rc5..rc6, which will likely take most of the rest of the
> > day. So, in the mean time I'm sending this as a heads-up that rc6
> > and onwards has a problem.
>
> Plain -rc7 fails (another random oops):
>
> Now starting the bisect between 7.0-rc5 and 7.0-rc6.
Thanks. Not what I wanted to hear at this point, but a bisect should
get the culprit if this is at least sufficiently repeatable.
The exact symptoms and oops details may be random, but hopefully the
"something bad happens" is reliable enough to bisect.
Linus
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc
From: guoweix @ 2026-04-08 15:09 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, f.kardame, pgwipeout, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, guoweix
The RK809 PMIC interrupt pin on the Firefly ROC-RK3566-PC (Station M2)
is physically connected to GPIO0_A3 (RK_PA3) according to the board's
schematic.
Currently, the PMIC node incorrectly specifies RK_PA7 for the interrupt,
which prevents the PMIC from correctly signaling interrupts. (Note that
the pinctrl node 'pmic_int' correctly configures RK_PA3).
Fix this by updating the interrupts property to use RK_PA3.
Fixes: 30ac9b4e25d8 ("arm64: dts: rockchip: add dts for Firefly Station M2 rk3566")
Signed-off-by: guoweix <2298701336@qq.com>
---
arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
index 7e499064e035..985770e3a5e2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
@@ -245,7 +245,7 @@ rk809: pmic@20 {
compatible = "rockchip,rk809";
reg = <0x20>;
interrupt-parent = <&gpio0>;
- interrupts = <RK_PA7 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
clock-output-names = "rk808-clkout1", "rk808-clkout2";
assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 01/13] arm64: Move the zero page to rodata
From: Ard Biesheuvel @ 2026-04-08 15:09 UTC (permalink / raw)
To: Catalin Marinas, Ard Biesheuvel
Cc: linux-kernel, linux-arm-kernel, Will Deacon, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, linux-hardening
In-Reply-To: <adZbgYJqY6bisaoZ@arm.com>
On Wed, 8 Apr 2026, at 15:43, Catalin Marinas wrote:
> Hi Ard,
>
> On Fri, Mar 20, 2026 at 03:59:36PM +0100, Ard Biesheuvel wrote:
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 2964aad0362e..2d021a576e50 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -229,6 +229,7 @@ SECTIONS
>> #endif
>>
>> reserved_pg_dir = .;
>> + empty_zero_page = .;
>> . += PAGE_SIZE;
>>
>> swapper_pg_dir = .;
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a6a00accf4f9..795743913ce5 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -66,9 +66,8 @@ long __section(".mmuoff.data.write") __early_cpu_boot_status;
>>
>> /*
>> * Empty_zero_page is a special page that is used for zero-initialized data
>> - * and COW.
>> + * and COW. Defined in the linker script.
>> */
>> -unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
>> EXPORT_SYMBOL(empty_zero_page);
>
> I looked at Sashiko's reports
> (https://sashiko.dev/#/patchset/20260320145934.2349881-15-ardb+git@google.com)
> and it has a point here that with MTE, map_mem() doesn't map the
> empty_zero_page as Tagged in the for_each_mem_range() loop. The
> subsequent cpu_enable_mte() will fail to initialise the tags. I think
> this problem disappears with patch 11 where all the linear map is now
> Tagged.
>
> We either ignore it or we temporarily map the kernel as Tagged until the
> linear alias is removed later:
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 795743913ce5..5290f7537074 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1175,7 +1175,7 @@ static void __init map_mem(pgd_t *pgdp)
> * so we should avoid them here.
> */
> __map_memblock(pgdp, kernel_start, kernel_end,
> - PAGE_KERNEL, NO_CONT_MAPPINGS);
> + pgprot_tagged(PAGE_KERNEL), NO_CONT_MAPPINGS);
> memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
> arm64_kfence_map_pool(early_kfence_pool, pgdp);
> }
>
OK. There were some other very good comments too, I'll look into those and respin this for the next cycle.
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Rob Herring @ 2026-04-08 15:03 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, devicetree, Conor Dooley, Vignesh Raghavendra,
Mathieu Poirier, Dhruva Gole, Akashdeep Kaur, Kevin Hilman,
Bjorn Andersson, linux-remoteproc, linux-kernel, Kendall Willis,
Vishal Mahaveer, Sebin Francis, Krzysztof Kozlowski, Tero Kristo,
linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com>
On Wed, Mar 18, 2026 at 10:14 AM Markus Schneider-Pargmann (TI)
<msp@baylibre.com> wrote:
>
> Hi,
>
> Split the firmware memory region in more specific parts so it is better
> described where which information is stored. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data and resume from RAM.
>
> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
> for wakeup while the DDR is kept in self refresh. Everything else is
> powered off.
>
> The changes in this series were suggested as part of the IO+DDR u-boot series:
> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>
> There are currently no real users of the memory-region that is split in
> this series. The size of the memory-region in total stays the same.
> The new layout is derived from the software running on the r5f
> processor:
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>
> Additionally the two important devicetree nodes for resuming from IO+DDR
> have the bootph-pre-ram flag added as this data needs to be read before
> the RAM is in use.
>
> Best
> Markus
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> Changes in v3:
> - Squash the enforcement of the memory-region-names requirement in the
> patch adding the memory-region-names, as suggested.
> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>
> Changes in v2:
> - Make memory-region-names required if memory-region is present
> - Fixup memory-region and memory-region-names conditions. Require either
> 2 or 6 regions for memory-region and memory-region-names
> - Reword and restructure the binding documentation for memory-region and
> memory-region-names
> - Add memory-region-names to all uses of memory-region
> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>
> ---
> Markus Schneider-Pargmann (TI) (7):
> dt-bindings: remoteproc: k3-r5f: Split up memory regions
> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
> arm64: dts: ti: k3: Use memory-region-names for r5f
> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
TI folks, Please make sure these dts patches are picked up for 7.1.
There's now a crap load of warnings in next with the binding change:
58 (ti,am62-r5fss): r5f@78000000: 'memory-region-names' is a
required property
30 (ti,am62-r5fss): r5f@79000000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5f00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5e00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@41400000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@41000000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78600000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78400000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78200000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78000000: 'memory-region-names' is a
required property
12 (ti,j721s2-r5fss): r5f@5a00000: 'memory-region-names' is a
required property
12 (ti,j721s2-r5fss): r5f@5900000: 'memory-region-names' is a
required property
12 (ti,am654-r5fss): r5f@41400000: 'memory-region-names' is a
required property
12 (ti,am654-r5fss): r5f@41000000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5f00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5e00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@41400000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@41000000: 'memory-region-names' is a
required property
4 (ti,am62-r5fss): r5f@78400000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@41400000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@41000000: 'memory-region-names' is a
required property
If they aren't applied, making 'memory-region-names' required needs
to be dropped from the binding.
Rob
^ permalink raw reply
* Re: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Alexey Klimov @ 2026-04-08 14:49 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <20260119-acpm-tmu-v2-0-e02a834f04c6@linaro.org>
On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
> Add support for the Thermal Management Unit (TMU) on the Google GS101
> SoC.
>
> The GS101 TMU implementation utilizes a hybrid architecture where
> management is shared between the kernel and the Alive Clock and
> Power Manager (ACPM) firmware.
Do you plan to update or work on this series? If, by some reason,
this series is postphoned I can rebase it and re-send, for example.
IIRC it needs a clean rebase as a minimial change.
I am constructing some code on top of it, so it will be nice to have
newer version that can be (re-)tested for Exynos850.
Thanks,
Alexey
[...]
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: soc: samsung: exynos-pmu: add samsung,pmu-intr-gen phandle
From: Alexey Klimov @ 2026-04-08 14:30 UTC (permalink / raw)
To: André Draszik, Sam Protsenko, linux-samsung-soc,
Krzysztof Kozlowski, Peter Griffin, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <01ffe5d3aca040edcedb084386ab6e195cb93013.camel@linaro.org>
Hi André,
On Fri Apr 3, 2026 at 11:17 AM BST, André Draszik wrote:
> Hi Alexey,
>
> On Wed, 2026-04-01 at 05:51 +0100, Alexey Klimov wrote:
>> Some Exynos-based SoCs, for instance Exynos850, require access
>> to the pmu interrupt generation register region which is exposed
>> as a syscon. Update the exynos-pmu bindings documentation to
>> reflect this.
>
> You could mention that this is similar to the existing google,...
> one due to same requirement, hence a new and more general property.
Ok. Thanks.
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> .../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-
>> pmu.yaml
>> index 76ce7e98c10f..92acdfd5d44e 100644
>> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
>> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
>> @@ -110,6 +110,11 @@ properties:
>> description:
>> Node for reboot method
>>
>> + samsung,pmu-intr-gen-syscon:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle to PMU interrupt generation interface.
>> +
>> google,pmu-intr-gen-syscon:
>
> Please keep alphabetical order of vendors.
Sure. Thanks for noticing this.
Best regards,
Alexey
^ permalink raw reply
* [PATCH v2] nvme-apple: drop invalid put of admin queue reference count
From: Fedor Pchelkin @ 2026-04-08 14:18 UTC (permalink / raw)
To: Keith Busch, Christoph Hellwig, Jens Axboe
Cc: Fedor Pchelkin, Sven Peter, Janne Grunau, Neal Gompa,
Sagi Grimberg, Hannes Reinecke, Ming Lei, Chaitanya Kulkarni,
Heyne, Maximilian, asahi, linux-arm-kernel, linux-nvme,
linux-kernel, lvc-project, stable
Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the
admin queue reference ->put call into nvme_free_ctrl() - a controller
device release callback performed for every nvme driver doing
nvme_init_ctrl().
nvme-apple sets refcount of the admin queue to 1 at allocation during the
probe function and then puts it twice now:
nvme_free_ctrl()
blk_put_queue(ctrl->admin_q) // #1
->free_ctrl()
apple_nvme_free_ctrl()
blk_put_queue(anv->ctrl.admin_q) // #2
Note that there is a commit 941f7298c70c ("nvme-apple: remove an extra
queue reference") which intended to drop taking an extra admin queue
reference. Looks like at that moment it accidentally fixed a refcount
leak, which existed since the driver's introduction. There were two ->get
calls at driver's probe function and a single ->put inside
apple_nvme_free_ctrl().
However now after commit 03b3bcd319b3 ("nvme: fix admin request_queue
lifetime") the refcount is imbalanced again. Fix it by removing extra
->put call from apple_nvme_free_ctrl(). anv->dev and ctrl->dev point to
the same device, so use ctrl->dev directly for simplification. Compile
tested only.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 03b3bcd319b3 ("nvme: fix admin request_queue lifetime")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
---
v2: use ctrl->dev directly for simplification (Jens Axboe)
link to v1: https://lore.kernel.org/linux-nvme/20260403202701.991276-1-pchelkin@ispras.ru/
drivers/nvme/host/apple.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index ed61b97fde59..423c9c628e7b 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -1267,11 +1267,7 @@ static int apple_nvme_get_address(struct nvme_ctrl *ctrl, char *buf, int size)
static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
{
- struct apple_nvme *anv = ctrl_to_apple_nvme(ctrl);
-
- if (anv->ctrl.admin_q)
- blk_put_queue(anv->ctrl.admin_q);
- put_device(anv->dev);
+ put_device(ctrl->dev);
}
static const struct nvme_ctrl_ops nvme_ctrl_ops = {
--
2.53.0
^ permalink raw reply related
* [PATCH] pmdomain: mediatek: fix use-after-free in scpsys_get_bus_protection_legacy()
From: Wentao Liang @ 2026-04-08 14:11 UTC (permalink / raw)
To: Ulf Hansson, Matthias Brugger, AngeloGioacchino Del Regno
Cc: nfraprado, Macpaul Lin, Adam Ford, Chen-Yu Tsai, linux-pm,
linux-kernel, linux-arm-kernel, linux-mediatek, Wentao Liang,
stable
In scpsys_get_bus_protection_legacy(), of_find_node_with_property()
returns a device node with its reference count incremented. The function
then calls of_node_put(node) before checking whether
syscon_regmap_lookup_by_phandle() returns an error. If an error occurs,
dev_err_probe() dereferences the node pointer to print diagnostic
information, but the node memory may have already been freed due to the
earlier of_node_put(), leading to a use-after-free vulnerability.
Fix this by moving the of_node_put() call after the error check, ensuring
the node is still valid when accessed in the error path.
Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/pmdomain/mediatek/mtk-pm-domains.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index e2800aa1bc59..d3b36f32417c 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -993,6 +993,7 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
struct device_node *node, *smi_np;
int num_regmaps = 0, i, j;
struct regmap *regmap[3];
+ int ret = 0;
/*
* Legacy code retrieves a maximum of three bus protection handles:
@@ -1043,11 +1044,14 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
if (node) {
regmap[2] = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg-nao");
num_regmaps++;
- of_node_put(node);
- if (IS_ERR(regmap[2]))
- return dev_err_probe(dev, PTR_ERR(regmap[2]),
+ if (IS_ERR(regmap[2])) {
+ ret = dev_err_probe(dev, PTR_ERR(regmap[2]),
"%pOF: failed to get infracfg regmap\n",
node);
+ of_node_put(node);
+ return ret;
+ }
+ of_node_put(node);
} else {
regmap[2] = NULL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V11 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Manivannan Sadhasivam @ 2026-04-08 14:10 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114A60C4A7E43ED62A32B04925BA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 06:34:02AM +0000, Sherry Sun wrote:
[...]
> > > +/**
> > > + * pci_host_common_parse_port - Parse a single Root Port node
> > > + * @dev: Device pointer
> > > + * @bridge: PCI host bridge
> > > + * @node: Device tree node of the Root Port
> > > + *
> > > + * Returns: 0 on success, negative error code on failure */ static
> > > +int pci_host_common_parse_port(struct device *dev,
> > > + struct pci_host_bridge *bridge,
> > > + struct device_node *node)
> > > +{
> > > + struct pci_host_port *port;
> > > + struct gpio_desc *reset;
> > > +
> > > + reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > > + "reset", GPIOD_ASIS, "PERST#");
> >
> > Sorry, I missed this earlier.
> >
> > Since PERST# is optional, you cannot reliably detect whether the Root Port
> > binding intentionally skipped the PERST# GPIO or legacy binding is used, just
> > by checking for PERST# in Root Port node.
> >
> > So this helper should do 3 things:
> >
> > 1. If PERST# is found in Root Port node, use it.
> > 2. If not, check the RC node and if present, return -ENOENT to fallback to the
> > legacy binding.
> > 3. If not found in both nodes, assume that the PERST# is not present in the
> > design, and proceed with parsing Root Port binding further.
>
> Hi Mani, understand, does the following code looks ok for above three cases?
>
> /* Check if PERST# is present in Root Port node */
> reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> "reset", GPIOD_ASIS, "PERST#");
> if (IS_ERR(reset)) {
> /* If error is not -ENOENT, it's a real error */
> if (PTR_ERR(reset) != -ENOENT)
> return PTR_ERR(reset);
>
> /* PERST# not found in Root Port node, check RC node */
> rc_has_reset = of_property_read_bool(dev->of_node, "reset-gpios") ||
> of_property_read_bool(dev->of_node, "reset-gpio");
Just:
if (of_property_read_bool(dev->of_node, "reset-gpios") ||
of_property_read_bool(dev->of_node, "reset-gpio")) {
return -ENOENT;
}
> if (rc_has_reset)
> return -ENOENT;
>
> /* No PERST# in either node, assume not present in design */
> reset = NULL;
> }
>
> port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> if (!port)
> return -ENOMEM;
> ...
>
> >
> > But there is one more important limitation here. Right now, this API only
> > handles PERST#. But if another vendor tries to use it and if they need other
> > properties such as PHY, clocks etc... those resources should be fetched
> > optionally only by this helper. But if the controller has a hard dependency on
> > those resources, the driver will fail to operate.
> >
> > I don't think we can fix this limitation though and those platforms should
> > ensure that the resource dependency is correctly modeled in DT binding and
> > the DTS is validated properly. It'd be good to mention this in the kernel doc of
> > this API.
>
> Ok, I will add a NOTE for this in this API description.
>
> >
> > > + if (IS_ERR(reset))
> > > + return PTR_ERR(reset);
> > > +
> > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > + if (!port)
> > > + return -ENOMEM;
> > > +
> > > + port->reset = reset;
> > > + INIT_LIST_HEAD(&port->list);
> > > + list_add_tail(&port->list, &bridge->ports);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * pci_host_common_parse_ports - Parse Root Port nodes from device
> > > +tree
> > > + * @dev: Device pointer
> > > + * @bridge: PCI host bridge
> > > + *
> > > + * This function iterates through child nodes of the host bridge and
> > > +parses
> > > + * Root Port properties (currently only reset GPIO).
> > > + *
> > > + * Returns: 0 on success, -ENOENT if no ports found, other negative
> > > +error codes
> > > + * on failure
> > > + */
> > > +int pci_host_common_parse_ports(struct device *dev, struct
> > > +pci_host_bridge *bridge) {
> > > + int ret = -ENOENT;
> > > +
> > > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > > + if (!of_node_is_type(of_port, "pci"))
> > > + continue;
> > > + ret = pci_host_common_parse_port(dev, bridge, of_port);
> > > + if (ret)
> > > + return ret;
> >
> > As Sashiko flagged, you need to make sure that devm_add_action_or_reset()
> > is added even during the error path:
>
> Yes, it needs to be fixed. We can handle it with the following two methods, I am not sure which method is better or more preferable?
>
> #1: register cleanup action after first successful port parse and use cleanup_registered flag to avoid duplicate register.
> int ret = -ENOENT;
> bool cleanup_registered = false;
>
> for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> if (!of_node_is_type(of_port, "pci"))
> continue;
> ret = pci_host_common_parse_port(dev, bridge, of_port);
> if (ret)
> return ret;
>
> /* Register cleanup action after first successful port parse */
> if (!cleanup_registered) {
> ret = devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> &bridge->ports);
Even if you register devm_add_action_or_reset(), it won't be called when
pci_host_common_parse_port() fails since the legacy fallback will be used.
So you need to manually call pci_host_common_delete_ports() in the error path.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 2/8] firmware: efi: Never declare sysfb_primary_display on x86
From: Thomas Zimmermann @ 2026-04-08 14:07 UTC (permalink / raw)
To: Ard Biesheuvel, Javier Martinez Canillas, Arnd Bergmann,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, maarten.lankhorst,
mripard, David Airlie, Simona Vetter, kys, haiyangz, Wei Liu,
decui, Long Li, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, kernel test robot
In-Reply-To: <d0624a61-b96b-4b2f-89c2-029e8671039d@app.fastmail.com>
Hi
Am 08.04.26 um 15:45 schrieb Ard Biesheuvel:
> Hi Thomas,
>
> On Thu, 2 Apr 2026, at 11:09, Thomas Zimmermann wrote:
>> The x86 architecture comes with its own instance of the global
>> state variable sysfb_primary_display. Never declare it in the EFI
>> subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID")
>> Cc: kernel test robot <lkp@intel.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Ard Biesheuvel <ardb@kernel.org>
>> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>> Cc: linux-efi@vger.kernel.org
>> ---
>> drivers/firmware/efi/efi-init.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
> Should this be sent out as a fix?
Yes, please.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 0/3] Exynos850 APM-to-AP mailbox support
From: Alexey Klimov @ 2026-04-08 14:05 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Sam Protsenko, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel
In-Reply-To: <d9c714fa-988c-4b0d-b756-c6e7a40da587@linaro.org>
On Thu Apr 2, 2026 at 9:45 AM BST, Tudor Ambarus wrote:
> Hi!
>
> On 4/2/26 5:20 AM, Alexey Klimov wrote:
>> This patch series introduces support for the APM-to-AP mailbox on the
>
> If AP initiates the communication and APM responds, shouldn't this be called
> AP-to-APM mailbox?
Yes, there is some inconsistency in the naming, in the downstream too.
If this has to be aligned with datasheet like in the comments to another
patch in this series, then name should be APM-to-AP or APM2AP for that
matter.
But let's keep it logical. I will rename it to ap2apm and will re-check.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH 08/14] KVM: arm64: Trap & emulate the ITS MAPD command
From: Sebastian Ene @ 2026-04-08 14:05 UTC (permalink / raw)
To: Fuad Tabba
Cc: alexandru.elisei, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, catalin.marinas, dbrazdil, joey.gouly, kees,
mark.rutland, maz, oupton, perlarsen, qperret, rananta, smostafa,
suzuki.poulose, tglx, vdonnefort, bgrzesik, will, yuzenghui
In-Reply-To: <CA+EHjTzfoRPvfe-SNW_e=-p+3Yy2UPu90y0bsvSJ9OOgnc7C6g@mail.gmail.com>
On Tue, Mar 17, 2026 at 10:20:14AM +0000, Fuad Tabba wrote:
Hi Fuad,
> Hi Sebastian,
>
> On Tue, 10 Mar 2026 at 12:49, Sebastian Ene <sebastianene@google.com> wrote:
> >
> > Parse the MAPD command and extract the ITT address to
> > sanitize it. When the command has the valid bit set,
> > share the memory that holds the ITT table
> > with the hypervisor to prevent it from being used
> > by someone else and track the pages in an array.
> > When the valid bit is cleared, check if the pages
> > are tracked and then remove the sharing with the
> > hypervisor.
> > Check if we need to do any shadow table updates
> > in case the device table is configured with an
> > indirect layout.
>
> Same as the previous commit message, could you please clarify the
> "why" rather than only the "how"?
Sure, I will enhance the commit message. There are at least two differnt
ways in which you can abuse this from a compromised host kernel to
attack the hypervisor memory:
One way:
1. Send a MAPD command to the ITS with an ITT address that belongs to the
hypervisor. This creates a device table entry that holds the ITT
address.
2. Use the MAPTI command to create an entry into the ITT table which
writes the entry to the previously pointed hypervisor memory.
Second way:
(assuming the device table is configured with an indirect layout)
1. Create a first level valid entry that holds a pointer to the hypervisor memory
2. Send a MAPD command so that you create a DTE in the memory pointed at
(1)
>
> For someone without deep context of the pKVM ITS isolation model, this
> message does not explain the threat vector.
>
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/its_emulate.c | 182 ++++++++++++++++++++++++++
> > drivers/irqchip/irq-gic-v3-its.c | 12 --
> > include/linux/irqchip/arm-gic-v3.h | 12 ++
> > 3 files changed, 194 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/its_emulate.c b/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > index 865a5d6353ed..722fe80dc2e5 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > @@ -12,8 +12,13 @@ struct its_priv_state {
> > void *cmd_host_cwriter;
> > struct its_shadow_tables *shadow;
> > hyp_spinlock_t its_lock;
> > + u16 empty_idx;
> > + u64 tracked_pfns[];
> > };
> >
> > +#define MAX_TRACKED_PFNS ((PAGE_SIZE - offsetof(struct its_priv_state, \
> > + tracked_pfns)) / sizeof(u64))
> > +
> > struct its_handler {
> > u64 offset;
> > u8 access_size;
> > @@ -23,6 +28,178 @@ struct its_handler {
> >
> > DEFINE_HYP_SPINLOCK(its_setup_lock);
> >
> > +static int track_pfn_add(struct its_priv_state *its, u64 pfn)
> > +{
> > + int ret, i;
> > +
> > + if (its->empty_idx + 1 >= MAX_TRACKED_PFNS)
> > + return -ENOSPC;
>
> Why +1? This wastes the final slot in the array. It should just be: if
> (its->empty_idx >= MAX_TRACKED_PFNS).
>
> More importantly, doing an O(N) linear array scan to manage empty_idx
> inside track_pfn_add and track_pfn_remove while holding the raw
> its_priv->its_lock needlessly inflates host IRQ latency. Please
> replace this array with a BITMAP.
>
> > +
> > + ret = __pkvm_host_share_hyp(pfn);
> > + if (ret)
> > + return ret;
> > +
> > + its->tracked_pfns[its->empty_idx] = pfn;
> > + for (i = 0; i < MAX_TRACKED_PFNS; i++) {
> > + if (!its->tracked_pfns[i])
> > + break;
> > + }
> > +
> > + its->empty_idx = i;
> > + return 0;
> > +}
> > +
> > +static int track_pfn_remove(struct its_priv_state *its, u64 pfn)
> > +{
> > + int i, ret;
> > +
> > + for (i = 0; i < MAX_TRACKED_PFNS; i++) {
> > + if (its->tracked_pfns[i] != pfn)
> > + continue;
> > +
> > + ret = __pkvm_host_unshare_hyp(pfn);
> > + if (ret)
> > + return ret;
> > +
> > + its->tracked_pfns[i] = 0;
> > + its->empty_idx = i;
> > + }
> > +
> > + return 0;
> > +}
>
> If the PFN isn't found in the array, this silently returns 0 (success).
>
> > +
> > +static int get_num_itt_pages(struct its_priv_state *its, u8 num_bits)
> > +{
> > + int nr_ites = 1 << (num_bits + 1);
> > + u64 size, gits_typer = readq_relaxed(its->base + GITS_TYPER);
> > +
> > + size = nr_ites * (FIELD_GET(GITS_TYPER_ITT_ENTRY_SIZE, gits_typer) + 1);
> > + size = max(size, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> > +
> > + return PAGE_ALIGN(size) >> PAGE_SHIFT;
> > +}
> > +
> > +static int track_pfn(struct its_priv_state *its, u64 start_pfn, int num_pages, bool remove)
> > +{
> > + int i, ret;
> > +
> > + for (i = 0; i < num_pages; i++) {
> > + if (remove)
> > + ret = track_pfn_remove(its, start_pfn + i);
> > + else
> > + ret = track_pfn_add(its, start_pfn + i);
> > +
> > + if (ret)
> > + goto err_track;
> > + }
> > +
> > + return 0;
> > +err_track:
> > + for (i = i - 1; i >= 0; i--) {
> > + if (remove)
> > + track_pfn_add(its, start_pfn + i);
> > + else
> > + track_pfn_remove(its, start_pfn + i);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static struct its_baser *get_table(struct its_priv_state *its, u64 type)
> > +{
> > + int i;
> > + struct its_shadow_tables *shadow = its->shadow;
> > +
> > + for (i = 0; i < GITS_BASER_NR_REGS; i++) {
> > + if (GITS_BASER_TYPE(shadow->tables[i].val) == type)
> > + return &shadow->tables[i];
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +static int check_table_update(struct its_priv_state *its, u32 id, u64 type)
> > +{
> > + u32 lvl1_idx;
> > + u64 esz, *host_table, *hyp_table, new_entry, update;
> > + struct its_baser *table = get_table(its, type);
> > + int ret;
> > + phys_addr_t new_lvl2_table, lvl2_table;
> > +
> > + if (!table)
> > + return -EINVAL;
> > +
> > + if (!(table->val & GITS_BASER_INDIRECT))
> > + return 0;
> > +
> > + esz = GITS_BASER_ENTRY_SIZE(table->val);
> > + lvl1_idx = id / (table->psz / esz);
> > +
> > + host_table = kern_hyp_va(table->shadow);
> > + hyp_table = kern_hyp_va(table->base);
> > +
> > + new_entry = host_table[id];
>
> This accesses the entry based on id, which isn't sanitized.
>
I should use lvl1_idx instead of id and sanitize this.
> > + update = new_entry ^ hyp_table[id];
> > + if (!update || !(update & GITS_BASER_VALID))
> > + return 0;
>
> This assumes any meaningful update must toggle the Valid bit. If the
> host issues a MAPD that changes the Level 2 table pointer but keeps
> Valid=1, update & GITS_BASER_VALID is 0.
>
That is exactly what it does but it is expected because it usually
transitions from valid -> invalid and the address doesn't change without
this state transition.
> > +
> > + new_lvl2_table = hyp_phys_to_pfn(new_entry & PHYS_MASK_SHIFT);
> > + lvl2_table = hyp_phys_to_pfn(hyp_table[id] & PHYS_MASK_SHIFT);
>
> Should this be PHYS_MASK?
Yes good catch !
>
> > + if (new_entry & GITS_BASER_VALID)
> > + ret = __pkvm_host_donate_hyp(new_lvl2_table, table->psz >> PAGE_SHIFT);
> > + else
> > + ret = __pkvm_hyp_donate_host(lvl2_table, table->psz >> PAGE_SHIFT);
>
> Similar issue to the one I mentioned in a previous patch regarding ITS
> page size vs host page size.
>
>
> > + if (ret)
> > + return ret;
> > +
> > + hyp_table[id] = new_entry;
> > + return 0;
> > +}
> > +
> > +static int process_its_mapd(struct its_priv_state *its, struct its_cmd_block *cmd)
> > +{
> > + phys_addr_t itt_addr = cmd->raw_cmd[2] & GENMASK(51, 8);
> > + u8 size = cmd->raw_cmd[1] & GENMASK(4, 0);
> > + bool remove = !(cmd->raw_cmd[2] & BIT(63));
> > + u32 device_id = cmd->raw_cmd[0] >> 32;
> > + int num_pages, ret;
> > + u64 base_pfn;
> > +
> > + if (PAGE_ALIGNED(itt_addr))
> > + return -EINVAL;
>
> This is inverted, right?
>
Ouch (hide) yes, I will fix this.
> Cheers,
> /fuad
Cheers,
Sebastian
>
> > +
> > + base_pfn = hyp_phys_to_pfn(itt_addr);
> > + num_pages = get_num_itt_pages(its, size);
> > +
> > + ret = check_table_update(its, device_id, GITS_BASER_TYPE_DEVICE);
> > + if (ret)
> > + return ret;
> > +
> > + return track_pfn(its, base_pfn, num_pages, remove);
> > +}
> > +
> > +static int parse_its_cmdq(struct its_priv_state *its, int offset, ssize_t len)
> > +{
> > + struct its_cmd_block *cmd = its->cmd_hyp_base + offset;
> > + u8 req_type;
> > + int ret = 0;
> > +
> > + while (len > 0 && !ret) {
> > + req_type = cmd->raw_cmd[0] & GENMASK(7, 0);
> > +
> > + switch (req_type) {
> > + case GITS_CMD_MAPD:
> > + ret = process_its_mapd(its, cmd);
> > + break;
> > + }
> > +
> > + cmd++;
> > + len -= sizeof(struct its_cmd_block);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static void cwriter_write(struct its_priv_state *its, u64 offset, u64 value)
> > {
> > u64 cwriter_offset = value & GENMASK(19, 5);
> > @@ -41,11 +218,15 @@ static void cwriter_write(struct its_priv_state *its, u64 offset, u64 value)
> > return;
> >
> > memcpy(its->cmd_hyp_base + cmd_offset, its->cmd_host_cwriter, cmd_len);
> > + if (parse_its_cmdq(its, cmd_offset, cmd_len))
> > + return;
> >
> > its->cmd_host_cwriter = its->cmd_host_base +
> > (cmd_offset + cmd_len) % cmdq_sz;
> > if (its->cmd_host_cwriter == its->cmd_host_base) {
> > memcpy(its->cmd_hyp_base, its->cmd_host_base, cwriter_offset);
> > + if (parse_its_cmdq(its, cmd_offset, cmd_len))
> > + return;
> >
> > its->cmd_host_cwriter = its->cmd_host_base + cwriter_offset;
> > }
> > @@ -357,6 +538,7 @@ int pkvm_init_gic_its_emulation(phys_addr_t dev_addr, void *host_priv_state,
> > priv_state->cmd_hyp_base = kern_hyp_va(shadow->cmd_original);
> > priv_state->cmd_host_base = kern_hyp_va(shadow->cmd_shadow);
> > priv_state->cmd_host_cwriter = priv_state->cmd_host_base;
> > + priv_state->empty_idx = 0;
> >
> > hyp_spin_unlock(&its_setup_lock);
> >
> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> > index 278dbc56f962..be78f7dccb9f 100644
> > --- a/drivers/irqchip/irq-gic-v3-its.c
> > +++ b/drivers/irqchip/irq-gic-v3-its.c
> > @@ -121,8 +121,6 @@ static DEFINE_PER_CPU(struct its_node *, local_4_1_its);
> > #define is_v4_1(its) (!!((its)->typer & GITS_TYPER_VMAPP))
> > #define device_ids(its) (FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1)
> >
> > -#define ITS_ITT_ALIGN SZ_256
> > -
> > /* The maximum number of VPEID bits supported by VLPI commands */
> > #define ITS_MAX_VPEID_BITS \
> > ({ \
> > @@ -515,16 +513,6 @@ struct its_cmd_desc {
> > };
> > };
> >
> > -/*
> > - * The ITS command block, which is what the ITS actually parses.
> > - */
> > -struct its_cmd_block {
> > - union {
> > - u64 raw_cmd[4];
> > - __le64 raw_cmd_le[4];
> > - };
> > -};
> > -
> > #define ITS_CMD_QUEUE_SZ SZ_64K
> > #define ITS_CMD_QUEUE_NR_ENTRIES (ITS_CMD_QUEUE_SZ / sizeof(struct its_cmd_block))
> >
> > diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> > index 40457a4375d4..4f7d47f3d970 100644
> > --- a/include/linux/irqchip/arm-gic-v3.h
> > +++ b/include/linux/irqchip/arm-gic-v3.h
> > @@ -612,6 +612,8 @@
> > */
> > #define GIC_IRQ_TYPE_LPI 0xa110c8ed
> >
> > +#define ITS_ITT_ALIGN SZ_256
> > +
> > struct rdists {
> > struct {
> > raw_spinlock_t rd_lock;
> > @@ -634,6 +636,16 @@ struct rdists {
> > bool has_vpend_valid_dirty;
> > };
> >
> > +/*
> > + * The ITS command block, which is what the ITS actually parses.
> > + */
> > +struct its_cmd_block {
> > + union {
> > + u64 raw_cmd[4];
> > + __le64 raw_cmd_le[4];
> > + };
> > +};
> > +
> > struct irq_domain;
> > struct fwnode_handle;
> > int __init its_lpi_memreserve_init(void);
> > --
> > 2.53.0.473.g4a7958ca14-goog
> >
^ permalink raw reply
* Re: [RFC PATCH 5/8] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Dev Jain @ 2026-04-08 14:03 UTC (permalink / raw)
To: Barry Song (Xiaomi), linux-mm, linux-arm-kernel, catalin.marinas,
will, akpm, urezki
Cc: linux-kernel, anshuman.khandual, ryan.roberts, ajd, rppt, david,
Xueyuan.chen21
In-Reply-To: <20260408025115.27368-6-baohua@kernel.org>
On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
> In many cases, the pages passed to vmap() may include high-order
> pages allocated with __GFP_COMP flags. For example, the systemheap
> often allocates pages in descending order: order 8, then 4, then 0.
> Currently, vmap() iterates over every page individually—even pages
> inside a high-order block are handled one by one.
>
> This patch detects high-order pages and maps them as a single
> contiguous block whenever possible.
>
> An alternative would be to implement a new API, vmap_sg(), but that
> change seems to be large in scope.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> ---
> mm/vmalloc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index eba436386929..e8dbfada42bc 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3529,6 +3529,53 @@ void vunmap(const void *addr)
> }
> EXPORT_SYMBOL(vunmap);
>
> +static inline int get_vmap_batch_order(struct page **pages,
> + unsigned int max_steps, unsigned int idx)
> +{
> + unsigned int nr_pages;
> +
> + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP) ||
> + ioremap_max_page_shift == PAGE_SHIFT)
> + return 0;
> +
> + nr_pages = compound_nr(pages[idx]);
> + if (nr_pages == 1 || max_steps < nr_pages)
> + return 0;
This assumes that the page array passed to vmap() will have compound pages
if it is a higher order allocation.
See rb_alloc_aux_page(). It gets higher-order allocations without passing
GFP_COMP.
That is why my implementation does not assume anything about the property
of the pages.
Also it may be useful to do regression-testing for the common case of
vmap() with a single page (assuming it is common, I don't know), in
which case we may have to special case it.
My implementation requires opting in with VM_ALLOW_HUGE_VMAP - I suspect
you may run into problems if you make vmap() do huge-mappings as best-effort
by default. I am guessing this because ...
Drivers can operate on individual pages, so vmalloc() calls split_page()
and then does the block/cont mappings. This same issue should be present
with vmap() too? In which case if we are to do huge-mappings by default
then we can do split_page() after detecting contiguous chunks.
But ... that may create problems for the caller of vmap() - vmap now
has the changed the properties of the pages.
> +
> + if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages)
> + return compound_order(pages[idx]);
> + return 0;
> +}
> +
> +static int vmap_contig_pages_range(unsigned long addr, unsigned long end,
> + pgprot_t prot, struct page **pages)
> +{
> + unsigned int count = (end - addr) >> PAGE_SHIFT;
> + int err;
> +
> + err = kmsan_vmap_pages_range_noflush(addr, end, prot, pages,
> + PAGE_SHIFT, GFP_KERNEL);
> + if (err)
> + goto out;
> +
> + for (unsigned int i = 0; i < count; ) {
> + unsigned int shift = PAGE_SHIFT +
> + get_vmap_batch_order(pages, count - i, i);
> +
> + err = vmap_range_noflush(addr, addr + (1UL << shift),
> + page_to_phys(pages[i]), prot, shift);
> + if (err)
> + goto out;
> +
> + addr += 1UL << shift;
> + i += 1U << (shift - PAGE_SHIFT);
> + }
> +
> +out:
> + flush_cache_vmap(addr, end);
> + return err;
> +}
> +
> /**
> * vmap - map an array of pages into virtually contiguous space
> * @pages: array of page pointers
> @@ -3572,8 +3619,8 @@ void *vmap(struct page **pages, unsigned int count,
> return NULL;
>
> addr = (unsigned long)area->addr;
> - if (vmap_pages_range(addr, addr + size, pgprot_nx(prot),
> - pages, PAGE_SHIFT) < 0) {
> + if (vmap_contig_pages_range(addr, addr + size, pgprot_nx(prot),
> + pages) < 0) {
> vunmap(area->addr);
> return NULL;
> }
^ permalink raw reply
* Re: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Russell King (Oracle) @ 2026-04-08 13:59 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel, iommu, linux-ext4,
Linus Torvalds
Cc: Marek Szyprowski, Robin Murphy, Theodore Ts'o, Andreas Dilger
In-Reply-To: <adZTGOjjJrVJOcT8@shell.armlinux.org.uk>
On Wed, Apr 08, 2026 at 02:07:36PM +0100, Russell King (Oracle) wrote:
> Hi,
>
> Just a heads-up that current net-next (v7.0-rc6 based) fails to boot on
> my nVidia Jetson Xavier platform. v7.0-rc5 and v6.14 based net-next both
> boot fine. This is an arm64 platform.
>
> The problem appears to be completely random in terms of its symptoms,
> and looks like severe memory corruption - every boot seems to produce
> a different problem. The common theme is, although the kernel gets to
> userspace, it never gets anywhere close to a login prompt before
> failing in some way.
>
> The last net-next+ boot (which is currently v7.0-rc6 based) resulted
> in:
>
> tegra-mc 2c00000.memory-controller: xusb_hostw: secure write @0x00000003ffffff00: VPR violation ((null))
> ...
> irq 91: nobody cared (try booting with the "irqpoll" option)
> ...
> depmod: ERROR: could not open directory /lib/modules/7.0.0-rc6-net-next+: No such file or directory
> ...
> Unable to handle kernel paging request at virtual address 0003201fd50320cf
>
>
> A previous boot of the exact same kernel didn't oops, but was unable
> to find the block device to mount for /mnt via block UUID.
>
> A previous boot to that resulted in an oops.
>
>
> The intersting thing is - the depmod error above is incorrect:
>
> root@tegra-ubuntu:~# ls -ld /lib/modules/7.0.0-rc6-net-next+
> drwxrwxr-x 3 root root 4096 Apr 8 10:23 /lib/modules/7.0.0-rc6-net-next+
>
> The directory is definitely there, and is readable - checked after
> booting back into net-next based on 7.0-rc5. In some of these boots,
> stmmac hasn't probed yet, which rules out my changes.
>
> Rootfs is ext4, and it seems there were a lot of ext4 commits merged
> between rc5 and rc6, but nothing for rc7.
>
> My current net-next head is dfecb0c5af3b. Merging rc7 on top also
> fails, I suspect also randomly, with that I just got:
>
> EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error.
> mount: /mnt/: can't find PARTUUID=741c0777-391a-4bce-a222-455e180ece2a.
> Unable to handle kernel paging request at virtual address f9bf0011ac0fb893
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [f9bf0011ac0fb893] address between user and kernel address ranges
> Internal error: Oops: 0000000096000004 [#1] SMP
> Modules linked in:
> CPU: 1 UID: 0 PID: 936 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
> Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : refill_objects+0x298/0x5ec
> lr : refill_objects+0x1f0/0x5ec
>
> ...
>
> Call trace:
> refill_objects+0x298/0x5ec (P)
> __pcs_replace_empty_main+0x13c/0x3a8
> kmem_cache_alloc_noprof+0x324/0x3a0
> alloc_iova+0x3c/0x290
> alloc_iova_fast+0x168/0x2d4
> iommu_dma_alloc_iova+0x84/0x154
> iommu_dma_map_sg+0x2c4/0x538
> __dma_map_sg_attrs+0x124/0x2c0
> dma_map_sg_attrs+0x10/0x20
> sdhci_pre_dma_transfer+0xb8/0x164
> sdhci_pre_req+0x38/0x44
> mmc_blk_mq_issue_rq+0x3dc/0x920
> mmc_mq_queue_rq+0x104/0x2b0
> __blk_mq_issue_directly+0x38/0xb0
> blk_mq_request_issue_directly+0x54/0xb4
> blk_mq_issue_direct+0x84/0x180
> blk_mq_dispatch_queue_requests+0x1a8/0x2e0
> blk_mq_flush_plug_list+0x60/0x140
> __blk_flush_plug+0xe0/0x11c
> blk_finish_plug+0x38/0x4c
> read_pages+0x158/0x260
> page_cache_ra_unbounded+0x158/0x3e0
> force_page_cache_ra+0xb0/0xe4
> page_cache_sync_ra+0x88/0x480
> filemap_get_pages+0xd8/0x850
> filemap_read+0xdc/0x3d8
> blkdev_read_iter+0x84/0x198
> vfs_read+0x208/0x2d8
> ksys_read+0x58/0xf4
> __arm64_sys_read+0x1c/0x28
> invoke_syscall.constprop.0+0x50/0xe0
> do_el0_svc+0x40/0xc0
> el0_svc+0x48/0x2a0
> el0t_64_sync_handler+0xa0/0xe4
> el0t_64_sync+0x19c/0x1a0
> Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Oops: Fatal exception
>
> Looking at the changes between rc5 and rc6, there's one drivers/block
> change for zram (which is used on this platform), one change in
> drivers/base for regmap, nothing for drivers/mmc, but plenty for
> fs/ext4. There are five DMA API changes.
>
> Now building straight -rc7. If that also fails, my plan is to start
> bisecting rc5..rc6, which will likely take most of the rest of the
> day. So, in the mean time I'm sending this as a heads-up that rc6
> and onwards has a problem.
Plain -rc7 fails (another random oops):
Root device found: PARTUUID=741c0777-391a-4bce-a222-455e180ece2a
depmod: ERROR: could not open directory /lib/modules/7.0.0-rc7-net-next+: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
usb 2-3: new SuperSpeed Plus Gen 2x1 USB device number 2 using tegra-xusb
hub 2-3:1.0: USB hub found
hub 2-3:1.0: 4 ports detected
usb 1-3: new full-speed USB device number 3 using tegra-xusb
Unable to handle kernel paging request at virtual address 0003201fd50320cf
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[0003201fd50320cf] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in:
CPU: 1 UID: 0 PID: 917 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : refill_objects+0x298/0x5ec
lr : refill_objects+0x1f0/0x5ec
sp : ffff80008606b500
x29: ffff80008606b500 x28: 0000000000000001 x27: fffffdffc20e6200
x26: 0000000000000006 x25: 0000000000000000 x24: 000000000000003c
x23: ffff0000809e4840 x22: ffff0000809dba00 x21: ffff80008606b5a0
x20: ffff000081133820 x19: fffffdffc20e6220 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000100 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: ffff800081e5faa8
x11: ffff800082192c70 x10: ffff8000814074dc x9 : 0000000000000050
x8 : ffff80008606b490 x7 : ffff000083988b40 x6 : ffff80008606b4a0
x5 : 000000080015000f x4 : d503201fd503201f x3 : 00000000000000b0
x2 : d503201fd503201f x1 : ffff000081133828 x0 : d503201fd503201f
Call trace:
refill_objects+0x298/0x5ec (P)
__pcs_replace_empty_main+0x13c/0x3a8
kmem_cache_alloc_noprof+0x324/0x3a0
mempool_alloc_slab+0x1c/0x28
mempool_alloc_noprof+0x98/0xe0
bio_alloc_bioset+0x160/0x3e0
do_mpage_readpage+0x3d0/0x618
mpage_readahead+0xb8/0x144
blkdev_readahead+0x18/0x24
read_pages+0x58/0x260
page_cache_ra_unbounded+0x158/0x3e0
force_page_cache_ra+0xb0/0xe4
page_cache_sync_ra+0x88/0x480
filemap_get_pages+0xd8/0x850
filemap_read+0xdc/0x3d8
blkdev_read_iter+0x84/0x198
vfs_read+0x208/0x2d8
ksys_read+0x58/0xf4
__arm64_sys_read+0x1c/0x28
invoke_syscall.constprop.0+0x50/0xe0
do_el0_svc+0x40/0xc0
el0_svc+0x48/0x2a0
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x19c/0x1a0
Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
---[ end trace 0000000000000000 ]---
Now starting the bisect between 7.0-rc5 and 7.0-rc6.
--
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: [PATCH] nvme-apple: drop invalid put of admin queue reference count
From: Fedor Pchelkin @ 2026-04-08 13:57 UTC (permalink / raw)
To: Jens Axboe
Cc: Keith Busch, Christoph Hellwig, Sven Peter, Janne Grunau,
Neal Gompa, Sagi Grimberg, Hannes Reinecke, Ming Lei,
Chaitanya Kulkarni, Heyne, Maximilian, asahi, linux-arm-kernel,
linux-nvme, linux-kernel, lvc-project, stable
In-Reply-To: <8143e057-4c3b-4365-8780-003e897b9baf@kernel.dk>
On Mon, 06. Apr 20:20, Jens Axboe wrote:
> On 4/3/26 2:27 PM, Fedor Pchelkin wrote:
> > @@ -1269,8 +1269,6 @@ static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
> > {
> > struct apple_nvme *anv = ctrl_to_apple_nvme(ctrl);
> >
> > - if (anv->ctrl.admin_q)
> > - blk_put_queue(anv->ctrl.admin_q);
> > put_device(anv->dev);
> > }
>
> Could this just be:
>
> static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
> {
> put_device(ctrl->dev);
> }
>
> at this point?
Right, ctrl->dev and anv->dev point to the same device. I'll simplify in v2.
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: imx952: Describe Mali G310 GPU
From: Liviu Dudau @ 2026-04-08 13:56 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260407-master-v3-1-5a05cea0c521@nxp.com>
On Tue, Apr 07, 2026 at 11:15:03AM +0800, Guangliu Ding wrote:
> Support Mali G310 GPU on i.MX952 board. Describe this GPU in the DT.
> Include dummy GPU voltage regulator and OPP tables.
>
> A hardware GPU auto clock‑gating mechanism has been introduced,
> enabling GPUMIX to automatically manage the GPU clock. This improves
> overall response time.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
> IP as the instance on i.MX95 boards.
> ---
> Changes in v3:
> - Follow the order of interrupts/interrupt-names in arm,mali-valhall-csf.yaml.
> - Drop dt-bindings change in arm,mali-valhall-csf.yaml.
> - Replace "nxp,imx952-mali" with "nxp,imx95-mali" in compatible.
> - Link to v2: https://patch.msgid.link/20260401-master-v2-0-20d3fbcd19d6@nxp.com
>
> Changes in v2:
> - Improve patch description, adding more GPU information.
> - Remove Reviewed-by tag.
> - Link to v1: https://patch.msgid.link/20260331-master-v1-0-65c8e318d462@nxp.com
> ---
> arch/arm64/boot/dts/freescale/imx952.dtsi | 36 +++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
> index 91fe4916ac04..ced09e7a1dc5 100644
> --- a/arch/arm64/boot/dts/freescale/imx952.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
> @@ -318,6 +318,28 @@ usbphynop2: usbphynop2 {
> clock-names = "main_clk";
> };
>
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + opp-hz-real = /bits/ 64 <500000000>;
> + opp-microvolt = <920000>;
> + };
> +
> + opp-800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-hz-real = /bits/ 64 <800000000>;
> + opp-microvolt = <920000>;
> + };
> +
> + opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-hz-real = /bits/ 64 <1000000000>;
> + opp-microvolt = <920000>;
> + };
> + };
> +
> soc {
> compatible = "simple-bus";
> #address-cells = <2>;
> @@ -1262,5 +1284,19 @@ usbmisc2: usbmisc@4c200200 {
> reg = <0x0 0x4c200200 0x0 0x200>,
> <0x0 0x4c010014 0x0 0x4>;
> };
> +
> + gpu: gpu@4d900000 {
> + compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
> + reg = <0 0x4d900000 0 0x480000>;
> + interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&scmi_clk IMX952_CLK_GPU>;
> + clock-names = "core";
> + power-domains = <&scmi_devpd IMX952_PD_GPU>;
> + operating-points-v2 = <&gpu_opp_table>;
> + dynamic-power-coefficient = <1013>;
> + };
> };
> };
>
> ---
> base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
> change-id: 20260331-master-7ec7ff0fe1b2
>
> Best regards,
> --
> Guangliu Ding <guangliu.ding@nxp.com>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
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