Message-ID: <9d21022d-5051-4165-b8fa-f77ec7e820ab@suse.com>
Date: Wed, 31 Dec 2025 15:25:08 +1030
From: Qu Wenruo <wqu@...e.com>
To: Daniel J Blueman <daniel@...ra.org>
Cc: David Sterba <dsterba@...e.com>, Chris Mason <clm@...com>,
 Linux BTRFS <linux-btrfs@...r.kernel.org>, linux-crypto@...r.kernel.org,
 Linux Kernel <linux-kernel@...r.kernel.org>, kasan-dev@...glegroups.com,
 ryabinin.a.a@...il.com
Subject: Re: Soft tag and inline kasan triggering NULL pointer dereference,
 but not for hard tag and outline mode (was Re: [6.19-rc3] xxhash invalid
 access during BTRFS mount)



在 2025/12/31 14:35, Qu Wenruo 写道:
> 
> 
> 在 2025/12/31 13:59, Daniel J Blueman 写道:
>> On Tue, 30 Dec 2025 at 17:28, Qu Wenruo <wqu@...e.com> wrote:
>>> 在 2025/12/30 19:26, Qu Wenruo 写道:
>>>> 在 2025/12/30 18:02, Daniel J Blueman 写道:
>>>>> When mounting a BTRFS filesystem on 6.19-rc3 on ARM64 using xxhash
>>>>> checksumming and KASAN, I see invalid access:
>>>>
>>>> Mind to share the page size? As aarch64 has 3 different supported pages
>>>> size (4K, 16K, 64K).
>>>>
>>>> I'll give it a try on that branch. Although on my rc1 based development
>>>> branch it looks OK so far.
>>>
>>> Tried both 4K and 64K page size with KASAN enabled, all on 6.19-rc3 tag,
>>> no reproduce on newly created fs with xxhash.
>>>
>>> My environment is aarch64 VM on Orion O6 board.
>>>
>>> The xxhash implementation is the same xxhash64-generic:
>>>
>>> [   17.035933] BTRFS: device fsid 260364b9-d059-410c-92de-56243c346d6d
>>> devid 1 transid 8 /dev/mapper/test-scratch1 (253:2) scanned by mount 
>>> (629)
>>> [   17.038033] BTRFS info (device dm-2): first mount of filesystem
>>> 260364b9-d059-410c-92de-56243c346d6d
>>> [   17.038645] BTRFS info (device dm-2): using xxhash64
>>> (xxhash64-generic) checksum algorithm
>>> [   17.041303] BTRFS info (device dm-2): checking UUID tree
>>> [   17.041390] BTRFS info (device dm-2): turning on async discard
>>> [   17.041393] BTRFS info (device dm-2): enabling free space tree
>>> [   19.032109] BTRFS info (device dm-2): last unmount of filesystem
>>> 260364b9-d059-410c-92de-56243c346d6d
>>>
>>> So there maybe something else involved, either related to the fs or the
>>> hardware.
>>
>> Thanks for checking Wenruo!
>>
>> With KASAN_GENERIC or KASAN_HW_TAGS, I don't see "kasan:
>> KernelAddressSanitizer initialized", so please ensure you are using
>> KASAN_SW_TAGS, KASAN_OUTLINE and 4KB pages. Full config at
>> https://gist.github.com/dblueman/cb4113f2cf880520081cf3f7c8dae13f
> 
> Thanks a lot for the detailed configs.
> 
> Unfortunately with that KASAN_SW_TAGS and KASAN_INLINE, the kernel can 
> no longer boot, will always crash at boot with the following call trace, 
> thus not even able to reach btrfs:
> 
> [    3.938722] 
> ==================================================================
> [    3.938739] BUG: KASAN: invalid-access in 
> bpf_patch_insn_data+0x178/0x3b0
[...]
> 
> 
> Considering this is only showing up in KASAN_SW_TAGS, not HW_TAGS or the 
> default generic mode, I'm wondering if this is a bug in KASAN itself.
> 
> Adding KASAN people to the thread, meanwhile I'll check more KASAN + 
> hardware combinations including x86_64 (since it's still 4K page size).

I tried the following combinations, with a simple workload of mounting a 
btrfs with xxhash checksum.

According to the original report, the KASAN is triggered as btrfs 
metadata verification time, thus mount option/workload shouldn't cause 
any different, as all metadata will use the same checksum algorithm.

x86_64 + generic + inline:	PASS
x86_64 + generic + outline:	PASS
arm64 + soft tag + inline:	KASAN error at boot
arm64 + soft tag + outline:	KASAN error at boot
arm64 + hard tag:		PASS
arm64 + generic + inline:	PASS
arm64 + generic + outline:	PASS

So it looks like it's the software tag based KASAN itself causing false 
alerts.

Thanks,
Qu

> 
> Thanks,
> Qu
> 
> 
>>
>> Also ensure your mount options resolve similar to
>> "rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/".
>>
>> Failing that, let me know of any significant filesystem differences from:
>> # btrfs inspect-internal dump-super /dev/nvme0n1p5
>> superblock: bytenr=65536, device=/dev/nvme0n1p5
>> ---------------------------------------------------------
>> csum_type        1 (xxhash64)
>> csum_size        8
>> csum            0x97ec1a3695ae35d0 [match]
>> bytenr            65536
>> flags            0x1
>>              ( WRITTEN )
>> magic            _BHRfS_M [match]
>> fsid            f99f2753-0283-4f93-8f5d-7a9f59f148cc
>> metadata_uuid        00000000-0000-0000-0000-000000000000
>> label
>> generation        34305
>> root            586579968
>> sys_array_size        129
>> chunk_root_generation    33351
>> root_level        0
>> chunk_root        19357892608
>> chunk_root_level    0
>> log_root        0
>> log_root_transid (deprecated)    0
>> log_root_level        0
>> total_bytes        83886080000
>> bytes_used        14462930944
>> sectorsize        4096
>> nodesize        16384
>> leafsize (deprecated)    16384
>> stripesize        4096
>> root_dir        6
>> num_devices        1
>> compat_flags        0x0
>> compat_ro_flags        0x3
>>              ( FREE_SPACE_TREE |
>>                FREE_SPACE_TREE_VALID )
>> incompat_flags        0x361
>>              ( MIXED_BACKREF |
>>                BIG_METADATA |
>>                EXTENDED_IREF |
>>                SKINNY_METADATA |
>>                NO_HOLES )
>> cache_generation    0
>> uuid_tree_generation    34305
>> dev_item.uuid        86166b5f-2258-4ab9-aac6-0d0e37ffbdb6
>> dev_item.fsid        f99f2753-0283-4f93-8f5d-7a9f59f148cc [match]
>> dev_item.type        0
>> dev_item.total_bytes    83886080000
>> dev_item.bytes_used    22624075776
>> dev_item.io_align    4096
>> dev_item.io_width    4096
>> dev_item.sector_size    4096
>> dev_item.devid        1
>> dev_item.dev_group    0
>> dev_item.seek_speed    0
>> dev_item.bandwidth    0
>> dev_item.generation    0
>>
>> Thanks,
>>    Dan
>> -- 
>> Daniel J Blueman
> 
> 

Powered by blists - more mailing lists