[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56AA939D.6080104@oracle.com>
Date: Thu, 28 Jan 2016 14:18:05 -0800
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Paul Gortmaker <paul.gortmaker@...driver.com>,
Christian Borntraeger <borntraeger@...ibm.com>
Cc: 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)
On 01/28/2016 07:05 AM, Mike Kravetz wrote:
> On 01/28/2016 06:37 AM, 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 10:48) Christian Borntraeger wrote:
>>
>>> On 01/28/2016 10:40 AM, Hillf Danton wrote:
>>>>>
>>>>> Paul,
>>>>>
>>>>> the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular")
>>>>> triggers belows warning/oops, if CONFIG_TIMER_STATS is set.
>>>>>
>>>>> Looking at the patch the only "real" change is the init_call,
>>>>> and indeed
>>>>> --- a/mm/hugetlb.c
>>>>> +++ b/mm/hugetlb.c
>>>>> @@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
>>>>> mutex_init(&hugetlb_fault_mutex_table[i]);
>>>>> return 0;
>>>>> }
>>>>> -subsys_initcall(hugetlb_init);
>>>>> +device_initcall(hugetlb_init);
>>>>>
>>>>> /* Should be called on processing a hugepagesz=... option */
>>>>> void __init hugetlb_add_hstate(unsigned int order)
>>>>>
>>>>> makes the problem go away.
>>>>
>>>> Helps more if a patch is delivered.
>>>
>>> The problem is that the original change was intentional. So I do not not
>>> what the right fix is.
>>
>> Thanks for the report ; let me see if I can work out what TIMER_STATS
>> is doing to cause this sometime today.
>>
>
> Hmmm? CONFIG_TIMER_STATS is set in my config and I am not seeing the
> issue. Not sure, but it looks like Christian is building/running on
> s390. This 'might' be a contributing factor.
I do not see how CONFIG_TIMER_STATS contributes to this issue. However,
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.
Is there a way to add checks for this type of thing in the code? I'm
guessing not.
--
Mike Kravetz
hugetlb: move hugetlb_init and init_hugetlbfs_fs to device_initcall level
hugetlb_init() must be called after numa initialization for all
architectures. Currently, numa initialization happens as late as
device_initcall. Therefore, move hugetlb_init to device_initcall
level. init_hugetlbfs_fs() depends on hugetlb_init(), so move it
to device_initcall as well.
Fixes: 3e89e1c5ea ("hugetlb: make mm and fs code explicitly non-modular")
Reported-by: Christian Borntraeger <borntraeger@...ibm.com>
Signed-off-by: Mike Kravetz <mike.kravetz@...cle.com>
---
fs/hugetlbfs/inode.c | 3 ++-
mm/hugetlb.c | 6 +++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 540ddc9..d27d3f6 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1363,4 +1363,5 @@ static int __init init_hugetlbfs_fs(void)
out2:
return error;
}
-fs_initcall(init_hugetlbfs_fs)
+/* Must happen after hugetlb_init() */
+device_initcall(init_hugetlbfs_fs)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 12908dc..a4c0015 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2653,7 +2653,11 @@ static int __init hugetlb_init(void)
mutex_init(&hugetlb_fault_mutex_table[i]);
return 0;
}
-subsys_initcall(hugetlb_init);
+/*
+ * hugetlb_init must be called after numa initialization for all
architectures.
+ * Currently, this is as late as device_initcall().
+ */
+device_initcall(hugetlb_init);
/* Should be called on processing a hugepagesz=... option */
void __init hugetlb_add_hstate(unsigned int order)
--
2.4.3
Powered by blists - more mailing lists