linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Eric Dumazet <edumazet@google.com>
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:08:27 -0700	[thread overview]
Message-ID: <CAHk-=wiwydQEhbZCkUhwbDZp_CdMJrOtRwTThA5bT5C7b+grnA@mail.gmail.com> (raw)
In-Reply-To: <CANn89iJ5Q-PeZ=+87DT-BY4EVhWZATtieid59W7Tq0bkCvRQbw@mail.gmail.com>

On Fri, Sep 3, 2021 at 4:00 PM Eric Dumazet <edumazet@google.com> wrote:
>
> > 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.

Sure.

Let's keep the warning in place. We can remove it before the actual
release if things don't get better, but it does look like it's
actually finding places where people should have checked limits more,
rather than apparently just relying on the allocation failing.

Because with enough memory, the allocations traditionally didn't fail
- they just succeed with completely insane allocations and absolutely
horrendous latencies (ie allocating and possibly clearing gigabytes
and gigabytes of data).

This other one:

>  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
> Call Trace:
>  check_btf_line+0x1a9/0xad0 kernel/bpf/verifier.c:9925

Yeah, that code should check "nr_linfo" a lot more than it seems to do.

It had just added __GFP_NOWARN to hide the fact that it did crazy
allocations and just wanted the craziest ones to fail silently.

I think it should just limit itself to something sane.

               Linus

  reply	other threads:[~2021-09-03 23:08 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
2021-09-03 23:08     ` Linus Torvalds [this message]
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='CAHk-=wiwydQEhbZCkUhwbDZp_CdMJrOtRwTThA5bT5C7b+grnA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.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).