* Re: [PATCH v10 01/30] arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06
From: Mark Brown @ 2026-05-09 0:43 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Ben Horgan,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <af4ZYVFsbYlEfdOu@J2N7QTR9R3>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Fri, May 08, 2026 at 06:12:01PM +0100, Mark Rutland wrote:
> On Fri, Mar 06, 2026 at 05:00:53PM +0000, Mark Brown wrote:
> > Update the definition of SMIDR_EL1 in the sysreg definition to reflect the
> > information in DD0601 2025-06. This includes somewhat more generic ways of
> > describing the sharing of SMCUs, more information on supported priorities
> > and provides additional resolution for describing affinity groups.
> FWIW, these are all in ARM DDI 0487 M.b:
> https://developer.arm.com/documentation/ddi0487/mb/
> Is anything later in the series going to depend on these fields, or
> would everything behave correctly with the existing RES0 field
> definitions?
We're exposing the affinity fields so there's a build time issue.
> > +Field 55:52 HIP
> Reading the ARM ARM, HIP is arguably a backwards-incompatible change.
Yes, I belive people are aware.
> Do we expect to expose that to VMs, or just hide priorities entirely? I
> suspect we probably want to require that the guest sees
> SMIDR_EL1.SMPS==0, and not care about any of that.
Currently we're not exposing priority support to guests so we don't need
to worry about it yet.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Andrew Morton @ 2026-05-09 0:36 UTC (permalink / raw)
To: Sasha Levin
Cc: corbet, skhan, linux-doc, linux-kernel, linux-kselftest, gregkh
In-Reply-To: <af58hCeOU15570Yq@laps>
On Fri, 8 May 2026 20:15:00 -0400 Sasha Levin <sashal@kernel.org> wrote:
> Livepatch is great when you have one. The problem is getting one...
>
> To get a livepatch, somebody has to write the fix, build it against the exact
> kernel you're running (for distros, thats hundreds of different
> kernel/arch/flavor combinations), sign it, and get it onto every machine.
>
> Most regular users won't be able to do it on their own because of secure boot
> limitations, so they depend on their vendor to provide them with one.
>
> Yes, you could write a livepatch that just stubs the function out, same end
> state as killswitch, but you still have to build, sign, and ship a module per
> kernel to do it
>
> Killswitch would be just a single write to /sys which an ordinary user can do
> to mitigate a critical issue immediately.
OK, thanks. Worth adding the changelog in case someone else was
wondering?
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-09 0:15 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, skhan, linux-doc, linux-kernel, linux-kselftest, gregkh
In-Reply-To: <20260508164925.20e09fba0277f0bc8ffc9a3d@linux-foundation.org>
On Fri, May 08, 2026 at 04:49:25PM -0700, Andrew Morton wrote:
>On Fri, 8 May 2026 17:47:04 -0400 Sasha Levin <sashal@kernel.org> wrote:
>
>> >> 19 files changed, 1451 insertions(+), 1 deletion(-)
>> >
>> >wowzers. I'm looking at samples/livepatch/livepatch-sample.c wondering
>> >"why"?
>>
>> Yup, a bit chunky, but over half of it is documentation and testing, and the
>> actual functional code is largely the securityfs interface.
>
>So we can't use livepatch here?
I might have misunderstood your original question.
Livepatch is great when you have one. The problem is getting one...
To get a livepatch, somebody has to write the fix, build it against the exact
kernel you're running (for distros, thats hundreds of different
kernel/arch/flavor combinations), sign it, and get it onto every machine.
Most regular users won't be able to do it on their own because of secure boot
limitations, so they depend on their vendor to provide them with one.
Yes, you could write a livepatch that just stubs the function out, same end
state as killswitch, but you still have to build, sign, and ship a module per
kernel to do it
Killswitch would be just a single write to /sys which an ordinary user can do
to mitigate a critical issue immediately.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2 02/14] mm: rename uffd-wp PTE bit macros to uffd
From: SeongJae Park @ 2026-05-08 23:52 UTC (permalink / raw)
To: Kiryl Shutsemau (Meta)
Cc: SeongJae Park, akpm, rppt, peterx, david, ljs, surenb, vbabka,
Liam.Howlett, ziy, corbet, skhan, seanjc, pbonzini, jthoughton,
aarcange, usama.arif, linux-mm, linux-kernel, linux-doc,
linux-kselftest, kvm, kernel-team
In-Reply-To: <4ff3508b951ec4879177dd079003c3fa3af0a444.1778254670.git.kas@kernel.org>
On Fri, 8 May 2026 16:55:14 +0100 "Kiryl Shutsemau (Meta)" <kas@kernel.org> wrote:
> The uffd-wp PTE bit is about to gain a second consumer: userfaultfd
> RWP will use the same bit to mark access-tracking PTEs, distinct
> from mprotect(PROT_NONE) or NUMA-hinting PTEs. WP vs RWP semantics
> come from the VMA flag; the bit is just "uffd has claimed this
> entry." Drop the "_wp" suffix from the arch-private bit macros so
> they reflect that.
>
> x86: _PAGE_BIT_UFFD_WP -> _PAGE_BIT_UFFD
> _PAGE_UFFD_WP -> _PAGE_UFFD
> _PAGE_SWP_UFFD_WP -> _PAGE_SWP_UFFD
> arm64: PTE_UFFD_WP -> PTE_UFFD
> PTE_SWP_UFFD_WP -> PTE_SWP_UFFD
> riscv: _PAGE_UFFD_WP -> _PAGE_UFFD
> _PAGE_SWP_UFFD_WP -> _PAGE_SWP_UFFD
>
> Pure mechanical rename -- no behavior change.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-6
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH v9 0/4] kunit: Add support for suppressing warning backtraces
From: Andrew Morton @ 2026-05-08 23:52 UTC (permalink / raw)
To: Albert Esteve
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, linux-kernel,
linux-arch, linux-kselftest, kunit-dev, dri-devel, workflows,
linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook, Linux Kernel Functional Testing,
Maíra Canal, Dan Carpenter, Simona Vetter
In-Reply-To: <20260508-kunit_add_support-v9-0-99df7aa880f6@redhat.com>
On Fri, 08 May 2026 17:02:44 +0200 Albert Esteve <aesteve@redhat.com> wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> ...
>
> Solve the problem by providing a means to suppress warning backtraces
> originating from the current kthread while executing test code.
> Since each KUnit test runs in its own kthread, this effectively scopes
> suppression to the test that enabled it, without requiring any
> architecture-specific code.
Thanks. AI review has a bunch of questions:
https://sashiko.dev/#/patchset/20260508-kunit_add_support-v9-0-99df7aa880f6@redhat.com
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Andrew Morton @ 2026-05-08 23:49 UTC (permalink / raw)
To: Sasha Levin
Cc: corbet, skhan, linux-doc, linux-kernel, linux-kselftest, gregkh
In-Reply-To: <af5Z2IvtS5pVorSl@laps>
On Fri, 8 May 2026 17:47:04 -0400 Sasha Levin <sashal@kernel.org> wrote:
> >> 19 files changed, 1451 insertions(+), 1 deletion(-)
> >
> >wowzers. I'm looking at samples/livepatch/livepatch-sample.c wondering
> >"why"?
>
> Yup, a bit chunky, but over half of it is documentation and testing, and the
> actual functional code is largely the securityfs interface.
So we can't use livepatch here?
^ permalink raw reply
* Re: [PATCH v6 01/43] KVM: guest_memfd: Introduce per-gmem attributes, use to guard user mappings
From: Ackerley Tng @ 2026-05-08 23:36 UTC (permalink / raw)
To: Ackerley Tng via B4 Relay, aik, andrew.jones, binbin.wu, brauner,
chao.p.peng, david, ira.weiny, jmattson, jthoughton, michael.roth,
oupton, pankaj.gupta, qperret, rick.p.edgecombe, rientjes,
shivankg, steven.price, tabba, willy, wyihan, yan.y.zhao,
forkloop, pratyush, suzuki.poulose, aneesh.kumar, liam,
Paolo Bonzini, Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-1-91ab5a8b19a4@google.com>
Ackerley Tng via B4 Relay <devnull+ackerleytng.google.com@kernel.org>
writes:
>
> [...snip...]
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 69c9d6d546b28..5011d38820d0d 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -4,6 +4,7 @@
> #include <linux/falloc.h>
> #include <linux/fs.h>
> #include <linux/kvm_host.h>
> +#include <linux/maple_tree.h>
> #include <linux/mempolicy.h>
> #include <linux/pseudo_fs.h>
> #include <linux/pagemap.h>
> @@ -33,6 +34,13 @@ struct gmem_inode {
> struct list_head gmem_file_list;
>
> u64 flags;
> + /*
> + * Every index in this inode, whether memory is populated or
> + * not, is tracked in attributes. The entire range of indices,
> + * corresponding to the size of this inode, is represented in
> + * this maple tree.
Concretely, if the entire guest_memfd is 2M in size, indices [0, 511] is
represented with some value, either 0 (SHARED) or
KVM_MEMORY_ATTRIBUTE_PRIVATE. [512, ULONG_MAX] is also defined in the
tree, as NULL.
Since guest_memfd uses xa_mk_value(0) to store the value 0 ("SHARED"),
that makes 0 distinct from NULL, which works for guest_memfd.
(Liam and I discussed this off-list due to a email configuration issue)
> + */
> + struct maple_tree attributes;
> };
>
>
> [...snip...]
>
^ permalink raw reply
* Re: [PATCH net-next v3 3/8] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Bobby Eshleman @ 2026-05-08 23:03 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu, Michael Chan, Pavan Chebbi, Joshua Washington,
Harshitha Ramamurthy, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Leon Romanovsky, Alexander Duyck, kernel-team, Daniel Borkmann,
Nikolay Aleksandrov, Shuah Khan, dw, sdf.kernel, mohsin.bashr,
willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev, linux-doc,
linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260508152708.011a9687@kernel.org>
On Fri, May 08, 2026 at 03:27:08PM -0700, Jakub Kicinski wrote:
> On Fri, 8 May 2026 14:28:55 -0700 Bobby Eshleman wrote:
> > My guess is this would probably be the simplest way?
>
> IDK. Notifiers are so inelegant. Don't we have the same problem with
> the main ->dev on Tx binding?
Yes, true. For some reason, I thought I recalled the dma buf attachment
causing some chain of reference holding that kept the device alive, but
that is actually not true...
^ permalink raw reply
* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: Randy Dunlap @ 2026-05-08 22:52 UTC (permalink / raw)
To: Andrew Lunn, Shuah Khan
Cc: Adrien Reynard, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Richard Weinberger, Anton Ivanov,
Johannes Berg, open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <3c6cde1a-9ce0-4d63-ba89-820c596cff3e@lunn.ch>
On 5/8/26 3:41 PM, Andrew Lunn wrote:
> On Fri, May 08, 2026 at 11:23:43AM -0600, Shuah Khan wrote:
>> On 5/8/26 10:38, Adrien Reynard wrote:
>>
>> Missing commit log
>>
>>> Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
>>> ---
>>> Documentation/dev-tools/kasan.rst | 2 +-
>>> Documentation/networking/switchdev.rst | 2 +-
>>> Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 +-
>>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
>>> index 4968b2aa60c8..3a8bd40ad905 100644
>>> --- a/Documentation/dev-tools/kasan.rst
>>> +++ b/Documentation/dev-tools/kasan.rst
>>> @@ -392,7 +392,7 @@ reserved to tag freed memory regions.
>>> If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN
>>> will not be enabled. In this case, all KASAN boot parameters are ignored.
>>> -Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
>>> +Note that enabling CONFIG_KASAN_HW_TAGS always results in-kernel TBI being
>>
>> This is correct the way it is - no need to change this. "results in in-kernel"
>>
>>> enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
>>> support MTE (but supports TBI).
>>> diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
>>> index 2966b7122f05..948bce44ca9b 100644
>>> --- a/Documentation/networking/switchdev.rst
>>> +++ b/Documentation/networking/switchdev.rst
>>> @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
>>> monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
>>> bond will see its upper master change. If that bond is moved into a bridge,
>>> the bond's upper master will change. And so on. The driver will track such
>>> -movements to know what position a port is in in the overall topology by
>>> +movements to know what position a port is in the overall topology by
>>
>> This looks fine.
>
> Fine as in the change is correct, or fine in that the original is
> correct and the change is wrong?
>
> Because the change is wrong, there should be two in's here. Please
> search the archive for an explanation why.
>
> This is the second time in a week i've had to deal with "improvements"
> like this actually breaking stuff. Which also shows that the submitter
> did not search to see if somebody has tried to fix this once already,
> and failed.
>
> Can we get the tool changed to add a warning, something like:
>
> WARNING: This tool uses very simple pattern matching to look for
> repeated words. It does not understand the complexity of English,
> and will often result in false positive reports. Please assume it is
> wrong until proven otherwise.
There was no commit log and no cover letter AFAIK.
Do we know what tool was used?
Adrien, how did you discover these repeated words?
(If it's my script from 2021, I'll gladly update it.)
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 00/14] userfaultfd: working set tracking for VM guest memory
From: Kiryl Shutsemau @ 2026-05-08 22:48 UTC (permalink / raw)
To: Andrew Morton
Cc: rppt, peterx, david, ljs, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team
In-Reply-To: <20260508103220.aa46427b6f4c5d0247d2afb0@linux-foundation.org>
On Fri, May 08, 2026 at 10:32:20AM -0700, Andrew Morton wrote:
> On Fri, 8 May 2026 16:55:12 +0100 "Kiryl Shutsemau (Meta)" <kas@kernel.org> wrote:
>
> > This series adds userfaultfd support for tracking the working set of
> > VM guest memory, so a VMM can identify cold pages and evict them to
> > tiered or remote storage.
> >
> > v1: https://lore.kernel.org/all/20260427114607.4068647-1-kas@kernel.org/
>
> Thanks. I'll duck v2 for now, await more review.
Sure.
> > Assisted-by: Claude:claude-opus-4-6
>
> For my education, and perhaps for others: can you please explain how
> you used Claude in the preparation of this series?
I'm no expert by any means, but here's how I used it here.
For this particular project there was quite a bit of path-finding.
I had a phase where I bounced ideas off Claude. It helped me
understand the problem space better and formulate possible solutions.
Rubber ducking on steroids.
Once it's clear _what_ to do, we formulate a plan on _how_. It also
involves back and forth.
Once the plan was done, I gave the go-ahead on executing it.
Userfaultfd already had a test suite, and it was extended to cover the new
functionality. I have some scripts to build the kernel and run it in a VM.
Claude knows how to use them, so at the end of plan execution I had a
functional feature.
Then the review phase. The most time-consuming and draining part.
I carefully reviewed all patches.
At this stage I use Claude as an editor.
Some of the changes I asked for required substantial rework of the whole
patchset, and I had to start the review from scratch. A good test suite and
build-test harness help to keep the whole thing from falling apart.
It took me quite a few review rounds before I was happy with the result.
Maybe between 8 and 10. I think better instructions can cut this number down.
And I need to rethink how I do the review. Reading the git log in
parallel with examining the code in the editor and giving instructions to
Claude is not very ergonomic. There's room for improvement.
Once I was happy with the patchset to give it Signed-off-by, I ran it
through Chris' review prompts several times, addressing the issues.
I hope it is helpful. I would also be glad if other folks shared their
workflow. There is probably a better way to achieve the same result.
I am new to the game.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: Andrew Lunn @ 2026-05-08 22:41 UTC (permalink / raw)
To: Shuah Khan
Cc: Adrien Reynard, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Richard Weinberger, Anton Ivanov,
Johannes Berg, open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <2b771350-0562-4cb1-b9b3-cc3ce59b1a63@linuxfoundation.org>
On Fri, May 08, 2026 at 11:23:43AM -0600, Shuah Khan wrote:
> On 5/8/26 10:38, Adrien Reynard wrote:
>
> Missing commit log
>
> > Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
> > ---
> > Documentation/dev-tools/kasan.rst | 2 +-
> > Documentation/networking/switchdev.rst | 2 +-
> > Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
> > index 4968b2aa60c8..3a8bd40ad905 100644
> > --- a/Documentation/dev-tools/kasan.rst
> > +++ b/Documentation/dev-tools/kasan.rst
> > @@ -392,7 +392,7 @@ reserved to tag freed memory regions.
> > If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN
> > will not be enabled. In this case, all KASAN boot parameters are ignored.
> > -Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
> > +Note that enabling CONFIG_KASAN_HW_TAGS always results in-kernel TBI being
>
> This is correct the way it is - no need to change this. "results in in-kernel"
>
> > enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
> > support MTE (but supports TBI).
> > diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
> > index 2966b7122f05..948bce44ca9b 100644
> > --- a/Documentation/networking/switchdev.rst
> > +++ b/Documentation/networking/switchdev.rst
> > @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
> > monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
> > bond will see its upper master change. If that bond is moved into a bridge,
> > the bond's upper master will change. And so on. The driver will track such
> > -movements to know what position a port is in in the overall topology by
> > +movements to know what position a port is in the overall topology by
>
> This looks fine.
Fine as in the change is correct, or fine in that the original is
correct and the change is wrong?
Because the change is wrong, there should be two in's here. Please
search the archive for an explanation why.
This is the second time in a week i've had to deal with "improvements"
like this actually breaking stuff. Which also shows that the submitter
did not search to see if somebody has tried to fix this once already,
and failed.
Can we get the tool changed to add a warning, something like:
WARNING: This tool uses very simple pattern matching to look for
repeated words. It does not understand the complexity of English,
and will often result in false positive reports. Please assume it is
wrong until proven otherwise.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 3/8] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Jakub Kicinski @ 2026-05-08 22:27 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu, Michael Chan, Pavan Chebbi, Joshua Washington,
Harshitha Ramamurthy, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Leon Romanovsky, Alexander Duyck, kernel-team, Daniel Borkmann,
Nikolay Aleksandrov, Shuah Khan, dw, sdf.kernel, mohsin.bashr,
willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev, linux-doc,
linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <af5Vlwb5RctHym8D@devvm29614.prn0.facebook.com>
On Fri, 8 May 2026 14:28:55 -0700 Bobby Eshleman wrote:
> My guess is this would probably be the simplest way?
IDK. Notifiers are so inelegant. Don't we have the same problem with
the main ->dev on Tx binding?
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-08 21:47 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, skhan, linux-doc, linux-kernel, linux-kselftest, gregkh
In-Reply-To: <20260508135630.a380e3c187b59e4c04e6f358@linux-foundation.org>
On Fri, May 08, 2026 at 01:56:30PM -0700, Andrew Morton wrote:
>On Thu, 7 May 2026 03:05:45 -0400 Sasha Levin <sashal@kernel.org> wrote:
>
>> When a (security) issue goes public, fleets stay exposed until a patched kernel
>> is built, distributed, and rebooted into.
>>
>> For many such issues the simplest mitigation is to stop calling the buggy
>> function. Killswitch provides that. An admin writes:
>>
>> echo "engage af_alg_sendmsg -1" \
>> > /sys/kernel/security/killswitch/control
>
>It certainly sounds useful, but what would I know. How do we hunt down
>suitable operations people (aka "target audience") to find out how
>useful this is to them?
I'm not entierly sure here... If folks have suggestions on folks to loop in,
that'll be great!
>> 19 files changed, 1451 insertions(+), 1 deletion(-)
>
>wowzers. I'm looking at samples/livepatch/livepatch-sample.c wondering
>"why"?
Yup, a bit chunky, but over half of it is documentation and testing, and the
actual functional code is largely the securityfs interface.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net-next v3 3/8] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Bobby Eshleman @ 2026-05-08 21:28 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu, Michael Chan, Pavan Chebbi, Joshua Washington,
Harshitha Ramamurthy, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Leon Romanovsky, Alexander Duyck, kernel-team, Daniel Borkmann,
Nikolay Aleksandrov, Shuah Khan, dw, sdf.kernel, mohsin.bashr,
willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev, linux-doc,
linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260508134717.4ef87ab6@kernel.org>
On Fri, May 08, 2026 at 01:47:17PM -0700, Jakub Kicinski wrote:
> On Thu, 07 May 2026 19:27:48 -0700 Bobby Eshleman wrote:
> > + /* Virtual device (e.g. netkit) the user called bind-tx on. Must be
> > + * NETMEM_TX_NO_DMA.
> > + */
> > + struct net_device *vdev;
>
> AI keeps complaining that we don't hold a reference to this dev which
> I think is fine, we're just comparing pointers. Could we maybe make this
> a void pointer and mention in the comment that we treat it as "best
> effort cookie" (better phrasing welcome).
>
> Or we should wipe these vdev pointers when vdevs disappear, not sure
> how hard that'd be (or whether it's worth the extra state).
My guess is this would probably be the simplest way?
diff --git a/net/core/devmem.c b/net/core/devmem.c
index 644c286b778f..e28fae14c687 100644
--- a/net/core/devmem.c
+++ b/net/core/devmem.c
@@ -533,3 +533,38 @@ static const struct memory_provider_ops dmabuf_devmem_ops = {
.nl_fill = mp_dmabuf_devmem_nl_fill,
.uninstall = mp_dmabuf_devmem_uninstall,
};
+
+static int net_devmem_netdev_event(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+ struct net_devmem_dmabuf_binding *binding;
+ unsigned long id;
+
+ if (event != NETDEV_UNREGISTER)
+ return NOTIFY_DONE;
+
+ xa_for_each(&net_devmem_dmabuf_bindings, id, binding) {
+ if (!net_devmem_dmabuf_binding_get(binding))
+ continue;
+ mutex_lock(&binding->lock);
+ if (READ_ONCE(binding->vdev) == dev) {
+ ASSERT_EXCLUSIVE_WRITER(binding->vdev);
+ WRITE_ONCE(binding->vdev, NULL);
+ }
+ mutex_unlock(&binding->lock);
+ net_devmem_dmabuf_binding_put(binding);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block net_devmem_netdev_nb = {
+ .notifier_call = net_devmem_netdev_event,
+};
+
+static int __init net_devmem_init(void)
+{
+ return register_netdevice_notifier(&net_devmem_netdev_nb);
+}
+subsys_initcall(net_devmem_init);
I'm open to either approach. The void* + comment is good too, IMHO. For
the notifier, I'd probably want to add a test too ensure sendmsg() kicks
back after the device is removed.
Best,
Bobby
^ permalink raw reply related
* Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Ackerley Tng @ 2026-05-08 21:21 UTC (permalink / raw)
To: Sean Christopherson, Michael Roth
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Jason Gunthorpe,
Vlastimil Babka, kvm, linux-kernel, linux-trace-kernel, linux-doc,
linux-kselftest, linux-mm
In-Reply-To: <af4gJ6xZ3e7UXOuO@google.com>
Sean Christopherson <seanjc@google.com> writes:
>
> [...snip...]
>
>
> Summarizing this week's PUCK call[*]:
>
> Scrap PRESERVE and ZERO, and simply rely on vendor specific semantics.
>
>
> [...snip...]
>
Thanks for the summary! Please see v6 here:
https://lore.kernel.org/all/20260507-gmem-inplace-conversion-v6-0-91ab5a8b19a4@google.com/T/
^ permalink raw reply
* Re: [PATCH v11 02/12] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Borislav Petkov @ 2026-05-08 21:05 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
Jason Baron, Alice Ryhl, Steven Rostedt, Ard Biesheuvel,
Shuah Khan, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260422-vmscape-bhb-v11-2-b18e0cf32af4@linux.intel.com>
On Wed, Apr 22, 2026 at 11:15:15PM -0700, Pawan Gupta wrote:
> As a mitigation for BHI, clear_bhb_loop() executes branches that overwrite
> the Branch History Buffer (BHB). On Alder Lake and newer parts this
> sequence is not sufficient because it doesn't clear enough entries. This
> was not an issue because these CPUs use the BHI_DIS_S hardware mitigation
> in the kernel.
>
> Now with VMSCAPE (BHI variant) it is also required to isolate branch
> history between guests and userspace. Since BHI_DIS_S only protects the
> kernel, the newer CPUs also use IBPB.
>
> A cheaper alternative to the current IBPB mitigation is clear_bhb_loop().
> But it currently does not clear enough BHB entries to be effective on newer
> CPUs with larger BHB. At boot, dynamically set the loop count of
> clear_bhb_loop() such that it is effective on newer CPUs too.
>
> Introduce global loop counts, initializing them with appropriate value
> based on the hardware feature X86_FEATURE_BHI_CTRL.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/entry/entry_64.S | 8 +++++---
> arch/x86/include/asm/nospec-branch.h | 2 ++
> arch/x86/kernel/cpu/bugs.c | 13 +++++++++++++
> 3 files changed, 20 insertions(+), 3 deletions(-)
Simple and clean - that's how I like 'em.
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Andrew Morton @ 2026-05-08 20:56 UTC (permalink / raw)
To: Sasha Levin
Cc: corbet, skhan, linux-doc, linux-kernel, linux-kselftest, gregkh
In-Reply-To: <20260507070547.2268452-1-sashal@kernel.org>
On Thu, 7 May 2026 03:05:45 -0400 Sasha Levin <sashal@kernel.org> wrote:
> When a (security) issue goes public, fleets stay exposed until a patched kernel
> is built, distributed, and rebooted into.
>
> For many such issues the simplest mitigation is to stop calling the buggy
> function. Killswitch provides that. An admin writes:
>
> echo "engage af_alg_sendmsg -1" \
> > /sys/kernel/security/killswitch/control
It certainly sounds useful, but what would I know. How do we hunt down
suitable operations people (aka "target audience") to find out how
useful this is to them?
Also,
> 19 files changed, 1451 insertions(+), 1 deletion(-)
wowzers. I'm looking at samples/livepatch/livepatch-sample.c wondering
"why"?
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Shuah Khan @ 2026-05-08 20:52 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: leon, security, Jonathan Corbet, workflows, linux-doc,
linux-kernel, Greg KH, Shuah Khan
In-Reply-To: <20260503113506.5710-3-w@1wt.eu>
On 5/3/26 05:35, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/index.rst | 1 +
> Documentation/process/security-bugs.rst | 28 +++
> Documentation/process/threat-model.rst | 231 ++++++++++++++++++++++++
> 3 files changed, 260 insertions(+)
> create mode 100644 Documentation/process/threat-model.rst
>
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index dbd6ea16aca70..aa7c959a52b87 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -86,6 +86,7 @@ regressions and security problems.
> debugging/index
> handling-regressions
> security-bugs
> + threat-model
> cve
> embargoed-hardware-issues
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 6dc525858125e..3b44464dd9ba7 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -66,6 +66,34 @@ In addition, the following information are highly desirable:
> the issue appear. It is useful to share them, as they can be helpful to
> keep end users protected during the time it takes them to apply the fix.
>
> +What qualifies as a security bug
> +--------------------------------
> +
> +It is important that most bugs are handled publicly so as to involve the widest
> +possible audience and find the best solution. By nature, bugs that are handled
> +in closed discussions between a small set of participants are less likely to
> +produce the best possible fix (e.g., risk of missing valid use cases, limited
> +testing abilities).
> +
> +It turns out that the majority of the bugs reported via the security team are
> +just regular bugs that have been improperly qualified as security bugs due to
> +ignorance or misunderstanding of the Linux kernel's threat model described in
"lack of understanding" instead of ignorance?
> +Documentation/process/threat-model.rst, and ought to have been sent through
> +the normal channels described in Documentation/admin-guide/reporting-issues.rst
> +instead.
> +
> +The security list exists for urgent bugs that grant an attacker a capability
> +they are not supposed to have on a correctly configured production system, and
> +can be easily exploited, representing an imminent threat to many users. Before
> +reporting, consider whether the issue actually crosses a trust boundary on such
> +a system.
> +
> +If you are unsure whether an issue qualifies, err on the side of reporting
> +privately: the security team would rather triage a borderline report than miss
> +a real vulnerability. Reporting ordinary bugs to the security list, however,
> +does not make them move faster and consumes triage capacity that other reports
> +need.
> +
> Identifying contacts
> --------------------
>
> diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
> new file mode 100644
> index 0000000000000..8cd46483cd8b5
> --- /dev/null
> +++ b/Documentation/process/threat-model.rst
> @@ -0,0 +1,231 @@
> +.. _threatmodel:
> +
> +The Linux Kernel threat model
> +=============================
> +
> +There are a lot of assumptions regarding what the kernel protects against and
> +what it does not protect against. These assumptions tend to cause confusion for
Could simply say "what it does not" or "what the kernel does and does not protect
against"
> +bug reports (:doc:`security-related ones <security-bugs>` vs
> +:doc:`non-security ones <../admin-guide/reporting-issues>`), and can complicate
> +security enforcement when the responsibilities for some boundaries is not clear
> +between the kernel, distros, administrators and users.
> +
> +This document tries to clarify the responsibilities of the kernel in this
> +domain.
> +
> +The kernel's responsibilities
> +-----------------------------
> +
> +The kernel abstracts access to local hardware resources and to remote systems
> +in a way that allows multiple local users to get a fair share of the available
> +resources granted to them, and, when the underlying hardware permits, to assign
> +a level of confidentiality to their communications and to the data they are
> +processing or storing.
> +
> +The kernel assumes that the underlying hardware behaves according to its
> +specifications. This includes the integrity of the CPU's instruction set, the
> +transparency of the branch prediction unit and the cache units, the consistency
> +of the Memory Management Unit (MMU), the isolation of DMA-capable peripherals
> +(e.g., via IOMMU), state transitions in controllers, ranges of values read from
> +registers, the respect of documented hardware limitations, etc.
> +
> +When hardware fails to maintain its specified isolation (e.g., CPU bugs,
> +side-channels, hardware response to unexpected inputs), the kernel will usually
> +attempt to implement reasonable mitigations. These are best-effort measures
> +intended to reduce the attack surface or elevate the cost of an attack within
> +the limits of the hardware's facilities; they do not constitute a
> +kernel-provided safety guarantee.
> +
> +Users always perform their activities under the authority of an administrator
> +who is able to grant or deny various types of permissions that may affect how
> +users benefit from available resources, or the level of confidentiality of
> +their activities. Administrators may also delegate all or part of their own
> +permissions to some users, particularly via capabilities but not only. All this
> +is performed via configuration (sysctl, file-system permissions etc).
> +
> +The Linux Kernel applies a certain collection of default settings that match
> +its threat model. Distros have their own threat model and will come with their
> +own configuration presets, that the administrator may have to adjust to better
> +suit their expectations (relax or restrict).
> +
> +By default, the Linux Kernel guarantees the following protections when running
> +on common processors featuring privilege levels and memory management units:
> +
> +* **User-based isolation**: an unprivileged user may restrict access to their
> + own data from other unprivileged users running on the same system. This
> + includes:
> +
> + * stored data, via file system permissions
> + * in-memory data (pages are not accessible by default to other users)
> + * process activity (ptrace is not permitted to other users)
> + * inter-process communication (other users may not observe data exchanged via
> + UNIX domain sockets or other IPC mechanisms).
> + * network communications within the same or with other systems
> +
> +* **Capability-based protection**:
> +
> + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
> + kernel's configuration, memory nor state, change other users' view of the
> + file system layout, grant any user capabilities they do not have, nor
> + affect the system's availability (shutdown, reboot, panic, hang, or making
> + the system unresponsive via unbounded resource exhaustion).
> + * users not having the ``CAP_NET_ADMIN`` capability may not alter the network
> + configuration, intercept nor spoof network communications from other users
> + nor systems.
> + * users not having ``CAP_SYS_PTRACE`` may not observe other users' processes
> + activities.
> +
> +When ``CONFIG_USER_NS`` is set, the kernel also permits unprivileged users to
> +create their own user namespace in which they have all capabilities, but with a
> +number of restrictions (they may not perform actions that have impacts on the
> +initial user namespace, such as changing time, loading modules or mounting
> +block devices). Please refer to ``user_namespaces(7)`` for more details, the
> +possibilities of user namespaces are not covered in this document.
> +
> +The kernel also offers a lot of troubleshooting and debugging facilities, which
> +can constitute attack vectors when placed in wrong hands. While some of them
> +are designed to be accessible to regular local users with a low risk (e.g.
> +kernel logs via ``/proc/kmsg``), some would expose enough information to
> +represent a risk in most places and the decision to expose them is under the
> +administrator's responsibility (perf events, traces), and others are not
> +designed to be accessed by non-privileged users (e.g. debugfs). Access to these
> +facilities by a user who has been explicitly granted permission by an
> +administrator does not constitute a security breach.
> +
> +Bugs that permit to violate the principles above constitute security breaches.
> +However, bugs that permit one violation only once another one was already
> +achieved are only weaknesses. The kernel applies a number of self-protection
> +measures whose purpose is to avoid crossing a security boundary when certain
> +classes of bugs are found, but a failure of these extra protections do not
> +constitute a vulnerability alone.
> +
> +What does not constitute a security bug
> +---------------------------------------
> +
> +In the Linux kernel's threat model, the following classes of problems are
> +**NOT** considered as Linux Kernel security bugs. However, when it is believed
> +that the kernel could do better, they should be reported, so that they can be
> +reviewed and fixed where reasonably possible, but they will be handled as any
> +regular bug:
> +
> +* **Configuration**:
> +
> + * outdated kernels and particularly end-of-life branches are out of the scope
> + of the kernel's threat model: administrators are responsible for keeping
> + their system up to date. For a bug to qualify as a security bug, it must be
> + demonstrated that it affects actively maintained versions.
> +
> + * build-level: changes to the kernel configuration that are explicitly
> + documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
> + targeted at developers only.
> +
> + * OS-level: changes to command line parameters, sysctls, filesystem
> + permissions, user capabilities, exposure of privileged interfaces, that
> + explicitly increase exposure by either offering non-default access to
> + unprivileged users, or reduce the kernel's ability to enforce some
> + protections or mitigations. Example: write access to procfs or debugfs.
> +
> + * issues triggered only when using features intended for development or
> + debugging (e.g., lockdep, KASAN, fault-injection): these features are known
> + to introduce overhead and potential instability and are not intended for
> + production use.
Can we call out features and tools (the ones in kernel repo)
sched_ext's Kconfig enables
a few debug options including LOCKDEP
tools/sched_ext/Kconfig:CONFIG_DEBUG_LOCKDEP=y
> +
> + * loading of explicitly insecure/broken/staging modules, and generally any
> + using any subsystem marked as experimental or not intended for production
> + use.
> +
> + * running out-of-tree modules or unofficial kernel forks; these should be
> + reported to the relevant vendor.
> +
> +* **Excess of initial privileges**:
> +
> + * actions performed by a user already possessing the privileges required to
> + perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``,
> + ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further
> + boundary being crossed).
> +
> + * actions performed in user namespace without permitting anything in the
> + initial namespace that was not already permitted to the same user there.
This was a bit hard to parse - examples might help here
> +
> + * anything performed by the root user in the initial namespace (e.g. kernel
> + oops when writing to a privileged device).
> +
> +* **Out of production use**:
> +
> + This covers theoretical/probabilistic attacks that rely on laboratory
> + conditions with zero system noise, or those requiring an unrealistic number
> + of attempts (e.g., billions of trials) that would be detected by standard
> + system monitoring long before success, such as:
> +
> + * prediction of random numbers that only works in a totally silent
> + environment (such as IP ID, TCP ports or sequence numbers that can only be
> + guessed in a lab).
> +
> + * activity observation and information leaks based on probabilistic
> + approaches that are prone to measurement noise and not realistically
> + reproducible on a production system.
> +
> + * issues that can only be triggered by heavy attacks (e.g. brute force) whose
> + impact on the system makes it unlikely or impossible to remain undetected
> + before they succeed (e.g. consuming all memory before succeeding).
> +
> + * problems seen only under development simulators, emulators, or combinations
> + that do not exist on real systems at the time of reporting (issues
> + involving tens of millions of threads, tens of thousands of CPUs,
> + unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
> +
> + * issues whose reproduction requires hardware modification or emulation,
> + including fake USB devices that pretend to be another one.
> +
> + * as well as issues that can be triggered at a cost that is orders of
> + magnitude higher than the expected benefits (e.g. fully functional keyboard
> + emulator only to retrieve 7 uninitialized bytes in a structure, or
> + brute-force method involving millions of connection attempts to guess a
> + port number).
Can we add a section about problems found using experimental or tools
in development stage?
> +
> +* **Hardening failures**:
> +
> + * ability to bypass some of the kernel's hardening measures with no
> + demonstrable exploit path (e.g. ASLR bypass, events timing or probing with
> + no demonstrable consequence). These are just weaknesses, not
> + vulnerabilities.
> +
> + * missing argument checks and failure to report certain errors with no
> + immediate consequence.
> +
> +* **Random information leaks**:
> +
> + This concerns information leaks of small data parts that happen to be there
> + and that cannot be chosen by the attacker, or face access restrictions:
> +
> + * structure padding reported by syscalls or other interfaces.
> +
> + * identifiers, partial data, non-terminated strings reported in error
> + messages.
> +
> + * Leaks of kernel memory addresses/pointers do not constitute an immediately
> + exploitable vector and are not security bugs, though they must be reported
> + and fixed.
> +
> +* **Crafted file system images**:
> +
> + * bugs triggered by mounting a corrupted or maliciously crafted file system
> + image are generally not security bugs, as the kernel assumes the underlying
> + storage media is under the administrator's control, unless the filesystem
> + driver is specifically documented as being hardened against untrusted media.
> +
> + * issues that are resolved, mitigated, or detected by running a filesystem
> + consistency check (fsck) on the image prior to mounting.
> +
> +* **Physical access**:
> +
> + Issues that require physical access to the machine, hardware modification, or
> + the use of specialized hardware (e.g., logic analyzers, DMA-attack tools over
> + PCI-E/Thunderbolt) are out of scope unless the system is explicitly
> + configured with technologies meant to defend against such attacks
> + (e.g. IOMMU).
> +
> +* **Functional and performance regressions**:
> +
> + Any issue that can be mitigated by setting proper permissions and limits
> + doesn't qualify as a security bug.
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH net-next v3 3/8] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Jakub Kicinski @ 2026-05-08 20:47 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu, Michael Chan, Pavan Chebbi, Joshua Washington,
Harshitha Ramamurthy, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Leon Romanovsky, Alexander Duyck, kernel-team, Daniel Borkmann,
Nikolay Aleksandrov, Shuah Khan, dw, sdf.kernel, mohsin.bashr,
willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev, linux-doc,
linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <20260507-tcp-dm-netkit-v3-3-52821445867c@meta.com>
On Thu, 07 May 2026 19:27:48 -0700 Bobby Eshleman wrote:
> + /* Virtual device (e.g. netkit) the user called bind-tx on. Must be
> + * NETMEM_TX_NO_DMA.
> + */
> + struct net_device *vdev;
AI keeps complaining that we don't hold a reference to this dev which
I think is fine, we're just comparing pointers. Could we maybe make this
a void pointer and mention in the comment that we treat it as "best
effort cookie" (better phrasing welcome).
Or we should wipe these vdev pointers when vdevs disappear, not sure
how hard that'd be (or whether it's worth the extra state).
^ permalink raw reply
* Re: [PATCH net-next v3 3/8] net: devmem: support TX over NETMEM_TX_NO_DMA devices
From: Jakub Kicinski @ 2026-05-08 20:44 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Bobby Eshleman, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan, Alex Shi,
Yanteng Si, Dongliang Mu, Michael Chan, Pavan Chebbi,
Joshua Washington, Harshitha Ramamurthy, Saeed Mahameed,
Tariq Toukan, Mark Bloch, Leon Romanovsky, Alexander Duyck,
kernel-team, Daniel Borkmann, Nikolay Aleksandrov, Shuah Khan, dw,
mohsin.bashr, willemb, jiang.kun2, xu.xin16, wang.yaxin, netdev,
linux-doc, linux-kernel, linux-rdma, bpf, linux-kselftest,
Stanislav Fomichev, Mina Almasry, Bobby Eshleman
In-Reply-To: <af3593dYeiEeMzC2@devvm7509.cco0.facebook.com>
On Fri, 8 May 2026 08:01:17 -0700 Stanislav Fomichev wrote:
> Since this is a good case, maybe fold it into skb_frags_readable check above?
>
> if (likely(skb_frags_readable() || netmem_tx == NETMEM_TX_NO_DMA))
FWIW I had the same feeling on v2, so probably worth fixing.
^ permalink raw reply
* [RFC PATCH 3/5] mm: zswap: load fully stored large folios
From: fujunjie @ 2026-05-08 20:20 UTC (permalink / raw)
To: Andrew Morton, Chris Li, Kairui Song, Johannes Weiner, Nhat Pham,
Yosry Ahmed
Cc: linux-mm, linux-kernel, linux-doc, Jonathan Corbet,
David Hildenbrand, Ryan Roberts, Barry Song, Baolin Wang,
Chengming Zhou, Baoquan He, Lorenzo Stoakes
In-Reply-To: <tencent_8B437BE4F586C162950BF71954316C1EDB05@qq.com>
zswap_store() already stores every base page of a large folio as a
separate zswap entry and tears the whole folio back down on store
failure. The load side still rejects any large folio, which forces the
swapin path to avoid mTHP swapin once zswap has ever been enabled.
Use zswap_entry_batch() to distinguish three cases: the whole range is
absent from zswap and should fall through to the disk backend, the whole
range is present and can be decompressed one base page at a time, or the
range is mixed and must be treated as an invalid large-folio backend
selection.
After all entries decompress successfully, mark the folio uptodate and
dirty, account the mTHP swpin stat once for the folio, account one ZSWPIN
event per base page, and invalidate each zswap entry because the
swapcache folio becomes authoritative.
Signed-off-by: fujunjie <fujunjie1@qq.com>
---
Documentation/admin-guide/mm/transhuge.rst | 4 +-
mm/zswap.c | 65 ++++++++++++++--------
2 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index 5fbc3d89bb07..05456906aff6 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -644,8 +644,8 @@ zswpout
piece without splitting.
swpin
- is incremented every time a huge page is swapped in from a non-zswap
- swap device in one piece.
+ is incremented every time a huge page is swapped in from swap I/O or
+ zswap in one piece.
swpin_fallback
is incremented if swapin fails to allocate or charge a huge page
diff --git a/mm/zswap.c b/mm/zswap.c
index 27c14b8edd15..863ca1e896ed 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -28,6 +28,7 @@
#include <crypto/acompress.h>
#include <crypto/scatterwalk.h>
#include <linux/zswap.h>
+#include <linux/huge_mm.h>
#include <linux/mm_types.h>
#include <linux/page-flags.h>
#include <linux/swapops.h>
@@ -1614,20 +1615,23 @@ bool zswap_store(struct folio *folio)
* NOT marked up-to-date, so that an IO error is emitted (e.g. do_swap_page()
* will SIGBUS).
*
- * -EINVAL: if the swapped out content was in zswap, but the page belongs
- * to a large folio, which is not supported by zswap. The folio is unlocked,
- * but NOT marked up-to-date, so that an IO error is emitted (e.g.
- * do_swap_page() will SIGBUS).
+ * -EINVAL: if the folio spans a mix of zswap and non-zswap entries. The
+ * folio is unlocked, but NOT marked up-to-date, so that an IO error is
+ * emitted (e.g. do_swap_page() will SIGBUS). Large folio swapin should
+ * reject such ranges before calling zswap_load().
*
- * -ENOENT: if the swapped out content was not in zswap. The folio remains
+ * -ENOENT: if the swapped out content was not in zswap. For a large folio,
+ * this means the whole folio range was not in zswap. The folio remains
* locked on return.
*/
int zswap_load(struct folio *folio)
{
swp_entry_t swp = folio->swap;
pgoff_t offset = swp_offset(swp);
- struct xarray *tree = swap_zswap_tree(swp);
struct zswap_entry *entry;
+ int nr_pages = folio_nr_pages(folio);
+ bool is_zswap;
+ int index;
VM_WARN_ON_ONCE(!folio_test_locked(folio));
VM_WARN_ON_ONCE(!folio_test_swapcache(folio));
@@ -1635,30 +1639,36 @@ int zswap_load(struct folio *folio)
if (zswap_never_enabled())
return -ENOENT;
- /*
- * Large folios should not be swapped in while zswap is being used, as
- * they are not properly handled. Zswap does not properly load large
- * folios, and a large folio may only be partially in zswap.
- */
- if (WARN_ON_ONCE(folio_test_large(folio))) {
+ if (zswap_entry_batch(swp, nr_pages, &is_zswap) != nr_pages) {
+ WARN_ON_ONCE(folio_test_large(folio));
folio_unlock(folio);
return -EINVAL;
}
- entry = xa_load(tree, offset);
- if (!entry)
+ if (!is_zswap)
return -ENOENT;
- if (!zswap_decompress(entry, folio, 0)) {
- folio_unlock(folio);
- return -EIO;
+ for (index = 0; index < nr_pages; index++) {
+ swp_entry_t entry_swp = swp_entry(swp_type(swp),
+ offset + index);
+ struct xarray *tree = swap_zswap_tree(entry_swp);
+
+ entry = xa_load(tree, offset + index);
+ if (WARN_ON_ONCE(!entry)) {
+ folio_unlock(folio);
+ return -EINVAL;
+ }
+
+ if (!zswap_decompress(entry, folio, index)) {
+ folio_unlock(folio);
+ return -EIO;
+ }
}
folio_mark_uptodate(folio);
- count_vm_event(ZSWPIN);
- if (entry->objcg)
- count_objcg_events(entry->objcg, ZSWPIN, 1);
+ count_mthp_stat(folio_order(folio), MTHP_STAT_SWPIN);
+ count_vm_events(ZSWPIN, nr_pages);
/*
* We are reading into the swapcache, invalidate zswap entry.
@@ -1668,8 +1678,19 @@ int zswap_load(struct folio *folio)
* compression work.
*/
folio_mark_dirty(folio);
- xa_erase(tree, offset);
- zswap_entry_free(entry);
+
+ for (index = 0; index < nr_pages; index++) {
+ swp_entry_t entry_swp = swp_entry(swp_type(swp),
+ offset + index);
+ struct xarray *tree = swap_zswap_tree(entry_swp);
+
+ entry = xa_erase(tree, offset + index);
+ if (WARN_ON_ONCE(!entry))
+ continue;
+ if (entry->objcg)
+ count_objcg_events(entry->objcg, ZSWPIN, 1);
+ zswap_entry_free(entry);
+ }
folio_unlock(folio);
return 0;
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 2/5] mm: zswap: add a zswap entry batch helper
From: fujunjie @ 2026-05-08 20:20 UTC (permalink / raw)
To: Andrew Morton, Chris Li, Kairui Song, Johannes Weiner, Nhat Pham,
Yosry Ahmed
Cc: linux-mm, linux-kernel, linux-doc, Jonathan Corbet,
David Hildenbrand, Ryan Roberts, Barry Song, Baolin Wang,
Chengming Zhou, Baoquan He, Lorenzo Stoakes
In-Reply-To: <tencent_8B437BE4F586C162950BF71954316C1EDB05@qq.com>
Large folio swapin has to know whether a contiguous swap range is backed
consistently by zswap. A range that is partly in zswap and partly on
disk cannot be read by the existing whole-folio swap_read_folio()
backend selection.
Add zswap_entry_batch(), mirroring the existing zeromap batch query: it
returns how many entries starting at a swap entry share the same zswap
presence, and optionally reports the first entry's state. The
CONFIG_ZSWAP=n stub reports that the whole range is not in zswap.
Signed-off-by: fujunjie <fujunjie1@qq.com>
---
include/linux/zswap.h | 9 +++++++++
mm/zswap.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/include/linux/zswap.h b/include/linux/zswap.h
index 30c193a1207e..b9d71f027200 100644
--- a/include/linux/zswap.h
+++ b/include/linux/zswap.h
@@ -27,6 +27,7 @@ struct zswap_lruvec_state {
unsigned long zswap_total_pages(void);
bool zswap_store(struct folio *folio);
int zswap_load(struct folio *folio);
+int zswap_entry_batch(swp_entry_t swp, int max_nr, bool *is_zswap);
void zswap_invalidate(swp_entry_t swp);
int zswap_swapon(int type, unsigned long nr_pages);
void zswap_swapoff(int type);
@@ -49,6 +50,14 @@ static inline int zswap_load(struct folio *folio)
return -ENOENT;
}
+static inline int zswap_entry_batch(swp_entry_t swp, int max_nr,
+ bool *is_zswap)
+{
+ if (is_zswap)
+ *is_zswap = false;
+ return max_nr;
+}
+
static inline void zswap_invalidate(swp_entry_t swp) {}
static inline int zswap_swapon(int type, unsigned long nr_pages)
{
diff --git a/mm/zswap.c b/mm/zswap.c
index afe38dfc5a29..27c14b8edd15 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -234,6 +234,42 @@ static inline struct xarray *swap_zswap_tree(swp_entry_t swp)
>> ZSWAP_ADDRESS_SPACE_SHIFT];
}
+/*
+ * Return the number of contiguous swap entries that share the same zswap
+ * presence as @swp. If @is_zswap is not NULL, return @swp's zswap status.
+ *
+ * Context: callers must keep the swap type alive. The result is a snapshot
+ * of zswap xarray presence; callers must tolerate races by rechecking under
+ * the lock that matters for their operation or by falling back safely.
+ */
+int zswap_entry_batch(swp_entry_t swp, int max_nr, bool *is_zswap)
+{
+ pgoff_t offset = swp_offset(swp);
+ bool first;
+ int i;
+
+ if (zswap_never_enabled()) {
+ if (is_zswap)
+ *is_zswap = false;
+ return max_nr;
+ }
+
+ first = !!xa_load(swap_zswap_tree(swp), offset);
+ if (is_zswap)
+ *is_zswap = first;
+
+ for (i = 1; i < max_nr; i++) {
+ swp_entry_t entry = swp_entry(swp_type(swp), offset + i);
+ bool present;
+
+ present = !!xa_load(swap_zswap_tree(entry), offset + i);
+ if (present != first)
+ return i;
+ }
+
+ return max_nr;
+}
+
#define zswap_pool_debug(msg, p) \
pr_debug("%s pool %s\n", msg, (p)->tfm_name)
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 5/5] mm: swap: allow zswap-backed large folio swapin
From: fujunjie @ 2026-05-08 20:20 UTC (permalink / raw)
To: Andrew Morton, Chris Li, Kairui Song, Johannes Weiner, Nhat Pham,
Yosry Ahmed
Cc: linux-mm, linux-kernel, linux-doc, Jonathan Corbet,
David Hildenbrand, Ryan Roberts, Barry Song, Baolin Wang,
Chengming Zhou, Baoquan He, Lorenzo Stoakes
In-Reply-To: <tencent_8B437BE4F586C162950BF71954316C1EDB05@qq.com>
alloc_swap_folio() has been falling back to order-0 in the anonymous
synchronous swapin path whenever zswap was ever enabled, because a large
folio range could contain a mixture of zswap and non-zswap entries and
zswap_load() could not handle large folios.
zswap_load() can now load a range that is fully present in zswap, and
zswap_entry_batch() can identify mixed zswap ranges. Use that check
alongside the existing zeromap and swapcache checks when selecting a large
folio for anonymous swapin, and recheck before inserting a large folio into
the swap cache while holding the swap cluster lock.
With mixed zswap ranges rejected and the insertion-race fallback in place,
remove the blanket zswap_never_enabled() fallback from the anonymous swapin
path so all-zswap and all-disk anonymous ranges can use mTHP swapin. Shmem
keeps its existing zswap fallback and is outside this RFC.
Signed-off-by: fujunjie <fujunjie1@qq.com>
---
mm/memory.c | 21 ++++++---------------
mm/swap_state.c | 23 +++++++++++++++--------
2 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 84e3b77b8293..0be249108de1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -78,6 +78,7 @@
#include <linux/sched/sysctl.h>
#include <linux/pgalloc.h>
#include <linux/uaccess.h>
+#include <linux/zswap.h>
#include <trace/events/kmem.h>
@@ -4635,13 +4636,11 @@ static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep, int nr_pages)
if (swap_pte_batch(ptep, nr_pages, pte) != nr_pages)
return false;
- /*
- * swap_read_folio() can't handle the case a large folio is hybridly
- * from different backends. And they are likely corner cases. Similar
- * things might be added once zswap support large folios.
- */
+ /* swap_read_folio() can't handle hybrid backend large folios. */
if (unlikely(swap_zeromap_batch(entry, nr_pages, NULL) != nr_pages))
return false;
+ if (unlikely(zswap_entry_batch(entry, nr_pages, NULL) != nr_pages))
+ return false;
if (unlikely(non_swapcache_batch(entry, nr_pages) != nr_pages))
return false;
@@ -4690,14 +4689,6 @@ static struct folio *alloc_swap_folio(struct vm_fault *vmf)
if (unlikely(userfaultfd_armed(vma)))
goto fallback;
- /*
- * A large swapped out folio could be partially or fully in zswap. We
- * lack handling for such cases, so fallback to swapping in order-0
- * folio.
- */
- if (!zswap_never_enabled())
- goto fallback;
-
entry = softleaf_from_pte(vmf->orig_pte);
/*
* Get a list of all the (large) orders below PMD_ORDER that are enabled
@@ -4772,8 +4763,8 @@ static struct folio *swapin_synchronous_folio(swp_entry_t entry,
order = folio_order(folio);
/*
- * folio is charged, so swapin can only fail due to raced swapin and
- * return NULL.
+ * folio is charged, so NULL means the large folio could not be
+ * inserted and needs order-0 fallback.
*/
swapcache = swapin_folio(entry, folio);
if (swapcache == folio)
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 1415a5c54a43..4e58fad5e5f0 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -22,6 +22,7 @@
#include <linux/vmalloc.h>
#include <linux/huge_mm.h>
#include <linux/shmem_fs.h>
+#include <linux/zswap.h>
#include "internal.h"
#include "swap_table.h"
#include "swap.h"
@@ -207,6 +208,11 @@ static int swap_cache_add_folio(struct folio *folio, swp_entry_t entry,
if (swp_tb_is_shadow(old_tb))
shadow = swp_tb_to_shadow(old_tb);
} while (++ci_off < ci_end);
+ if (unlikely(folio_test_large(folio) &&
+ zswap_entry_batch(entry, nr_pages, NULL) != nr_pages)) {
+ err = -EAGAIN;
+ goto failed;
+ }
__swap_cache_add_folio(ci, folio, entry);
swap_cluster_unlock(ci);
if (shadowp)
@@ -460,7 +466,8 @@ void swap_update_readahead(struct folio *folio, struct vm_area_struct *vma,
*
* Context: Caller must protect the swap device with reference count or locks.
* Return: Returns the folio being added on success. Returns the existing folio
- * if @entry is already cached. Returns NULL if raced with swapin or swapoff.
+ * if @entry is already cached. Returns NULL if raced with swapin or swapoff,
+ * or if a large folio fails a backend recheck before insertion.
*/
static struct folio *__swap_cache_prepare_and_add(swp_entry_t entry,
struct folio *folio,
@@ -483,10 +490,10 @@ static struct folio *__swap_cache_prepare_and_add(swp_entry_t entry,
/*
* Large order allocation needs special handling on
- * race: if a smaller folio exists in cache, swapin needs
- * to fallback to order 0, and doing a swap cache lookup
- * might return a folio that is irrelevant to the faulting
- * entry because @entry is aligned down. Just return NULL.
+ * race or backend recheck failure: swapin needs to fall back
+ * to order 0, and doing a swap cache lookup might return a
+ * folio that is irrelevant to the faulting entry because
+ * @entry is aligned down. Just return NULL.
*/
if (ret != -EEXIST || folio_test_large(folio))
goto failed;
@@ -567,9 +574,9 @@ struct folio *swap_cache_alloc_folio(swp_entry_t entry, gfp_t gfp_mask,
* with the folio size.
*
* Return: returns pointer to @folio on success. If folio is a large folio
- * and this raced with another swapin, NULL will be returned to allow fallback
- * to order 0. Else, if another folio was already added to the swap cache,
- * return that swap cache folio instead.
+ * and it raced with another swapin or failed a backend recheck, NULL will be
+ * returned to allow fallback to order 0. Else, if another folio was already
+ * added to the swap cache, return that swap cache folio instead.
*/
struct folio *swapin_folio(swp_entry_t entry, struct folio *folio)
{
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 4/5] mm: swap: fall back to order-0 after large swapin races
From: fujunjie @ 2026-05-08 20:20 UTC (permalink / raw)
To: Andrew Morton, Chris Li, Kairui Song, Johannes Weiner, Nhat Pham,
Yosry Ahmed
Cc: linux-mm, linux-kernel, linux-doc, Jonathan Corbet,
David Hildenbrand, Ryan Roberts, Barry Song, Baolin Wang,
Chengming Zhou, Baoquan He, Lorenzo Stoakes
In-Reply-To: <tencent_8B437BE4F586C162950BF71954316C1EDB05@qq.com>
swapin_folio() documents that a large folio insertion race returns NULL
so the caller can fall back to order-0 swapin. do_swap_page() currently
turns that NULL into VM_FAULT_OOM if the PTE is unchanged, which is
harsher than necessary and gets in the way of rejecting large folio
ranges for backend reasons.
Move the synchronous swapin sequence into a helper and retry with an
order-0 folio when a large folio cannot be inserted into the swap cache.
Count the event as an mTHP swapin fallback before dropping the failed
large allocation.
Signed-off-by: fujunjie <fujunjie1@qq.com>
---
mm/memory.c | 50 +++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index ea6568571131..84e3b77b8293 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4757,6 +4757,44 @@ static struct folio *alloc_swap_folio(struct vm_fault *vmf)
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+static struct folio *swapin_synchronous_folio(swp_entry_t entry,
+ struct vm_fault *vmf)
+{
+ struct folio *swapcache, *folio;
+ bool large;
+ int order;
+
+ folio = alloc_swap_folio(vmf);
+ if (!folio)
+ return NULL;
+
+ large = folio_test_large(folio);
+ order = folio_order(folio);
+
+ /*
+ * folio is charged, so swapin can only fail due to raced swapin and
+ * return NULL.
+ */
+ swapcache = swapin_folio(entry, folio);
+ if (swapcache == folio)
+ return folio;
+
+ if (!swapcache && large)
+ count_mthp_stat(order, MTHP_STAT_SWPIN_FALLBACK);
+ folio_put(folio);
+ if (swapcache || !large)
+ return swapcache;
+
+ folio = __alloc_swap_folio(vmf);
+ if (!folio)
+ return NULL;
+
+ swapcache = swapin_folio(entry, folio);
+ if (swapcache != folio)
+ folio_put(folio);
+ return swapcache;
+}
+
/* Sanity check that a folio is fully exclusive */
static void check_swap_exclusive(struct folio *folio, swp_entry_t entry,
unsigned int nr_pages)
@@ -4860,17 +4898,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
swap_update_readahead(folio, vma, vmf->address);
if (!folio) {
if (data_race(si->flags & SWP_SYNCHRONOUS_IO)) {
- folio = alloc_swap_folio(vmf);
- if (folio) {
- /*
- * folio is charged, so swapin can only fail due
- * to raced swapin and return NULL.
- */
- swapcache = swapin_folio(entry, folio);
- if (swapcache != folio)
- folio_put(folio);
- folio = swapcache;
- }
+ folio = swapin_synchronous_folio(entry, vmf);
} else {
folio = swapin_readahead(entry, GFP_HIGHUSER_MOVABLE, vmf);
}
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 1/5] mm: zswap: decompress into a folio subpage
From: fujunjie @ 2026-05-08 20:20 UTC (permalink / raw)
To: Andrew Morton, Chris Li, Kairui Song, Johannes Weiner, Nhat Pham,
Yosry Ahmed
Cc: linux-mm, linux-kernel, linux-doc, Jonathan Corbet,
David Hildenbrand, Ryan Roberts, Barry Song, Baolin Wang,
Chengming Zhou, Baoquan He, Lorenzo Stoakes
In-Reply-To: <tencent_8B437BE4F586C162950BF71954316C1EDB05@qq.com>
zswap_decompress() always writes to offset 0 of the target folio. That
is sufficient while zswap only loads order-0 folios, but large folio
swapin needs to fill each base page from its own zswap entry.
Pass the base-page index to zswap_decompress() and use it for the kmap
and scatterlist output offsets. Existing callers pass index 0, so this
is a preparatory change with no intended behavior change.
Signed-off-by: fujunjie <fujunjie1@qq.com>
---
mm/zswap.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 4b5149173b0e..afe38dfc5a29 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -921,12 +921,14 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,
return comp_ret == 0 && alloc_ret == 0;
}
-static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)
+static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio,
+ unsigned long index)
{
struct zswap_pool *pool = entry->pool;
struct scatterlist input[2]; /* zsmalloc returns an SG list 1-2 entries */
struct scatterlist output;
struct crypto_acomp_ctx *acomp_ctx;
+ size_t offset = index * PAGE_SIZE;
int ret = 0, dlen;
acomp_ctx = raw_cpu_ptr(pool->acomp_ctx);
@@ -939,14 +941,14 @@ static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)
WARN_ON_ONCE(input->length != PAGE_SIZE);
- dst = kmap_local_folio(folio, 0);
+ dst = kmap_local_folio(folio, offset);
memcpy_from_sglist(dst, input, 0, PAGE_SIZE);
dlen = PAGE_SIZE;
kunmap_local(dst);
flush_dcache_folio(folio);
} else {
sg_init_table(&output, 1);
- sg_set_folio(&output, folio, PAGE_SIZE, 0);
+ sg_set_folio(&output, folio, PAGE_SIZE, offset);
acomp_request_set_params(acomp_ctx->req, input, &output,
entry->length, PAGE_SIZE);
ret = crypto_acomp_decompress(acomp_ctx->req);
@@ -1034,7 +1036,7 @@ static int zswap_writeback_entry(struct zswap_entry *entry,
goto out;
}
- if (!zswap_decompress(entry, folio)) {
+ if (!zswap_decompress(entry, folio, 0)) {
ret = -EIO;
goto out;
}
@@ -1611,7 +1613,7 @@ int zswap_load(struct folio *folio)
if (!entry)
return -ENOENT;
- if (!zswap_decompress(entry, folio)) {
+ if (!zswap_decompress(entry, folio, 0)) {
folio_unlock(folio);
return -EIO;
}
--
2.34.1
^ 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