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)?
