From: Kees Cook <keescook@chromium.org>
To: Willy Tarreau <w@1wt.eu>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
"Stephen Rothwell" <sfr@canb.auug.org.au>,
"Emese Revfy" <re.emese@gmail.com>,
"Linux Next Mailing List" <linux-next@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Sami Tolvanen" <samitolvanen@google.com>,
"Daniel Díaz" <daniel.diaz@linaro.org>
Subject: Re: linux-next: build failure after merge of the origin tree
Date: Thu, 30 Jul 2020 10:49:20 -0700 [thread overview]
Message-ID: <202007301047.5E8561F203@keescook> (raw)
In-Reply-To: <20200730061407.GA7941@1wt.eu>
On Thu, Jul 30, 2020 at 08:14:07AM +0200, Willy Tarreau wrote:
> On Thu, Jul 30, 2020 at 05:22:50AM +0200, Willy Tarreau wrote:
> > On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
> > > And just another heads-up, the patch[1] (which was never sent to a public
> > > list) also breaks arm64 (circular header needs?):
> > (...)
> >
> > Definitely, we've just got a report about this, I'll have a look once
> > I'm at the office. I'd like to check that we don't obviously break
> > another arch by just removing percpu. If at least shuffling them around
> > is sufficient that'd be nice. Otherwise we'll likely need a separate
> > header (which is not a bad thing for the long term).
>
> So Linus proposed a clean solution which might be harder to backport
> but looks better for 5.8. However the attached one addresses the issue
> for me on arm64 and still works on x86_64, arm, mips. I think we should
> go with this one first then apply Linus' one on top of it to be long
> term proof, and backport only the first one. Linus ?
>
> Willy
> From 18fba9e2dfb16605a722e01f95d9e2d020efaa42 Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w@1wt.eu>
> Date: Thu, 30 Jul 2020 07:59:24 +0200
> Subject: random: fix circular include dependency on arm64 after addition of
> percpu.h
> MIME-Version: 1.0
> Content-Type: text/plain; charset=latin1
> Content-Transfer-Encoding: 8bit
>
> Daniel Díaz and Kees Cook independently reported that commit f227e3ec3b5c
> ("random32: update the net random state on interrupt and activity") broke
> arm64 due to a circular dependency on include files since the addition of
> percpu.h in random.h.
>
> The correct fix would definitely be to move all the prandom32 stuff out
> of random.h but for backporting, a smaller solution is preferred. This
> one replaces linux/percpu.h with asm/percpu.h, and this fixes the problem
> on x86_64, arm64, arm, and mips. Note that moving percpu.h around didn't
> change anything and that removing it entirely broke differently. When
> backporting, such options might still be considered if this patch fails
> to help.
>
> Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
> Reported-by: Kees Cook <keescook@chromium.org>
FWIW, I was only a messenger. Sami (in Cc) pointed it out to me right
before I got the email from Linus for the x86 plugin breakage. :)
But yes, thanks, this seems to work for me.
> Fixes: f227e3ec3b5c
nit:
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
-Kees
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> include/linux/random.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/random.h b/include/linux/random.h
> index f310897f051d..9ab7443bd91b 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -11,7 +11,7 @@
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/once.h>
> -#include <linux/percpu.h>
> +#include <asm/percpu.h>
>
> #include <uapi/linux/random.h>
>
> --
> 2.20.1
>
--
Kees Cook
next prev parent reply other threads:[~2020-07-30 17:49 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 23:08 linux-next: build failure after merge of the origin tree Stephen Rothwell
2020-07-29 23:43 ` Linus Torvalds
2020-07-30 0:09 ` Linus Torvalds
2020-07-30 2:12 ` Linus Torvalds
2020-07-30 2:30 ` Willy Tarreau
2020-07-30 3:17 ` Kees Cook
2020-07-30 3:22 ` Willy Tarreau
2020-07-30 6:14 ` Willy Tarreau
2020-07-30 9:59 ` Marc Zyngier
2020-07-30 10:09 ` Catalin Marinas
2020-07-30 15:00 ` Will Deacon
2020-07-30 17:49 ` Kees Cook [this message]
2020-07-30 18:24 ` Linus Torvalds
2020-07-30 18:47 ` Kees Cook
-- strict thread matches above, loose matches on Subject: below --
2023-06-30 2:59 Stephen Rothwell
2023-06-30 3:43 ` Linus Torvalds
2021-09-19 23:42 Stephen Rothwell
2021-09-14 0:08 Stephen Rothwell
2021-09-14 0:19 ` Linus Torvalds
2021-09-14 0:24 ` Linus Torvalds
2021-09-14 0:58 ` Stephen Rothwell
2021-09-14 1:29 ` Linus Torvalds
2021-09-14 1:37 ` Linus Torvalds
2021-09-14 2:03 ` Linus Torvalds
2021-09-14 2:08 ` Stephen Rothwell
2021-09-14 2:12 ` Linus Torvalds
2021-09-14 2:50 ` Michael Ellerman
2021-09-14 12:21 ` Michael Ellerman
2021-09-14 2:39 ` Stephen Rothwell
2021-09-07 23:07 Stephen Rothwell
2021-09-07 23:09 ` Stephen Rothwell
2021-09-07 23:17 ` Marco Elver
2021-09-07 23:38 ` Miguel Ojeda
2020-07-30 22:58 Stephen Rothwell
2020-07-30 23:15 ` Stephen Rothwell
2020-06-04 22:37 Stephen Rothwell
2020-06-05 0:04 ` Josh Poimboeuf
2020-06-05 9:48 ` Jessica Yu
2020-04-20 10:23 Stephen Rothwell
2020-01-31 4:12 Stephen Rothwell
2020-01-31 4:17 ` Randy Dunlap
2020-01-31 9:39 ` Daniel Lezcano
2012-10-09 23:21 Stephen Rothwell
2012-10-09 23:45 ` Andrew Morton
2012-10-09 23:52 ` Yasuaki Ishimatsu
2012-10-10 3:12 ` Stephen Rothwell
2012-10-10 0:07 ` Stephen Rothwell
2012-06-04 2:57 Stephen Rothwell
2012-06-04 7:39 ` Paul Mundt
2012-01-18 23:31 Stephen Rothwell
2012-01-19 8:21 ` Jens Axboe
2012-01-19 8:23 ` Jens Axboe
2011-11-06 23:12 Stephen Rothwell
2011-11-07 1:52 ` David Miller
2011-11-07 2:47 ` Stephen Rothwell
2011-11-07 3:36 ` David Miller
2011-11-07 5:29 ` Kirsher, Jeffrey T
2011-11-07 16:46 ` Rose, Gregory V
2011-11-07 17:46 ` Rose, Gregory V
2011-07-25 1:16 Stephen Rothwell
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=202007301047.5E8561F203@keescook \
--to=keescook@chromium.org \
--cc=catalin.marinas@arm.com \
--cc=daniel.diaz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=re.emese@gmail.com \
--cc=samitolvanen@google.com \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
--cc=will@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).