On Thu, 9 Apr 2020 15:00:20 +0200 Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > On Thu, Apr 9, 2020 at 1:49 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx/ > > > > > > > > WARNING: bad unlock balance in __get_user_pages_remote > > > > https://lore.kernel.org/lkml/00000000000005c65d05a2b90e70@xxxxxxxxxx/ > > > > > > (Is there an email address for the syzbot operators?) > > > > I'd suggest syzkaller-bugs@xxxxxxxxxxxxxxxx (added to the Cc). > > syzkaller@xxxxxxxxxxxxxxxx is a better one. > syzkaller-bugs@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxx 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.
