Re: Reminder: 22 open syzbot bugs in perf subsystem

From: Ravi Bangoria
Date: Wed Jul 03 2019 - 00:36:28 EST




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@xxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>
>>>>> 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@xxxxxxxxxx
>>>>>
>>>>
>>>> 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 :)