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.1711271515540.5925@knanqh.ubzr>
Date:   Mon, 27 Nov 2017 15:31:52 -0500 (EST)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Tejun Heo <tj@...nel.org>
cc:     Guenter Roeck <linux@...ck-us.net>,
        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, 27 Nov 2017, Tejun Heo wrote:

> Hello,
> 
> I'm reverting the offending commit till we figure out what's going on.

It is figured out. The cris port is wrongly initializing the bootmem 
allocator with virtual memory addresses rather than physical addresses. 
And because its __va() definition reads like this:

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

then things just work out because the end result is the same whether you 
give this a physical or a virtual address.

Untill you call memblock_free_early(__pa(address)) that is, because 
values from __pa() don't match with the virtual addresses stuffed in the 
bootmem allocator anymore.

So IMHO I don't think reverting the commit is the right thing to do. 
That commit is clearly not at fault here.

Nicolas