Re: [refcount] 26d2e0d5df: WARNING:at_lib/refcount.c:#refcount_warn_saturate

From: Joseph Qi
Date: Sun Sep 15 2019 - 22:39:10 EST




On 19/9/12 18:56, Will Deacon wrote:
> [Adding the ocfs2 maintainers and mailing list]
>
> On Mon, Sep 09, 2019 at 09:52:26AM +0800, kernel test robot wrote:
>> FYI, we noticed the following commit (built with gcc-7):
>>
>> commit: 26d2e0d5df5b9aab517d8327743e66fcb38e8136 ("refcount: Consolidate implementations of refcount_t")
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/will/linux.git refcount/full
>
> This branch effectively enables REFCOUNT_FULL by default, so I think the
> issue being flagged is a latent use-after-free in ocfs2, rather than a bug
> in the refcount implementation.
>
>> in testcase: ocfs2test
>> with following parameters:
>>
>> disk: 1SSD
>> test: test-mkfs
>>
>>
>>
>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
>
> [...]
>
>> If you fix the issue, kindly add following tag
>> Reported-by: kernel test robot <rong.a.chen@xxxxxxxxx>
>>
>>
>> [ 72.121725] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1499
>> [ 72.126078] in_atomic(): 1, irqs_disabled(): 0, pid: 2466, name: mount.ocfs2
>> [ 72.128523] CPU: 1 PID: 2466 Comm: mount.ocfs2 Not tainted 5.3.0-rc3-00008-g26d2e0d5df5b9 #1
>> [ 72.130522] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
>> [ 72.132522] Call Trace:
>> [ 72.134024] dump_stack+0x5c/0x7b
>> [ 72.135106] ___might_sleep+0xf1/0x110
>> [ 72.136280] down_write+0x1c/0x50
>> [ 72.137349] configfs_depend_item+0x3a/0xb0
>> [ 72.138597] o2hb_region_pin+0xf9/0x180 [ocfs2_nodemanager]
>
> This looks dodgy because o2hb_region_pin() asserts that the 'o2hb_live_lock'
> is held, but then configfs_depend_item() calls inode_lock(), which can
> sleep on the semaphore.
>

Yes, the warning exactly blames this.
But this code lives here for a long time. I'm not sure why no blames
before.


>> [ 72.140103] ? inode_init_always+0x120/0x1d0
>> [ 72.141368] o2hb_register_callback+0xc6/0x2a0 [ocfs2_nodemanager]
>> [ 72.143016] dlm_join_domain+0xbd/0x7a0 [ocfs2_dlm]
>> [ 72.144441] ? dlm_alloc_ctxt+0x50a/0x580 [ocfs2_dlm]
>> [ 72.145880] dlm_register_domain+0x31f/0x440 [ocfs2_dlm]
>> [ 72.147395] ? enqueue_entity+0x109/0x6c0
>> [ 72.148658] ? _cond_resched+0x19/0x30
>> [ 72.149870] o2cb_cluster_connect+0x132/0x2c0 [ocfs2_stack_o2cb]
>> [ 72.151524] ocfs2_cluster_connect+0x14b/0x220 [ocfs2_stackglue]
>> [ 72.153237] ocfs2_dlm_init+0x2f1/0x4b0 [ocfs2]
>> [ 72.154647] ? ocfs2_init_node_maps+0x50/0x50 [ocfs2]
>> [ 72.156167] ocfs2_fill_super+0xcfc/0x12b0 [ocfs2]
>> [ 72.157640] ? ocfs2_initialize_super+0x1030/0x1030 [ocfs2]
>> [ 72.159395] mount_bdev+0x173/0x1b0
>> [ 72.160627] legacy_get_tree+0x27/0x40
>> [ 72.161900] vfs_get_tree+0x25/0xf0
>> [ 72.163138] do_mount+0x691/0x9c0
>> [ 72.164343] ksys_mount+0x80/0xd0
>> [ 72.165536] __x64_sys_mount+0x21/0x30
>> [ 72.166828] do_syscall_64+0x5b/0x1f0
>> [ 72.168124] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 72.169649] RIP: 0033:0x7f9aec59148a
>> [ 72.170904] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d de f9 2a 00 f7 d8 64 89 01 48
>> [ 72.175696] RSP: 002b:00007ffc97973af8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
>> [ 72.177764] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9aec59148a
>> [ 72.179756] RDX: 00005630f7e3b3ee RSI: 00005630f988a0b0 RDI: 00005630f988a310
>> [ 72.181768] RBP: 00007ffc97973ca0 R08: 00005630f988a2b0 R09: 0000000000000020
>> [ 72.183776] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffc97973b90
>> [ 72.185795] R13: 0000000000000000 R14: 00005630f988b000 R15: 00007ffc97973b10
>> [ 72.193593] o2dlm: Joining domain 87608FBB69A6455A927DB6EE644FA256
>> [ 72.193593] (
>> [ 72.195534] 1
>> [ 72.196744] ) 1 nodes
>> [ 72.201889] JBD2: Ignoring recovery information on journal
>> [ 72.211850] ocfs2: Mounting device (8,0) on (node 1, slot 0) with ordered data mode.
>> [ 72.261789] mount /dev/sda /mnt/ocfs2 /dev/sda 16515072 243712 16271360 2% /mnt/ocfs2
>> [ 72.261792]
>> [ 72.268799] OK
>> [ 72.268801]
>> [ 72.273936] create testdir /mnt/ocfs2/20190907_114755
>> [ 72.273938]
>> [ 72.286732] create 15890 files .
>> [ 72.286734]
>> [ 72.290339]
>> [ 76.331476] o2dlm: Leaving domain 87608FBB69A6455A927DB6EE644FA256
>> [ 76.402235] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
>> [ 76.406909] floppy: error 10 while reading block 0
>> [ 78.260271] ocfs2: Unmounting device (8,0) on (node 1)
>> [ 78.264188] ------------[ cut here ]------------
>> [ 78.267624] refcount_t: underflow; use-after-free.
>
> Here's the use-after-free, but I couldn't follow 'ocfs2_dismount_volume()'
> enough to figure out where the refcount_t actually lives.
>
> I've preserved the rest of the log below, in the hope that somebody more
> familiar with ocfs2 can take a look. The original report, including the
> .config, is here:
>
> 20190909015226.GM15734@shao2-debian">http://lkml.kernel.org/r/20190909015226.GM15734@shao2-debian
>
>From the dmesg, it has almost finished umount.
And the following step is to clean up ocfs2 super. I also don't
figure out how refcount_t related use-after-free during the flow
of ocfs2_dismount_volume().

Thanks,
Joseph