Hi Eric, On 7/3/19 9:25 AM, Eric Biggers wrote: > On Wed, Jul 03, 2019 at 09:09:55AM +0530, Ravi Bangoria wrote: >> >> >> On 7/2/19 11:13 AM, Eric Biggers wrote: >>> -------------------------------------------------------------------------------- >>> Title: possible deadlock in uprobe_clear_state >>> Last occurred: 164 days ago >>> Reported: 201 days ago >>> Branches: Mainline >>> Dashboard link: >>> https://syzkaller.appspot.com/bug?id=a1ce9b3da349209c5085bb8c4fee753d68c3697f >>> Original thread: >>> https://lkml.kernel.org/lkml/[email protected]/T/#u >>> >>> Unfortunately, this bug does not have a reproducer. >>> >>> No one replied to the original thread for this bug. >>> >>> If you fix this bug, please add the following tag to the commit: >>> Reported-by: [email protected] >>> >>> If you send any email or patch for this bug, please consider replying to the >>> original thread. For the git send-email command to use, or tips on how to >>> reply >>> if the thread isn't in your mailbox, see the "Reply instructions" at >>> https://lkml.kernel.org/r/[email protected] >>> >> >> This is false positive: >> https://marc.info/?l=linux-kernel&m=154925313012615&w=2 >> > > What do you mean "false positive"? Your patch says there can be a deadlock. > Also, your patch hasn't been merged yet. So doesn't it still need to be > fixed?
Please see Oleg's reply to the patch: https://marc.info/?l=linux-kernel&m=154946017315554&w=2 """ But this is false positive, right? if CPU1 calls update_ref_ctr() then either ->mm_users is already zero so binder_alloc_free_page()->mmget_not_zero() will fail, or the caller of update_ref_ctr() has a reference and thus binder_alloc_free_page()->mmput() can't trigger __mmput() ? """
