Greeting,
FYI, we noticed the following commit (built with clang-14):
commit: 0858d7da8a09e440fb192a0239d20249a2d16af8 ("ramfs: fix mount source show for ramfs")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+------------------------------------------+------------+------------+
| | 2d93a5835a | 0858d7da8a |
+------------------------------------------+------------+------------+
| boot_successes | 17 | 4 |
| boot_failures | 0 | 13 |
| canonical_address#:#[##] | 0 | 12 |
| RIP:ntfs_update_mftmirr | 0 | 12 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 12 |
+------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <[email protected]>
[ 806.118664][ T1] selinux=0
[ 806.119418][ T1] softlockup_panic=1
[ 806.120350][ T1] nmi_watchdog=panic
[ 806.121180][ T1] vga=normal
[ 806.257788][ T204] /dev/root: Can't open blockdev
[ 806.259101][ T204] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN
[ 806.263082][ T204] KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[ 806.264593][ T204] CPU: 1 PID: 204 Comm: mount Not tainted 5.15.0-00312-g0858d7da8a09 #1
[ 806.266012][ T204] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
[ 806.267540][ T204] RIP: 0010:ntfs_update_mftmirr (kbuild/src/consumer/fs/ntfs3/fsntfs.c:834)
[ 806.268641][ T204] Code: 4c 89 e8 48 c1 e8 03 42 80 3c 30 00 74 08 4c 89 ef e8 f4 4b a0 ff 4d 8b 65 00 49 8d 5c 24 18 48 89 d8 48 c1 e8 03 48 89 45 90 <42> 80 3c 30 00 74 08 48 89 df e8 d1 4b a0 ff 48 89 9d 78 ff ff ff
All code
========
0: 4c 89 e8 mov %r13,%rax
3: 48 c1 e8 03 shr $0x3,%rax
7: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1)
c: 74 08 je 0x16
e: 4c 89 ef mov %r13,%rdi
11: e8 f4 4b a0 ff callq 0xffffffffffa04c0a
16: 4d 8b 65 00 mov 0x0(%r13),%r12
1a: 49 8d 5c 24 18 lea 0x18(%r12),%rbx
1f: 48 89 d8 mov %rbx,%rax
22: 48 c1 e8 03 shr $0x3,%rax
26: 48 89 45 90 mov %rax,-0x70(%rbp)
2a:* 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) <-- trapping instruction
2f: 74 08 je 0x39
31: 48 89 df mov %rbx,%rdi
34: e8 d1 4b a0 ff callq 0xffffffffffa04c0a
39: 48 89 9d 78 ff ff ff mov %rbx,-0x88(%rbp)
Code starting with the faulting instruction
===========================================
0: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1)
5: 74 08 je 0xf
7: 48 89 df mov %rbx,%rdi
a: e8 d1 4b a0 ff callq 0xffffffffffa04be0
f: 48 89 9d 78 ff ff ff mov %rbx,-0x88(%rbp)
[ 806.271820][ T204] RSP: 0000:ffffc90000297c08 EFLAGS: 00010206
[ 806.272964][ T204] RAX: 0000000000000003 RBX: 0000000000000018 RCX: ffff888122c58000
[ 806.274379][ T204] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888122a76000
[ 806.275793][ T204] RBP: ffffc90000297c90 R08: dffffc0000000000 R09: ffff888122a762a8
[ 806.277143][ T204] R10: dfffe9102454ec59 R11: 1ffff1102454ec55 R12: 0000000000000000
[ 806.278484][ T204] R13: ffff888122a76000 R14: dffffc0000000000 R15: dffffc0000000000
[ 806.279930][ T204] FS: 0000000000000000(0000) GS:ffff8883a0500000(0063) knlGS:00000000f7e8f200
[ 806.281545][ T204] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 806.282669][ T204] CR2: 00000000565fa0ec CR3: 00000001229cf000 CR4: 00000000000406e0
[ 806.284123][ T204] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 806.285604][ T204] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 806.287064][ T204] Call Trace:
[ 806.287746][ T204] ? kfree (kbuild/src/consumer/mm/slub.c:4553)
[ 806.288623][ T204] ? trace_kfree (kbuild/src/consumer/include/trace/events/kmem.h:118)
[ 806.289448][ T204] ? memset (kbuild/src/consumer/mm/kasan/shadow.c:?)
[ 806.290232][ T204] put_ntfs (kbuild/src/consumer/fs/ntfs3/super.c:465)
[ 806.291046][ T204] ntfs_fs_free (kbuild/src/consumer/fs/ntfs3/super.c:1365)
To reproduce:
# build kernel
cd linux
cp config-5.15.0-00312-g0858d7da8a09 .config
make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install
cd <mod-install-dir>
find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
---
0DAY/LKP+ Test Infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/[email protected] Intel Corporation
Thanks,
Oliver Sang
On Thu, Nov 25, 2021 at 6:08 AM kernel test robot <[email protected]> wrote:
> FYI, we noticed the following commit (built with clang-14):
>
> commit: 0858d7da8a09e440fb192a0239d20249a2d16af8 ("ramfs: fix mount source show for ramfs")
Funky. That commit seems to have nothing to do with the oops:
> [ 806.257788][ T204] /dev/root: Can't open blockdev
> [ 806.259101][ T204] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN
> [ 806.263082][ T204] KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
Not a very helpful error message,a nd the KASAN comment makes little sense, but
> [ 806.267540][ T204] RIP: 0010:ntfs_update_mftmirr (kbuild/src/consumer/fs/ntfs3/fsntfs.c:834)
That's
u32 blocksize = sb->s_blocksize;
and presumably with KASAN you end up getting hat odd 0xdffffc0000000003 thing.
Anyway, looks like sb is NULL, and the code is
int ntfs_update_mftmirr(struct ntfs_sb_info *sbi, int wait)
{
int err;
struct super_block *sb = sbi->sb;
u32 blocksize = sb->s_blocksize;
sector_t block1, block2;
although I have no idea how sbi->sb could be NULL.
Konstantin? See
https://lore.kernel.org/lkml/20211125140816.GC3109@xsang-OptiPlex-9020/
for the full thing.
Linus
Cc ntfs3:
Maybe it's a problem like this:
do_new_mount
fs_context_for_mount
alloc_fs_context
ntfs_init_fs_context
sbi = kzalloc(sizeof(struct ntfs_sb_info), GFP_NOFS);
fc->s_fs_info = sbi;
vfs_get_tree
ntfs_fs_get_tree
get_tree_bdev
blkdev_get_by_path // return error and sbi->sb will be NULL
put_fs_context
ntfs_fs_free
put_ntfs
ntfs_update_mftmirr
struct super_block *sb = sbi->sb; // NULL
u32 blocksize = sb->s_blocksize; // BOOM
It's actually a ntfs3 bug which may be introduced by:
610f8f5a7baf fs/ntfs3: Use new api for mounting
On 2021/11/26 2:03, Linus Torvalds wrote:
> On Thu, Nov 25, 2021 at 6:08 AM kernel test robot <[email protected]> wrote:
>> FYI, we noticed the following commit (built with clang-14):
>>
>> commit: 0858d7da8a09e440fb192a0239d20249a2d16af8 ("ramfs: fix mount source show for ramfs")
>
> Funky. That commit seems to have nothing to do with the oops:
>
>> [ 806.257788][ T204] /dev/root: Can't open blockdev
>> [ 806.259101][ T204] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN
>> [ 806.263082][ T204] KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
>
> Not a very helpful error message,a nd the KASAN comment makes little sense, but
>
>> [ 806.267540][ T204] RIP: 0010:ntfs_update_mftmirr (kbuild/src/consumer/fs/ntfs3/fsntfs.c:834)
>
> That's
>
> u32 blocksize = sb->s_blocksize;
>
> and presumably with KASAN you end up getting hat odd 0xdffffc0000000003 thing.
>
> Anyway, looks like sb is NULL, and the code is
>
> int ntfs_update_mftmirr(struct ntfs_sb_info *sbi, int wait)
> {
> int err;
> struct super_block *sb = sbi->sb;
> u32 blocksize = sb->s_blocksize;
> sector_t block1, block2;
>
> although I have no idea how sbi->sb could be NULL.
>
> Konstantin? See
>
> https://lore.kernel.org/lkml/20211125140816.GC3109@xsang-OptiPlex-9020/
>
> for the full thing.
>
> Linus
> .
>
On Fri, Nov 26, 2021 at 09:54:56AM +0800, yangerkun wrote:
> Cc ntfs3:
>
> Maybe it's a problem like this:
>
> do_new_mount
> fs_context_for_mount
> alloc_fs_context
> ntfs_init_fs_context
> sbi = kzalloc(sizeof(struct ntfs_sb_info), GFP_NOFS);
> fc->s_fs_info = sbi;
> vfs_get_tree
> ntfs_fs_get_tree
> get_tree_bdev
> blkdev_get_by_path // return error and sbi->sb will be NULL
> put_fs_context
> ntfs_fs_free
> put_ntfs
> ntfs_update_mftmirr
> struct super_block *sb = sbi->sb; // NULL
> u32 blocksize = sb->s_blocksize; // BOOM
>
> It's actually a ntfs3 bug which may be introduced by:
>
> 610f8f5a7baf fs/ntfs3: Use new api for mounting
Yeap. Thank you very much. Will send patch for this in within 24h.
> On 2021/11/26 2:03, Linus Torvalds wrote:
> > On Thu, Nov 25, 2021 at 6:08 AM kernel test robot <[email protected]> wrote:
> > > FYI, we noticed the following commit (built with clang-14):
> > >
> > > commit: 0858d7da8a09e440fb192a0239d20249a2d16af8 ("ramfs: fix mount source show for ramfs")
> >
> > Funky. That commit seems to have nothing to do with the oops:
> >
> > > [ 806.257788][ T204] /dev/root: Can't open blockdev
> > > [ 806.259101][ T204] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN
> > > [ 806.263082][ T204] KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
> >
> > Not a very helpful error message,a nd the KASAN comment makes little sense, but
> >
> > > [ 806.267540][ T204] RIP: 0010:ntfs_update_mftmirr (kbuild/src/consumer/fs/ntfs3/fsntfs.c:834)
> >
> > That's
> >
> > u32 blocksize = sb->s_blocksize;
> >
> > and presumably with KASAN you end up getting hat odd 0xdffffc0000000003 thing.
> >
> > Anyway, looks like sb is NULL, and the code is
> >
> > int ntfs_update_mftmirr(struct ntfs_sb_info *sbi, int wait)
> > {
> > int err;
> > struct super_block *sb = sbi->sb;
> > u32 blocksize = sb->s_blocksize;
> > sector_t block1, block2;
> >
> > although I have no idea how sbi->sb could be NULL.
> >
> > Konstantin? See
> >
> > https://lore.kernel.org/lkml/20211125140816.GC3109@xsang-OptiPlex-9020/
> >
> > for the full thing.
> >
> > Linus
> > .
> >