Re: Reminder: 22 open syzbot bugs in perf subsystem

[Ravi Bangoria <ravi.bangoria@linux.ibm.com>]

On 7/3/19 9:49 AM, Eric Biggers wrote:
> On Wed, Jul 03, 2019 at 09:29:39AM +0530, Ravi Bangoria wrote:
>> 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/00000000000010a9fb057cd14174@google.com/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: syzbot+1068f09c44d151250c33@syzkaller.appspotmail.com
>>>>>
>>>>> 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/00000000000010a9fb057cd14174@google.com
>>>>>
>>>>
>>>> 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() ?
>> """
>>
> 
> Even if it's a lockdep false positive you can't ignore it.  People rely on
> lockdep to find bugs, and they will keep sending you bug reports.  So someone
> has to fix something.

Agreed.

> Did you see Oleg's suggestion to change mmput() to
> mmput_async() in binder_alloc_free_page()?
> https://marc.info/?l=linux-kernel&m=155119805728815&w=2
> If you believe that is the right fix,

Yes, fixing it in binderfs looks right to me.

> I can reassign this report to binder
> subsystem and nag the binder maintainers instead...

Yes please :)