Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-19 Thread Jaegeuk Kim
On 09/16, Al Viro wrote: > On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > > > The mntput() in delayed_fput() is the last function call. So before that > > moment, > > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. > > I'm not > > sure why it check over

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-19 Thread Jaegeuk Kim
On 09/16, Al Viro wrote: > On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > > > The mntput() in delayed_fput() is the last function call. So before that > > moment, > > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. > > I'm not > > sure why it check over

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-16 Thread Amir Goldstein
On Sat, Sep 16, 2017 at 1:12 AM, Theodore Ts'o wrote: > On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote: >> >> So, I digged it in more detail, and found, in drivers/android/binder.c [1], >> - binder_ioctl() >> - create a kernel thread >> - zombie_cleanup_check() >>

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-16 Thread Amir Goldstein
On Sat, Sep 16, 2017 at 1:12 AM, Theodore Ts'o wrote: > On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote: >> >> So, I digged it in more detail, and found, in drivers/android/binder.c [1], >> - binder_ioctl() >> - create a kernel thread >> - zombie_cleanup_check() >> -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Al Viro
On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > The mntput() in delayed_fput() is the last function call. So before that > moment, > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. I'm > not > sure why it check over 2 tho. Because it has just grabbed a

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Al Viro
On Fri, Sep 15, 2017 at 04:29:11PM -0700, Jaegeuk Kim wrote: > The mntput() in delayed_fput() is the last function call. So before that > moment, > sys_umount() may see mnt_get_count() as 2, so it avoids EBUSY condition. I'm > not > sure why it check over 2 tho. Because it has just grabbed a

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Jaegeuk Kim
On 09/15, Theodore Ts'o wrote: > On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote: > > > > So, I digged it in more detail, and found, in drivers/android/binder.c [1], > > - binder_ioctl() > > - create a kernel thread > > - zombie_cleanup_check() > > - binder_defer_work() > > -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Jaegeuk Kim
On 09/15, Theodore Ts'o wrote: > On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote: > > > > So, I digged it in more detail, and found, in drivers/android/binder.c [1], > > - binder_ioctl() > > - create a kernel thread > > - zombie_cleanup_check() > > - binder_defer_work() > > -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Theodore Ts'o
On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote: > > So, I digged it in more detail, and found, in drivers/android/binder.c [1], > - binder_ioctl() > - create a kernel thread > - zombie_cleanup_check() > - binder_defer_work() > - queue_work(..., _deferred_work); > > -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Theodore Ts'o
On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote: > > So, I digged it in more detail, and found, in drivers/android/binder.c [1], > - binder_ioctl() > - create a kernel thread > - zombie_cleanup_check() > - binder_defer_work() > - queue_work(..., _deferred_work); > > -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Jaegeuk Kim
On 09/15, Al Viro wrote: > On Thu, Sep 14, 2017 at 08:45:18PM -0700, Jaegeuk Kim wrote: > > > > 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

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-15 Thread Jaegeuk Kim
On 09/15, Al Viro wrote: > On Thu, Sep 14, 2017 at 08:45:18PM -0700, Jaegeuk Kim wrote: > > > > 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

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Al Viro
On Thu, Sep 14, 2017 at 08:45:18PM -0700, Jaegeuk Kim wrote: > > 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...

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Al Viro
On Thu, Sep 14, 2017 at 08:45:18PM -0700, Jaegeuk Kim wrote: > > 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...

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Jaegeuk Kim
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 > > -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Jaegeuk Kim
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 > > -

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Al Viro
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()-

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Al Viro
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()-

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Jaegeuk Kim
On 09/14, Jaegeuk Kim wrote: > On 09/14, Al Viro wrote: > > On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > > > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > > > > > Android triggers umount(2) by init process, which is definitely not a > > > > kernel > > > >

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Jaegeuk Kim
On 09/14, Jaegeuk Kim wrote: > On 09/14, Al Viro wrote: > > On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > > > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > > > > > Android triggers umount(2) by init process, which is definitely not a > > > > kernel > > > >

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Jaegeuk Kim
On 09/14, Al Viro wrote: > On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > > > Android triggers umount(2) by init process, which is definitely not a > > > kernel > > > thread. But, we've seen some kernel panics which

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Jaegeuk Kim
On 09/14, Al Viro wrote: > On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > > > Android triggers umount(2) by init process, which is definitely not a > > > kernel > > > thread. But, we've seen some kernel panics which

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Al Viro
On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > Android triggers umount(2) by init process, which is definitely not a kernel > > thread. But, we've seen some kernel panics which say umount(2) was > > succeeded, > > but

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-14 Thread Al Viro
On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > Android triggers umount(2) by init process, which is definitely not a kernel > > thread. But, we've seen some kernel panics which say umount(2) was > > succeeded, > > but

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Al Viro
On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > Android triggers umount(2) by init process, which is definitely not a kernel > thread. But, we've seen some kernel panics which say umount(2) was succeeded, > but ext4 triggered a kernel panic due to EIO after then like below. I'm

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Al Viro
On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > Android triggers umount(2) by init process, which is definitely not a kernel > thread. But, we've seen some kernel panics which say umount(2) was succeeded, > but ext4 triggered a kernel panic due to EIO after then like below. I'm

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Jaegeuk Kim
On 09/14, Al Viro wrote: > On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote: > > Hi Al, > > > > On 09/14, Al Viro wrote: > > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > > > + if (!retval && (flags & UMOUNT_WAIT)) { > > > > + if

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Jaegeuk Kim
On 09/14, Al Viro wrote: > On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote: > > Hi Al, > > > > On 09/14, Al Viro wrote: > > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > > > + if (!retval && (flags & UMOUNT_WAIT)) { > > > > + if

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Al Viro
On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote: > Hi Al, > > On 09/14, Al Viro wrote: > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > > + if (!retval && (flags & UMOUNT_WAIT)) { > > > + if (likely(!(current->flags & PF_KTHREAD))) > > > +

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Al Viro
On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote: > Hi Al, > > On 09/14, Al Viro wrote: > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > > + if (!retval && (flags & UMOUNT_WAIT)) { > > > + if (likely(!(current->flags & PF_KTHREAD))) > > > +

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Jaegeuk Kim
Hi Al, On 09/14, Al Viro wrote: > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > + if (!retval && (flags & UMOUNT_WAIT)) { > > + if (likely(!(current->flags & PF_KTHREAD))) > > + task_work_run(); > > This is complete crap. The same damn thing will

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Jaegeuk Kim
Hi Al, On 09/14, Al Viro wrote: > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > > + if (!retval && (flags & UMOUNT_WAIT)) { > > + if (likely(!(current->flags & PF_KTHREAD))) > > + task_work_run(); > > This is complete crap. The same damn thing will

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Al Viro
On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > + if (!retval && (flags & UMOUNT_WAIT)) { > + if (likely(!(current->flags & PF_KTHREAD))) > + task_work_run(); This is complete crap. The same damn thing will be done by caller of sys_umount()

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Al Viro
On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote: > + if (!retval && (flags & UMOUNT_WAIT)) { > + if (likely(!(current->flags & PF_KTHREAD))) > + task_work_run(); This is complete crap. The same damn thing will be done by caller of sys_umount()

[PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Jaegeuk Kim
This patch introduces UMOUNT_WAIT flag for umount(2) which let user wait for its completion. This would fix a kernel panic caused by block device access by filesystem, after device_shutdown during kernel_restart. This can happen due to delayed umount -- reboot process already succeeded to unmount

[PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

2017-09-13 Thread Jaegeuk Kim
This patch introduces UMOUNT_WAIT flag for umount(2) which let user wait for its completion. This would fix a kernel panic caused by block device access by filesystem, after device_shutdown during kernel_restart. This can happen due to delayed umount -- reboot process already succeeded to unmount