When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
cpu_max_bits_warn() generates a runtime warning similar as below while
we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------
[ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
[ 3.070072] Modules linked in: efivarfs autofs4
[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
[ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
[ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
[ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
[ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
[ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
[ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
[ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
[ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000
[ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
[ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
[ 3.195868] ...
[ 3.199917] Call Trace:
[ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c
[ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
[ 3.217625] [<900000000023d268>] __warn+0xd0/0x100
[ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
[ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
[ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
[ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
[ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
[ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
[ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
[ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
[ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: [email protected]
Signed-off-by: Huacai Chen <[email protected]>
---
arch/m68k/kernel/setup_no.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 19eea73d3c17..ee03287a386c 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -201,7 +201,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
- return *pos < NR_CPUS ? ((void *) 0x12345678) : NULL;
+ return *pos < nr_cpu_ids ? ((void *) 0x12345678) : NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
--
2.31.1
Hi Huacai,
Thanks for your patch!
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
and thus cannot be enabled.
> cpu_max_bits_warn() generates a runtime warning similar as below while
> we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
> instead of NR_CPUS to iterate CPUs.
>
> [ 3.052463] ------------[ cut here ]------------
> [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
> [ 3.070072] Modules linked in: efivarfs autofs4
efivarfs on m68k?
EFIVAR_FS depends on EFI depends on !CPU_BIG_ENDIAN
> [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
> [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
> [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
> [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
> [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
> [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
> [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
> [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
> [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000
> [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
> [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
> [ 3.195868] ...
> [ 3.199917] Call Trace:
> [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c
> [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
> [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100
> [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
> [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
> [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
> [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
> [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
> [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
> [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
> [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
> [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
>
> Cc: [email protected]
> Signed-off-by: Huacai Chen <[email protected]>
Does this need a Fixes tag, so we know when the problem was introduced?
> --- a/arch/m68k/kernel/setup_no.c
> +++ b/arch/m68k/kernel/setup_no.c
> @@ -201,7 +201,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
>
> static void *c_start(struct seq_file *m, loff_t *pos)
> {
> - return *pos < NR_CPUS ? ((void *) 0x12345678) : NULL;
> + return *pos < nr_cpu_ids ? ((void *) 0x12345678) : NULL;
> }
include/linux/cpumask.h has:
#if NR_CPUS == 1
#define nr_cpu_ids 1U
so on m68k, both evaluate to the same value?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi, Geert,
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Huacai,
>
> Thanks for your patch!
>
> On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
> > When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
>
> DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
> and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all
architectures and change those that look the same as MIPS and
LoongArch.
And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no
difference, but does it make sense to keep consistency across all
architectures?
Huacai
>
> > cpu_max_bits_warn() generates a runtime warning similar as below while
> > we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
> > instead of NR_CPUS to iterate CPUs.
> >
> > [ 3.052463] ------------[ cut here ]------------
> > [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
> > [ 3.070072] Modules linked in: efivarfs autofs4
>
> efivarfs on m68k?
>
> EFIVAR_FS depends on EFI depends on !CPU_BIG_ENDIAN
>
> > [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
> > [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
> > [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
> > [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
> > [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
> > [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
> > [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
> > [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
> > [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000
> > [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
> > [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
> > [ 3.195868] ...
> > [ 3.199917] Call Trace:
> > [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c
> > [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
> > [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100
> > [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
> > [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
> > [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
> > [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
> > [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
> > [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
> > [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
> > [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
> > [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
> >
> > Cc: [email protected]
> > Signed-off-by: Huacai Chen <[email protected]>
>
> Does this need a Fixes tag, so we know when the problem was introduced?
>
> > --- a/arch/m68k/kernel/setup_no.c
> > +++ b/arch/m68k/kernel/setup_no.c
> > @@ -201,7 +201,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> >
> > static void *c_start(struct seq_file *m, loff_t *pos)
> > {
> > - return *pos < NR_CPUS ? ((void *) 0x12345678) : NULL;
> > + return *pos < nr_cpu_ids ? ((void *) 0x12345678) : NULL;
> > }
>
> include/linux/cpumask.h has:
>
> #if NR_CPUS == 1
> #define nr_cpu_ids 1U
>
> so on m68k, both evaluate to the same value?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Hi Huacai,
On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen <[email protected]> wrote:
> On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
> > On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
> > > When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
> >
> > DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
> > and thus cannot be enabled.
> This patch is derived from MIPS and LoongArch, I search all
> architectures and change those that look the same as MIPS and
> LoongArch.
> And the warning message below is also a copy-paste from LoongArch, sorry.
>
> Since M68K doesn't support SMP, then this patch seems to make no
> difference, but does it make sense to keep consistency across all
> architectures?
Yes, having consistency is good. But that should be mentioned in the
patch description, instead of a scary warning CCed to stable ;-)
BTW, you probably want to update the other copy of c_start() in
arch/m68k/kernel/setup_mm.c, too.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi, Geert,
On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Huacai,
>
> On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen <[email protected]> wrote:
> > On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
> > > On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
> > > > When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
> > >
> > > DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
> > > and thus cannot be enabled.
> > This patch is derived from MIPS and LoongArch, I search all
> > architectures and change those that look the same as MIPS and
> > LoongArch.
> > And the warning message below is also a copy-paste from LoongArch, sorry.
> >
> > Since M68K doesn't support SMP, then this patch seems to make no
> > difference, but does it make sense to keep consistency across all
> > architectures?
>
> Yes, having consistency is good. But that should be mentioned in the
> patch description, instead of a scary warning CCed to stable ;-)
>
> BTW, you probably want to update the other copy of c_start() in
> arch/m68k/kernel/setup_mm.c, too.
For no-SMP architectures, it seems c_start() in
arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither
NR_CPUS, nor nr_cpu_ids)?
Huacai
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Hi Huacai,
On Tue, Jul 12, 2022 at 11:08 AM Huacai Chen <[email protected]> wrote:
> On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven <[email protected]> wrote:
> > On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen <[email protected]> wrote:
> > > On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
> > > > On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
> > > > > When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
> > > >
> > > > DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
> > > > and thus cannot be enabled.
> > > This patch is derived from MIPS and LoongArch, I search all
> > > architectures and change those that look the same as MIPS and
> > > LoongArch.
> > > And the warning message below is also a copy-paste from LoongArch, sorry.
> > >
> > > Since M68K doesn't support SMP, then this patch seems to make no
> > > difference, but does it make sense to keep consistency across all
> > > architectures?
> >
> > Yes, having consistency is good. But that should be mentioned in the
> > patch description, instead of a scary warning CCed to stable ;-)
> >
> > BTW, you probably want to update the other copy of c_start() in
> > arch/m68k/kernel/setup_mm.c, too.
> For no-SMP architectures, it seems c_start() in
> arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither
> NR_CPUS, nor nr_cpu_ids)?
The advantage of using nr_cpu_ids() is that this is one place less
to update when adding SMP support later...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert and Huacai,
On 2022/7/12 17:13, Geert Uytterhoeven wrote:
> Hi Huacai,
>
> On Tue, Jul 12, 2022 at 11:08 AM Huacai Chen <[email protected]> wrote:
>> On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven <[email protected]> wrote:
>>> On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen <[email protected]> wrote:
>>>> On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
>>>>> On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
>>>>>> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
>>>>> DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
>>>>> and thus cannot be enabled.
>>>> This patch is derived from MIPS and LoongArch, I search all
>>>> architectures and change those that look the same as MIPS and
>>>> LoongArch.
>>>> And the warning message below is also a copy-paste from LoongArch, sorry.
>>>>
>>>> Since M68K doesn't support SMP, then this patch seems to make no
>>>> difference, but does it make sense to keep consistency across all
>>>> architectures?
>>> Yes, having consistency is good. But that should be mentioned in the
>>> patch description, instead of a scary warning CCed to stable ;-)
>>>
>>> BTW, you probably want to update the other copy of c_start() in
>>> arch/m68k/kernel/setup_mm.c, too.
>> For no-SMP architectures, it seems c_start() in
>> arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither
>> NR_CPUS, nor nr_cpu_ids)?
> The advantage of using nr_cpu_ids() is that this is one place less
> to update when adding SMP support later...
Hmm, so I've been watching m68k development lately (although not as
closely as I'd like to, due to lack of vintage hardware at hand), given
the current amazing momentum all the hobbyists/developers have been
contributing to, SMP is well within reach...
But judging from the intent of this patch series (fixing WARNs on
certain configs), and that the triggering condition is currently
impossible on m68k (and other non-SMP) platforms, I think cleanups for
such arches could come as a separate patch series later. I think the
m68k refactoring is reasonable after all, due to my observation above,
but for the other non-SMP arches we may want to wait for the respective
maintainers' opinions.
Hi, all,
On Tue, Jul 12, 2022 at 6:15 PM WANG Xuerui <[email protected]> wrote:
>
> Hi Geert and Huacai,
>
> On 2022/7/12 17:13, Geert Uytterhoeven wrote:
> > Hi Huacai,
> >
> > On Tue, Jul 12, 2022 at 11:08 AM Huacai Chen <[email protected]> wrote:
> >> On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven <[email protected]> wrote:
> >>> On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen <[email protected]> wrote:
> >>>> On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
> >>>>> On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen <[email protected]> wrote:
> >>>>>> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
> >>>>> DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k,
> >>>>> and thus cannot be enabled.
> >>>> This patch is derived from MIPS and LoongArch, I search all
> >>>> architectures and change those that look the same as MIPS and
> >>>> LoongArch.
> >>>> And the warning message below is also a copy-paste from LoongArch, sorry.
> >>>>
> >>>> Since M68K doesn't support SMP, then this patch seems to make no
> >>>> difference, but does it make sense to keep consistency across all
> >>>> architectures?
> >>> Yes, having consistency is good. But that should be mentioned in the
> >>> patch description, instead of a scary warning CCed to stable ;-)
> >>>
> >>> BTW, you probably want to update the other copy of c_start() in
> >>> arch/m68k/kernel/setup_mm.c, too.
> >> For no-SMP architectures, it seems c_start() in
> >> arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither
> >> NR_CPUS, nor nr_cpu_ids)?
> > The advantage of using nr_cpu_ids() is that this is one place less
> > to update when adding SMP support later...
>
> Hmm, so I've been watching m68k development lately (although not as
> closely as I'd like to, due to lack of vintage hardware at hand), given
> the current amazing momentum all the hobbyists/developers have been
> contributing to, SMP is well within reach...
>
> But judging from the intent of this patch series (fixing WARNs on
> certain configs), and that the triggering condition is currently
> impossible on m68k (and other non-SMP) platforms, I think cleanups for
> such arches could come as a separate patch series later. I think the
> m68k refactoring is reasonable after all, due to my observation above,
> but for the other non-SMP arches we may want to wait for the respective
> maintainers' opinions.
It seems that the best solution is only fix architectures with SMP
support and leave others (m68k, microblaze, um) as is. :)
Huacai
>
On Thu, Jul 14, 2022 at 4:07 AM Huacai Chen <[email protected]> wrote:
> On Tue, Jul 12, 2022 at 6:15 PM WANG Xuerui <[email protected]> wrote:
> > On 2022/7/12 17:13, Geert Uytterhoeven wrote:
> >
> > But judging from the intent of this patch series (fixing WARNs on
> > certain configs), and that the triggering condition is currently
> > impossible on m68k (and other non-SMP) platforms, I think cleanups for
> > such arches could come as a separate patch series later. I think the
> > m68k refactoring is reasonable after all, due to my observation above,
> > but for the other non-SMP arches we may want to wait for the respective
> > maintainers' opinions.
>
> It seems that the best solution is only fix architectures with SMP
> support and leave others (m68k, microblaze, um) as is. :)
I think it probably makes sense to do this as a combined cleanup patch,
which I can merge through the asm-generic tree, for all architectures
whose maintainer does not pick it up directly. For SMP architectures,
it's a bugfix that we probably want backported into stable kernels, while
for non-SMP targets it is just a minor cleanup for consistency.
Arnd
Hi, Arnd,
On Thu, Jul 14, 2022 at 2:59 PM Arnd Bergmann <[email protected]> wrote:
>
> On Thu, Jul 14, 2022 at 4:07 AM Huacai Chen <[email protected]> wrote:
> > On Tue, Jul 12, 2022 at 6:15 PM WANG Xuerui <[email protected]> wrote:
> > > On 2022/7/12 17:13, Geert Uytterhoeven wrote:
> > >
> > > But judging from the intent of this patch series (fixing WARNs on
> > > certain configs), and that the triggering condition is currently
> > > impossible on m68k (and other non-SMP) platforms, I think cleanups for
> > > such arches could come as a separate patch series later. I think the
> > > m68k refactoring is reasonable after all, due to my observation above,
> > > but for the other non-SMP arches we may want to wait for the respective
> > > maintainers' opinions.
> >
> > It seems that the best solution is only fix architectures with SMP
> > support and leave others (m68k, microblaze, um) as is. :)
>
> I think it probably makes sense to do this as a combined cleanup patch,
> which I can merge through the asm-generic tree, for all architectures
> whose maintainer does not pick it up directly. For SMP architectures,
> it's a bugfix that we probably want backported into stable kernels, while
> for non-SMP targets it is just a minor cleanup for consistency.
OK, I will send V2 later.
Huacai
>
> Arnd