* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Lorenzo Stoakes @ 2026-01-20 16:46 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module
In-Reply-To: <20260120152245.GC1134360@nvidia.com>
On Tue, Jan 20, 2026 at 11:22:45AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 20, 2026 at 03:10:54PM +0000, Lorenzo Stoakes wrote:
> > The natural implication of what you're saying is that we can no longer use this
> > from _anywhere_ because - hey - passing this by value is bad so now _everything_
> > has to be re-written as:
>
> No, I'm not saying that, I'm saying this specific case where you are
> making an accessor to reach an unknown value located on the heap
OK it would have been helpful for you to say that! Sometimes reviews feel
like a ratcheting series of 'what do you actually mean?'s... :)
> should be using a pointer as both a matter of style and to simplify
> life for the compiler.
OK fine.
>
> > vma_flags_t flags_to_set = mk_vma_flags(<flags>);
> >
> > if (vma_flags_test(&flags, &flags_to_set)) { ... }
>
> This is quite a different situation, it is a known const at compile
> time value located on the stack.
Well as a const time thing it'll be optimised to just a value assuming
nothing changes flags_to_set in the mean time. You'd hope.
Note that we have xxx_mask() variants, such that you can do, e.g.:
vma_flags_t flags1 = mk_vma_flags(...);
vma_flags_t flags2 = mk_vma_flags(...);
if (vma_flags_test_mask(flags1, flags2)) {
...
}
ASIDE ->
NOTE: A likely use of this, and one I already added is so we can do
e.g.:
#define VMA_REMAP_FLAGS mk_vma_flags(VMA_IO_BIT, VMA_PFNMAP_BIT, \
VMA_DONTEXPAND_BIT, VMA_DONTDUMP_BIT)
...
if (vma_flagss_test_mask(flags, VMA_REMAP_FLAGS)) { ... }
Which would be effectively a const input anyway.
<- ASIDE
Or in a world where flags1 is a const pointer now:
if (vma_flags_test_mask(&flags1, flags2)) { ... }
Which makes the form... kinda weird. Then again it's consistent with other
forms which update flags1, ofc we name this separately, e.g. flags, to_test
or flags, to_set so I guess not such a problme.
Now, nobody is _likely_ to do e.g.:
if (vma_flags_test_mask(&vma1->flags, vma2->flags)) { ... }
In this situation, but they could.
However perhaps having one value pass-by-const-pointer and the other
by-value essentially documents the fact you're being dumb.
And if somebody really needs something like this (not sure why) we could
add something.
But yeah ok, I'll change this. It's more than this case it's also all the
test stuff but shouldn't be a really huge change.
>
> > If it was just changing this one function I'd still object as it makes it differ
> > from _every other test predicate_ using vma_flags_t but maybe to humour you I'd
> > change it, but surely by this argument you're essentially objecting to the whole
> > series?
>
> I only think that if you are taking a heap input that is not of known
> value you should continue to pass by pointer as is generally expected
> in the C style we use.
Ack.
>
> And it isn't saying anything about the overall technique in the
> series, just a minor note about style.
OK good, though Arnd's reply feels more like a comment on the latter,
though only really doing pass-by-value for const values (in nearly all sane
cases) should hopefully mitigate.
>
> > I am not sure about this 'idiomatic kernel style' thing either, it feels rather
> > conjured. Yes you wouldn't ordinarily pass something larger than a register size
> > by-value, but here the intent is for it to be inlined anyway right?
>
> Well, exactly, we don't normally pass things larger than an interger
> by value, that isn't the style, so I don't think it is such a great
> thing to introduce here kind of unnecessarily.
>
> The troubles I recently had were linked to odd things like gcov and
> very old still supported versions of gcc. Also I saw a power compiler
> make a very strange choice to not inline something that evaluated to a
> constant.
Right ok.
>
> Jason
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Arnd Bergmann @ 2026-01-20 16:44 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Jason Gunthorpe, Andrew Morton, Jarkko Sakkinen, Dave Hansen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, Greg Kroah-Hartman, Dan Williams, Vishal Verma,
Dave Jiang, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dave Airlie, Simona Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Christian König, Huang Rui,
Matthew Auld, Matthew Brost, Alexander Viro, Christian Brauner,
Jan Kara, Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador,
David Hildenbrand (Red Hat), Konstantin Komarov, Mike Marshall,
Martin Brandenburg, Tony Luck, Reinette Chatre, Dave Martin,
James Morse, Babu Moger, Carlos Maiolino, Damien Le Moal,
Naohiro Aota, Johannes Thumshirn, Matthew Wilcox, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Hugh Dickins, Baolin Wang, Zi Yan, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Jann Horn, Pedro Falcato,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Yury Norov, Rasmus Villemoes, linux-sgx, linux-kernel, nvdimm,
linux-cxl, dri-devel, intel-gfx, linux-fsdevel, linux-aio,
linux-erofs, linux-ext4, linux-mm, ntfs3, devel, linux-xfs,
keyrings, linux-security-module
In-Reply-To: <44461883-a75c-466b-a278-97c4ab46b461@lucifer.local>
On Tue, Jan 20, 2026, at 17:22, Lorenzo Stoakes wrote:
> On Tue, Jan 20, 2026 at 05:00:28PM +0100, Arnd Bergmann wrote:
>> On Tue, Jan 20, 2026, at 16:10, Lorenzo Stoakes wrote:
>> >
>> > It strikes me that the key optimisation here is the inlining, now if the issue
>> > is that ye olde compiler might choose not to inline very small functions (seems
>> > unlikely) we could always throw in an __always_inline?
>>
>> I can think of three specific things going wrong with structures passed
>> by value:
>
> I mean now you seem to be talking about it _in general_ which, _in theory_,
> kills the whole concept of bitmap VMA flags _altogether_ really, or at
> least any workable version of them.
No, what I'm saying is "understand what the pitfalls are", not
"don't do it". I think that is what Jason was also getting at.
Arnd
^ permalink raw reply
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Lorenzo Stoakes @ 2026-01-20 16:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jason Gunthorpe, Andrew Morton, Jarkko Sakkinen, Dave Hansen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, Greg Kroah-Hartman, Dan Williams, Vishal Verma,
Dave Jiang, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Dave Airlie, Simona Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Christian König, Huang Rui,
Matthew Auld, Matthew Brost, Alexander Viro, Christian Brauner,
Jan Kara, Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador,
David Hildenbrand (Red Hat), Konstantin Komarov, Mike Marshall,
Martin Brandenburg, Tony Luck, Reinette Chatre, Dave Martin,
James Morse, Babu Moger, Carlos Maiolino, Damien Le Moal,
Naohiro Aota, Johannes Thumshirn, Matthew Wilcox, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Hugh Dickins, Baolin Wang, Zi Yan, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Jann Horn, Pedro Falcato,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Yury Norov, Rasmus Villemoes, linux-sgx, linux-kernel, nvdimm,
linux-cxl, dri-devel, intel-gfx, linux-fsdevel, linux-aio,
linux-erofs, linux-ext4, linux-mm, ntfs3, devel, linux-xfs,
keyrings, linux-security-module
In-Reply-To: <1617ac60-6261-483d-aeb5-13aba5f477af@app.fastmail.com>
On Tue, Jan 20, 2026 at 05:00:28PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 20, 2026, at 16:10, Lorenzo Stoakes wrote:
> > On Tue, Jan 20, 2026 at 09:36:19AM -0400, Jason Gunthorpe wrote:
> >
> > I am not sure about this 'idiomatic kernel style' thing either, it feels rather
> > conjured. Yes you wouldn't ordinarily pass something larger than a register size
> > by-value, but here the intent is for it to be inlined anyway right?
> >
> > It strikes me that the key optimisation here is the inlining, now if the issue
> > is that ye olde compiler might choose not to inline very small functions (seems
> > unlikely) we could always throw in an __always_inline?
>
> I can think of three specific things going wrong with structures passed
> by value:
I mean now you seem to be talking about it _in general_ which, _in theory_,
kills the whole concept of bitmap VMA flags _altogether_ really, or at
least any workable version of them.
But... no.
I'm not going to not do this because of perceived possible issues with ppc
and mips.
It's not reasonable to hold up a necessary change for the future of the
kernel IMO, and we can find workarounds as necessary should anything
problematic actually occur in practice.
I am happy to do so as maintainer of this work :)
>
> - functions that cannot be inlined are bound by the ELF ABI, and
> several of them require structs to be passed on the stack regardless
> of the size. Most of the popular architectures seem fine here, but
> mips and powerpc look like they are affected.
I explicitly checked mips and it seemed fine, but not gone super deep.
>
> - The larger the struct is, the more architectures are affected.
> Parts of the amdgpu driver and the bcachefs file system ran into this
bcachefs is not in the kernel. We don't care about out-of-tree stuff by
convention.
amdgpu is more concerning, but...
> with 64-bit structures passed by value on 32-bit architectures
> causing horrible codegen even with inlining. I think it's
> usually fine up to a single register size.
...32-bit kernels are not ones where you would anticipate incredible
performance for one, for another if any significant issues arise we can
look at arch-specific workarounds.
I already have vma_flags_*_word*() helpers to do things 'the old way' in
the worst case. More can be added if and when anything arises.
Again, I don't think we should hold up the rest of the kernel (being able
to transition to not being arbitrarily limited by VMA count is very
important) on this basis.
Also I've checked 32-bit code generation which _seemed_ fine at a
glance. Of course again I've not good super deep on that.
>
> - clang's inlining algorithm works the other way round from gcc's:
> inlining into the root caller first and sometimes leaving tiny
> leaf function out of line unless you add __always_inline.
I already __always_inline all pertinent funcitons so hopefully that should
be no issue.
And for instance the assembly I shared earlier was built using clang, as I
now use clang for _all_ my builds locally.
>
> Arnd
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Arnd Bergmann @ 2026-01-20 16:00 UTC (permalink / raw)
To: Lorenzo Stoakes, Jason Gunthorpe
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H. Peter Anvin,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Dave Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian König, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador,
David Hildenbrand (Red Hat), Konstantin Komarov, Mike Marshall,
Martin Brandenburg, Tony Luck, Reinette Chatre, Dave Martin,
James Morse, Babu Moger, Carlos Maiolino, Damien Le Moal,
Naohiro Aota, Johannes Thumshirn, Matthew Wilcox, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Hugh Dickins, Baolin Wang, Zi Yan, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Jann Horn, Pedro Falcato,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Yury Norov, Rasmus Villemoes, linux-sgx, linux-kernel, nvdimm,
linux-cxl, dri-devel, intel-gfx, linux-fsdevel, linux-aio,
linux-erofs, linux-ext4, linux-mm, ntfs3, devel, linux-xfs,
keyrings, linux-security-module
In-Reply-To: <488a0fd8-5d64-4907-873b-60cefee96979@lucifer.local>
On Tue, Jan 20, 2026, at 16:10, Lorenzo Stoakes wrote:
> On Tue, Jan 20, 2026 at 09:36:19AM -0400, Jason Gunthorpe wrote:
>
> I am not sure about this 'idiomatic kernel style' thing either, it feels rather
> conjured. Yes you wouldn't ordinarily pass something larger than a register size
> by-value, but here the intent is for it to be inlined anyway right?
>
> It strikes me that the key optimisation here is the inlining, now if the issue
> is that ye olde compiler might choose not to inline very small functions (seems
> unlikely) we could always throw in an __always_inline?
I can think of three specific things going wrong with structures passed
by value:
- functions that cannot be inlined are bound by the ELF ABI, and
several of them require structs to be passed on the stack regardless
of the size. Most of the popular architectures seem fine here, but
mips and powerpc look like they are affected.
- The larger the struct is, the more architectures are affected.
Parts of the amdgpu driver and the bcachefs file system ran into this
with 64-bit structures passed by value on 32-bit architectures
causing horrible codegen even with inlining. I think it's
usually fine up to a single register size.
- clang's inlining algorithm works the other way round from gcc's:
inlining into the root caller first and sometimes leaving tiny
leaf function out of line unless you add __always_inline.
Arnd
^ permalink raw reply
* [PATCH] cipso: harden use of skb_cow() in cipso_v4_skbuff_setattr()
From: Will Rosenberg @ 2026-01-20 15:57 UTC (permalink / raw)
Cc: Will Rosenberg, Paul Moore, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, netdev,
linux-security-module, linux-kernel
In-Reply-To: <CAHC9VhR4d7WXOVR7Y9ee2+=-t2nThzOo-ySMB+5x_87LfBJbZw@mail.gmail.com>
If skb_cow() is passed a headroom <= -NET_SKB_PAD, it will trigger a
BUG. As a result, use cases should avoid calling with a headroom that
is negative to prevent triggering this issue.
This is the same code pattern fixed in Commit 58fc7342b529 ("ipv6:
BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()").
In cipso_v4_skbuff_setattr(), len_delta can become negative, leading to
a negative headroom passed to skb_cow(). However, the BUG is not
triggerable because the condition headroom <= -NET_SKB_PAD cannot be
satisfied due to limits on the IPv4 options header size.
Avoid potential problems in the future by only using skb_cow() to grow
the skb headroom.
Signed-off-by: Will Rosenberg <whrosenb@asu.edu>
---
Notes:
Given that IPv4 option length should not change,
this may not be a worthwhile patch.
Apologies in advance if this ends up being a waste
of time.
net/ipv4/cipso_ipv4.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 709021197e1c..32b951ebc0c2 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -2196,7 +2196,8 @@ int cipso_v4_skbuff_setattr(struct sk_buff *skb,
/* if we don't ensure enough headroom we could panic on the skb_push()
* call below so make sure we have enough, we are also "mangling" the
* packet so we should probably do a copy-on-write call anyway */
- ret_val = skb_cow(skb, skb_headroom(skb) + len_delta);
+ ret_val = skb_cow(skb,
+ skb_headroom(skb) + (len_delta > 0 ? len_delta : 0));
if (ret_val < 0)
return ret_val;
base-commit: 58bae918d73e3b6cd57d1e39fcf7c75c7dd1a8fe
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Jason Gunthorpe @ 2026-01-20 15:22 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module
In-Reply-To: <488a0fd8-5d64-4907-873b-60cefee96979@lucifer.local>
On Tue, Jan 20, 2026 at 03:10:54PM +0000, Lorenzo Stoakes wrote:
> The natural implication of what you're saying is that we can no longer use this
> from _anywhere_ because - hey - passing this by value is bad so now _everything_
> has to be re-written as:
No, I'm not saying that, I'm saying this specific case where you are
making an accessor to reach an unknown value located on the heap
should be using a pointer as both a matter of style and to simplify
life for the compiler.
> vma_flags_t flags_to_set = mk_vma_flags(<flags>);
>
> if (vma_flags_test(&flags, &flags_to_set)) { ... }
This is quite a different situation, it is a known const at compile
time value located on the stack.
> If it was just changing this one function I'd still object as it makes it differ
> from _every other test predicate_ using vma_flags_t but maybe to humour you I'd
> change it, but surely by this argument you're essentially objecting to the whole
> series?
I only think that if you are taking a heap input that is not of known
value you should continue to pass by pointer as is generally expected
in the C style we use.
And it isn't saying anything about the overall technique in the
series, just a minor note about style.
> I am not sure about this 'idiomatic kernel style' thing either, it feels rather
> conjured. Yes you wouldn't ordinarily pass something larger than a register size
> by-value, but here the intent is for it to be inlined anyway right?
Well, exactly, we don't normally pass things larger than an interger
by value, that isn't the style, so I don't think it is such a great
thing to introduce here kind of unnecessarily.
The troubles I recently had were linked to odd things like gcov and
very old still supported versions of gcc. Also I saw a power compiler
make a very strange choice to not inline something that evaluated to a
constant.
Jason
^ permalink raw reply
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Lorenzo Stoakes @ 2026-01-20 15:10 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module
In-Reply-To: <20260120133619.GZ1134360@nvidia.com>
On Tue, Jan 20, 2026 at 09:36:19AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 20, 2026 at 09:46:05AM +0000, Lorenzo Stoakes wrote:
> > On Mon, Jan 19, 2026 at 07:14:03PM -0400, Jason Gunthorpe wrote:
> > > On Mon, Jan 19, 2026 at 09:19:11PM +0000, Lorenzo Stoakes wrote:
> > > > +static inline bool is_shared_maywrite(vma_flags_t flags)
> > > > +{
> > >
> > > I'm not sure it is ideal to pass this array by value? Seems like it
> > > might invite some negative optimizations since now the compiler has to
> > > optimze away a copy too.
> >
> > I really don't think so? This is inlined and thus collapses to a totally
> > standard vma_flags_test_all() which passes by value anyway.
>
> > Do you have specific examples or evidence the compiler will optimise poorly here
> > on that basis as compared to pass by reference? And pass by reference would
> > necessitate:
>
> I've recently seen enough cases of older compilers and other arches
> making weird choices to be a little concerened. In the above case
> there is no reason not to use a const pointer (and indeed that would
> be the expected idomatic kernel style), so why take chances is my
> thinking.
With respect Jason, you're going to have to do better than that.
The entire implementation is dependent on passing-by-value.
Right now we can do:
vma_flags_test(&flags, VMA_READ_BIT, VMA_WRITE_BIT, ...);
Which uses mk_vma_flags() in a macro to generalise to:
vma_flags_test(&flags, <vma_flags_t value>);
The natural implication of what you're saying is that we can no longer use this
from _anywhere_ because - hey - passing this by value is bad so now _everything_
has to be re-written as:
vma_flags_t flags_to_set = mk_vma_flags(<flags>);
if (vma_flags_test(&flags, &flags_to_set)) { ... }
Right?
But is even that ok? Because presumably these compilers can inline, so that is
basically equivalent to what the macro's doing so does that rule out the VMA
bitmap flags concept altogether...
For hand-waved 'old compilers' (ok, people who use old compilers should not
expect optimal code) or 'other arches' (unspecified)?
If it was just changing this one function I'd still object as it makes it differ
from _every other test predicate_ using vma_flags_t but maybe to humour you I'd
change it, but surely by this argument you're essentially objecting to the whole
series?
I find it really strange you're going down this road as it was you who suggested
this approach in the first place and had to convince me the compiler would
manage it!...
Maybe I'm missing something here...
I am not sure about this 'idiomatic kernel style' thing either, it feels rather
conjured. Yes you wouldn't ordinarily pass something larger than a register size
by-value, but here the intent is for it to be inlined anyway right?
It strikes me that the key optimisation here is the inlining, now if the issue
is that ye olde compiler might choose not to inline very small functions (seems
unlikely) we could always throw in an __always_inline?
But it seems rather silly for a one-liner?
If the concern is deeper (not optimising the bitmap operations) then aren't you
saying no to the whole concept of the series?
Out of interest I godbolted a bunch of architectures:
x86-64
riscv
mips
s390x
sparc
arm7 32-bit
loongarch
m68k
xtensa
And found the manual method vs. the pass-by-value macro method were equivalent
in each case as far as I could tell.
In the worst case if we hit a weirdo case we can always substitute something
manual I have all the vma_flags_*word*() stuff available (which I recall you
objecting to...!)
I may have completely the wrong end of the stick here?...
>
> Jason
Thanks, Lorenzo
^ permalink raw reply
* [PATCH] apparmor: replace strcpy with strscpy
From: Ryan Foster @ 2026-01-20 14:50 UTC (permalink / raw)
To: john.johansen
Cc: paul, jmorris, serge, apparmor, linux-security-module,
linux-kernel, Ryan Foster
Found by checkpatch. Replace strcpy() with strscpy() for safer
string handling per KSPP recommendations.
Two changes:
- apparmorfs.c: gen_symlink_name() uses tracked buffer size
- lib.c: aa_policy_init() uses exact allocation size
Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Ryan Foster <foster.ryan.r@gmail.com>
---
security/apparmor/apparmorfs.c | 2 +-
security/apparmor/lib.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 907bd2667e28..f38974231df2 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -1614,7 +1614,7 @@ static char *gen_symlink_name(int depth, const char *dirname, const char *fname)
return ERR_PTR(-ENOMEM);
for (; depth > 0; depth--) {
- strcpy(s, "../../");
+ strscpy(s, "../../", size);
s += 6;
size -= 6;
}
diff --git a/security/apparmor/lib.c b/security/apparmor/lib.c
index 82dbb97ad406..7cb393f91a10 100644
--- a/security/apparmor/lib.c
+++ b/security/apparmor/lib.c
@@ -487,7 +487,7 @@ bool aa_policy_init(struct aa_policy *policy, const char *prefix,
} else {
hname = aa_str_alloc(strlen(name) + 1, gfp);
if (hname)
- strcpy(hname, name);
+ strscpy(hname, name, strlen(name) + 1);
}
if (!hname)
return false;
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 4/4] net: uapi: Provide an UAPI definition of 'struct sockaddr'
From: Thomas Weißschuh @ 2026-01-20 14:10 UTC (permalink / raw)
To: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Shuah Khan,
Matthieu Baerts, Mat Martineau, Geliang Tang,
Mickaël Salaün, Günther Noack, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa
Cc: netdev, linux-kernel, linux-api, Arnd Bergmann, linux-kselftest,
mptcp, linux-security-module, bpf, libc-alpha,
Carlos O'Donell, Adhemerval Zanella, Rich Felker, klibc,
Florian Weimer, Thomas Weißschuh
In-Reply-To: <20260120-uapi-sockaddr-v2-0-63c319111cf6@linutronix.de>
Various UAPI headers reference 'struct sockaddr'. Currently the
definition of this struct is pulled in from the libc header
sys/socket.h. This is problematic as it introduces a dependency
on a full userspace toolchain.
Instead expose a custom but compatible definition of 'struct sockaddr'
in the UAPI headers. It is guarded by the libc compatibility
infrastructure to avoid potential conflicts.
The compatibility symbol won't be supported by glibc right away,
but right now __UAPI_DEF_IF_IFNAMSIZ is not supported either,
so including the libc headers before the UAPI headers is broken anyways.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
include/linux/socket.h | 10 ----------
include/uapi/linux/if.h | 4 ----
include/uapi/linux/libc-compat.h | 12 ++++++++++++
include/uapi/linux/socket.h | 14 ++++++++++++++
4 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index ec715ad4bf25..8363d4e0a044 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -28,16 +28,6 @@ extern void socket_seq_show(struct seq_file *seq);
typedef __kernel_sa_family_t sa_family_t;
-/*
- * 1003.1g requires sa_family_t and that sa_data is char.
- */
-
-/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */
-struct sockaddr {
- sa_family_t sa_family; /* address family, AF_xxx */
- char sa_data[14]; /* 14 bytes of protocol address */
-};
-
/**
* struct sockaddr_unsized - Unspecified size sockaddr for callbacks
* @sa_family: Address family (AF_UNIX, AF_INET, AF_INET6, etc.)
diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
index 797ba2c1562a..a4bc54196a07 100644
--- a/include/uapi/linux/if.h
+++ b/include/uapi/linux/if.h
@@ -25,10 +25,6 @@
#include <linux/socket.h> /* for "struct sockaddr" et al */
#include <linux/compiler.h> /* for "__user" et al */
-#ifndef __KERNEL__
-#include <sys/socket.h> /* for struct sockaddr. */
-#endif
-
#if __UAPI_DEF_IF_IFNAMSIZ
#define IFNAMSIZ 16
#endif /* __UAPI_DEF_IF_IFNAMSIZ */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 0eca95ccb41e..13a06ce4e825 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -140,6 +140,13 @@
#endif /* _NETINET_IN_H */
+/* Definitions for socket.h */
+#if defined(_SYS_SOCKET_H)
+#define __UAPI_DEF_SOCKADDR 0
+#else
+#define __UAPI_DEF_SOCKADDR 1
+#endif
+
/* Definitions for xattr.h */
#if defined(_SYS_XATTR_H)
#define __UAPI_DEF_XATTR 0
@@ -221,6 +228,11 @@
#define __UAPI_DEF_IP6_MTUINFO 1
#endif
+/* Definitions for socket.h */
+#ifndef __UAPI_DEF_SOCKADDR
+#define __UAPI_DEF_SOCKADDR 1
+#endif
+
/* Definitions for xattr.h */
#ifndef __UAPI_DEF_XATTR
#define __UAPI_DEF_XATTR 1
diff --git a/include/uapi/linux/socket.h b/include/uapi/linux/socket.h
index d3fcd3b5ec53..35d7d5f4b1a8 100644
--- a/include/uapi/linux/socket.h
+++ b/include/uapi/linux/socket.h
@@ -2,6 +2,8 @@
#ifndef _UAPI_LINUX_SOCKET_H
#define _UAPI_LINUX_SOCKET_H
+#include <linux/libc-compat.h> /* for compatibility with glibc */
+
/*
* Desired design of maximum size and alignment (see RFC2553)
*/
@@ -26,6 +28,18 @@ struct __kernel_sockaddr_storage {
};
};
+/*
+ * 1003.1g requires sa_family_t and that sa_data is char.
+ */
+
+/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */
+#if __UAPI_DEF_SOCKADDR
+struct sockaddr {
+ __kernel_sa_family_t sa_family; /* address family, AF_xxx */
+ char sa_data[14]; /* 14 bytes of protocol address */
+};
+#endif /* __UAPI_DEF_SOCKADDR */
+
#define SOCK_SNDBUF_LOCK 1
#define SOCK_RCVBUF_LOCK 2
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 3/4] samples/bpf: Move some UAPI header inclusions after libc ones
From: Thomas Weißschuh @ 2026-01-20 14:10 UTC (permalink / raw)
To: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Shuah Khan,
Matthieu Baerts, Mat Martineau, Geliang Tang,
Mickaël Salaün, Günther Noack, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa
Cc: netdev, linux-kernel, linux-api, Arnd Bergmann, linux-kselftest,
mptcp, linux-security-module, bpf, libc-alpha,
Carlos O'Donell, Adhemerval Zanella, Rich Felker, klibc,
Florian Weimer, Thomas Weißschuh
In-Reply-To: <20260120-uapi-sockaddr-v2-0-63c319111cf6@linutronix.de>
Interleaving inclusions of UAPI headers and libc headers is problematic.
Both sets of headers define conflicting symbols. To enable their
coexistence a compatibility-mechanism is in place.
An upcoming change will define 'struct sockaddr' from linux/socket.h.
However sys/socket.h from libc does not yet handle this case and a
symbol conflict will arise.
Move the inclusion of all UAPI headers after the inclusion of the glibc
ones, so the compatibility mechanism from the UAPI headers is used.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
samples/bpf/xdp_adjust_tail_user.c | 6 ++++--
samples/bpf/xdp_fwd_user.c | 7 ++++---
samples/bpf/xdp_router_ipv4_user.c | 6 +++---
samples/bpf/xdp_sample_user.c | 15 ++++++++-------
samples/bpf/xdp_tx_iptunnel_user.c | 4 ++--
5 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/samples/bpf/xdp_adjust_tail_user.c b/samples/bpf/xdp_adjust_tail_user.c
index e9426bd65420..32d00405debc 100644
--- a/samples/bpf/xdp_adjust_tail_user.c
+++ b/samples/bpf/xdp_adjust_tail_user.c
@@ -5,8 +5,6 @@
* modify it under the terms of version 2 of the GNU General Public
* License as published by the Free Software Foundation.
*/
-#include <linux/bpf.h>
-#include <linux/if_link.h>
#include <assert.h>
#include <errno.h>
#include <signal.h>
@@ -18,9 +16,13 @@
#include <netinet/ether.h>
#include <unistd.h>
#include <time.h>
+
#include <bpf/bpf.h>
#include <bpf/libbpf.h>
+#include <linux/bpf.h>
+#include <linux/if_link.h>
+
#define STATS_INTERVAL_S 2U
#define MAX_PCKT_SIZE 600
diff --git a/samples/bpf/xdp_fwd_user.c b/samples/bpf/xdp_fwd_user.c
index 193b3b79b31f..ca55f3eac12a 100644
--- a/samples/bpf/xdp_fwd_user.c
+++ b/samples/bpf/xdp_fwd_user.c
@@ -11,9 +11,6 @@
* General Public License for more details.
*/
-#include <linux/bpf.h>
-#include <linux/if_link.h>
-#include <linux/limits.h>
#include <net/if.h>
#include <errno.h>
#include <stdio.h>
@@ -27,6 +24,10 @@
#include <bpf/libbpf.h>
#include <bpf/bpf.h>
+#include <linux/bpf.h>
+#include <linux/if_link.h>
+#include <linux/limits.h>
+
static __u32 xdp_flags = XDP_FLAGS_UPDATE_IF_NOEXIST;
static int do_attach(int idx, int prog_fd, int map_fd, const char *name)
diff --git a/samples/bpf/xdp_router_ipv4_user.c b/samples/bpf/xdp_router_ipv4_user.c
index 266fdd0b025d..2abc7d294251 100644
--- a/samples/bpf/xdp_router_ipv4_user.c
+++ b/samples/bpf/xdp_router_ipv4_user.c
@@ -1,9 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/* Copyright (C) 2017 Cavium, Inc.
*/
-#include <linux/bpf.h>
-#include <linux/netlink.h>
-#include <linux/rtnetlink.h>
#include <assert.h>
#include <errno.h>
#include <signal.h>
@@ -25,6 +22,9 @@
#include <libgen.h>
#include <getopt.h>
#include <pthread.h>
+#include <linux/bpf.h>
+#include <linux/netlink.h>
+#include <linux/rtnetlink.h>
#include "xdp_sample_user.h"
#include "xdp_router_ipv4.skel.h"
diff --git a/samples/bpf/xdp_sample_user.c b/samples/bpf/xdp_sample_user.c
index 158682852162..d9aec2bd372c 100644
--- a/samples/bpf/xdp_sample_user.c
+++ b/samples/bpf/xdp_sample_user.c
@@ -7,13 +7,6 @@
#include <errno.h>
#include <fcntl.h>
#include <getopt.h>
-#include <linux/ethtool.h>
-#include <linux/hashtable.h>
-#include <linux/if_link.h>
-#include <linux/jhash.h>
-#include <linux/limits.h>
-#include <linux/list.h>
-#include <linux/sockios.h>
#include <locale.h>
#include <math.h>
#include <net/if.h>
@@ -32,6 +25,14 @@
#include <time.h>
#include <unistd.h>
+#include <linux/ethtool.h>
+#include <linux/hashtable.h>
+#include <linux/if_link.h>
+#include <linux/jhash.h>
+#include <linux/limits.h>
+#include <linux/list.h>
+#include <linux/sockios.h>
+
#include "bpf_util.h"
#include "xdp_sample_user.h"
diff --git a/samples/bpf/xdp_tx_iptunnel_user.c b/samples/bpf/xdp_tx_iptunnel_user.c
index 7e4b2f7108a6..e9503036d0a0 100644
--- a/samples/bpf/xdp_tx_iptunnel_user.c
+++ b/samples/bpf/xdp_tx_iptunnel_user.c
@@ -1,8 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/* Copyright (c) 2016 Facebook
*/
-#include <linux/bpf.h>
-#include <linux/if_link.h>
#include <assert.h>
#include <errno.h>
#include <signal.h>
@@ -16,6 +14,8 @@
#include <time.h>
#include <bpf/libbpf.h>
#include <bpf/bpf.h>
+#include <linux/bpf.h>
+#include <linux/if_link.h>
#include "bpf_util.h"
#include "xdp_tx_iptunnel_common.h"
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 1/4] selftests: net: Move some UAPI header inclusions after libc ones
From: Thomas Weißschuh @ 2026-01-20 14:10 UTC (permalink / raw)
To: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Shuah Khan,
Matthieu Baerts, Mat Martineau, Geliang Tang,
Mickaël Salaün, Günther Noack, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa
Cc: netdev, linux-kernel, linux-api, Arnd Bergmann, linux-kselftest,
mptcp, linux-security-module, bpf, libc-alpha,
Carlos O'Donell, Adhemerval Zanella, Rich Felker, klibc,
Florian Weimer, Thomas Weißschuh
In-Reply-To: <20260120-uapi-sockaddr-v2-0-63c319111cf6@linutronix.de>
Interleaving inclusions of UAPI headers and libc headers is problematic.
Both sets of headers define conflicting symbols. To enable their
coexistence a compatibility-mechanism is in place.
An upcoming change will define 'struct sockaddr' from linux/socket.h.
However sys/socket.h from libc does not yet handle this case and a
symbol conflict will arise.
Furthermore libc-compat.h evaluates the state of the libc
inclusions only once, at the point it is included first. If another
problematic header from libc is included later, symbol conflicts arise.
This will trigger other duplicate definitions when linux/libc-compat.h
is added to linux/socket.h
Move the inclusion of UAPI headers after the inclusion of the glibc
ones, so the libc-compat.h continues to work correctly.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
tools/testing/selftests/net/af_unix/diag_uid.c | 9 +++++----
tools/testing/selftests/net/busy_poller.c | 3 ++-
tools/testing/selftests/net/mptcp/mptcp_diag.c | 11 ++++++-----
tools/testing/selftests/net/nettest.c | 4 ++--
tools/testing/selftests/net/tcp_ao/icmps-discard.c | 6 +++---
tools/testing/selftests/net/tcp_ao/lib/netlink.c | 9 +++++----
tools/testing/selftests/net/tun.c | 5 +++--
7 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/tools/testing/selftests/net/af_unix/diag_uid.c b/tools/testing/selftests/net/af_unix/diag_uid.c
index da7d50cedee6..05456a205325 100644
--- a/tools/testing/selftests/net/af_unix/diag_uid.c
+++ b/tools/testing/selftests/net/af_unix/diag_uid.c
@@ -5,15 +5,16 @@
#include <sched.h>
#include <unistd.h>
-#include <linux/netlink.h>
-#include <linux/rtnetlink.h>
-#include <linux/sock_diag.h>
-#include <linux/unix_diag.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/un.h>
+#include <linux/netlink.h>
+#include <linux/rtnetlink.h>
+#include <linux/sock_diag.h>
+#include <linux/unix_diag.h>
+
#include "kselftest_harness.h"
FIXTURE(diag_uid)
diff --git a/tools/testing/selftests/net/busy_poller.c b/tools/testing/selftests/net/busy_poller.c
index 3a81f9c94795..34bd8d28808a 100644
--- a/tools/testing/selftests/net/busy_poller.c
+++ b/tools/testing/selftests/net/busy_poller.c
@@ -9,7 +9,6 @@
#include <stdio.h>
#include <string.h>
#include <unistd.h>
-#include <ynl.h>
#include <arpa/inet.h>
#include <netinet/in.h>
@@ -19,6 +18,8 @@
#include <sys/socket.h>
#include <sys/types.h>
+#include <ynl.h>
+
#include <linux/genetlink.h>
#include <linux/netlink.h>
diff --git a/tools/testing/selftests/net/mptcp/mptcp_diag.c b/tools/testing/selftests/net/mptcp/mptcp_diag.c
index 8e0b1b8d84b6..af25ebfd2915 100644
--- a/tools/testing/selftests/net/mptcp/mptcp_diag.c
+++ b/tools/testing/selftests/net/mptcp/mptcp_diag.c
@@ -1,11 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2025, Kylin Software */
-#include <linux/sock_diag.h>
-#include <linux/rtnetlink.h>
-#include <linux/inet_diag.h>
-#include <linux/netlink.h>
-#include <linux/compiler.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <linux/tcp.h>
@@ -17,6 +12,12 @@
#include <errno.h>
#include <stdio.h>
+#include <linux/sock_diag.h>
+#include <linux/rtnetlink.h>
+#include <linux/inet_diag.h>
+#include <linux/netlink.h>
+#include <linux/compiler.h>
+
#ifndef IPPROTO_MPTCP
#define IPPROTO_MPTCP 262
#endif
diff --git a/tools/testing/selftests/net/nettest.c b/tools/testing/selftests/net/nettest.c
index 1f5227f3d64d..71430403b50b 100644
--- a/tools/testing/selftests/net/nettest.c
+++ b/tools/testing/selftests/net/nettest.c
@@ -10,8 +10,6 @@
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/wait.h>
-#include <linux/tcp.h>
-#include <linux/udp.h>
#include <arpa/inet.h>
#include <net/if.h>
#include <netinet/in.h>
@@ -30,6 +28,8 @@
#include <errno.h>
#include <getopt.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
#include <linux/xfrm.h>
#include <linux/ipsec.h>
#include <linux/pfkeyv2.h>
diff --git a/tools/testing/selftests/net/tcp_ao/icmps-discard.c b/tools/testing/selftests/net/tcp_ao/icmps-discard.c
index 85c1a1e958c6..451ba89914c9 100644
--- a/tools/testing/selftests/net/tcp_ao/icmps-discard.c
+++ b/tools/testing/selftests/net/tcp_ao/icmps-discard.c
@@ -16,12 +16,12 @@
* Author: Dmitry Safonov <dima@arista.com>
*/
#include <inttypes.h>
-#include <linux/icmp.h>
-#include <linux/icmpv6.h>
-#include <linux/ipv6.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <sys/socket.h>
+#include <linux/icmp.h>
+#include <linux/icmpv6.h>
+#include <linux/ipv6.h>
#include "aolib.h"
#include "../../../../include/linux/compiler.h"
diff --git a/tools/testing/selftests/net/tcp_ao/lib/netlink.c b/tools/testing/selftests/net/tcp_ao/lib/netlink.c
index 7f108493a29a..69a05820782a 100644
--- a/tools/testing/selftests/net/tcp_ao/lib/netlink.c
+++ b/tools/testing/selftests/net/tcp_ao/lib/netlink.c
@@ -1,14 +1,15 @@
// SPDX-License-Identifier: GPL-2.0
/* Original from tools/testing/selftests/net/ipsec.c */
-#include <linux/netlink.h>
-#include <linux/random.h>
-#include <linux/rtnetlink.h>
-#include <linux/veth.h>
#include <net/if.h>
#include <stdint.h>
#include <string.h>
#include <sys/socket.h>
+#include <linux/netlink.h>
+#include <linux/random.h>
+#include <linux/rtnetlink.h>
+#include <linux/veth.h>
+
#include "aolib.h"
#define MAX_PAYLOAD 2048
diff --git a/tools/testing/selftests/net/tun.c b/tools/testing/selftests/net/tun.c
index 0efc67b0357a..e6e4c52d538e 100644
--- a/tools/testing/selftests/net/tun.c
+++ b/tools/testing/selftests/net/tun.c
@@ -8,12 +8,13 @@
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+
#include <linux/if.h>
#include <linux/if_tun.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
-#include <sys/ioctl.h>
-#include <sys/socket.h>
#include "kselftest_harness.h"
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 2/4] selftests/landlock: Move some UAPI header inclusions after libc ones
From: Thomas Weißschuh @ 2026-01-20 14:10 UTC (permalink / raw)
To: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Shuah Khan,
Matthieu Baerts, Mat Martineau, Geliang Tang,
Mickaël Salaün, Günther Noack, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa
Cc: netdev, linux-kernel, linux-api, Arnd Bergmann, linux-kselftest,
mptcp, linux-security-module, bpf, libc-alpha,
Carlos O'Donell, Adhemerval Zanella, Rich Felker, klibc,
Florian Weimer, Thomas Weißschuh
In-Reply-To: <20260120-uapi-sockaddr-v2-0-63c319111cf6@linutronix.de>
Interleaving inclusions of UAPI headers and libc headers is problematic.
Both sets of headers define conflicting symbols. To enable their
coexistence a compatibility-mechanism is in place.
An upcoming change will define 'struct sockaddr' from linux/socket.h.
However sys/socket.h from libc does not yet handle this case and a
symbol conflict will arise.
Move the inclusion of all UAPI headers after the inclusion of the glibc
ones, so the compatibility mechanism from the UAPI headers is used.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
tools/testing/selftests/landlock/audit.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/landlock/audit.h b/tools/testing/selftests/landlock/audit.h
index 44eb433e9666..c12b16c690dc 100644
--- a/tools/testing/selftests/landlock/audit.h
+++ b/tools/testing/selftests/landlock/audit.h
@@ -7,9 +7,6 @@
#define _GNU_SOURCE
#include <errno.h>
-#include <linux/audit.h>
-#include <linux/limits.h>
-#include <linux/netlink.h>
#include <regex.h>
#include <stdbool.h>
#include <stdint.h>
@@ -20,6 +17,10 @@
#include <sys/time.h>
#include <unistd.h>
+#include <linux/audit.h>
+#include <linux/limits.h>
+#include <linux/netlink.h>
+
#include "kselftest.h"
#ifndef ARRAY_SIZE
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 0/4] net: uapi: Provide an UAPI definition of 'struct sockaddr'
From: Thomas Weißschuh @ 2026-01-20 14:10 UTC (permalink / raw)
To: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Shuah Khan,
Matthieu Baerts, Mat Martineau, Geliang Tang,
Mickaël Salaün, Günther Noack, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa
Cc: netdev, linux-kernel, linux-api, Arnd Bergmann, linux-kselftest,
mptcp, linux-security-module, bpf, libc-alpha,
Carlos O'Donell, Adhemerval Zanella, Rich Felker, klibc,
Florian Weimer, Thomas Weißschuh
Various UAPI headers reference 'struct sockaddr'. Currently the
definition of this struct is pulled in from the libc header
sys/socket.h. This is problematic as it introduces a dependency
on a full userspace toolchain.
Add a definition of 'struct sockaddr' to the UAPI headers.
Before that, reorder some problematic header inclusions in the selftests.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v2:
- Fix compilation failures in BPF samples and selftests
- Link to v1: https://lore.kernel.org/r/20260105-uapi-sockaddr-v1-1-b7653aba12a5@linutronix.de
---
Thomas Weißschuh (4):
selftests: net: Move some UAPI header inclusions after libc ones
selftests/landlock: Move some UAPI header inclusions after libc ones
samples/bpf: Move some UAPI header inclusions after libc ones
net: uapi: Provide an UAPI definition of 'struct sockaddr'
include/linux/socket.h | 10 ----------
include/uapi/linux/if.h | 4 ----
include/uapi/linux/libc-compat.h | 12 ++++++++++++
include/uapi/linux/socket.h | 14 ++++++++++++++
samples/bpf/xdp_adjust_tail_user.c | 6 ++++--
samples/bpf/xdp_fwd_user.c | 7 ++++---
samples/bpf/xdp_router_ipv4_user.c | 6 +++---
samples/bpf/xdp_sample_user.c | 15 ++++++++-------
samples/bpf/xdp_tx_iptunnel_user.c | 4 ++--
tools/testing/selftests/landlock/audit.h | 7 ++++---
tools/testing/selftests/net/af_unix/diag_uid.c | 9 +++++----
tools/testing/selftests/net/busy_poller.c | 3 ++-
tools/testing/selftests/net/mptcp/mptcp_diag.c | 11 ++++++-----
tools/testing/selftests/net/nettest.c | 4 ++--
tools/testing/selftests/net/tcp_ao/icmps-discard.c | 6 +++---
tools/testing/selftests/net/tcp_ao/lib/netlink.c | 9 +++++----
tools/testing/selftests/net/tun.c | 5 +++--
17 files changed, 77 insertions(+), 55 deletions(-)
---
base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
change-id: 20251222-uapi-sockaddr-cf10e7624729
Best regards,
--
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Jason Gunthorpe @ 2026-01-20 13:36 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module
In-Reply-To: <36abc616-471b-4c7b-82f5-db87f324d708@lucifer.local>
On Tue, Jan 20, 2026 at 09:46:05AM +0000, Lorenzo Stoakes wrote:
> On Mon, Jan 19, 2026 at 07:14:03PM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 19, 2026 at 09:19:11PM +0000, Lorenzo Stoakes wrote:
> > > +static inline bool is_shared_maywrite(vma_flags_t flags)
> > > +{
> >
> > I'm not sure it is ideal to pass this array by value? Seems like it
> > might invite some negative optimizations since now the compiler has to
> > optimze away a copy too.
>
> I really don't think so? This is inlined and thus collapses to a totally
> standard vma_flags_test_all() which passes by value anyway.
> Do you have specific examples or evidence the compiler will optimise poorly here
> on that basis as compared to pass by reference? And pass by reference would
> necessitate:
I've recently seen enough cases of older compilers and other arches
making weird choices to be a little concerened. In the above case
there is no reason not to use a const pointer (and indeed that would
be the expected idomatic kernel style), so why take chances is my
thinking.
Jason
^ permalink raw reply
* Re: [PATCH tip/locking/core 0/6] compiler-context-analysis: Scoped init guards
From: Peter Zijlstra @ 2026-01-20 10:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Marco Elver, Ingo Molnar, Thomas Gleixner, Will Deacon,
Boqun Feng, Waiman Long, Steven Rostedt, Bart Van Assche,
kasan-dev, llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
In-Reply-To: <20260120072401.GA5905@lst.de>
On Tue, Jan 20, 2026 at 08:24:01AM +0100, Christoph Hellwig wrote:
> On Mon, Jan 19, 2026 at 10:05:50AM +0100, Marco Elver wrote:
> > Note: Scoped guarded initialization remains optional, and normal
> > initialization can still be used if no guarded members are being
> > initialized. Another alternative is to just disable context analysis to
> > initialize guarded members with `context_unsafe(var = init)` or adding
> > the `__context_unsafe(init)` function attribute (the latter not being
> > recommended for non-trivial functions due to lack of any checking):
>
> I still think this is doing the wrong for the regular non-scoped
> cased, and I think I finally understand what is so wrong about it.
>
> The fact that mutex_init (let's use mutexes for the example, applied
> to other primitives as well) should not automatically imply guarding
> the members for the rest of the function. Because as soon as the
> structure that contains the lock is published that is not actually
> true, and we did have quite a lot of bugs because of that in the
> past.
>
> So I think the first step is to avoid implying the safety of guarded
> member access by initialing the lock. We then need to think how to
> express they are save, which would probably require explicit annotation
> unless we can come up with a scheme that makes these accesses fine
> before the mutex_init in a magic way.
But that is exactly what these patches do!
Note that the current state of things (tip/locking/core,next) is that
mutex_init() is 'special'. And I agree with you that that is quite
horrible.
Now, these patches, specifically patch 6, removes this implied
horribleness.
The alternative is an explicit annotation -- as you suggest.
So given something like:
struct my_obj {
struct mutex mutex;
int data __guarded_by(&mutex);
...
};
tip/locking/core,next:
init_my_obj(struct my_obj *obj)
{
mutex_init(&obj->mutex); // implies obj->mutex is taken until end of function
obj->data = FOO; // OK, because &obj->mutex 'held'
...
}
And per these patches that will no longer be true. So if you apply just
patch 6, which removes this implied behaviour, you get a compile fail.
Not good!
So patches 1-5 introduces alternatives.
So your preferred solution:
hch_my_obj(struct my_obj *obj)
{
mutex_init(&obj->mutex);
mutex_lock(&obj->mutex); // actually acquires lock
obj->data = FOO;
...
}
is perfectly fine and will work. But not everybody wants this. For the
people that only need to init the data fields and don't care about the
lock state we get:
init_my_obj(struct my_obj *obj)
{
guard(mutex_init)(&obj->mutex); // initializes mutex and considers lock
// held until end of function
obj->data = FOO;
...
}
For the people that want to first init the object but then actually lock
it, we get:
use_my_obj(struct my_obj *obj)
{
scoped_guard (mutex_init, &obj->mutex) { // init mutex and 'hold' for scope
obj->data = FOO;
...
}
mutex_lock(&obj->lock);
...
}
And for the people that *reaaaaaly* hate guards, it is possible to write
something like:
ugly_my_obj(struct my_obj *obj)
{
mutex_init(&obj->mutex);
__acquire_ctx_lock(&obj->mutex);
obj->data = FOO;
...
__release_ctx_lock(&obj->mutex);
mutex_lock(&obj->lock);
...
}
And, then there is the option that C++ has:
init_my_obj(struct my_obj *obj)
__no_context_analysis // STFU!
{
mutex_init(&obj->mutex);
obj->data = FOO; // WARN; but ignored
...
}
All I can make from your email is that you must be in favour of these
patches.
^ permalink raw reply
* Re: [PATCH RESEND 00/12] mm: add bitmap VMA flag helpers and convert all mmap_prepare to use them
From: Lorenzo Stoakes @ 2026-01-20 9:48 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module
In-Reply-To: <20260119231443.GT1134360@nvidia.com>
On Mon, Jan 19, 2026 at 07:14:43PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 19, 2026 at 09:19:02PM +0000, Lorenzo Stoakes wrote:
> > We introduced the bitmap VMA type vma_flags_t in the aptly named commit
> > 9ea35a25d51b ("mm: introduce VMA flags bitmap type") in order to permit
> > future growth in VMA flags and to prevent the asinine requirement that VMA
> > flags be available to 64-bit kernels only if they happened to use a bit
> > number about 32-bits.
> >
> > This is a long-term project as there are very many users of VMA flags
> > within the kernel that need to be updated in order to utilise this new
> > type.
> >
> > In order to further this aim, this series adds a number of helper functions
> > to enable ordinary interactions with VMA flags - that is testing, setting
> > and clearing them.
> >
> > In order to make working with VMA bit numbers less cumbersome this series
> > introduces the mk_vma_flags() helper macro which generates a vma_flags_t
> > from a variadic parameter list, e.g.:
> >
> > vma_flags_t flags = mk_vma_flags(VMA_READ_BIT, VMA_WRITE_BIT,
> > VMA_EXEC_BIT);
>
> I didn't try to check every conversion, but the whole approach looks
> nice to me and I think this design is ergonomic!
Thanks :) I have spent a _lot_ of time experimenting with different approaches
and making sure the compiler generates reasonable assembly, obviously inspired
by your suggestion that something like this was viable (I lacked faith in the
compiler doing this well previously).
I did initially have the macro be even 'cleverer' so you could do e.g.:
vma_flags_set(&flags, READ, WRITE, EXEC);
And have the macro prefix VMA_ and suffix _BIT but... a. we #define READ, WRITE
and b. it means the symbols are no longer anything to do with real symbols that
exist in the source so would be confusing.
At any rate once the conversion is complete we can drop the _BIT and make it a
little nicer.
>
> Jason
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH RESEND 09/12] mm: make vm_area_desc utilise vma_flags_t only
From: Lorenzo Stoakes @ 2026-01-20 9:46 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module
In-Reply-To: <20260119231403.GS1134360@nvidia.com>
On Mon, Jan 19, 2026 at 07:14:03PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 19, 2026 at 09:19:11PM +0000, Lorenzo Stoakes wrote:
> > +static inline bool is_shared_maywrite(vma_flags_t flags)
> > +{
>
> I'm not sure it is ideal to pass this array by value? Seems like it
> might invite some negative optimizations since now the compiler has to
> optimze away a copy too.
I really don't think so? This is inlined and thus collapses to a totally
standard vma_flags_test_all() which passes by value anyway.
Which is in itself passing-an-array-by-value, and also inlined (though we force
the inline).
I have done a bunch of assembly generation and it has all indicated the compiler
handles this perfectly well.
It in fact is the basis of being able to pretty well like-for-like replace
vm_flags_t with vma_flags_t which makes the transition significantly better (and
allows for the mk_vma_flags() helper and associated helper macros).
Do you have specific examples or evidence the compiler will optimise poorly here
on that basis as compared to pass by reference? And pass by reference would
necessitate:
vma_flags_test_all(*flags, ...);
Or changing the whole approach? My experience generating assembly doesn't
suggest any of this is necessary.
Explicitly for this case, generating the invocation from
generic_file_readonly_mmap_prepare():
if (is_shared_maywrite(desc->vma_flags))
return -EINVAL;
Is:
notl %ecx
testb $40, %cl
je .LBB106_6 [ return -EINVAL ]
In this implementation and:
notl %ecx
testb $40, %cl
je .LBB106_6 [ return -EINVAL ]
Without my series (I am omitting movl $-22, %eax in both as this just sets up
the -EINVAL return).
i.e. exactly identical.
My experience so far is this is _always_ the case, the compiler is very adept at
optimising these kinds of things.
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH RESEND 08/12] mm: update all remaining mmap_prepare users to use vma_flags_t
From: Lorenzo Stoakes @ 2026-01-20 9:01 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Jann Horn, Pedro Falcato, David Howells, Paul Moore, James Morris,
Serge E . Hallyn, Yury Norov, Rasmus Villemoes, linux-sgx,
linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module,
Jason Gunthorpe
In-Reply-To: <34F72E48-5F22-4A20-BF32-917CDB898164@nvidia.com>
On Mon, Jan 19, 2026 at 09:59:51PM -0500, Zi Yan wrote:
> On 19 Jan 2026, at 16:19, Lorenzo Stoakes wrote:
>
> > We will be shortly removing the vm_flags_t field from vm_area_desc so we
> > need to update all mmap_prepare users to only use the dessc->vma_flags
> > field.
> >
> > This patch achieves that and makes all ancillary changes required to make
> > this possible.
> >
> > This lays the groundwork for future work to eliminate the use of vm_flags_t
> > in vm_area_desc altogether and more broadly throughout the kernel.
> >
> > While we're here, we take the opportunity to replace VM_REMAP_FLAGS with
> > VMA_REMAP_FLAGS, the vma_flags_t equivalent.
> >
> > No functional changes intended.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> > drivers/char/mem.c | 6 +++---
> > drivers/dax/device.c | 10 +++++-----
> > fs/aio.c | 2 +-
> > fs/erofs/data.c | 5 +++--
> > fs/ext4/file.c | 4 ++--
> > fs/ntfs3/file.c | 2 +-
> > fs/orangefs/file.c | 4 ++--
> > fs/ramfs/file-nommu.c | 2 +-
> > fs/resctrl/pseudo_lock.c | 2 +-
> > fs/romfs/mmap-nommu.c | 2 +-
> > fs/xfs/xfs_file.c | 4 ++--
> > fs/zonefs/file.c | 3 ++-
> > include/linux/dax.h | 4 ++--
> > include/linux/mm.h | 24 +++++++++++++++++++-----
> > kernel/relay.c | 2 +-
> > mm/memory.c | 17 ++++++++---------
> > 16 files changed, 54 insertions(+), 39 deletions(-)
> >
>
> You missed one instance in !CONFIG_DAX:
Yup of course I did... :/ the amount of testing I did here and yet there's
always some straggler that even allmodconfig somehow doesn't expose.
Let me gather up the cases first and I'll fix-patch.
Thanks, Lorenzo
>
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index 162c19fe478c..48d20b790a7d 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -111,11 +111,11 @@ static inline void set_dax_nomc(struct dax_device *dax_dev)
> static inline void set_dax_synchronous(struct dax_device *dax_dev)
> {
> }
> -static inline bool daxdev_mapping_supported(vm_flags_t vm_flags,
> +static inline bool daxdev_mapping_supported(vma_flags_t flags,
> const struct inode *inode,
> struct dax_device *dax_dev)
> {
> - return !(vm_flags & VM_SYNC);
> + return !vma_flags_test(flags, VMA_SYNC_BIT);
> }
> static inline size_t dax_recovery_write(struct dax_device *dax_dev,
> pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i)
>
>
> Best Regards,
> Yan, Zi
^ permalink raw reply
* Re: [PATCH tip/locking/core 0/6] compiler-context-analysis: Scoped init guards
From: Christoph Hellwig @ 2026-01-20 7:24 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Will Deacon,
Boqun Feng, Waiman Long, Christoph Hellwig, Steven Rostedt,
Bart Van Assche, kasan-dev, llvm, linux-crypto, linux-doc,
linux-security-module, linux-kernel
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
On Mon, Jan 19, 2026 at 10:05:50AM +0100, Marco Elver wrote:
> Note: Scoped guarded initialization remains optional, and normal
> initialization can still be used if no guarded members are being
> initialized. Another alternative is to just disable context analysis to
> initialize guarded members with `context_unsafe(var = init)` or adding
> the `__context_unsafe(init)` function attribute (the latter not being
> recommended for non-trivial functions due to lack of any checking):
I still think this is doing the wrong for the regular non-scoped
cased, and I think I finally understand what is so wrong about it.
The fact that mutex_init (let's use mutexes for the example, applied
to other primitives as well) should not automatically imply guarding
the members for the rest of the function. Because as soon as the
structure that contains the lock is published that is not actually
true, and we did have quite a lot of bugs because of that in the
past.
So I think the first step is to avoid implying the safety of guarded
member access by initialing the lock. We then need to think how to
express they are save, which would probably require explicit annotation
unless we can come up with a scheme that makes these accesses fine
before the mutex_init in a magic way.
^ permalink raw reply
* Re: [PATCH RESEND 08/12] mm: update all remaining mmap_prepare users to use vma_flags_t
From: Zi Yan @ 2026-01-20 2:59 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Nico Pache, Ryan Roberts, Dev Jain, Barry Song, Lance Yang,
Jann Horn, Pedro Falcato, David Howells, Paul Moore, James Morris,
Serge E . Hallyn, Yury Norov, Rasmus Villemoes, linux-sgx,
linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module,
Jason Gunthorpe
In-Reply-To: <24317e6f6b71e8b439e672893da8d268880f7ada.1768857200.git.lorenzo.stoakes@oracle.com>
On 19 Jan 2026, at 16:19, Lorenzo Stoakes wrote:
> We will be shortly removing the vm_flags_t field from vm_area_desc so we
> need to update all mmap_prepare users to only use the dessc->vma_flags
> field.
>
> This patch achieves that and makes all ancillary changes required to make
> this possible.
>
> This lays the groundwork for future work to eliminate the use of vm_flags_t
> in vm_area_desc altogether and more broadly throughout the kernel.
>
> While we're here, we take the opportunity to replace VM_REMAP_FLAGS with
> VMA_REMAP_FLAGS, the vma_flags_t equivalent.
>
> No functional changes intended.
>
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
> drivers/char/mem.c | 6 +++---
> drivers/dax/device.c | 10 +++++-----
> fs/aio.c | 2 +-
> fs/erofs/data.c | 5 +++--
> fs/ext4/file.c | 4 ++--
> fs/ntfs3/file.c | 2 +-
> fs/orangefs/file.c | 4 ++--
> fs/ramfs/file-nommu.c | 2 +-
> fs/resctrl/pseudo_lock.c | 2 +-
> fs/romfs/mmap-nommu.c | 2 +-
> fs/xfs/xfs_file.c | 4 ++--
> fs/zonefs/file.c | 3 ++-
> include/linux/dax.h | 4 ++--
> include/linux/mm.h | 24 +++++++++++++++++++-----
> kernel/relay.c | 2 +-
> mm/memory.c | 17 ++++++++---------
> 16 files changed, 54 insertions(+), 39 deletions(-)
>
You missed one instance in !CONFIG_DAX:
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 162c19fe478c..48d20b790a7d 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -111,11 +111,11 @@ static inline void set_dax_nomc(struct dax_device *dax_dev)
static inline void set_dax_synchronous(struct dax_device *dax_dev)
{
}
-static inline bool daxdev_mapping_supported(vm_flags_t vm_flags,
+static inline bool daxdev_mapping_supported(vma_flags_t flags,
const struct inode *inode,
struct dax_device *dax_dev)
{
- return !(vm_flags & VM_SYNC);
+ return !vma_flags_test(flags, VMA_SYNC_BIT);
}
static inline size_t dax_recovery_write(struct dax_device *dax_dev,
pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i)
Best Regards,
Yan, Zi
^ permalink raw reply related
* Re: [PATCH v2 1/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer
From: John Johansen @ 2026-01-20 0:44 UTC (permalink / raw)
To: Zhengmian Hu, john, apparmor; +Cc: linux-security-module, linux-kernel
In-Reply-To: <20260120000307.369587-2-huzhengmian@gmail.com>
On 1/19/26 16:03, Zhengmian Hu wrote:
> When aa_get_buffer() pulls from the per-cpu list it unconditionally
> decrements cache->hold. If hold reaches 0 while count is still non-zero,
> the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a
> very long time, so aa_put_buffer() never returns buffers to the global
> list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max)
> allocations.
>
> Guard the decrement so hold never underflows.
>
> Signed-off-by: Zhengmian Hu <huzhengmian@gmail.com>
thanks, Acked-by: John Johansen <john.johansen@canonical.com>
I have pulled this into apparmor-next
> ---
> security/apparmor/lsm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 9b6c2f157..a6c884ba6 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1868,7 +1868,8 @@ char *aa_get_buffer(bool in_atomic)
> if (!list_empty(&cache->head)) {
> aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
> list_del(&aa_buf->list);
> - cache->hold--;
> + if (cache->hold)
> + cache->hold--;
> cache->count--;
> put_cpu_ptr(&aa_local_buffers);
> return &aa_buf->buffer[0];
^ permalink raw reply
* [PATCH v2 1/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer
From: Zhengmian Hu @ 2026-01-20 0:03 UTC (permalink / raw)
To: john.johansen, john, apparmor
Cc: linux-security-module, linux-kernel, Zhengmian Hu
In-Reply-To: <20260120000307.369587-1-huzhengmian@gmail.com>
When aa_get_buffer() pulls from the per-cpu list it unconditionally
decrements cache->hold. If hold reaches 0 while count is still non-zero,
the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a
very long time, so aa_put_buffer() never returns buffers to the global
list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max)
allocations.
Guard the decrement so hold never underflows.
Signed-off-by: Zhengmian Hu <huzhengmian@gmail.com>
---
security/apparmor/lsm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 9b6c2f157..a6c884ba6 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1868,7 +1868,8 @@ char *aa_get_buffer(bool in_atomic)
if (!list_empty(&cache->head)) {
aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
list_del(&aa_buf->list);
- cache->hold--;
+ if (cache->hold)
+ cache->hold--;
cache->count--;
put_cpu_ptr(&aa_local_buffers);
return &aa_buf->buffer[0];
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer
From: Zhengmian Hu @ 2026-01-20 0:03 UTC (permalink / raw)
To: john.johansen, john, apparmor
Cc: linux-security-module, linux-kernel, Zhengmian Hu
Hi all,
This series fixes a per-cpu hold counter underflow in the AppArmor buffer
cache. Under high-frequency execve workloads with AppArmor enabled, cache->hold
can wrap to UINT_MAX, preventing buffers from returning to the global list and
forcing repeated kmalloc(aa_g_path_max) allocations.
Summary:
On high-frequency execve workloads with AppArmor enabled, the per-CPU buffer
cache can enter a pathological state: aa_get_buffer() decrements hold even
when it is already zero, causing an unsigned underflow. The resulting huge
hold value prevents aa_put_buffer() from refilling the global list, which
starves other CPUs and forces repeated kmalloc(aa_g_path_max) allocations.
Because the AppArmor pool does not shrink, this accumulates into large
kmalloc-8k slab growth over time.
Repro (QEMU TCG, 4 vCPU, 1 GiB RAM, v6.16):
- Unpatched: kmalloc-8k objects grow 12->16 in 120s (run1), 16->20 in 120s (run2)
- Patched: kmalloc-8k stays at 12 for 120s
Notes:
This fix targets the observed underflow mechanism without changing the overall
AppArmor buffer pool design. Happy to provide the reproduction script and logs
on request.
Changes in v2:
- Add patch description to the commit message.
Thanks,
Zhengmian Hu
Zhengmian Hu (1):
apparmor: avoid per-cpu hold underflow in aa_get_buffer
security/apparmor/lsm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH 1/1] apparmor: avoid per-cpu hold underflow in aa_get_buffer
From: John Johansen @ 2026-01-19 23:56 UTC (permalink / raw)
To: Zhengmian Hu, john, apparmor; +Cc: linux-security-module, linux-kernel
In-Reply-To: <20260119122119.3648154-2-huzhengmian@gmail.com>
On 1/19/26 04:21, Zhengmian Hu wrote:
> Signed-off-by: Zhengmian Hu <huzhengmian@gmail.com>
Small nit, there is no patch description. I can pull that from patch [0/1] if you are okay with that, otherwise can you send in a v2?
I will pull this in once I know your preference
> ---
> security/apparmor/lsm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 9b6c2f157..a6c884ba6 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1868,7 +1868,8 @@ char *aa_get_buffer(bool in_atomic)
> if (!list_empty(&cache->head)) {
> aa_buf = list_first_entry(&cache->head, union aa_buffer, list);
> list_del(&aa_buf->list);
> - cache->hold--;
> + if (cache->hold)
> + cache->hold--;
> cache->count--;
> put_cpu_ptr(&aa_local_buffers);
> return &aa_buf->buffer[0];
^ permalink raw reply
* Re: ipv4: cipso potential BUG()
From: Paul Moore @ 2026-01-19 23:31 UTC (permalink / raw)
To: Will Rosenberg
Cc: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Huw Davies, netdev,
linux-security-module, linux-kernel
In-Reply-To: <aW6YMA11KFzSkgfw@gmail.com>
On Mon, Jan 19, 2026 at 3:46 PM Will Rosenberg <whrosenb@asu.edu> wrote:
>
> Previously, it was discussed that skb_cow() has a bug due to implicit
> integer casting that can lead to a BUG when headroom < -NET_SKB_PAD. We
> concluded that it was not worthwhile to fix the root cause and to
> instead fix the symptom found in calipso. The thread for this issue can
> be found here:
>
> https://lore.kernel.org/netdev/CAHC9VhQmR8A2vz0W-VrrhYNQ2wgCYxHbAmdgmM2yTL-uh4qiOg@mail.gmail.com/
>
> I recently reviewed the use cases of skb_cow() throughout the kernel and
> found that cipso_v4_skbuff_setattr() comes very close to triggering the
> same BUG. However, I concluded this was not triggerable. Even though
> len_delta can become negative, leading to a negative headroom passed to
> skb_cow(), we do not satisfy the condition headroom < -NET_SKB_PAD.
>
> Nonetheless, I believe cipso is using skb_cow() dangerously, but since
> the issue is not triggerable, would it still make sense to patch it?
> I figured I would throw out a quick email. Please let me know and I can
> make a similar patch for cipso if necessary.
Sometimes the easiest way to get an answer to questions like this is
to send a patch; since I would expect this particular patch to be of
limited scope and very small, I think this advice holds true here.
--
paul-moore.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox