lkml.org 
[lkml]   [2020]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] mm: Two small fixes for recent syzbot reports
    On Thu, 9 Apr 2020 15:00:20 +0200 Dmitry Vyukov <dvyukov@google.com> wrote:

    > On Thu, Apr 9, 2020 at 1:49 PM Matthew Wilcox <willy@infradead.org> wrote:
    > >
    > > On Wed, Apr 08, 2020 at 05:47:32PM -0700, Andrew Morton wrote:
    > > > On Tue, 7 Apr 2020 21:40:08 -0400 Peter Xu <peterx@redhat.com> wrote:
    > > >
    > > > > The two patches should fix below syzbot reports:
    > > > >
    > > > > BUG: unable to handle kernel paging request in kernel_get_mempolicy
    > > > > https://lore.kernel.org/lkml/0000000000002b25f105a2a3434d@google.com/
    > > > >
    > > > > WARNING: bad unlock balance in __get_user_pages_remote
    > > > > https://lore.kernel.org/lkml/00000000000005c65d05a2b90e70@google.com/
    > > >
    > > > (Is there an email address for the syzbot operators?)
    > >
    > > I'd suggest syzkaller-bugs@googlegroups.com (added to the Cc).
    >
    > syzkaller@googlegroups.com is a better one.
    > syzkaller-bugs@googlegroups.com plays more of an LKML role.
    >
    > > But there's a deeper problem in that we don't have anywhere to stash
    > > that kind of information in the kernel tree right now. Perhaps a special
    > > entry in the MAINTAINERS file for bot operators? Or one entry per bot?
    >
    > I don't mind adding syzkaller. Some time ago I wanted to contact
    > KernelCI, CKI, LKFT, 0-day owners, finding relevant lists wasn't
    > impossible, but for some it was hard.
    >
    > For syzkaller it would be:
    >
    > https://github.com/google/syzkaller/issues for bugs/feature requests.
    > syzkaller@googlegroups.com for discussions.

    OK, thanks. A MAINTAINERS entry would be great.

    Could I please direct attention back to my original question regarding
    the problems we've recently discovered in 4426e945df58 ("mm/gup: allow
    VM_FAULT_RETRY for multiple times") and 71335f37c5e8 ("mm/gup: allow to
    react to fatal signals")?

    > sysbot does test linux-next, yet these patches sat in linux-next for a
    > month without a peep, but all hell broke loose when they hit Linus's
    > tree. How could this have happened?
    >
    > Possibly I've been carrying a later patch which fixed all this up, but
    > I'm not seeing anything like that. Nothing at all against mm/gup.c.

    \
     
     \ /
      Last update: 2020-04-09 20:16    [W:2.229 / U:0.644 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site