Bug 216784 - There is "ext4_xattr_block_set" WARNING in v6.1-rc8 guest kernel
Summary: There is "ext4_xattr_block_set" WARNING in v6.1-rc8 guest kernel
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-07 08:58 UTC by xupengfe
Modified: 2022-12-07 17:19 UTC (History)
1 user (show)

See Also:
Kernel Version: v6.1-rc8
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description xupengfe 2022-12-07 08:58:57 UTC
Platform: raptor lake

There is "ext4_xattr_block_set" WARNING in v6.1-rc8 guest kernel.
"
[   27.922337] loop0: detected capacity change from 0 to 1024
[   27.922663] =======================================================
[   27.922663] WARNING: The mand mount option has been deprecated and
[   27.922663]          and is ignored by this kernel. Remove the mand
[   27.922663]          option from the mount to silence this warning.
[   27.922663] =======================================================
[   27.923771] EXT4-fs: Ignoring removed bh option
[   27.923947] EXT4-fs: Ignoring removed i_version option
[   27.924204] EXT4-fs: Journaled quota options ignored when QUOTA feature is enabled
[   27.925839] EXT4-fs (loop0): mounted filesystem without journal. Quota mode: writeback.
[   27.928984] ------------[ cut here ]------------
[   27.929173] WARNING: CPU: 0 PID: 567 at fs/ext4/xattr.c:2069 ext4_xattr_block_set+0x170d/0x1770
[   27.929514] Modules linked in:
[   27.929651] CPU: 0 PID: 567 Comm: repro Not tainted 6.1.0-rc8-76dcd734eca2 #1
[   27.929931] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[   27.930355] RIP: 0010:ext4_xattr_block_set+0x170d/0x1770
[   27.930562] Code: e8 78 18 ff ff 48 8b 7d a0 e8 4f eb e5 ff e9 80 fe ff ff e8 25 3d b5 ff 4c 89 ff e8 fd c2 e9 ff e9 b6 f5 ff ff e8 13 3d b5 ff <0f> 0b e9 21 1
[   27.931241] RSP: 0018:ffffc90000fc7a10 EFLAGS: 00010246
[   27.931442] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff816fa04d
[   27.931708] RDX: 0000000000000000 RSI: ffff88800cb6cc80 RDI: 0000000000000002
[   27.931973] RBP: ffffc90000fc7ae8 R08: ffff88800bae3824 R09: ffff88800bae3bfe
[   27.932236] R10: ffffc90000fc7e28 R11: 00000000fa83b201 R12: 0000000000000000
[   27.932502] R13: ffff88800cb85800 R14: 0000000000000000 R15: 0000000000000000
[   27.932781] FS:  00007f69b3c68740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
[   27.933079] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   27.933296] CR2: 000055c48486e5e8 CR3: 000000000b76a005 CR4: 0000000000770ef0
[   27.933569] PKRU: 55555554
[   27.933676] Call Trace:
[   27.933773]  <TASK>
[   27.933861]  ? __sanitizer_cov_trace_pc+0x25/0x60
[   27.934048]  ext4_expand_extra_isize_ea+0x5e9/0xcd0
[   27.934242]  __ext4_expand_extra_isize+0x188/0x1f0
[   27.934443]  __ext4_mark_inode_dirty+0x246/0x370
[   27.934637]  ? ext4_setattr+0x1380/0x1380
[   27.934794]  ext4_dirty_inode+0x7a/0xa0
[   27.934946]  __mark_inode_dirty+0xa3/0x650
[   27.935107]  ? setattr_copy+0x11e/0x320
[   27.935259]  ext4_setattr+0xb26/0x1380
[   27.935407]  ? __sanitizer_cov_trace_pc+0x25/0x60
[   27.935593]  ? ext4_journalled_write_end+0x900/0x900
[   27.935792]  notify_change+0x3f8/0xb50
[   27.935943]  chmod_common+0xef/0x200
[   27.936085]  ? chmod_common+0xef/0x200
[   27.936235]  ? __sanitizer_cov_trace_pc+0x25/0x60
[   27.936420]  do_fchmodat+0x76/0xf0
[   27.936558]  __x64_sys_chmod+0x28/0x40
[   27.936713]  do_syscall_64+0x3b/0x90
[   27.936862]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[   27.937062] RIP: 0033:0x7f69b3d8d59d
[   27.937203] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 8
[   27.937900] RSP: 002b:00007ffccac7eef8 EFLAGS: 00000246 ORIG_RAX: 000000000000005a
[   27.938184] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f69b3d8d59d
[   27.938450] RDX: 0031656c69662f2e RSI: 0000000000000140 RDI: 0000000020000100
[   27.938719] RBP: 00007ffccac7ef00 R08: 00007ffccac7ed60 R09: 00000000004028e0
[   27.938985] R10: 00007ffccac7ed60 R11: 0000000000000246 R12: 00000000004011a0
[   27.939250] R13: 00007ffccac7efe0 R14: 0000000000000000 R15: 0000000000000000
[   27.939517]  </TASK>
[   27.939605] ---[ end trace 0000000000000000 ]---
"

