On 09/15, Al Viro wrote: > 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? It's ext4, and we use umount(0) and retry it several times if -EBUSY happens. But, I don't see -EBUSY error in the log. > In other words, where has that fput() come from and how had it managed > to get past the umount(2)? Huge number of fput() were called by system drivers when init kills all the processes before umount(2). So, most of fput() were added in delayed_fput_list. Then, it seems there is a race between delayed_fput() and umount(). Anyway, even after umount returns zero, it seems ext4's superblock is still alive and waiting for delayed_fput() which will finally call put_super.
