linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: dozens of sysbot reports
Date: Fri, 3 Sep 2021 16:00:20 -0700	[thread overview]
Message-ID: <CANn89iJ5Q-PeZ=+87DT-BY4EVhWZATtieid59W7Tq0bkCvRQbw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wiENdk_AXGRrmbbOYqq9zYptdv=vYszgG2ZzztDUTJwRA@mail.gmail.com>

On Fri, Sep 3, 2021 at 3:21 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Sep 3, 2021 at 1:44 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I have a pile of (still under triage) sysbot reports coming after one of your patch
> >
> > Typical stack trace:
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 24889 at mm/util.c:597 kvmalloc_node+0x111/0x120 mm/util.c:597
> > Call Trace:
> >  hash_ipport_create+0x3dd/0x1220 net/netfilter/ipset/ip_set_hash_gen.h:1524
> >  ip_set_create+0x782/0x15a0 net/netfilter/ipset/ip_set_core.c:1100
> >  nfnetlink_rcv_msg+0xbc9/0x13f0 net/netfilter/nfnetlink.c:296
>
> So the real question is mainly just whether those huge allocations
> actually make sense or not.
>
> If they truly are sensible, we can remove the warning. But it would be
> good to perhaps look at them more.
>
> Because no:
>
> > Do we want to fix all problematic callers, with ad-hoc patches like
>
> Not insane patches like this, no.
>
> >  ip_set_alloc(size_t size)
> >  {
> > +       if (size > INT_MAX)
> > +               return NULL;
> >         return kvzalloc(size, GFP_KERNEL_ACCOUNT);
> >  }
>
> But does that kind of size really make sense? I'm looking at the
> particular caller, is it *really* senseible to have a 4GB+ hash table
> size?
>
> IOW, I don't think we want that warning to cause the above kinds of
> ad-hoc patches.
>
> But I _do_ want that warning to make people go "is that allocation
> truly sensible"?
>
> IOW, it sounds like you can send some netlink message that causes
> insane hash size allocations. Shouldn't _that_ be fixed?
>

Probably, but as I said there are many different reports.

If there was only one or two, I would simply have sent a fix(es).

I will probably release these bugs, so that they can be spread among
interested parties.

 WARNING: CPU: 1 PID: 26011 at mm/util.c:597 kvmalloc_node+0x111/0x120
mm/util.c:597
Modules linked in:
CPU: 1 PID: 26011 Comm: syz-executor.2 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
RIP: 0010:kvmalloc_node+0x111/0x120 mm/util.c:597
Code: 01 00 00 00 4c 89 e7 e8 8d 12 0d 00 49 89 c5 e9 69 ff ff ff e8
f0 21 d1 ff 41 89 ed 41 81 cd 00 20 01 00 eb 95 e8 df 21 d1 ff <0f> 0b
e9 4c ff ff ff 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 e8 c6
RSP: 0018:ffffc90003a77720 EFLAGS: 00010216
RAX: 0000000000000e48 RBX: ffffc90003a77e18 RCX: ffffc9000df6d000
RDX: 0000000000040000 RSI: ffffffff81a4f621 RDI: 0000000000000003
RBP: 0000000000002dc0 R08: 000000007fffffff R09: 00000000ffffffff
R10: ffffffff81a4f5de R11: 0000000000000000 R12: 000000020008a100
R13: 0000000000000000 R14: 00000000ffffffff R15: ffff88802032c000
FS:  00007fbfc5618700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000540198 CR3: 000000006e529000 CR4: 0000000000350ee0
Call Trace:
 kvmalloc include/linux/mm.h:806 [inline]
 kvmalloc_array include/linux/mm.h:824 [inline]
 kvcalloc include/linux/mm.h:829 [inline]
 check_btf_line+0x1a9/0xad0 kernel/bpf/verifier.c:9925
 check_btf_info kernel/bpf/verifier.c:10049 [inline]
 bpf_check+0x1636/0xbd20 kernel/bpf/verifier.c:13759
 bpf_prog_load+0xe57/0x21f0 kernel/bpf/syscall.c:2301
 __sys_bpf+0x67e/0x5df0 kernel/bpf/syscall.c:4587
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80

  reply	other threads:[~2021-09-03 23:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 20:44 dozens of sysbot reports Eric Dumazet
2021-09-03 22:20 ` Linus Torvalds
2021-09-03 23:00   ` Eric Dumazet [this message]
2021-09-03 23:08     ` Linus Torvalds
2021-09-03 23:11       ` Linus Torvalds
2021-09-07 10:18   ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANn89iJ5Q-PeZ=+87DT-BY4EVhWZATtieid59W7Tq0bkCvRQbw@mail.gmail.com' \
    --to=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).