Bisect automation tried twice on 2 different rpl-p platforms, both results show
the same first bad commit as below:
"
cebe85d570cf84804e848332d6721bc9e5300e07
ext4: switch to the new mount api
"

And I tried that: installed the patch in below link based on v6.1-rc8,
this issue still could be reproduced.
https://lore.kernel.org/lkml/20221107133651.qmitthhev3lq4h5q@quack3/

Kconfig, reproduced code, bisect info are in attached.
All detailed info is in link:
https://github.com/xupengfe/syzkaller_logs/tree/main/221207_100056_ext4_xattr_block_set
Comment 1 Theodore Tso 2022-12-07 17:19:03 UTC
This is a high-level comment since I see you also filed a report via e-mail, and Jan has already responded to the report.  (Thanks, Jan!)

Are you running your own syzkaller instance or are you using the public syzkaller instance?   If this is the public syzkaller, please include a link to the public syzkaller.  There are a couple of reasons why this is useful.  (a) That way we can add a reported-by link to the syzkaller id, which is something that that the syzkaller maintainers have requested.  (b)  The public syzkaller has useful information about whether a particular issue shows up on other kernels (including older LTS kernels) which can be useful.   (c)  The newest syzkaller updates has convenient ways of downloading the the file system involved with syzkaller reproducers, the strace log so it's easier to understand what the heck the reproducer is doing, etc.   (d)   The syzkaller dashboard now has clickable links in the stack trace which means that so it's much easier to determine what is going on.

I suspect it's this one: https://syzkaller.appspot.com/bug?extid=98346927678ac3059c77   Can you confirm?

In addition, please consider whether there is more you can do to add value.  For example, can you simplify the reproducer, and translate it into C so it's more obvious what's going on?   In this particular case, the repro.c is fairly straightforward, but there are many times when it is not so simple to understand what is going on, and the programatic minimalization of the reproducer is not ideal.    In the ideal case, you'd actually identify the root cause and propose a patch, not just throw it to the upstream maintainers to look at.  (This is especially true if this came from the public syzkaller instance, since we get e-mail notifications for them already.)

Finally, I'd suggest that providing a pre-compiled reproducer in the git repo is not a great way to add value, since it's a security issue (we don't want to encourage people to use random binaries downloaded from the web) and it's not all that hard to compile the C reproducer in any case.  It also bloats the git repo, which is not a great thing in the long term, if people decide it's easier to browse the files by cloning the repro.  (Although in this case, if you had provided a link to the public Syzkaller dashboard, that would arguably be easier for those artifacts already provided by Syzkaller.)

Thanks!

Note You need to log in before you can comment on or make changes to this bug.