filesystem: Details of mount_ref_count in struct mount

[Pravin Shedage]

On Wed, Apr 20, 2016 at 6:24 PM, manty kuma <mantykuma at gmail.com> wrote:

> Hi,
>
> I am looking into an issue where unmounting /data is failing.
> I receive -EBUSY as the sum off all mnt_count(mnt->mnt_pcp->mnt_count) of
> all cpu's > 2 (the value in my case is 3).
>
> I am debugging from linux crash dump.
> Is there any way that I can know the owners/responsible drivers that have
> incereased this refcount and left it like that without decrementing?
>
>
> Kindly share any helpful information. Thank you.
>
> Best Regards,
> Manty
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


Hi Manty,


UMOUNT returns -EBUSY in many cases.
Following points you may consider to debug your issue:

1. Check any file is open or mount point is in used by
     1. lsof | grep <mount_path>
     2. fuser -m <mount_path>
     3. you cd into mount path directory
2. If there are no files open or mount point is not actually busy then
   - Track the dentry count & mount counts
     - fget, dget, mntget and fput, dput, mntput verify any leakage
happened.
     You have to add printk statements in all such locations and whether
they really increment or decrement dentry or mnt counts.
3. Please provide the more details,
   - Are you using automount or normal mount ?
   - Which operation you perform inside mount and the steps to reproduce
the problem.
4. I recently worked on similar problem that automount give EBUSY error on
umount and
   the the root cause I found is : Implementation of fput changes from
3.6.x kernel.
   They added deffered working and perform fput operation asynchronously.
   which causes immediate umount fails on automount.

Hope so this will help you to debug your problem.


Thanks & Regards,
   PraviN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160421/c2d0df3e/attachment.html