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()
> > - queue_work(..., &binder_deferred_work);
> >
> > - binder_deferred_func()
> > - binder_clear_zombies()
> > - binder_proc_clear_zombies()
> > - put_files_struct()
> > - close_files()
> > - filp_close()
> > - fput()
> >
> > It seems binder holds some proc files.
>
> If binder was holding some files open, then umount should have failed
> with EBUSY, no?
Based on what I've got some traces so far,
- binder_ioctl
- create a kernel thread
- zombie_cleanup_check
- binder_defer_work
- queue_work(..., &binder_deferred_work);
- binder_deferred_func
- binder_clear_zombies
- binder_proc_clear_zombies
- put_files_struct
- close_files
- filp_close
- fput
- delayed_fput
...
- file_free
- dput
init
- umount
- mntput
- mntput_no_expire
- do_umount
- mnt_get_count() > 2
- mntput_no_expire
- mnt_add_count(-1);
- mnt_add_count(-1);
- mnt_get_count() return;
- return 0;
- delayed_mntput_work
- device_shutdown
- ext4_put_super()
- EIO, and panic if error=panic
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.
>
> Does Android use mount namespaces at all?
>
> - Ted
