All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: wireguard@lists.zx2c4.com
Subject: Random arrays on kernel stack..
Date: Thu, 28 Jul 2022 16:51:58 -0700	[thread overview]
Message-ID: <CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com> (raw)

So I finally have an arm64 laptop that I'm playing with, and as a
result building the kernel the way I usually do - with warnings as
errors.

And I get this:

  drivers/net/wireguard/allowedips.c: In function ‘root_remove_peer_lists’:
  drivers/net/wireguard/allowedips.c:77:1: error: the frame size of
1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
     77 | }
        | ^
  drivers/net/wireguard/allowedips.c: In function ‘root_free_rcu’:
  drivers/net/wireguard/allowedips.c:64:1: error: the frame size of
1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
     64 | }
        | ^

and clearly it only happens for me because it turns out Asahi has for
some odd reason picked that low CONFIG_FRAME_WARN of just 1kB.

So the fix for the warning was just to update my .config file, no biggie.

But when I look at the code that generates that warning, it just
worries me. It has that magical constant 128.

Sure, that same constant is also in push_rcu().

And there it is randomly as a warning, and then it will happily
overflow the stack frame.

That's not ok.

I think that

 (a) that constant should be a bit lower, so that we *can* use a 1kB
stack frame warning on 64-bit architectures

 (b) it should be documented some way as a #define

 (c) push_rcu() should damn well not "warn and corrupt the stack". It
should warn-and-not-corrupt the stack, even if that then means that
the thing isn't pushed at all.

Hmm?

                 Linus

             reply	other threads:[~2022-07-28 23:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-28 23:51 Linus Torvalds [this message]
2022-07-29 17:12 ` Random arrays on kernel stack Jason A. Donenfeld
2022-07-29 17:56   ` Linus Torvalds

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-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=Jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.