Re: [PATCH 1/4] exit: Move read_unlock() up in mm_update_next_owner()

2018-04-26 Thread Oleg Nesterov
On 04/26, Kirill Tkhai wrote: > > @@ -464,18 +464,15 @@ void mm_update_next_owner(struct mm_struct *mm) > return; > > assign_new_owner: > - BUG_ON(c == p); > get_task_struct(c); > + read_unlock(_lock); > + BUG_ON(c == p); > + > /* >* The task_lock protects

Re: [PATCH 1/4] exit: Move read_unlock() up in mm_update_next_owner()

2018-04-26 Thread Oleg Nesterov
On 04/26, Kirill Tkhai wrote: > > @@ -464,18 +464,15 @@ void mm_update_next_owner(struct mm_struct *mm) > return; > > assign_new_owner: > - BUG_ON(c == p); > get_task_struct(c); > + read_unlock(_lock); > + BUG_ON(c == p); > + > /* >* The task_lock protects

[PATCH 1/4] exit: Move read_unlock() up in mm_update_next_owner()

2018-04-26 Thread Kirill Tkhai
All the places, we update task's mm, are made this under task_lock(). These are exec_mmap(), exit_mm() and kernel thread's use_mm() and unuse_mm(). The only exception is copy_mm(), which initializes newborn task's mm, but we can't race with it, as mm_update_next_owner() iterates tasks already

[PATCH 1/4] exit: Move read_unlock() up in mm_update_next_owner()

2018-04-26 Thread Kirill Tkhai
All the places, we update task's mm, are made this under task_lock(). These are exec_mmap(), exit_mm() and kernel thread's use_mm() and unuse_mm(). The only exception is copy_mm(), which initializes newborn task's mm, but we can't race with it, as mm_update_next_owner() iterates tasks already