[Ocfs2-devel] report BUG: io_uring triggers umount error

[Joseph Qi]

On 2/24/23 4:03 PM, Heming Zhao wrote:
> On 2/24/23 3:52 PM, Joseph Qi wrote:
>>
>>
>> On 2/24/23 3:48 PM, Heming Zhao via Ocfs2-devel wrote:
>>> On 2/24/23 2:54 PM, Joseph Qi wrote:
>>>> I can reproduce this in my local VM.
>>>> I've traced ocfs2_dismount_volume and found that it hasn't been called.
>>>> So EBUSY is returned in VFS layer. I guess something wrong when doing
>>>> a copy with linked SQEs (normal copy seems no problem).
>>>>
>>>
>>> I am inclined to agree with you. I also test liburing examples apps
>>> on ext4 partition, everything looks fine.
>>>
>>> I used below bpftrace method, the retval is '3'.
>>>   bpftrace -e 'kr:mnt_get_count{printf("%d\n", retval);}'
>>>
>>> It responds to flow: path_umount() => do_umount => mnt_get_count (gets '3')
>>>
>> Yes, that's the place return EBUSY.
>> So the problem seems to be getmnt/putmnt not match in this case.
>>
> 
> I didn't familiar with setting up kernel bi-search env. I used one last year
> openSUSE tumblweed (with kernel 5.16.2), this umount issue doesn't exist.
> So there is a possibility one ocfs2 commit introduced this issue.
>You can checkout each mailine version like Linux 6.0, 6.1, ... and try
to check if it can be reproduced.

I've tried trace mntget/mntput using the following bpftrace script,
link-cp output shows it misses a fput.

#include <linux/mount.h>
#include <linux/string.h>

kprobe:mntget
{
	$n = ((struct vfsmount *)arg0)->mnt_sb->s_type->name;

	if (!strncmp(str($n), "ocfs2", 5)) {
		@[comm] += 1;

		printf("%s", kstack);
	}
}

kprobe:mntput
{
	$n = ((struct vfsmount *)arg0)->mnt_sb->s_type->name;

	if (!strncmp(str($n), "ocfs2", 5)) {
		@[comm] +=1;

		printf("%s", kstack);
	}
}

Joseph