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. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listin

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

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

2020-07-16 Thread Tetsuo Handa
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 delayed_uprobe_lock. Commit a1b2289cef92ef0e ("android: bin