lkml.org 
[lkml]   [2019]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Reminder: 22 open syzbot bugs in perf subsystem
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. 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, I can reassign this report to binder
subsystem and nag the binder maintainers instead...

- Eric

\
 
 \ /
  Last update: 2019-07-03 06:20    [W:0.045 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site