Re: [PATCH] x86: Fix /proc/cpuinfo cpumask warning

[Yury Norov <yury.norov@gmail.com>]

On Tue, Oct 11, 2022 at 11:17 AM Andrew Jones <ajones@ventanamicro.com> wrote:
>
> On Tue, Oct 11, 2022 at 08:01:03PM +0200, Borislav Petkov wrote:
> > On Tue, Oct 11, 2022 at 07:50:31PM +0200, Andrew Jones wrote:
> > > Upcoming cpumask changes will start issuing warnings[*] when cpu
> >
> > What upcoming changes?
> >
> > This needs a concrete pointer to a commit or so.
>
> Hi Boris,
>
> Sorry, I should have pointed this out. The upcoming change is
>
> linux-next/master commit a314123c8bdb ("cpumask: fix checking valid cpu
> range")
>
> And also an ongoing discussion here
> https://lore.kernel.org/lkml/20221011170949.upxk3tcfcwnkytwm@kamzik/
>
> I'm hoping that Yury will pick these patches up and integrate
> them at the front of his series when introducing the warnings.
> I wasn't sure how to call that out other than with the generic
> "upcoming change".
>
> >
> > > indices equal to nr_cpu_ids are passed to cpumask_next* functions.
> >
> > How do those indices get passed here? I think you need to explain how
> > exactly this happens.

The cpumask_check() fix is already in master. Because of some mess in
cpumask, cpumask_check() was broken for quite a long time, and didn't
bark when passed with an out-of-range CPU.

I fixed some false-positives and sent those fixes together with a314123c8bdb.
Now, I expect that people will see warnings generated by correct
cpumask_check().
This is actually the first sign.

Andrew, can you please answer Borislav's question:

> > How do those indices get passed here? I think you need to explain how
> > exactly this happens.

It might be either an expected behaviour, and then there should be a great
explanation on how and why things work in the subsystem.

Or it might be an error in the caller. In that case, the caller must be fixed.

Thanks,
Yury