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
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
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()
>>
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()
>> -
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
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
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()
> > -
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()
> > -
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);
>
> -
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);
>
> -
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
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
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...
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...
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
> > -
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
> > -
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()-
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()-
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
> > > >
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
> > > >
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
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
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
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
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
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
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
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
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)))
> > > +
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)))
> > > +
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
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
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()
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()
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
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
36 matches
Mail list logo