From: Ingo Molnar <mingo@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH] x86: fixmap: use CONFIG_NR_CPUS instead of NR_CPUS
Date: Wed, 26 May 2021 08:50:20 +0200 [thread overview]
Message-ID: <YK3vrIB7cWop+UIW@gmail.com> (raw)
In-Reply-To: <20210521195918.2183-1-rdunlap@infradead.org>
* Randy Dunlap <rdunlap@infradead.org> wrote:
> Use CONFIG_NR_CPUS instead of NR_CPUS for an enum entry item.
> (Alternatively, #include <linux/threads.h> unconditionally instead of
> conditionally.)
>
> This fixes 100+ build errors like so:
>
> In file included from ../include/asm-generic/early_ioremap.h:6:0,
> from ./arch/x86/include/generated/asm/early_ioremap.h:1,
> from ../arch/x86/include/asm/io.h:44,
> from ../include/linux/io.h:13,
> from ../mm/early_ioremap.c:13:
> ../arch/x86/include/asm/fixmap.h:103:48: error: ‘NR_CPUS’ undeclared here (not in a function); did you mean ‘NR_OPEN’?
> FIX_KMAP_END = FIX_KMAP_BEGIN + (KM_MAX_IDX * NR_CPUS) - 1,
>
> Fixes: e972c2511967 ("mm/early_ioremap: add prototype for early_memremap_pgprot_adjust")
I believe this patch is in the -mm tree, not the x86 tree.
> @@ -100,7 +100,7 @@ enum fixed_addresses {
> #endif
> #ifdef CONFIG_KMAP_LOCAL
> FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
> - FIX_KMAP_END = FIX_KMAP_BEGIN + (KM_MAX_IDX * NR_CPUS) - 1,
> + FIX_KMAP_END = FIX_KMAP_BEGIN + (KM_MAX_IDX * CONFIG_NR_CPUS) - 1,
> #ifdef CONFIG_PCI_MMCONFIG
> FIX_PCIE_MCFG,
> #endif
Please resolve this bug properly:
- Don't sprinkle low level headers with random CONFIG_NR_CPUS conversions.
- <asm/io.h> currently includes <asm/early_ioremap.h>, but this seems
unjustified.
- Once early_ioremap.h is gone from io.h, it's potentially possible to
include <linux/threads.h>. More work to resolve dependencies might be
needed though.
Frankly, I'd prefer if such a low level header dependencies change came in
via the x86 tree so we can properly review it, test it, and keep it
working. Right now I can only guess what is needed here...
Thanks,
Ingo
next prev parent reply other threads:[~2021-05-26 6:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 19:59 [PATCH] x86: fixmap: use CONFIG_NR_CPUS instead of NR_CPUS Randy Dunlap
2021-05-26 6:50 ` Ingo Molnar [this message]
2021-05-26 17:59 ` Randy Dunlap
2021-05-27 13:53 ` Mel Gorman
2021-05-27 15:48 ` Randy Dunlap
2021-05-27 16:55 ` Mel Gorman
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=YK3vrIB7cWop+UIW@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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 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.