Re: [PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Todd Kjos
On Thu, Jul 16, 2020 at 8:18 AM Michal Hocko wrote: > > On Fri 17-07-20 00:12:15, Tetsuo Handa wrote: > > syzbot is reporting that mmput() from shrinker function has a risk of > > deadlock [1], for delayed_uprobe_add() from update_ref_ctr() calls > > kzalloc(GFP_KERNEL) with delayed_uprobe_lock he

Re: [PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Tetsuo Handa
On 2020/07/17 1:29, Christian Brauner wrote: > Does this need a Cc: stable? Up to someone who applies this patch. I think this race is hard to hit.

Re: [PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Christian Brauner
On Thu, Jul 16, 2020 at 05:17:56PM +0200, Michal Hocko wrote: > On Fri 17-07-20 00:12:15, Tetsuo Handa wrote: > > syzbot is reporting that mmput() from shrinker function has a risk of > > deadlock [1], for delayed_uprobe_add() from update_ref_ctr() calls > > kzalloc(GFP_KERNEL) with delayed_uprobe_

Re: [PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Michal Hocko
On Fri 17-07-20 00:12:15, Tetsuo Handa wrote: > syzbot is reporting that mmput() from shrinker function has a risk of > deadlock [1], for delayed_uprobe_add() from update_ref_ctr() calls > kzalloc(GFP_KERNEL) with delayed_uprobe_lock held, and > uprobe_clear_state() from __mmput() also holds delaye