Re: [PATCH] btrfs: Fix BTRFS arm64 tagged KASAN false-positive

[Qu Wenruo]

在 2026/3/21 13:09, Daniel J Blueman 写道:
> On Sat, 21 Mar 2026 at 06:27, Qu Wenruo <wqu@xxxxxxxx> wrote:
> > 在 2026/3/21 08:31, David Sterba 写道:
> > > On Thu, Mar 19, 2026 at 07:26:34PM +1030, Qu Wenruo wrote:
[...]
> > There is the interface, page_kasan_tag_set()/page_kasan_tag_reset(), and
> > is already utilized inside MM.
> >
> > And the deeper problem is, if this is a false alert, shouldn't we fix
> > the sanitizer?
> >
> > Especially in this case I didn't see any problem accessing properly
> > allocated and physically adjacent pages.
>
> I agree with this, however BTRFS doesn't have multi-page folios, thus
> these pages are from different allocations; from extent_io.c:
>
> /* For now, we should only have single-page folios for btree inode. */
> ASSERT(folio_nr_pages(existing_folio) == 1);
>
> The goal of the differing KASAN tags per allocation is to catch UAF
> and other lifecycle issues. If preferred, I can test and submit a
> patch to set the same KASAN tag in alloc_eb_folio_array()? This would
> be removed when multi-page folio support is added and is along the
> lines of:
>
> for (int i = 1; i < num_pages; i++)
>    page_kasan_tag_set(page_array[i], page_kasan_tag(page_array[0]));

That's exactly what I expect.

> It will be less minimal as won't implicitly be compiled out as per my
> previous patch.

To be honest, I think the above change is the minimal fix, as it doesn't 
inject kasan code into the main loop of folio allocation.

And it will be compiled out, as page_kasan_tag_set() is no-op if neither 
software nor hardware tag is selected, and I believe the compiler is 
definitely clever enough to remove a loop with no-op in it.

Thanks,
Qu

> Thanks,
>    Dan