search for: putmnt

...ace 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. Thanks, Joseph > >> >> On 2/24/23 8:32 AM, Heming Zhao wrote: >>> Hello List, >>> >>> I found a weird bug on ocfs2. I am busying with other jobs, if anyone have time >>> he/she could fix it. This bug is blocking fstest ge...

...'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. Thanks, Heming > >> >>&gt...

...t; ??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...

...t;, 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 o...

...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 is...

...t;%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 c...

...gt;>>>>>> >>>>>>> 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 ther...

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,