On Tue, 2018-04-17 at 17:33 -0400, J. Bruce Fields wrote: > On Mon, Apr 16, 2018 at 09:02:01PM -0700, syzbot wrote: > > syzbot hit the following crash on bpf-next commit > > 5d1365940a68dd57b031b6e3c07d7d451cd69daf (Thu Apr 12 18:09:05 2018 > > +0000) > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > > syzbot dashboard link: > > https://syzkaller.appspot.com/bug?extid=4b98281f2401ab849f4b > > > > So far this crash happened 2 times on bpf-next. > > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6433835633 > > 868800 > > syzkaller reproducer: > > https://syzkaller.appspot.com/x/repro.syz?id=6407311794896896 > > Raw console output: > > https://syzkaller.appspot.com/x/log.txt?id=5861511176126464 > > Based on that, looks like it's attempting an nfs mount while causing > kmalloc failures? > > Probably one of rpcb->r_netid, r_addr, or r_owner was bad in > rpcb_enc_getaddr. > > Hm, and previous log makes it look like it was an > rpc_sockaddr2uaddr() > in rpcb_getport_async() that was made to fail. Do we need to check > for > failure of: > > map->r_addr = rpc_sockaddr2uaddr(sap, GFP_ATOMIC); > > ? Yes, and we can probably convert it, and the other GFP_ATOMIC allocations in the rpcbind client to use GFP_NOFS in order to improve reliability. Cheers Trond -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@hammer.space ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
