* Re: [PATCH v3] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Paul Moore @ 2026-07-02 13:27 UTC (permalink / raw)
To: Venkat Rao Bagalkote, rrobaina
Cc: Christophe Leroy (CS GROUP), Madhavan Srinivasan,
Harsh Prateek Bora, Michael Ellerman, Nicholas Piggin, Eric Paris,
linux-kernel, linuxppc-dev, audit, Thomas Weissschuh,
Cédric Le Goater, ritesh.list
In-Reply-To: <203f6e6d-2ce8-4e47-99a6-f4af745e0aaa@linux.ibm.com>
On Thu, Jul 2, 2026 at 8:50 AM Venkat Rao Bagalkote
<venkat88@linux.ibm.com> wrote:
>
> Current remaining issue:
>
> 1. amcast_joinpart
> ------------------
> Still fails due to a missing Perl dependency:
>
> Can't locate Socket/Netlink.pm in @INC
>
> I searched the configured repositories and could not find a package
> providing Socket::Netlink / Socket/Netlink.pm on this EL10 ppc64le system.
>
> Latest run summary:
>
> amcast_joinpart/test ................. Can't locate Socket/Netlink.pm in
> @INC (you may need to install the Socket::Netlink module) (@INC entries
> checked: /usr/local/lib64/perl5/5.40 /usr/local/share/perl5/5.40
> /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
> /usr/lib64/perl5 /usr/share/perl5 .) at amcast_joinpart/test line 10.
> BEGIN failed--compilation aborted at amcast_joinpart/test line 10.
> amcast_joinpart/test ................. Dubious, test returned 2 (wstat
> 512, 0x200)
> Failed 7/7 subtests
> backlog_wait_time_actual_reset/test .. ok
> bpf/test ............................. ok
> exec_execve/test ..................... ok
> exec_name/test ....................... ok
> fanotify/test ........................ ok
> field_compare/test ................... ok
> file_create/test ..................... ok
> file_delete/test ..................... ok
> file_permission/test ................. ok
> file_rename/test ..................... ok
> filter_exclude/test .................. ok
> filter_exit/test ..................... ok
> filter_saddr_fam/test ................ ok
> filter_sessionid/test ................ ok
> io_uring/test ........................ ok
> login_tty/test ....................... ok
> lost_reset/test ...................... ok
> netfilter_pkt/test ................... ok
> signal/test .......................... ok
> syscalls_file/test ................... ok
> syscall_module/test .................. ok
> time_change/test ..................... ok
> user_msg/test ........................ ok
>
> All tests now pass except amcast_joinpart, which is blocked by the
> missing Socket::Netlink Perl module.
>
> Please let me know if there is a recommended package source for
> Socket::Netlink on EL10 ppc64le.
Thanks for following up on this Venkat.
I'm adding your colleague Ricardo from the RH side of the house.
Ricardo is very familiar with audit and should be able to help you
with missing RHEL packages.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 11/13] mm/mlock: convert mlock code to use vma_flags_t
From: Lance Yang @ 2026-07-02 13:21 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <2db16db81538355ca65f778c246d2381c673cad4.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:34PM +0100, Lorenzo Stoakes wrote:
>Replace use of the legacy vm_flags_t flags with vma_flags_t values
>throughout the mlock logic.
>
>Additionally update comments to reflect the changes to be consistent.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nothing scary jumped out at me. Just one tiny nit below ;)
[...]
>@@ -466,24 +466,23 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma,
> */
> static int mlock_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma,
> struct vm_area_struct **prev, unsigned long start,
>- unsigned long end, vm_flags_t newflags)
>+ unsigned long end, vma_flags_t *new_vma_flags)
> {
>- vma_flags_t new_vma_flags = legacy_to_vma_flags(newflags);
> const vma_flags_t old_vma_flags = vma->flags;
> struct mm_struct *mm = vma->vm_mm;
> int nr_pages;
> int ret = 0;
>
>- if (vma_flags_same_pair(&old_vma_flags, &new_vma_flags) ||
>+ if (vma_flags_same_pair(&old_vma_flags, new_vma_flags) ||
> vma_is_secretmem(vma) || !vma_supports_mlock(vma)) {
> /*
>- * Don't set VM_LOCKED or VM_LOCKONFAULT and don't count.
>+ * Don't set VMA_LOCKED_BIT or VM_LOCKONFAULT and don't count.
s/VM_LOCKONFAULT/VMA_LOCKONFAULT_BIT/
Otherwise LGTM. Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
> * For secretmem, don't allow the memory to be unlocked.
> */
> goto out;
> }
>
>- vma = vma_modify_flags(vmi, *prev, vma, start, end, &new_vma_flags);
>+ vma = vma_modify_flags(vmi, *prev, vma, start, end, new_vma_flags);
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> goto out;
[...]
^ permalink raw reply
* Re: [PATCH 10/13] mm/vma: convert miscellaneous uses of VMA flags in core mm
From: Lance Yang @ 2026-07-02 13:12 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <1e7d834c887b6a65627d730addcff13d458c6268.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:33PM +0100, Lorenzo Stoakes wrote:
>Update various uses of legacy flags in vma.c and mmap.c to the new
>vma_flags_t type, updating comments alongside them to be consistent.
>
>Also update __install_special_mapping() to rearrange things slightly to
>accommodate the changes.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
[...]
>diff --git a/mm/vma.c b/mm/vma.c
>index b81c05e67a61..ab2ef0f04420 100644
>--- a/mm/vma.c
>+++ b/mm/vma.c
>@@ -3417,23 +3417,27 @@ struct vm_area_struct *__install_special_mapping(
> vm_flags_t vm_flags, void *priv,
> const struct vm_operations_struct *ops)
> {
>- int ret;
>+ vma_flags_t vma_flags = legacy_to_vma_flags(vm_flags);
> struct vm_area_struct *vma;
>+ int ret;
>
> vma = vm_area_alloc(mm);
>- if (unlikely(vma == NULL))
>+ if (unlikely(!vma))
> return ERR_PTR(-ENOMEM);
>
>- vma_set_range(vma, addr, addr + len, 0);
>- vm_flags |= vma_flags_to_legacy(mm->def_vma_flags) | VM_DONTEXPAND;
>+ vma_flags_set_mask(&vma_flags, mm->def_vma_flags);
>+ vma_flags_set(&vma_flags, VMA_DONTEXPAND_BIT);
> if (pgtable_supports_soft_dirty())
>- vm_flags |= VM_SOFTDIRTY;
>- vm_flags_init(vma, vm_flags & ~VM_LOCKED_MASK);
>+ vma_flags_set(&vma_flags, VMA_SOFTDIRTY_BIT);
>+ vma_flags_clear_mask(&vma_flags, VMA_LOCKED_MASK);
>+ vma->flags = vma_flags;
Maybe worth a vma_flags_init() helper here to mirror vm_flags_init()?
With this open-coded, we lose the soft-dirty WARN_ON_ONCE sanity check.
Might be nicer to keep that check in one place ;)
[...]
^ permalink raw reply
* Re: [PATCH v15 0/8] arm64: add ARCH_HAS_COPY_MC support
From: Ashok Raj @ 2026-07-02 12:17 UTC (permalink / raw)
To: Ruidong Tian
Cc: catalin.marinas, will, rafael, tony.luck, guohanjun, mchehab,
xueshuai, tongtiangen, james.morse, robin.murphy, andreyknvl,
dvyukov, vincenzo.frascino, mpe, npiggin, ryabinin.a.a, glider,
christophe.leroy, aneesh.kumar, naveen.n.rao, tglx, mingo,
linux-arm-kernel, linux-mm, linuxppc-dev, linux-kernel, kasan-dev,
Ashok Raj
In-Reply-To: <20260618092124.3901230-1-tianruidong@linux.alibaba.com>
On Thu, Jun 18, 2026 at 05:21:14PM +0800, Ruidong Tian wrote:
> This series continues Tong Tiangen's work on arm64 ARCH_HAS_COPY_MC
> support. We encounter the same problem, and from a forward-looking
> perspective, large-memory ARM machines will suffer more from this class
> of issues, which motivates us to push this feature upstream.
>
> Problem
> =========
> With the increase of memory capacity and density, the probability of memory
> error also increases. The increasing size and density of server RAM in data
> centers and clouds have shown increased uncorrectable memory errors.
>
> Currently, more and more scenarios that can tolerate memory errors, such as
> COW[1,2,8,9], KSM copy[3], coredump copy[4], khugepaged[5,6], uaccess copy[7],
> page migration[10,11], etc.
>
Hi Ruidong,
just a minor editorial nit :-)
> [PATCH v15 0/8] arm64: add ARCH_HAS_COPY_MC support
the series has 9 patches, but Subject says 0/8.
Cheers,
Ashok
^ permalink raw reply
* Re: [PATCH 09/13] mm/vma: update create_init_stack_vma() to use vma_flags_t
From: Lance Yang @ 2026-07-02 12:50 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <34689784ee6856f100c02ad4eabeaa4db643713a.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:32PM +0100, Lorenzo Stoakes wrote:
>Replace use of the legacy vm_flags_t flags with vma_flags_t values in
>create_init_stack_vma().
>
>As part of this change we add VMA_STACK_EARLY and VMA_STACK_INCOMPLETE
>vma_flags_t defines, and slightly rework create_init_stack_vma() for
>clarity.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nothing looks off to me ;) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH v3] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Venkat Rao Bagalkote @ 2026-07-02 12:49 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), Madhavan Srinivasan, Paul Moore
Cc: Harsh Prateek Bora, Michael Ellerman, Nicholas Piggin, Eric Paris,
linux-kernel, linuxppc-dev, audit, Thomas Weissschuh,
Cédric Le Goater, ritesh.list
In-Reply-To: <ba00c7a8-b4d5-4d80-859b-d75e9c91ebdb@kernel.org>
On 01/07/26 2:23 pm, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 01/07/2026 à 10:09, Venkat Rao Bagalkote a écrit :
>>
>> On 01/07/26 10:26 am, Christophe Leroy (CS GROUP) wrote:
>>>
>>>
>>> Le 01/07/2026 à 06:32, Venkat Rao Bagalkote a écrit :
>>>>
>>>> On 01/07/26 7:44 am, Madhavan Srinivasan wrote:
>>>>>
>>>>> On 7/1/26 12:41 AM, Paul Moore wrote:
>>>>>> On Wed, May 13, 2026 at 1:42 AM Madhavan Srinivasan
>>>>>> <maddy@linux.ibm.com> wrote:
>>>>>>> On 5/13/26 10:05 AM, Harsh Prateek Bora wrote:
>>>>>>>> On 11/03/26 12:49 am, Paul Moore wrote:
>>>>>>>>> On Tue, Mar 10, 2026 at 11:08 AM Christophe Leroy (CS GROUP)
>>>>>>>>> <chleroy@kernel.org> wrote:
>>>>>>>>>> From: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>>>>>>>>
>>>>>>>>>> Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all
>>>>>>>>>> normal
>>>>>>>>>> targets") added generic support for AUDIT but that didn't
>>>>>>>>>> include
>>>>>>>>>> support for bi-arch like powerpc.
>>>>>>>>>>
>>>>>>>>>> Commit 4b58841149dc ("audit: Add generic compat syscall
>>>>>>>>>> support")
>>>>>>>>>> added generic support for bi-arch.
>>>>>>>>>>
>>>>>>>>>> Convert powerpc to that bi-arch generic audit support.
>>>>>>>>>>
>>>>>>>>>> With this change generated text is similar.
>>>>>>>>>>
>>>>>>>>>> Thomas has confirmed that the previously failing
>>>>>>>>>> filter_exclude/test
>>>>>>>>>> is now successful both without and with this patch, see [1]
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://eur01.safelinks.protection.outlook.com/?
>>>>>>>>>> url=https%3A%2F%2Flore.kernel.org%2Fall%2F20260306115350-
>>>>>>>>>> ef265661-6d6b-4043-9bd0-8e6b437d0d67%40linutronix.de%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C81e1e4e3bae245103d3308ded729bb47%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639184771399964577%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FtCHXFR5np67gntCnXqv7Eemo5WuwaIEcywxZQzDADA%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> Link: https://eur01.safelinks.protection.outlook.com/?
>>>>>>>>>> url=https%3A%2F%2Fgithub.com%2Flinuxppc%2Fissues%2Fissues%2F412&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C81e1e4e3bae245103d3308ded729bb47%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639184771400190794%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4fPEX7HuGBcxOcXlcJVQvDdP7Y9InhDpbz3z%2BS9lkCQ%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>>>>>>>> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>>>>>>>>>> ---
>>>>>>>>>> Venkat, a test result with
>>>>>>>>>> https://eur01.safelinks.protection.outlook.com/?
>>>>>>>>>> url=https%3A%2F%2Fgithub.com%2Flinux-audit%2Faudit-
>>>>>>>>>> testsuite&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C81e1e4e3bae245103d3308ded729bb47%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639184771400214912%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yHp3p5zNx%2BqQg2cKBsKJADWcUcKVtZstzNScBfWzF%2FQ%3D&reserved=0
>>>>>>>>>> would be appreciated.
>>>>>>>>> Yes, I'd like to see confirmation that the audit test suite
>>>>>>>>> runs clean
>>>>>>>>> on ppc systems with this patch applied, and unfortunately
>>>>>>>>> without a
>>>>>>>>> ppc system I have no way to test this myself.
>>>>>>> My bad, this is a miss from my end.
>>>>>>> Venkat is already on this and will update the results here.
>>>>>> Do we have an update on this? Maybe I missed it, but I don't recall
>>>>>> seeing any test results.
>>>>> Venkat, did run the test but I guess he missed to respond here,
>>>>> Details of his test run that he shared me in the internal chat
>>>>> from May 13.
>>>>
>>>>
>>>> Sorry, My bad. I missed updating here. Yes, this was tested in May.
>>>> Please let me know, if a re-run is required?
>>>
>>> It looks like netcat
>>> (https://eur01.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Flinux.die.net%2Fman%2F1%2Fnc&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C97ac234e82884f729d1508ded7480f62%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639184901648983046%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=18PJTLp9ozMqSkWWvBZmtjzjTI355Oq%2F5aqmU6zCiZE%3D&reserved=0)
>>> is not installed in you setup. Are you able to install it and rerun
>>> the test ?
>>
>>
>> I investigated the failure on the RHEL 10 ppc64le test system.
>>
>>
>> The netfilter_pkt failure is due to missing userspace dependencies:
>>
>> Can't exec "nc": No such file or directory
>> Can't exec "iptables": No such file or directory
>> Can't exec "ip6tables": No such file or directory
>>
>> I checked the system and confirmed that nc, ncat, iptables, and
>> ip6tables are not installed:
>>
>>
>> which nc
>> which ncat
>> which iptables
>> which ip6tables
>>
>>
>> all return "not found".
>>
>> The system has nftables installed (/usr/sbin/nft), but I was unable
>> to locate packages providing nc/ncat or iptables/ip6tables in the
>> currently enabled repositories (epel, rh10_base, rh10_app, rh10_crb).
>
> Found:
> -
> https://dl.fedoraproject.org/pub/epel/10/Everything/ppc64le/Packages/n/netcat-1.238-1.el10_3.ppc64le.rpm
> -
> https://rpmfind.net/linux/RPM/almalinux-kitten/10/baseos/ppc64le/iptables-nft-1.8.11-6.el10.ppc64le.html
> -
> https://www.rpmfind.net/linux/RPM/centos-stream/10/appstream/ppc64le/iptables-devel-1.8.11-14.el10.ppc64le.html
>
> Does it help ?
>
> Christophe
Hi Christophe,
Thanks for sharing the RPMs,they were very helpful.
I reran the audit-testsuite after installing the missing userspace
dependencies that were identified earlier.
I installed:
- netcat (nc)
- iptables
- ip6tables
Following this, the previously failing netfilter_pkt test is now passing:
netfilter_pkt/test ................... ok
Current remaining issue:
1. amcast_joinpart
------------------
Still fails due to a missing Perl dependency:
Can't locate Socket/Netlink.pm in @INC
I searched the configured repositories and could not find a package
providing Socket::Netlink / Socket/Netlink.pm on this EL10 ppc64le system.
Latest run summary:
amcast_joinpart/test ................. Can't locate Socket/Netlink.pm in
@INC (you may need to install the Socket::Netlink module) (@INC entries
checked: /usr/local/lib64/perl5/5.40 /usr/local/share/perl5/5.40
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 .) at amcast_joinpart/test line 10.
BEGIN failed--compilation aborted at amcast_joinpart/test line 10.
amcast_joinpart/test ................. Dubious, test returned 2 (wstat
512, 0x200)
Failed 7/7 subtests
backlog_wait_time_actual_reset/test .. ok
bpf/test ............................. ok
exec_execve/test ..................... ok
exec_name/test ....................... ok
fanotify/test ........................ ok
field_compare/test ................... ok
file_create/test ..................... ok
file_delete/test ..................... ok
file_permission/test ................. ok
file_rename/test ..................... ok
filter_exclude/test .................. ok
filter_exit/test ..................... ok
filter_saddr_fam/test ................ ok
filter_sessionid/test ................ ok
io_uring/test ........................ ok
login_tty/test ....................... ok
lost_reset/test ...................... ok
netfilter_pkt/test ................... ok
signal/test .......................... ok
syscalls_file/test ................... ok
syscall_module/test .................. ok
time_change/test ..................... ok
user_msg/test ........................ ok
All tests now pass except amcast_joinpart, which is blocked by the
missing Socket::Netlink Perl module.
Please let me know if there is a recommended package source for
Socket::Netlink on EL10 ppc64le.
Regards,
Venkat.
>
>>
>>
>> At this point, the remaining failure appears to be an environmental
>> dependency issue rather than a test failure. Please let me know if
>> there is a recommended package/repository for EL10 ppc64le that
>> provides netcat and iptables compatibility tools, and I can re-run
>> the test.
>>
>>
>> Regards,
>>
>> Venkat.
>>
>>>
>>> Thanks
>>> Christophe
>>>
>>>>
>>>> Regards,
>>>>
>>>> Venkat.
>>>>
>>>>>
>>>>> backlog_wait_time_actual_reset/test .. ok
>>>>> bpf/test ............................. ok
>>>>> exec_execve/test ..................... ok
>>>>> exec_name/test ....................... ok
>>>>> fanotify/test ........................ ok
>>>>> field_compare/test ................... ok
>>>>> file_create/test ..................... ok
>>>>> file_delete/test ..................... ok
>>>>> file_permission/test ................. ok
>>>>> file_rename/test ..................... ok
>>>>> filter_exclude/test .................. ok
>>>>> filter_exit/test ..................... ok
>>>>> filter_saddr_fam/test ................ ok
>>>>> filter_sessionid/test ................ ok
>>>>> io_uring/test ........................ ok
>>>>> login_tty/test ....................... ok
>>>>> lost_reset/test ...................... ok
>>>>> netfilter_pkt/test ................... Can't exec "nc": No such
>>>>> file or directory at netfilter_pkt/test line 83.
>>>>>
>>>>> Venkat, can you please re-run if possible and paste the log here.
>>>>>
>>>>> Thanks
>>>>> Maddy
>>>>>
>>>>>
>>>
>
>
^ permalink raw reply
* Re: [PATCH 08/13] mm: introduce vma_get_page_prot() and use it
From: Lance Yang @ 2026-07-02 12:38 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <3bb8bdc4788230c33102166d56cbc5abfad9d4cb.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:31PM +0100, Lorenzo Stoakes wrote:
>There's a large number of vm_get_page_prot(vma->vm_flags) invocations. Make
>life easier by introducing vma_get_page_prot() parameterised by the VMA.
>
>This also makes converting vm_get_page_prot() to vma_flags_t easier.
>
>Also update the userland VMA tests to reflect the change.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
> drivers/gpu/drm/drm_gem.c | 2 +-
> drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 12 ++++++------
> drivers/gpu/drm/msm/msm_gem.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_gem.c | 6 +++---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> drivers/gpu/drm/tegra/gem.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_vram.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
> drivers/gpu/drm/xe/xe_device.c | 2 +-
> drivers/gpu/drm/xe/xe_mmio_gem.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> drivers/video/fbdev/core/fb_io_fops.c | 2 +-
One missed?
drivers/gpu/drm/panthor/panthor_gem.c still has:
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
Can use vma_get_page_prot(vma) too.
[...]
^ permalink raw reply
* Re: [PATCH 07/13] mm/vma: rename vma_get_page_prot to vma_flags_to_page_prot
From: Lance Yang @ 2026-07-02 12:25 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <fc8ac30d03d29d236e76542b36432bba315aca60.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:30PM +0100, Lorenzo Stoakes wrote:
>Having vma_get_page_prot() refer to VMA flags and vma_set_page_prot() refer
>to a VMA is confusing.
>
>Rename vma_get_page_prot() to vma_flags_to_page_prot() to resolve this
>confusion.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
straight rename, no stale callers that I can spot ;) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH 06/13] mm/vma: convert vm_pgprot_modify() to use vma_flags_t and rename
From: Lance Yang @ 2026-07-02 12:21 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <548ba81b2971734d4d2143237ad1465bd1b2f525.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:29PM +0100, Lorenzo Stoakes wrote:
>Update vm_pgprot_modify() to use the new VMA flags type vma_flags_t, and
>rename to vma_pgprot_modify() accordingly.
>
>This is part of the ongoing work to convert vm_flags_t to vma_flags_t, in
>order to eliminate the arbitrary limit of the number of bits in a system
>word on available VMA flags.
>
>Update VMA userland tests accordingly, updating vma_set_page_prot() to no
>longer inline vma_pgprot_modify(), rather we can simply define
>vma_pgprot_modify() as a static inline function and the tests will pick it
>up from vma.h.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
[...]
>diff --git a/mm/vma.h b/mm/vma.h
>index bcf0c2773449..6a8abb8ae937 100644
>--- a/mm/vma.h
>+++ b/mm/vma.h
>@@ -522,9 +522,11 @@ static inline bool vma_wants_manual_pte_write_upgrade(struct vm_area_struct *vma
> }
>
> #ifdef CONFIG_MMU
>-static inline pgprot_t vm_pgprot_modify(pgprot_t oldprot, vm_flags_t vm_flags)
>+static inline pgprot_t vma_pgprot_modify(pgprot_t oldprot, vma_flags_t vma_flags)
> {
>- return pgprot_modify(oldprot, vm_get_page_prot(vm_flags));
>+ const pgprot_t prot = vma_get_page_prot(vma_flags);
>+
>+ return pgprot_modify(oldprot, prot);
Nit: could this just stay as a single return? something like:
return pgprot_modify(oldprot, vma_get_page_prot(vma_flags));
Otherwise, LGTM, feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
[...]
^ permalink raw reply
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Michal Suchánek @ 2026-07-02 12:13 UTC (permalink / raw)
To: Sven Schnelle
Cc: Peter Zijlstra, Jonathan Corbet, Shuah Khan, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andrew Donnellan, Mark Rutland,
Arnd Bergmann, Jiaxun Yang, Ryan Roberts, Greg Kroah-Hartman,
Mukesh Kumar Chaurasiya, Shrikanth Hegde, Zong Li, Nam Cao,
Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook, linux-doc,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <yt9d5x2xbny9.fsf@linux.ibm.com>
On Thu, Jul 02, 2026 at 02:01:02PM +0200, Sven Schnelle wrote:
> Michal Suchánek <msuchanek@suse.de> writes:
>
> > On Thu, Jul 02, 2026 at 10:12:35AM +0200, Sven Schnelle wrote:
> >> Michal Suchánek <msuchanek@suse.de> writes:
> >>
> >> > The return value of syscall_enter_from_user_mode is used both for the
> >> > adjusted syscall number and the indicator that a syscall should be
> >> > skipped.
> >> >
> >> > As seccomp can be invoked on any syscall, including invalid ones this
> >> > somewhat undermines seccomp.
> >> >
> >> > While the seccomp variants that terminate the process do not need to
> >> > care about this for the filter that sets the syscall return value this
> >> > disctinction is required.
> >> >
> >> > Pass the syscall number as a pointer to the inline entry functions, and
> >> > use the return value exclusively for the indication that the syscall is
> >> > already handled.
> >> >
> >> > This should avoid the need for the s390 PIF_SYSCALL_RET_SET which is the
> >> > workaround for exactly this deficiency.
> >>
> >> I'm not sure whether PIF_SYSCALL_RET_SET can be removed - the syscall
> >> return might still get set by PTRACE_SET_SYSCALL_INFO when the tracee is
> >> stopped. This might be a positive number which can't be distinguished
> >> from a syscall number. But maybe i'm missing something? It's been quite
> >> a while since I touched all that ptrace stuff.
> >
> > When the syscall return value is set (in the registers) the return value
> > which is also the modified syscall number is set to -1 indicating the
> > syscall was handled. At least that's how the API is described.
> >
> > So yes, if the syscall number range is restricted or the syscall number
> > is returned through a path different from the function return value the
> > flag should not be needed in the entry path because the case can be
> > detected through the return value alone.
>
> I'm still failing to see how this would work without an additional
> flag. Assume a program (the tracee) is stopped because of a syscall
> entry. The tracer then decides to skip the syscall and changes
> regs->gpr2 (which contains either the syscall number or return value)
> to contain 42. When the tracer than restarts the syscall, how does
> do_syscall() know that gpr2 is now a return value and not a syscall number?
Because then the return value from the syscall_enter_from_user_mode
machinery would be -1 indicating the syscall should be skipped. That is
how the return value of syscall_enter_from_user_mode is documented, I
did not verify that it actually works that way for the tracing case on
s390.
So long as it is clarified that -1 is not a syscall number or the
syscall number is retuned elsewhere there is no doubt, the -1 indicates
already handled syscall without the need for an additional flag.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH 05/13] mm: prefer mm->def_vma_flags in mm logic
From: Lance Yang @ 2026-07-02 12:10 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <3b4ccdc38819b42ddc79ee5a795831208ac7986c.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:28PM +0100, Lorenzo Stoakes wrote:
>Currently mm->def_flags (of type vm_flags_t) is union'd with
>mm->def_vma_flags (of type vma_flags_t).
>
>As part of the effort to convert vm_flags_t usage to vma_flags_t (in order
>to no longer be arbitrarily limited to a system word size for VMA flags),
>prefer mm->def_vma_flags to mm->def_flags throughout the mm logic.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
> mm/debug.c | 2 +-
> mm/mlock.c | 13 +++++++------
> mm/mmap.c | 11 ++++++-----
> mm/vma.c | 4 ++--
> 4 files changed, 16 insertions(+), 14 deletions(-)
>
>diff --git a/mm/debug.c b/mm/debug.c
>index 497654b36f1a..f0a354a9496a 100644
>--- a/mm/debug.c
>+++ b/mm/debug.c
>@@ -226,7 +226,7 @@ void dump_mm(const struct mm_struct *mm)
> mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
> #endif
> atomic_read(&mm->tlb_flush_pending),
>- mm->def_flags, &mm->def_flags
>+ vma_flags_to_legacy(mm->def_vma_flags), &mm->def_vma_flags
> );
While at it, one thing for later: dump_mm() still assumes one-world VMA
flags. That works today since vma_flags_t is one word. Maybe worth a
BUILD_BUG_ON() here, before that stops being true?
Not a big deal though. Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
> }
> EXPORT_SYMBOL(dump_mm);
[...]
^ permalink raw reply
* [PATCH 2/2] powerpc/kaslr_booke: Fix reserved-memory reg property length check
From: Thorsten Blum @ 2026-07-02 12:05 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Jiri Bohac, Andrew Morton,
Scott Wood, Jason Yan, Diana Craciun
Cc: Thorsten Blum, stable, linuxppc-dev, linux-kernel
In-Reply-To: <20260702120551.3046-3-thorsten.blum@linux.dev>
In overlaps_reserved_region(), fdt_getprop() returns the reg property
length in bytes, which the loop condition compares against a cell count.
Since each cell is 4 bytes, scale the count to bytes before comparing it
with len to avoid reading past the end of a truncated reg property.
Fixes: 6a38ea1d7b94 ("powerpc/fsl_booke/32: randomize the kernel image offset")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/powerpc/mm/nohash/kaslr_booke.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
index 3e5e67c76bda..82106a9d9d4c 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -123,8 +123,8 @@ static __init bool overlaps_reserved_region(const void *fdt, u32 start,
len = 0;
reg = fdt_getprop(fdt, subnode, "reg", &len);
- while (len >= (regions.reserved_mem_addr_cells +
- regions.reserved_mem_size_cells)) {
+ while (len >= 4 * (regions.reserved_mem_addr_cells +
+ regions.reserved_mem_size_cells)) {
base = fdt32_to_cpu(reg[0]);
if (regions.reserved_mem_addr_cells == 2)
base = (base << 32) | fdt32_to_cpu(reg[1]);
^ permalink raw reply related
* [PATCH 1/2] powerpc/kaslr_booke: Fix reserved region overlap checks
From: Thorsten Blum @ 2026-07-02 12:05 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Jiri Bohac, Andrew Morton,
Diana Craciun, Jason Yan, Scott Wood
Cc: Thorsten Blum, stable, linuxppc-dev, linux-kernel
FDT reserved region addresses can be 64-bit, but regions_overlap() takes
32-bit arguments, which could truncate values before comparing them and
cause KASLR to incorrectly detect or miss overlaps. Make
regions_overlap() work with 64-bit values instead.
Also clamp reservation sizes before computing their end addresses to
prevent the addition from overflowing.
Fixes: 6a38ea1d7b94 ("powerpc/fsl_booke/32: randomize the kernel image offset")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/powerpc/mm/nohash/kaslr_booke.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
index 5e4897daaaea..3e5e67c76bda 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -91,7 +91,7 @@ static __init u64 get_kaslr_seed(void *fdt)
return ret;
}
-static __init bool regions_overlap(u32 s1, u32 e1, u32 s2, u32 e2)
+static __init bool regions_overlap(u64 s1, u64 e1, u64 s2, u64 e2)
{
return e1 >= s2 && e2 >= s1;
}
@@ -100,13 +100,15 @@ static __init bool overlaps_reserved_region(const void *fdt, u32 start,
u32 end)
{
int subnode, len, i;
- u64 base, size;
+ u64 base, size, rsv_end;
/* check for overlap with /memreserve/ entries */
for (i = 0; i < fdt_num_mem_rsv(fdt); i++) {
if (fdt_get_mem_rsv(fdt, i, &base, &size) < 0)
continue;
- if (regions_overlap(start, end, base, base + size))
+
+ rsv_end = base + min(size, U64_MAX - base);
+ if (regions_overlap(start, end, base, rsv_end))
return true;
}
@@ -118,7 +120,6 @@ static __init bool overlaps_reserved_region(const void *fdt, u32 start,
subnode >= 0;
subnode = fdt_next_subnode(fdt, subnode)) {
const fdt32_t *reg;
- u64 rsv_end;
len = 0;
reg = fdt_getprop(fdt, subnode, "reg", &len);
@@ -141,8 +142,7 @@ static __init bool overlaps_reserved_region(const void *fdt, u32 start,
if (base >= regions.pa_end)
continue;
- rsv_end = min(base + size, (u64)U32_MAX);
-
+ rsv_end = base + min(size, U64_MAX - base);
if (regions_overlap(start, end, base, rsv_end))
return true;
}
^ permalink raw reply related
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Sven Schnelle @ 2026-07-02 12:01 UTC (permalink / raw)
To: Michal Suchánek
Cc: Peter Zijlstra, Jonathan Corbet, Shuah Khan, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andrew Donnellan, Mark Rutland,
Arnd Bergmann, Jiaxun Yang, Ryan Roberts, Greg Kroah-Hartman,
Mukesh Kumar Chaurasiya, Shrikanth Hegde, Zong Li, Nam Cao,
Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook, linux-doc,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <akYreY_BHuRbxSsO@kunlun.suse.cz>
Michal Suchánek <msuchanek@suse.de> writes:
> On Thu, Jul 02, 2026 at 10:12:35AM +0200, Sven Schnelle wrote:
>> Michal Suchánek <msuchanek@suse.de> writes:
>>
>> > The return value of syscall_enter_from_user_mode is used both for the
>> > adjusted syscall number and the indicator that a syscall should be
>> > skipped.
>> >
>> > As seccomp can be invoked on any syscall, including invalid ones this
>> > somewhat undermines seccomp.
>> >
>> > While the seccomp variants that terminate the process do not need to
>> > care about this for the filter that sets the syscall return value this
>> > disctinction is required.
>> >
>> > Pass the syscall number as a pointer to the inline entry functions, and
>> > use the return value exclusively for the indication that the syscall is
>> > already handled.
>> >
>> > This should avoid the need for the s390 PIF_SYSCALL_RET_SET which is the
>> > workaround for exactly this deficiency.
>>
>> I'm not sure whether PIF_SYSCALL_RET_SET can be removed - the syscall
>> return might still get set by PTRACE_SET_SYSCALL_INFO when the tracee is
>> stopped. This might be a positive number which can't be distinguished
>> from a syscall number. But maybe i'm missing something? It's been quite
>> a while since I touched all that ptrace stuff.
>
> When the syscall return value is set (in the registers) the return value
> which is also the modified syscall number is set to -1 indicating the
> syscall was handled. At least that's how the API is described.
>
> So yes, if the syscall number range is restricted or the syscall number
> is returned through a path different from the function return value the
> flag should not be needed in the entry path because the case can be
> detected through the return value alone.
I'm still failing to see how this would work without an additional
flag. Assume a program (the tracee) is stopped because of a syscall
entry. The tracer then decides to skip the syscall and changes
regs->gpr2 (which contains either the syscall number or return value)
to contain 42. When the tracer than restarts the syscall, how does
do_syscall() know that gpr2 is now a return value and not a syscall number?
^ permalink raw reply
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Michal Suchánek @ 2026-07-02 11:45 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter Zijlstra, Jonathan Corbet, Shuah Khan, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Andy Lutomirski, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andrew Donnellan, Mark Rutland,
Arnd Bergmann, Jiaxun Yang, Ryan Roberts, Greg Kroah-Hartman,
Mukesh Kumar Chaurasiya, Shrikanth Hegde, Zong Li, Nam Cao,
Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook, linux-doc,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <878q7tprau.ffs@fw13>
On Thu, Jul 02, 2026 at 01:24:57PM +0200, Thomas Gleixner wrote:
> On Wed, Jul 01 2026 at 19:42, Michal Suchánek wrote:
> > The return value of syscall_enter_from_user_mode is used both for the
> > adjusted syscall number and the indicator that a syscall should be
> > skipped.
> >
> > As seccomp can be invoked on any syscall, including invalid ones this
> > somewhat undermines seccomp.
> >
> > While the seccomp variants that terminate the process do not need to
> > care about this for the filter that sets the syscall return value this
> > disctinction is required.
>
> You completely fail to explain why and what actual problem you are
> trying to solve. At least I can't figure it out from the above word
> salad.
syscall_enter_from_user_mode returns the new syscall number after doing
something arbitrarry with it, including running seccomp.
Wehn the syscall is already handled, eg. by seccomp filtering it returns
-1 as the new syscall number. -1 is an invalid syscall number but it can
still be filtered by seccomp. When the syscall number was -1 to start
with it's not possible to determine if the syscall was fileterd from the
return value. s390 returns the filtered state in a flag it sets on the
regs structure, avoiding this problem.
However, the API should be specified in a way that does not require
everyone implementing such flag.
>
> > Pass the syscall number as a pointer to the inline entry functions, and
> > use the return value exclusively for the indication that the syscall is
> > already handled.
> >
> > This should avoid the need for the s390 PIF_SYSCALL_RET_SET which is the
> > workaround for exactly this deficiency.
> >
> > If this is desirable the patch could be split into some series that
> > adjusts the code flow where needed so that the final change is mostly
> > mechanical.
>
> That's not a matter of desire. That's mandatory.
So long as it's desirable to implement an API change in this direction,
it's not clear to me so far.
> > - instrumentation_begin();
> > - if (!invoke_syscall(regs, nr) && nr != -1)
> > - result_reg(regs) = __sys_ni_syscall(regs);
> > - instrumentation_end();
> > + /* Skip syscall when -1 is returned */
> > + if (!syscall_enter_from_user_mode(regs, &nr)) {
>
> Seriously?
>
> If we go and separate the syscall number from the return value, then the
> return value 0 means success and anything else fail. Which in other
> words is a boolean. So instead of tastelessly adding a completely
> nonsensical comment about -1 here, syscall_enter_from_user_mode() wants
> to have the return value type bool with a proper boolean logic: true =
> success, false = abort.
We have that very same API down to __secure_computing() which returns
boolean represented as -1 and 0 values. That does not mean it's not
tasteless.
>
> > @@ -168,8 +168,7 @@ __visible noinstr void do_int80_emulation(struct pt_regs *regs)
> > nr = syscall_32_enter(regs);
> >
> > local_irq_enable();
> > - nr = syscall_enter_from_user_mode_work(regs, nr);
> > - do_syscall_32_irqs_on(regs, nr);
> > + syscall_enter_from_user_mode_work(regs, &nr);
>
> How exactly is this ever going to invoke a valid syscall?
That's one of the problems with giant all-in-one patch, things like this
easily slip in. However, it is in cluded mostly for illustration, I
don't expect anyone to merge this as-is.
>
> > + if (!syscall_enter_from_user_mode_work(regs, &nr)) {
> > + nr &= GENMASK(31, 0);
> > + do_syscall_32_irqs_on(regs, nr);
>
> do_syscall_32_irqs_on(regs, (int)nr);
>
> would be too simple, right?
Also way less explicit.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t
From: Lance Yang @ 2026-07-02 11:41 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <cef55b19f86c110952f13829aefa4859db3a70ed.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:27PM +0100, Lorenzo Stoakes wrote:
>As part of the changes converting VMA flags from a system word size to a
>bitmap, extend this change to generic_get_unmapped_area() and
>generic_get_unmapped_area_topdown(), which also allows us to convert
>stack_guard_placement() as well.
>
>We retain arch_get_unmapped_area() and arch_get_unmapped_area_topdown()
>as-is for now, using legacy_to_vma_flags() as necessary to do so.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nothing jumped out at me ;) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Lance Yang @ 2026-07-02 11:37 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <b1ad7c4443f5cba622e4c48c5a9ef15427001a93.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:26PM +0100, Lorenzo Stoakes wrote:
>Update __get_unmapped_area() to be parameterised by vma_flags_t rather than
>vm_flags_t as part of the effort to move VMA flags from a system word to a
>bitmap.
>
>We cascade the changes up to arch_get_unmapped_area_topdown() and
>arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in
>order to propagate the VMA flags.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nothing suspicious that I could spot :) Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Thomas Gleixner @ 2026-07-02 11:24 UTC (permalink / raw)
To: Michal Suchánek, Peter Zijlstra
Cc: Jonathan Corbet, Shuah Khan, Huacai Chen, WANG Xuerui,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Andy Lutomirski, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andrew Donnellan, Mark Rutland,
Michal Suchánek, Arnd Bergmann, Jiaxun Yang, Ryan Roberts,
Greg Kroah-Hartman, Mukesh Kumar Chaurasiya, Shrikanth Hegde,
Zong Li, Nam Cao, Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook,
linux-doc, linux-kernel, loongarch, linuxppc-dev, linux-riscv,
linux-s390
In-Reply-To: <akVRcPsD_R_CE1qW@kunlun.suse.cz>
On Wed, Jul 01 2026 at 19:42, Michal Suchánek wrote:
> The return value of syscall_enter_from_user_mode is used both for the
> adjusted syscall number and the indicator that a syscall should be
> skipped.
>
> As seccomp can be invoked on any syscall, including invalid ones this
> somewhat undermines seccomp.
>
> While the seccomp variants that terminate the process do not need to
> care about this for the filter that sets the syscall return value this
> disctinction is required.
You completely fail to explain why and what actual problem you are
trying to solve. At least I can't figure it out from the above word
salad.
> Pass the syscall number as a pointer to the inline entry functions, and
> use the return value exclusively for the indication that the syscall is
> already handled.
>
> This should avoid the need for the s390 PIF_SYSCALL_RET_SET which is the
> workaround for exactly this deficiency.
>
> If this is desirable the patch could be split into some series that
> adjusts the code flow where needed so that the final change is mostly
> mechanical.
That's not a matter of desire. That's mandatory.
> - instrumentation_begin();
> - if (!invoke_syscall(regs, nr) && nr != -1)
> - result_reg(regs) = __sys_ni_syscall(regs);
> - instrumentation_end();
> + /* Skip syscall when -1 is returned */
> + if (!syscall_enter_from_user_mode(regs, &nr)) {
Seriously?
If we go and separate the syscall number from the return value, then the
return value 0 means success and anything else fail. Which in other
words is a boolean. So instead of tastelessly adding a completely
nonsensical comment about -1 here, syscall_enter_from_user_mode() wants
to have the return value type bool with a proper boolean logic: true =
success, false = abort.
> @@ -168,8 +168,7 @@ __visible noinstr void do_int80_emulation(struct pt_regs *regs)
> nr = syscall_32_enter(regs);
>
> local_irq_enable();
> - nr = syscall_enter_from_user_mode_work(regs, nr);
> - do_syscall_32_irqs_on(regs, nr);
> + syscall_enter_from_user_mode_work(regs, &nr);
How exactly is this ever going to invoke a valid syscall?
> + if (!syscall_enter_from_user_mode_work(regs, &nr)) {
> + nr &= GENMASK(31, 0);
> + do_syscall_32_irqs_on(regs, nr);
do_syscall_32_irqs_on(regs, (int)nr);
would be too simple, right?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Lance Yang @ 2026-07-02 11:15 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <e0ac58ad2b88ff7e2f0024e3286b2e786f79ca32.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:25PM +0100, Lorenzo Stoakes wrote:
>The core do_mmap() function accepts a vm_flags_t parameter which it then
>manipulates before passing to mmap_region() to do the heavy lifting of the
>memory mapping.
>
>Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
>the logic within do_mmap() to manipulate this instead.
>
>This is as part of the ongoing effort to convert VMA flags from a system
>word size to a bitmap type which allows us to unrestrict the number of VMA
>flags, as well as gain control over how VMA flag manipulation occurs.
>
>We do not cascade these changes to all functions which accept vm_flags_t,
>but rather use vma_flags_to_legacy() where necessary, specifically
>deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
>__get_unmapped_area() to vma_flags_t.
>
>Also utilise the new vma_flags_can_grow() predicate which correctly handles
>the case of architectures without upward growing stacks.
>
>As part of this change, introduce VMA_SHADOW_STACK so we can correctly
>handle the case of the shadow stack not being defined.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Not exactly a small one :) I stared at this patch for a while, hopefully
don't miss anythig ...
Just one tiny nit below. Overall, LGTM, feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
[...]
>diff --git a/mm/mmap.c b/mm/mmap.c
>index 46174e706bbe..547352183214 100644
>--- a/mm/mmap.c
>+++ b/mm/mmap.c
[...]
>@@ -488,23 +496,27 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> * Check to see if we are violating any seals and update VMA
> * flags if necessary to avoid future seal violations.
> */
>- err = memfd_check_seals_mmap(file, &vm_flags);
>+ err = memfd_check_seals_mmap(file, &vma_flags);
> if (err)
> return (unsigned long)err;
> } else {
> switch (flags & MAP_TYPE) {
> case MAP_SHARED:
>- if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
>+ if (vma_flags_can_grow(&vma_flags))
> return -EINVAL;
> /*
> * Ignore pgoff.
> */
> pgoff = 0;
>- vm_flags |= VM_SHARED | VM_MAYSHARE;
>+ vma_flags_set(&vma_flags, VMA_SHARED_BIT, VMA_MAYSHARE_BIT);
> break;
>- case MAP_DROPPABLE:
>- if (VM_DROPPABLE == VM_NONE)
>+ case MAP_DROPPABLE: {
>+ vma_flags_t droppable = VMA_DROPPABLE;
>+
>+ if (vma_flags_empty(&droppable))
> return -EOPNOTSUPP;
>+ vma_flags_set_mask(&vma_flags, droppable);
>+
> /*
> * A locked or stack area makes no sense to be droppable.
> *
>@@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> */
> if (flags & (MAP_LOCKED | MAP_HUGETLB))
> return -EINVAL;
>- if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
>+ if (vma_flags_can_grow(&vma_flags))
> return -EINVAL;
>
>- vm_flags |= VM_DROPPABLE;
Old code checked VM_GROWSDOWN|VM_GROWSUP before seting VM_DROPPABLE. New
code flips that around. Hmm, shouldn't master, just made me look twice ;)
Maybe keep old order?
Cheers, Lance
>-
> /*
> * If the pages can be dropped, then it doesn't make
> * sense to reserve them.
> */
>- vm_flags |= VM_NORESERVE;
>+ vma_flags_set(&vma_flags, VMA_NORESERVE_BIT);
>
> /*
> * Likewise, they're volatile enough that they
> * shouldn't survive forks or coredumps.
> */
>- vm_flags |= VM_WIPEONFORK | VM_DONTDUMP;
>+ vma_flags_set(&vma_flags, VMA_WIPEONFORK_BIT,
>+ VMA_DONTDUMP_BIT);
>+
> fallthrough;
>+ }
> case MAP_PRIVATE:
> /*
> * Set pgoff according to addr for anon_vma.
[...]
^ permalink raw reply
* Re: [PATCH V2] powerpc/syscall: Fix seccomp errno handling with GENERIC_ENTRY
From: Mukesh Kumar Chaurasiya @ 2026-07-02 9:39 UTC (permalink / raw)
To: Michal Suchánek
Cc: Shrikanth Hegde, maddy, mpe, npiggin, chleroy, mkchauras,
ryan.roberts, ruanjinjie, linuxppc-dev, linux-kernel
In-Reply-To: <akYwv5niv-oX8mYv@kunlun.suse.cz>
On Thu, Jul 02, 2026 at 11:34:55AM +0200, Michal Suchánek wrote:
> On Thu, Jul 02, 2026 at 11:20:03AM +0530, Mukesh Kumar Chaurasiya wrote:
> > On Wed, Jul 01, 2026 at 10:29:49AM +0200, Michal Suchánek wrote:
> > > On Wed, Jul 01, 2026 at 10:01:49AM +0200, Michal Suchánek wrote:
> > > > On Wed, Jul 01, 2026 at 09:41:57AM +0200, Michal Suchánek wrote:
> > > > > On Wed, Jul 01, 2026 at 11:57:00AM +0530, Mukesh Kumar Chaurasiya wrote:
> > > > > > On Wed, Jul 01, 2026 at 01:41:09AM +0530, Shrikanth Hegde wrote:
> > > > > > > Hi Mukesh.
> > > > > > >
> > > > > > > On 6/29/26 11:59 PM, Mukesh Kumar Chaurasiya (IBM) wrote:
> > >
> > > > > > > > diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
> > > > > > > > index a9da2af6efa8..36d73933a311 100644
> > > > > > > > --- a/arch/powerpc/kernel/syscall.c
> > > > > > > > +++ b/arch/powerpc/kernel/syscall.c
> > > > > > > > @@ -20,7 +20,6 @@ notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> > > > > > > > syscall_fn f;
> > > > > > > > add_random_kstack_offset();
> > > > > > > > - r0 = syscall_enter_from_user_mode(regs, r0);
> > > > > > > > if (unlikely(r0 >= NR_syscalls)) {
> > > > > > > > if (unlikely(trap_is_unsupported_scv(regs))) {
> > > > > > > > @@ -31,6 +30,12 @@ notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> > > > > > > > return -ENOSYS;
> > > > > > > > }
> > > > > > > > + r0 = syscall_enter_from_user_mode(regs, r0);
> > > > > > > > +
> > > > > > >
> > > > > > > I see many arch first do syscall_enter_from_user_mode and then check for return value.
> > > > > > > take x86 for example,
> > > > > > >
> > > > > > > __visible noinstr bool do_syscall_64(struct pt_regs *regs, int nr)
> > > > > > > {
> > > > > > > nr = syscall_enter_from_user_mode(regs, nr);
> > > > > > >
> > > > > > > if (!do_syscall_x64(regs, nr) && !do_syscall_x32(regs, nr) && nr != -1) {
> > > > > > > /* Invalid system call, but still a system call. */
> > > > > > > regs->ax = __x64_sys_ni_syscall(regs);
> > > > > > > }
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > > So seccomp fails silently there if initial nr was -1?
> > > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > No the -1 syscall ignores the error silently and returns 0.
> > > > > >
> > > > >
> > > > > There seems to be some inconsistency with the invalid syscalls.
> > > > >
> > > > > Adapting the example from seccomp man page to ignore architecture I get
> > > > > on x86_64 (presumably with GENERIC_ENTRY since long ago):
> > > > >
> > > > > ./a.out -2 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-2, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > > > > ret=-1 errno=55 (No anode)
> > > > >
> > > > > but on ppc64le (with GENEREC_ENTRY):
> > > > >
> > > > > ./a.out -2 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-2, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > > > > ret=-1 errno=38 (Function not implemented)
> > > > >
> > > > > That said, behavior of seccomp on invalid syscalls is not particularly
> > > > > concerning. The tools that people typically use for constructing those
> > > > > filters typically require a valid syscall number.
> > > > >
> > > > > It would be nice to align, though.
> > > >
> > > > It is more concerning for SECCOMP_SET_MODE_STRICT or similar. So it
> > > > should be resolved to correctly execute seccomp even on invalid
> > > > syscalls. The syscall_enter_from_user_mode API is not particularly
> > > > well-suited for that, though.
> > >
> > > In particular the fixup per
> > > https://lore.kernel.org/linuxppc-dev/akJzuEJRLniHk4Fi@kunlun.suse.cz/
> > >
> > > handles some cases
> > >
> > > ./a.out -2 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-2, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > > ret=-1 errno=55 (No anode)
> > >
> > > but not -1
> > >
> > > ./a.out -1 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-1, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > > ret=-1 errno=38 (Function not implemented)
> > >
> > > which is the direct result of the ambiguous return value of
> > > syscall_enter_from_user_mode
> > >
> > > Thanks
> > >
> > > Michal
> > Hey Michal,
> >
> > Yeah this seems to be a more complex thing than anticipated.
> > As per conversation on your another patch here
> > https://lore.kernel.org/all/BA7CD91D-C0E5-47A1-B49C-BC6AF6604182@zytor.com/
> >
> > This patch seems to be redundant at this point.
>
> Hello,
>
> while improving the entry API is a fine goal it will take time if
> something can be even agreed on.
>
> In the mantime we should provide a fix using the current API.
>
> Inability to run container workloads is a significant regression.
>
> Thanks
>
> Michal
Yeah, i am working on a fix for now. Will post out a new version.
Regards,
Mukesh
^ permalink raw reply
* Re: [PATCH V2] powerpc/syscall: Fix seccomp errno handling with GENERIC_ENTRY
From: Michal Suchánek @ 2026-07-02 9:34 UTC (permalink / raw)
To: Mukesh Kumar Chaurasiya
Cc: Shrikanth Hegde, maddy, mpe, npiggin, chleroy, mkchauras,
ryan.roberts, ruanjinjie, linuxppc-dev, linux-kernel
In-Reply-To: <akX6TL6v4aRPGdkk@li-1a3e774c-28e4-11b2-a85c-acc9f2883e29.ibm.com>
On Thu, Jul 02, 2026 at 11:20:03AM +0530, Mukesh Kumar Chaurasiya wrote:
> On Wed, Jul 01, 2026 at 10:29:49AM +0200, Michal Suchánek wrote:
> > On Wed, Jul 01, 2026 at 10:01:49AM +0200, Michal Suchánek wrote:
> > > On Wed, Jul 01, 2026 at 09:41:57AM +0200, Michal Suchánek wrote:
> > > > On Wed, Jul 01, 2026 at 11:57:00AM +0530, Mukesh Kumar Chaurasiya wrote:
> > > > > On Wed, Jul 01, 2026 at 01:41:09AM +0530, Shrikanth Hegde wrote:
> > > > > > Hi Mukesh.
> > > > > >
> > > > > > On 6/29/26 11:59 PM, Mukesh Kumar Chaurasiya (IBM) wrote:
> >
> > > > > > > diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
> > > > > > > index a9da2af6efa8..36d73933a311 100644
> > > > > > > --- a/arch/powerpc/kernel/syscall.c
> > > > > > > +++ b/arch/powerpc/kernel/syscall.c
> > > > > > > @@ -20,7 +20,6 @@ notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> > > > > > > syscall_fn f;
> > > > > > > add_random_kstack_offset();
> > > > > > > - r0 = syscall_enter_from_user_mode(regs, r0);
> > > > > > > if (unlikely(r0 >= NR_syscalls)) {
> > > > > > > if (unlikely(trap_is_unsupported_scv(regs))) {
> > > > > > > @@ -31,6 +30,12 @@ notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> > > > > > > return -ENOSYS;
> > > > > > > }
> > > > > > > + r0 = syscall_enter_from_user_mode(regs, r0);
> > > > > > > +
> > > > > >
> > > > > > I see many arch first do syscall_enter_from_user_mode and then check for return value.
> > > > > > take x86 for example,
> > > > > >
> > > > > > __visible noinstr bool do_syscall_64(struct pt_regs *regs, int nr)
> > > > > > {
> > > > > > nr = syscall_enter_from_user_mode(regs, nr);
> > > > > >
> > > > > > if (!do_syscall_x64(regs, nr) && !do_syscall_x32(regs, nr) && nr != -1) {
> > > > > > /* Invalid system call, but still a system call. */
> > > > > > regs->ax = __x64_sys_ni_syscall(regs);
> > > > > > }
> > > > > >
> > > > > > }
> > > > > >
> > > > > > So seccomp fails silently there if initial nr was -1?
> > > > > >
> > > > > Hey,
> > > > >
> > > > > No the -1 syscall ignores the error silently and returns 0.
> > > > >
> > > >
> > > > There seems to be some inconsistency with the invalid syscalls.
> > > >
> > > > Adapting the example from seccomp man page to ignore architecture I get
> > > > on x86_64 (presumably with GENERIC_ENTRY since long ago):
> > > >
> > > > ./a.out -2 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-2, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > > > ret=-1 errno=55 (No anode)
> > > >
> > > > but on ppc64le (with GENEREC_ENTRY):
> > > >
> > > > ./a.out -2 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-2, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > > > ret=-1 errno=38 (Function not implemented)
> > > >
> > > > That said, behavior of seccomp on invalid syscalls is not particularly
> > > > concerning. The tools that people typically use for constructing those
> > > > filters typically require a valid syscall number.
> > > >
> > > > It would be nice to align, though.
> > >
> > > It is more concerning for SECCOMP_SET_MODE_STRICT or similar. So it
> > > should be resolved to correctly execute seccomp even on invalid
> > > syscalls. The syscall_enter_from_user_mode API is not particularly
> > > well-suited for that, though.
> >
> > In particular the fixup per
> > https://lore.kernel.org/linuxppc-dev/akJzuEJRLniHk4Fi@kunlun.suse.cz/
> >
> > handles some cases
> >
> > ./a.out -2 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-2, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > ret=-1 errno=55 (No anode)
> >
> > but not -1
> >
> > ./a.out -1 55 /usr/bin/perl -MPOSIX -e '$!=0; my $r = syscall(-1, 0); print "ret=$r errno=".($!+0)." ($!)\n"'
> > ret=-1 errno=38 (Function not implemented)
> >
> > which is the direct result of the ambiguous return value of
> > syscall_enter_from_user_mode
> >
> > Thanks
> >
> > Michal
> Hey Michal,
>
> Yeah this seems to be a more complex thing than anticipated.
> As per conversation on your another patch here
> https://lore.kernel.org/all/BA7CD91D-C0E5-47A1-B49C-BC6AF6604182@zytor.com/
>
> This patch seems to be redundant at this point.
Hello,
while improving the entry API is a fine goal it will take time if
something can be even agreed on.
In the mantime we should provide a fix using the current API.
Inability to run container workloads is a significant regression.
Thanks
Michal
^ permalink raw reply
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Michal Suchánek @ 2026-07-02 9:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, Jonathan Corbet, Shuah Khan, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Andrew Donnellan, Mark Rutland,
Arnd Bergmann, Jiaxun Yang, Ryan Roberts, Greg Kroah-Hartman,
Mukesh Kumar Chaurasiya, Shrikanth Hegde, Zong Li, Nam Cao,
Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook, linux-doc,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <BA7CD91D-C0E5-47A1-B49C-BC6AF6604182@zytor.com>
On Wed, Jul 01, 2026 at 11:29:01AM -0700, H. Peter Anvin wrote:
> On July 1, 2026 10:42:08 AM PDT, "Michal Suchánek" <msuchanek@suse.de> wrote:
> >The return value of syscall_enter_from_user_mode is used both for the
> >adjusted syscall number and the indicator that a syscall should be
> >skipped.
> >
> >As seccomp can be invoked on any syscall, including invalid ones this
> >somewhat undermines seccomp.
> >
> >While the seccomp variants that terminate the process do not need to
> >care about this for the filter that sets the syscall return value this
> >disctinction is required.
> >
> >Pass the syscall number as a pointer to the inline entry functions, and
> >use the return value exclusively for the indication that the syscall is
> >already handled.
> >
> >This should avoid the need for the s390 PIF_SYSCALL_RET_SET which is the
> >workaround for exactly this deficiency.
> >
> >If this is desirable the patch could be split into some series that
> >adjusts the code flow where needed so that the final change is mostly
> >mechanical.
> >
> >There is also another way to handle this problem.
> >
> >With x86 using bit 30 to denote compatibility syscall it sounds like
> >declaring syscall number a 30bit quantity would work.
> >
> >Then bit 31 could be used to denote an invalid syscall that can never be
> >executed, and the -1 returned from syscall_enter_from_user_mode would
> >then be inherently invalid.
> >
> >That is so long as no architectures use syscall numbers outside of this
> >range so far, and the limitation is considered fine.
> >
>
> Negative numbers most definitely not be assigned as valid system calls, not now, not ever.
Negativity of a number is a matter of intepretation. Sometimes the
syscall number is decleared as int, sometimes long, sometimes unsigned
long.
Passing -1 to strtoul generates some bit pattern that can then be
compared to another bit pattern inside a seccomp filter program, for
example.
> Therein lies some serious madness.
>
> I believe setting the syscall number to -1 to skip is an ABI already in e.g. ptrace, so I doubt we can just get rid of it anyway.
Yes, and seccomp can set the syscall number to -1 indicating it was
handled already even if the number was -1 to start with. While -1 is not
a valid syscall number it can still be filtered, at least on some
architectures.
> I would say as follows:
>
> Let's formally define that:
>
> - valid system call numbers are positive 32-bit numbers, using the appropriate ABI convention for "int".
>
> - bits [30:n] for some value of n are reserved for architecture-specific flags/modes. MIPS uses an offset of 2000 decimal between its syscall ABIs, which would imply n ~ 11, although I personally think that is too restrictive (MIPS could in fact use such a flag to provide an escape into a larger number space if we ever need more than 2000 system calls.)
>
> I would suggest n = 24, at least for now. It is easier to give up additional bits later than to claw them back when already used.
>
> Thus:
>
> 1. The type for a system call is int.
>
> 2. A valid system call number is always going to be positive.
>
> 3. Bits [30:24] are available for architecture ABI use. The "architecture independent" part of the system call number is therefore 24 bits wide.
Will that also work correctly with seccomp?
As I understand it the current situation is that on x86 the BPF code
passed to seccomp must filter the compat syscall bit in the PBF code,
and I do not see how restricting the syscall value to 24bit would happen
without changing the seccomp filter API.
See eg. https://lore.kernel.org/linuxppc-dev/akTExSO3ZT7iRtBa@kunlun.suse.cz/
for sample code.
>
> 4. The exact ABI is platform-specific, obviously, but as a general guideline (especially for new platforms/ABIs) should follow the rules for a platform "int" if practical. Notably, when passing a value in a register larger than 32 bits, which side of the calling interface is responsible for sign-extending a value passed in a register. If caller side, the kernel should validate, if callee side the kernel should ignore the additional bits and do the extension.
Do we even want to play with sign-extend?
If the syscall number is >= 1<<n after masking off flags recognized by
the platfrom (if any) it's invalid.
> 5. A negative system call number is guaranteed to return -ENOSYS (unless intercepted by seccomp, ptrace, or another mechanism under user space control.)
Interception by seccomp is exactly the case that's wonky.
> 6. If the platform needs to algorithmically modify the system call number due to platform-specific concerns (say, the platform uses a 16-bit special purpose register for the syscall number, or it has multiple kernel entry points with different behavior), it should if at all possible transcode the system call number as necessary to match this convention in APIs that are exposed to general kernel code.
>
> For example, in the future I could very much see the IA32 code in the x86 kernel using bit 29 internally to indicate an ia32 system call, simplifying the is_compat implementation on x86. It should not mean that passing bit 29 to either the syscall instruction or int $0x80 will be accepted.
As I understand the code it uses bit 30 for that. Maybe I missed
something?
Thanks
Michal
^ permalink raw reply
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Michal Suchánek @ 2026-07-02 9:12 UTC (permalink / raw)
To: Sven Schnelle
Cc: Peter Zijlstra, Jonathan Corbet, Shuah Khan, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andrew Donnellan, Mark Rutland,
Arnd Bergmann, Jiaxun Yang, Ryan Roberts, Greg Kroah-Hartman,
Mukesh Kumar Chaurasiya, Shrikanth Hegde, Zong Li, Nam Cao,
Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook, linux-doc,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <yt9dechlbyj0.fsf@linux.ibm.com>
On Thu, Jul 02, 2026 at 10:12:35AM +0200, Sven Schnelle wrote:
> Michal Suchánek <msuchanek@suse.de> writes:
>
> > The return value of syscall_enter_from_user_mode is used both for the
> > adjusted syscall number and the indicator that a syscall should be
> > skipped.
> >
> > As seccomp can be invoked on any syscall, including invalid ones this
> > somewhat undermines seccomp.
> >
> > While the seccomp variants that terminate the process do not need to
> > care about this for the filter that sets the syscall return value this
> > disctinction is required.
> >
> > Pass the syscall number as a pointer to the inline entry functions, and
> > use the return value exclusively for the indication that the syscall is
> > already handled.
> >
> > This should avoid the need for the s390 PIF_SYSCALL_RET_SET which is the
> > workaround for exactly this deficiency.
>
> I'm not sure whether PIF_SYSCALL_RET_SET can be removed - the syscall
> return might still get set by PTRACE_SET_SYSCALL_INFO when the tracee is
> stopped. This might be a positive number which can't be distinguished
> from a syscall number. But maybe i'm missing something? It's been quite
> a while since I touched all that ptrace stuff.
When the syscall return value is set (in the registers) the return value
which is also the modified syscall number is set to -1 indicating the
syscall was handled. At least that's how the API is described.
So yes, if the syscall number range is restricted or the syscall number
is returned through a path different from the function return value the
flag should not be needed in the entry path because the case can be
detected through the return value alone.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v3 4/4] panic: use sys_info_with_filter() to avoid duplicate backtraces
From: Petr Mladek @ 2026-07-02 9:09 UTC (permalink / raw)
To: Bradley Morgan
Cc: Feng Tang, Andrew Morton, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Madhavan Srinivasan, Douglas Anderson,
linux-kernel, linuxppc-dev, stable
In-Reply-To: <E482A23D-4E1C-42C0-9D07-83C6CDFD1546@grrlz.net>
On Mon 2026-06-29 13:54:18, Bradley Morgan wrote:
> On 29 June 2026 12:40:52 BST, Feng Tang <feng.tang@linux.alibaba.com>
> wrote:
> >On Fri, Jun 26, 2026 at 02:14:14PM +0200, Petr Mladek wrote:
> >> On Fri 2026-06-26 12:23:50, Petr Mladek wrote:
> >> > On Thu 2026-06-25 15:25:58, Bradley Morgan wrote:
> >> > > panic_other_cpus_shutdown() handles SYS_INFO_ALL_BT before stopping
> >the
> >> > > other CPUs. Do not ask sys_info() to handle that bit again later in
> >the
> >> > > panic path.
> >> > >
> >> > > Use sys_info_with_filter() so panic_print=all_bt does not request
> >more
> >> > > output after the CPUs are stopped.
> >> > >
> >> > > Fixes: a9af76a78760 ("watchdog: add sys_info sysctls to dump sys
> >info on system lockup")
> >> > > Cc: stable@vger.kernel.org
> >> > > Signed-off-by: Bradley Morgan <include@grrlz.net>
> >> > > ---
> >> > > kernel/panic.c | 2 +-
> >> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/kernel/panic.c b/kernel/panic.c
> >> > > index 213725b612aa..eb842823df61 100644
> >> > > --- a/kernel/panic.c
> >> > > +++ b/kernel/panic.c
> >> > > @@ -680,7 +680,7 @@ void vpanic(const char *fmt, va_list args)
> >> > > */
> >> > > atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
> >> > >
> >> > > - sys_info(panic_print);
> >> > > + sys_info_with_filter(panic_print, SYS_INFO_ALL_BT);
> >> >
> >> > Hmm, this prevents printing backtraces from all CPUs completely.
> >> > But what if they were not printed?
> >> >
> >> > They might be printed by:
> >> >
> >> > static void panic_other_cpus_shutdown(bool crash_kexec)
> >> > {
> >> > if (panic_print & SYS_INFO_ALL_BT)
> >> > panic_trigger_all_cpu_backtrace();
> >> >
> >> > [...]
> >> > }
> >> >
> >> > But it checks only "panic_print" variable. It won't do anything
> >> > when (panic_print == 0).
> >> >
> >> > In this case, we might still want to print the backraces when
> >> > SYS_INFO_ALL_BT is set in kernel_si_info.
> >> >
> >> > > kmsg_dump_desc(KMSG_DUMP_PANIC, buf);
> >> >
> >> > Of course, we might fix panic_other_cpus_shutdown() to check also
> >> > kernel_si_info.
> >> >
> >> > But it all becomes very hairy. We have several levels:
> >> >
> >> > + watchdog-all_bt-specific option, e.g.
> >sysctl_hardlockup_all_cpu_backtrace
> >> >
> >> > + watchdog-specific si_info preferences, e.g. hardlockup_si_mask
> >> >
> >> > + panic-specific si_info: panic_print
> >> >
> >> > + universal fallback for any layer: kernel_si_info
> >> >
> >> > Now, we try to check all these variables back and forth to
> >> > trigger all backtraces or to avoid triggering them.
> >> > And it clearly does not work well and the code is more and more
> >> > hairy.
> >> >
> >> > I think about another approach. The word "waterfall" comes to my mind.
> >> > Instead of checking all the settings back and forth, let's process
> >> > each setting one by one and just remember what has been done and
> >> > skip this in the next level.
> >> >
> >> > All the si_info actions seems to dump a global system state.
> >> > So, it would make sense to remember the state in a global variable
> >> > even when it might be modified by more CPUs in parallel.
> >> >
> >> > I am going to think more about it.
> >>
> >> I have created a POC using Gemini. I haven't tested it.
> >> But it looks acceptable. And the logic seems to be more
> >> straightforward.
> >>
> >> One drawback is that it requires adding the _reset()
> >> call for all sys_info() callers. It is fine in principle
> >> but it might complicate back-porting because all changes
> >> have to be done in one patch.
> >>
> >> But honestly, this is a nice to have fix. Most people could
> >> live happily without it.
> >>
> >> From 3c66436d9978030845a96bfaedd6b914536e2ac4 Mon Sep 17 00:00:00 2001
> >> From: Petr Mladek <pmladek@suse.com>
> >> Date: Fri, 26 Jun 2026 13:55:41 +0200
> >> Subject: [POC] sys_info: Introduce state-tracking APIs to prevent
> >duplicate
> >> backtraces
> >>
> >> In watchdog, panic, and hung task detection scenarios, sys_info() can
> >> be called multiple times or alongside direct backtrace triggers like
> >> trigger_allbutcpu_cpu_backtrace(). This results in identical backtraces
> >> being dumped repeatedly from all CPUs, cluttering the kernel log and
> >> delaying or obscuring critical debug details.
> >>
> >> Introduce a state tracking bitmask and associated helpers:
> >> - sys_info_done(mask): Marks specific sys_info bits as already printed.
> >> - sys_info_reset(): Resets the tracking state.
> >> - sys_info_is_done(mask): Checks if all bits in the mask have been
> >printed.
> >>
> >> Update sys_info() to automatically filter out already printed bits
> >> using this state. Integrate these APIs with the generic hardlockup
> >> and softlockup watchdogs, the PowerPC watchdog, the hung task detector,
> >> and the panic core. This ensures that each piece of system information
> >> and backtrace output is printed at most once per lockup/panic event,
> >> and the state is reset cleanly when a lockup does not trigger a panic.
> >>
> >> Races between sys_info() callers are ignored. It should be acceptable
> >> because the output from various watchdogs has never been synchronized.
> >> And panic() never returns.
> >>
> >> Assisted-by: gemini-1.5-flash
> >> Signed-off-by: Petr Mladek <pmladek@suse.com>
> >
> >Yep. There are cases that people want panic on task-hung or sw/hw lockup,
> >and this could remove much duplication of sys info dump, thanks!
> >
> >Reviewed-by: Feng Tang <feng.tang@linux.alibaba.com>
>
> Thanks,
>
> im feeling a new file to do all the force panic jazz, but putting tape
> on sys_info.c isn't bd either.
I wonder how to move forward with this.
Honestly, I am not sure what exactly you mean by creating another
API for tracking the reports so I could not judge it. Feel free
to sent some POC.
Otherwise, I would go with my proposal to remember the printed states
by the sys_info API. I am not sure whether I should send a proper
patch or you would like to somehow improve it.
Best Regards,
Petr
^ permalink raw reply
* [PATCH] KVM: PPC: Book3S HV: Fix comment typos
From: Salman Farooq @ 2026-07-02 3:03 UTC (permalink / raw)
To: maddy; +Cc: npiggin, mpe, chleroy, linuxppc-dev, kvm, linux-kernel,
Salman Farooq
Fix two instances of a misspelled word in comments.
Signed-off-by: Salman Farooq <salman.farooq3310@gmail.com>
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 5fbb95d90e99..6ac8364a7639 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -163,7 +163,7 @@ static DEFINE_SPINLOCK(kvmppc_uvmem_bitmap_lock);
* All its GFNs are moved to Normal-GFNs.
*
* UV_TERMINATE transitions the secure-VM back to normal-VM. All
- * the secure-GFN and shared-GFNs are tranistioned to normal-GFN
+ * the secure-GFN and shared-GFNs are transitioned to normal-GFN
* Note: The contents of the normal-GFN is undefined at this point.
*
* GFN state implementation:
@@ -1010,7 +1010,7 @@ static vm_fault_t kvmppc_uvmem_migrate_to_ram(struct vm_fault *vmf)
/*
* Release the device PFN back to the pool
*
- * Gets called when secure GFN tranistions from a secure-PFN
+ * Gets called when secure GFN transitions from a secure-PFN
* to a normal PFN during H_SVM_PAGE_OUT.
* Gets called with kvm->arch.uvmem_lock held.
*/
--
2.55.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox