| Message ID | 5ce3ee90-333e-638d-ac8c-cd6d7ab7aa3b@I-love.SAKURA.ne.jp (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | binder: Don't use mmput() from shrinker function. | expand |
On Thu 16-07-20 08:36:52, Tetsuo Handa wrote: > syzbot is reporting that mmput() from shrinker function has a risk of > deadlock [1]. Don't start synchronous teardown of mm when called from > shrinker function. Please add the actual lock dependency to the changelog. Anyway is this deadlock real? Mayve I have missed some details but the call graph points to these two paths. uprobe_mmap do_shrink_slab uprobes_mmap_hash #lock install_breakpoint binder_shrink_scan set_swbp binder_alloc_free_page uprobe_write_opcode __mmput update_ref_ctr uprobe_clear_state mutex_lock(&delayed_uprobe_lock) mutex_lock(&delayed_uprobe_lock); allocation -> reclaim But in order for this to happen the shrinker would have to do the last put on the mm. But mm cannot go away from under uprobe_mmap so those two paths cannot race with each other. Unless I am missing something this is a false positive. I do not mind using mmput_async from the shrinker as a workaround but the changelog should be explicit about the fact. > [1] https://syzkaller.appspot.com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45 > > Reported-by: syzbot <syzbot+1068f09c44d151250c33@syzkaller.appspotmail.com> > Reported-by: syzbot <syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com> > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > --- > drivers/android/binder_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c > index 42c672f1584e..cbe6aa77d50d 100644 > --- a/drivers/android/binder_alloc.c > +++ b/drivers/android/binder_alloc.c > @@ -947,7 +947,7 @@ enum lru_status binder_alloc_free_page(struct list_head *item, > trace_binder_unmap_user_end(alloc, index); > } > mmap_read_unlock(mm); > - mmput(mm); > + mmput_async(mm); > > trace_binder_unmap_kernel_start(alloc, index); > > -- > 2.18.4 >
On 2020/07/16 17:35, Michal Hocko wrote: > On Thu 16-07-20 08:36:52, Tetsuo Handa wrote: >> syzbot is reporting that mmput() from shrinker function has a risk of >> deadlock [1]. Don't start synchronous teardown of mm when called from >> shrinker function. > > Please add the actual lock dependency to the changelog. > > Anyway is this deadlock real? Mayve I have missed some details but the > call graph points to these two paths. > uprobe_mmap do_shrink_slab > uprobes_mmap_hash #lock > install_breakpoint binder_shrink_scan > set_swbp binder_alloc_free_page > uprobe_write_opcode __mmput > update_ref_ctr uprobe_clear_state > mutex_lock(&delayed_uprobe_lock) mutex_lock(&delayed_uprobe_lock); > allocation -> reclaim > static int update_ref_ctr(struct uprobe *uprobe, struct mm_struct *mm, short d) { mutex_lock(&delayed_uprobe_lock); ret = delayed_uprobe_add(uprobe, mm1) { du = kzalloc(sizeof(*du), GFP_KERNEL) { do_shrink_slab() { binder_shrink_scan() { binder_alloc_free_page() { mmget_not_zero(mm2); mmput(mm2) { __mmput(mm2) { uprobe_clear_state(mm2) { mutex_lock(&delayed_uprobe_lock); delayed_uprobe_remove(NULL, mm2); mutex_unlock(&delayed_uprobe_lock); } } } } } } } } mutex_unlock(&delayed_uprobe_lock); } > But in order for this to happen the shrinker would have to do the last > put on the mm. But mm cannot go away from under uprobe_mmap so those two > paths cannot race with each other. and mm1 != mm2 is possible, isn't it? > > Unless I am missing something this is a false positive. I do not mind > using mmput_async from the shrinker as a workaround but the changelog > should be explicit about the fact. > binder_alloc_free_page() is already using mmput_async() 14 lines later. It just took 18 months to hit this race for the third time, for it is quite difficult to let the owner of mm2 to call mmput(mm2) between binder_alloc_free_page() calls mmget_not_zero(mm2) and mmput(mm2). The reason I added you is to see whether we can do void mmput(struct mm_struct *mm) { might_sleep(); + /* Calling mmput() from shrinker context can deadlock. */ + WARN_ON(current->flags & PF_MEMALLOC); if (atomic_dec_and_test(&mm->mm_users)) __mmput(mm); } in order to catch this bug easier.
On Thu 16-07-20 22:41:14, Tetsuo Handa wrote: > On 2020/07/16 17:35, Michal Hocko wrote: [...] > > But in order for this to happen the shrinker would have to do the last > > put on the mm. But mm cannot go away from under uprobe_mmap so those two > > paths cannot race with each other. > > and mm1 != mm2 is possible, isn't it? OK, I have missed that information. You are right. Can you make this into the changelog please?
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 42c672f1584e..cbe6aa77d50d 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -947,7 +947,7 @@ enum lru_status binder_alloc_free_page(struct list_head *item, trace_binder_unmap_user_end(alloc, index); } mmap_read_unlock(mm); - mmput(mm); + mmput_async(mm); trace_binder_unmap_kernel_start(alloc, index);
syzbot is reporting that mmput() from shrinker function has a risk of deadlock [1]. Don't start synchronous teardown of mm when called from shrinker function. [1] https://syzkaller.appspot.com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45 Reported-by: syzbot <syzbot+1068f09c44d151250c33@syzkaller.appspotmail.com> Reported-by: syzbot <syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)