[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7dd388d6-628d-23aa-0a97-84e7e0800b74@linux.ibm.com>
Date: Wed, 3 Jul 2019 10:06:04 +0530
From: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Song Liu <songliubraving@...com>,
Kan Liang <kan.liang@...ux.intel.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
syzkaller-bugs@...glegroups.com, Oleg Nesterov <oleg@...hat.com>,
Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
Subject: Re: Reminder: 22 open syzbot bugs in perf subsystem
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@...kaller.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 :)
Powered by blists - more mailing lists