Re: btrfs crash in kobject_del while running xfstest

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Somehow the copy-paste of Chris Mason's name failed (user error
on my end), sorry about that Chris!

On 8/11/20 4:17 AM, John Hubbard wrote:
Hi,

Here's an early warning of a possible problem.

I'm seeing a new btrfs crash when running xfstests, as of
00e4db51259a5f936fec1424b884f029479d3981 ("Merge tag
'perf-tools-2020-08-10' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux") in linux.git.

This doesn't crash in v5.8, so I attempted to bisect, but ended up with
the net-next merge commit as the offending one: commit
47ec5303d73ea344e84f46660fff693c57641386 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next"), which
doesn't really help because it's 2088 files changed, of course.

I'm attaching the .config that I used.

This is easily reproducible via something like (change to match your setup,
of course):

     sudo TEST_DEV=/dev/nvme0n1p8 TEST_DIR=/xfstest_btrfs \
       SCRATCH_DEV=/dev/nvme0n1p9 SCRATCH_MNT=/xfstest_scratch  ./check \
       btrfs/002

which leads to:

[  586.097360] BTRFS info (device nvme0n1p8): disk space caching is enabled
[  586.103232] BTRFS info (device nvme0n1p8): has skinny extents
[  586.115169] BTRFS info (device nvme0n1p8): enabling ssd optimizations
[  586.308264] BTRFS: device fsid 5dfff89d-8f8d-42ac-8538-acb95164d0be devid 1 transid 5 /dev/nvme0n1p9 scanned by mkfs.btrfs (6374)
[  586.342776] BTRFS info (device nvme0n1p9): disk space caching is enabled
[  586.348585] BTRFS info (device nvme0n1p9): has skinny extents
[  586.353413] BTRFS info (device nvme0n1p9): flagging fs with big metadata feature
[  586.368129] BTRFS info (device nvme0n1p9): enabling ssd optimizations
[  586.373996] BTRFS info (device nvme0n1p9): checking UUID tree
[  586.387449] BUG: kernel NULL pointer dereference, address: 0000000000000018
[  586.393485] #PF: supervisor read access in kernel mode
[  586.397623] #PF: error_code(0x0000) - not-present page
[  586.401763] PGD 0 P4D 0
[  586.403219] Oops: 0000 [#1] SMP PTI
[  586.405650] CPU: 1 PID: 6405 Comm: umount Not tainted 5.8.0-hubbard-github+ #171
[  586.412118] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./X99-UD3P-CF, BIOS F1 02/10/2015
[  586.421360] RIP: 0010:kobject_del+0x1/0x20
[  586.424427] Code: 48 c7 43 18 00 00 00 00 5b 5d c3 c3 be 01 00 00 00 48 89 df e8 60 1b 00 00 eb c9 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 <48> 8b 6f 18 e8 86 ff ff ff 48 89 ef 5d e9 cd fe ff ff 66 66 2e 0f
[  586.442644] RSP: 0018:ffffc90009ef7e08 EFLAGS: 00010246
[  586.446914] RAX: 0000000000000000 RBX: ffff888896080000 RCX: 0000000000000006
[  586.453149] RDX: ffff88888ee4b000 RSI: ffffffff82669a00 RDI: 0000000000000000
[  586.459390] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
[  586.465631] R10: 0000000000000001 R11: 0000000000000000 R12: ffff888896080000
[  586.471866] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  586.478106] FS:  00007f5595739c80(0000) GS:ffff88889fc40000(0000) knlGS:0000000000000000
[  586.485325] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  586.490129] CR2: 0000000000000018 CR3: 0000000896d5a006 CR4: 00000000001706e0
[  586.496372] Call Trace:
[  586.497807]  btrfs_sysfs_del_qgroups+0xa5/0xe0 [btrfs]
[  586.502017]  close_ctree+0x1c5/0x2b6 [btrfs]
[  586.505307]  ? fsnotify_destroy_marks+0x24/0x124
[  586.508948]  generic_shutdown_super+0x67/0x100
[  586.512408]  kill_anon_super+0x14/0x30
[  586.515159]  btrfs_kill_super+0x12/0x20 [btrfs]
[  586.518704]  deactivate_locked_super+0x36/0x90
[  586.522159]  cleanup_mnt+0x12d/0x190
[  586.524720]  task_work_run+0x5c/0xa0
[  586.527285]  exit_to_user_mode_loop+0xb9/0xc0
[  586.530648]  exit_to_user_mode_prepare+0xab/0xe0
[  586.534276]  syscall_exit_to_user_mode+0x17/0x50
[  586.537908]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  586.541984] RIP: 0033:0x7f55959896fb
[  586.544531] Code: 07 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 90 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5d 07 0c 00 f7 d8 64 89 01 48
[  586.562775] RSP: 002b:00007fffcc431228 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
[  586.569485] RAX: 0000000000000000 RBX: 00007f5595ab31e4 RCX: 00007f55959896fb
[  586.575753] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005601fb16bb80
[  586.582020] RBP: 00005601fb16b970 R08: 0000000000000000 R09: 00007fffcc42ffa0
[  586.588278] R10: 00005601fb16c930 R11: 0000000000000246 R12: 00005601fb16bb80
[  586.594534] R13: 0000000000000000 R14: 00005601fb16ba68 R15: 0000000000000000
[  586.600805] Modules linked in: xfs rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache bpfilter dm_mirror dm_region_hash dm_log dm_mod iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul btrfs ghash_clmulni_intel aesni_intel blake2b_generic crypto_simd xor cryptd zstd_compress glue_helper input_leds raid6_pq libcrc32c lpc_ich i2c_i801 mfd_core mei_me i2c_smbus mei rpcrdma sunrpc ib_isert iscsi_target_mod ib_iser libiscsi ib_srpt target_core_mod ib_srp ib_ipoib rdma_ucm ib_uverbs ib_umad sr_mod cdrom sd_mod nouveau ahci libahci nvme crc32c_intel video e1000e led_class nvme_core libata t10_pi ttm mxm_wmi wmi fuse
[  586.661098] CR2: 0000000000000018
[  586.663455] ---[ end trace 158f42d646f4715d ]---

A quick peek shows that this is crashing here:

void kobject_del(struct kobject *kobj)
{
     struct kobject *parent = kobj->parent; <---- CRASHES HERE with NULL kobj

     __kobject_del(kobj);
     kobject_put(parent);
}
EXPORT_SYMBOL(kobject_del);

The crash at 0x18 matches passes in a null, because that's the right offset for
->parent, and the disassembly confirms that 0x18 gets offset right at kobject_del+0x1:

Dump of assembler code for function kobject_del:
    0xffffffff81534ec0 <+0>:     push   %rbp
    0xffffffff81534ec1 <+1>:     mov    0x18(%rdi),%rbp
    0xffffffff81534ec5 <+5>:     callq  0xffffffff81534e50 <__kobject_del>
    0xffffffff81534eca <+10>:    mov    %rbp,%rdi
    0xffffffff81534ecd <+13>:    pop    %rbp
    0xffffffff81534ece <+14>:    jmpq   0xffffffff81534da0 <kobject_put>
End of assembler dump.

But as for how we ended up with a null kobj here, that's actually hard to see, at least
for a non-btrfs person, which is why I hoped git bisect would help more than it did here.


thanks,

thanks,
--
John Hubbard
NVIDIA




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux