|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] timer: fix NR_CPUS=1 build with gcc13
On Wed, Sep 13, 2023 at 8:32 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> Gcc13 apparently infers from "if ( old_cpu < new_cpu )" that "new_cpu"
> is >= 1, and then (on x86) complains about "per_cpu(timers, new_cpu)"
> exceeding __per_cpu_offset[]'s bounds (being an array of 1 in such a
> configuration). Make the code conditional upon there being at least 2
> CPUs configured (otherwise there simply is nothing to migrate [to]).
Hmm, without digging into it, migrate_timer() doesn't seem like very
robust code: It doesn't check to make sure that new_cpu is valid, nor
does it give the option of returning an error if anything fails.
Making migrate_timer() just do nothing on 1-cpu systems seems will
remove the warning, but not really make things safer.
Is this a super hot path? Would it make more sense to add `||
(new_cpu > CONFIG_NR_CPUS)` to the early-return conditional at the
top of the first `for (; ; )` loop?
I guess if we don't expect it ever to be called, it might be better to
get rid of the code entirely; but maybe in that case we should add
something like the following?
```
#else
WARN_ONCE("migrate_timer: Request to move to %u on a single-core
system!", new_cpu);
ASSERT_UNREACHABLE();
#endif
```
Thoughts?
-George
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |