linux-kernel - Re: [oliver.sang@...el.com: [cpumask] b9a7ecc71f: WARNING:at_include/linux/cpumask.h:#__is_kernel_percpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20221011180442.cwjtcvjioias3qt6@kamzik>
Date:   Tue, 11 Oct 2022 20:04:42 +0200
From:   Andrew Jones <ajones@...tanamicro.com>
To:     Yury Norov <yury.norov@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>, lkp@...ts.01.org,
        lkp@...el.com, Linux Memory Management List <linux-mm@...ck.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [oliver.sang@...el.com: [cpumask] b9a7ecc71f:
 WARNING:at_include/linux/cpumask.h:#__is_kernel_percpu_address]

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