linux-kernel - Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly non-modular vs CONFIG_TIMER

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]

Date:	Fri, 29 Jan 2016 09:24:37 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Mike Kravetz <mike.kravetz@...cle.com>
CC:	Christian Borntraeger <borntraeger@...ibm.com>,
	Hillf Danton <hillf.zj@...baba-inc.com>,
	"'Andrew Morton'" <akpm@...ux-foundation.org>,
	"'Nadia Yvette Chambers'" <nyc@...omorphy.com>,
	"'Alexander Viro'" <viro@...iv.linux.org.uk>,
	"'Naoya Horiguchi'" <n-horiguchi@...jp.nec.com>,
	"'David Rientjes'" <rientjes@...gle.com>,
	"'Davidlohr Bueso'" <dave@...olabs.net>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code
 explicitly non-modular vs CONFIG_TIMER_STATS)

[Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly non-modular vs CONFIG_TIMER_STATS)] On 28/01/2016 (Thu 16:27) Mike Kravetz wrote:

> On 01/28/2016 02:59 PM, Paul Gortmaker wrote:
> > [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly non-modular vs CONFIG_TIMER_STATS)] On 28/01/2016 (Thu 14:18) Mike Kravetz wrote:
> > 
> >> On 01/28/2016 07:05 AM, Mike Kravetz wrote:

[...]

> >> on s390 numa nodes are initialized at device_initcall in the appropriately
> >> named routine numa_init_late().  hugetlb_init must be done after numa
> >> initialization.  So, I suggest we just move the hugetlb initialization
> >> back to device_initcall.  What do you think Paul?  Patch below.
> > 
> > We could, but that ignores the fact that the original priorities worked
> > by chance and not by design, as my commit log indicates.  Instead, I'd
> > like to know why S390 does core NUMA operations as late as
> > device_initcall.   Setting up NUMA nodes should be arch_initcall or
> > subsys_initcall, or earlier --- it should not be device_initcall as if
> > it was some leaf node UART driver or ethernet driver.  There is no
> > endpoint "device" in NUMA in this context.
> 
> This is in linux-next after 4.5-rc1
> 
> commit 2d0f76a6ca1f2cdcffca7ce130f67ec61caa0999
> Author: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
> Date:   Wed Jan 20 19:22:16 2016 +0100
> 
>     s390/numa: move numa_init_late() from device to arch_initcall

Nice.  Too bad one of us didn't see this a few hours earlier, but oh
well.  At least it backs up what I said above.

Thanks,
Paul.
--

> 
>     Commit 3e89e1c5ea ("hugetlb: make mm and fs code explicitly
> non-modular")
>     moves hugetlb_init() from module_init to subsys_initcall.
> 
>     The hugetlb_init()->hugetlb_register_node() code accesses
> "node->dev.kobj"
>     which is initialized in numa_init_late().
> 
>     Since numa_init_late() is a device_initcall which is called *after*
>     subsys_initcall the above mentioned patch breaks NUMA on s390.
> 
>     So fix this and move numa_init_late() to arch_initcall.
> 
>     Fixes: 3e89e1c5ea ("hugetlb: make mm and fs code explicitly
> non-modular")
>     Reviewed-by: Heiko Carstens <heiko.carstens@...ibm.com>
>     Signed-off-by: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
>     Signed-off-by: Martin Schwidefsky <schwidefsky@...ibm.com>
> 
> -- 
> Mike Kravetz