Re: [oliver.sang@intel.com: [cpumask] b9a7ecc71f: WARNING:at_include/linux/cpumask.h:#__is_kernel_percpu_address]

[Andrew Jones <ajones@ventanamicro.com>]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

On Tue, Oct 11, 2022 at 10:23:27AM -0700, Yury Norov wrote:
> On Tue, Oct 11, 2022 at 10:16:03AM -0700, Yury Norov wrote:
> > > Hi Yury,
> > > 
> > > I just wanted to report that the warning fires when doing
> > > 'cat /proc/cpuinfo' on at least x86 and riscv. I don't think
> > > those are false positives. I'm guessing a patch should be
> > > something like the following diff. If you haven't already
> > > addressed this and I'm not off in left field, then I guess
> > > we should integrate it into your series.
> > > 
> > > Thanks,
> > > drew
> >  
> > Hi Andrew,
> > 
> > Can you please send it as a patch with a description?
> 
> Also, can you describe why we'd silence the warning this way?
> If the cpu number greater than nr_cpu_ids comes from upper layer,
> we quite probably should investigate what happens there...

Darn, I fired off the patches before reading this. I didn't try to
completely digest seq_read_iter(), but on a quick look I think the
reason is that it implements something like

  p = start();
  while (1) {
     p = next();
     if (!p)
         break;
     show();
  }
  stop();

where cpuinfo's operators are

 start()
 {
    *pos = cpumask_next(*pos - 1, cpu_online_mask);
    if (*pos < nr_cpu_ids)
        return ...;
    return NULL;
 }

 next()
 {
   (*pos)++;
   return start(..., pos);
 }

So the justification for the patches the way I've written them is
that I think we just need to return NULL from start / next when
we've gone too far, before we first warn and then return NULL.

Thanks,
drew