[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFziNcDmN=DT7efKYGU-AZC535GDVKh57bC7UHaFff3vRw@mail.gmail.com>
Date: Tue, 15 May 2018 10:21:41 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dexuan Cui <decui@...rosoft.com>
Cc: Ingo Molnar <mingo@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rakib Mullick <rakib.mullick@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: for_each_cpu() is buggy for UP kernel?
On Mon, May 14, 2018 at 8:02 PM Dexuan Cui <decui@...rosoft.com> wrote:
> If you're OK with the below fix (not tested yet), I'll submit a patch for
it:
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -616,6 +616,10 @@ static void tick_handle_oneshot_broadcast(struct
clock_event_device *dev)
> now = ktime_get();
> /* Find all expired events */
> for_each_cpu(cpu, tick_broadcast_oneshot_mask) {
> +#ifndef CONFIG_SMP
> + if (cpumask_empty(tick_broadcast_oneshot_mask))
> + break;
> +#endif
I'm certainly ok with this. It's hacky, but maybe being explicitly hacky is
good to "document" this gotcha.
And I really do agree that this special UP case is nasty nasty and much too
subtle, and I hope that some day we won't care about UP at all, and maybe
kill it, or maybe just make for_each_cpu() generate the extra code to have
the actual same semantics as the SMP case.
Linus
Powered by blists - more mailing lists