lkml.org 
[lkml]   [2017]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion
On Thu, Sep 14, 2017 at 05:19:39PM -0700, Jaegeuk Kim wrote:
> Instead, I put more traces in the reboot procedure, and got a clue to suspect
> the below flow.
>
> delayed_fput() init
> - umount
> - mntput()
> - mntput_no_expire() - mntput_no_expire()
> - mnt_add_count(-1);
> - mnt_get_count() return;
> - return 0;
> - mnt_add_count(-1);
> - delayed_mntput_work
> - device_shutdown
> - ext4_put_super()
> - EIO
>
> Does this make any sense?

Which filesystem it is? With root I would've expected remount ro done
by sys_umount(); with anything else... How has it managed to avoid
-EBUSY? If it was umount -l (IOW, MNT_DETACH), I can see that happening,
but... How would flushing prevent the scenario when the same opened
file had remained open until after the umount(2) return?

In other words, where has that fput() come from and how had it managed
to get past the umount(2)?

\
 
 \ /
  Last update: 2017-09-15 04:07    [W:0.088 / U:1.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site