Bug 200981

Created attachment 278205 [details]
config

On Thu, Aug 30, 2018 at 02:32:35PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=200981
> 
> kernel: vanilla 4.18.5
> gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> More or less reproducible for me using next sequence:
> 
> - on host:
>   create LV of appropriate size (20g in my case)
>   mkfs.xfs -m reflink=1 /dev/data/LV
>   mount /dev/data/LV /mnt/
>   run kvm VM with qcow2 image (/mnt/disk)    
> 
> - inside vm:
>   sysbench --test=fileio --file-total-size=9G prepare
> 
> - on host:
>   cp --reflink=always disk disk.b
> 
> - inside vm: 
>   sysbench --test=fileio --file-total-size=9G --file-test-mode=seqwr
> --max-time=6000 --max-requests=0 --threads=16 run
> 
> Some time after i/o on /dev/data/LV fall to zero and fs become completely
> unavailable and then I see a bunch of records:

The first error is this:

[ 2212.046108] ================================================
[ 2212.051809] WARNING: lock held when returning to user space!
[ 2212.057511] 4.18.5 #1 Not tainted
[ 2212.060864] ------------------------------------------------
[ 2212.066564] worker/6123 is leaving the kernel with locks still held!
[ 2212.072961] 1 lock held by worker/6123:
[ 2212.076835]  #0: 000000009eab4f1b (sb_internal#2){.+.+}, at: xfs_trans_alloc+0x17c/0x220

Which happens 5 minutes before the hung processes start being
reported. Looks like something has gone wrong and an error path has
leaked a transaction.

Can you see if commit dcbd44f79986 ("xfs: fix transaction leak on
remote attr set/remove failure") addresses the problem you are
seeing?

-Dave.

> Can you see if commit dcbd44f79986 ("xfs: fix transaction leak on
remote attr set/remove failure") addresses the problem you are
seeing?

I've just tried but see no difference.
Warning still here and vm become blocked some time after.
( It worth noting I've CONFIG_LOCKDEP turned on )

Ok, so the obvious fix doesn't help.

Any idea why lockdep is not giving you the full stack trace of where the lock that was leaked to userspace was first accessed? Without that, we have no idea which of the 70-odd calls to xfs_trans_alloc() in the XFS code the lockdep warning refers to. At minimum, we need to know what syscall is triggering the warning so we know what code to look at.

Also, can you reproduce this on older kernels? If not, could you bisect it?

-Dave.

Created attachment 278345 [details]
dmesg showing all locks held in the system

Created attachment 278347 [details]
missing sb_end_intwrite: proof of concept

Ok, it looks like a warning is a result of missing sb_end_intwrite in
xfs_reflink_allocate_cow, namely in a sequence xfs_trans_alloc -> goto retry -> goto convert. With proof-of-concept patch (attached) warning is gone but deadlock is not. Though now I have a list of held locks (dmesg attached).
Did you mean taintad kernel  will not show locks held?

(In reply to Alexander Y.  Fomichev from comment #7)
> Ok, it looks like a warning is a result of missing y in
> xfs_reflink_allocate_cow, namely in a sequence xfs_trans_alloc -> goto retry
> -> goto convert.

Yup, I see the issue. Nice work finding this!

> With proof-of-concept patch (attached) warning is gone but
> deadlock is not.

The code is not missing a sb_end_intwrite() call - it's missing a xfs_trans_cancel() call. That's why it still deadlocks even though you shut up the warning. I'll have a closer look in the morning to see if there's any other paths that can leak the transaction and write a patch to fix it.

Thanks again for tracking it down, Alexander :)

Cheers,

Dave.

I confirm. With xfs_trans_cancel() lock is gone and works like a charm. Thanks.