linux-kernel - Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <nycvar.YSQ.7.76.1711202224490.16045@knanqh.ubzr>
Date:   Mon, 20 Nov 2017 22:50:46 -0500 (EST)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Guenter Roeck <linux@...ck-us.net>
cc:     Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Mikael Starvik <starvik@...s.com>,
        Jesper Nilsson <jesper.nilsson@...s.com>,
        linux-cris-kernel@...s.com
Subject: Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info
 (crisv32 hang)

On Mon, 20 Nov 2017, Guenter Roeck wrote:

> On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote:
> > On Mon, 20 Nov 2017, Guenter Roeck wrote:
> > 
> > > bdata->node_min_pfn=60000 PFN_PHYS(bdata->node_min_pfn)=c0000000 start_off=536000 region=c0536000
> > 
> > If PFN_PHYS(bdata->node_min_pfn)=c0000000 and
> > region=c0536000 that means phys_to_virt() is a no-op.
> > 
> No, it is |= 0x80000000

Then the bootmem registration looks very fishy. If you have:

> I think the problem is the 0x60000 in bdata->node_min_pfn. It is shifted
> left by PFN_PHYS, making it 0xc0000000, which in my understanding is
> a virtual address.

Exact.

#define __pa(x)                 ((unsigned long)(x) & 0x7fffffff)
#define __va(x)                 ((void *)((unsigned long)(x) | 0x80000000))

With that, the only possible physical address range you may have is 
0x40000000 - 0x7fffffff, and it better start at 0x40000000. If that's 
not where your RAM is then something is wrong.

This is in fact a very bad idea to define __va() and __pa() using 
bitwise operations as this hides mistakes like defining physical RAM 
address at 0xc0000000. Instead, it should look like:

#define __pa(x)                 ((unsigned long)(x) - 0x80000000)
#define __va(x)                 ((void *)((unsigned long)(x) + 0x80000000))

This way, bad physical RAM address definitions will be caught 
immediately.

> That doesn't seem to be easy to fix. It seems there is a mixup of physical
> and  virtual addresses in the architecture.

Well... I don't think there is much else to say other than this needs 
fixing.


Nicolas