Re: Linux 6.18-rc6

[David Hildenbrand (Red Hat)]

On 17.11.25 18:59, Linus Torvalds wrote:
> On Mon, 17 Nov 2025 at 09:53, David Hildenbrand (Red Hat)
> <david@xxxxxxxxxx> wrote:
> > I had the same in mind for a second, but then I looked at
> > kernel_init_pages() with the kasan_disable_current() handling and
> > concluded that it's clearer to just disallow tag_clear_highpage() being
> > abused in the first place and reduce the effective code footprint of
> > post_alloc_hook().
>
> See, I had the exact opposite reaction: I think the one-liner is
> better not just because it's simpler, but exactly *because* of the
> mess that is kernel_init_pages().

Heh, I intuitively avoid runtime checks on the fast paths where avoidable :)

> IOW, that one-liner is either correct *without* all that crud - and
> it's unnecessary for the __GFP_ZEROTAGS case because that only happens
> at init time - or it shows a bug in the arm64 code.

What sticks out is that we perform the tag_clear_highpage() before we do 
all the KASAN poison magic. And we perform the kernel_init_pages() after 
the kasan magic.

The clear_highpage() fallback in tag_clear_highpage() was just recently 
added by Catalin (in the same commit we are fixing here IIRC).

I am no expert on KASAN, but I would suspect that it is important for us 
to clear the pages after doing the 
kasan_unpoison_pages/page_kasan_tag_reset.

I'll have to dig into the history of tag_clear_highpage() a bit to 
understand how this would interact with non-hw-tag-based KASAN. IIRC, 
amd64 also supports SW-tag KASAN.


> Either way it's a win. Either it's simpler, or it gives us better coverage.
>
> No?

Staring a bit more at the arm64 fallback in tag_clear_highpage() I agree 
that it might help to find arm64 issues we might run into in the fallback.

But the interaction of KASAN config options are not particularly easy to 
understand -- and if this would actually break non-arm configs. I'll 
have to dig ...

--
Cheers

David