NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
first determining whether it should be allocated in the stack or dinamically
depending on NODES_SHIFT.
Right now, it goes the dynamic path whenever the nodemask_t is above 32
bytes.
Although we could bump it to a reasonable value, the largest a nodemask_t
can get is 128 bytes, so since __nr_hugepages_store_common is called from
a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
This reduces some code churn and complexity.
Signed-off-by: Oscar Salvador <[email protected]>
---
mm/hugetlb.c | 36 +++++++++++-------------------------
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f79ae4e42159..9cb2f91af897 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2447,44 +2447,30 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
unsigned long count, size_t len)
{
int err;
- NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
+ nodemask_t nodes_allowed, *n_mask;
- if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) {
- err = -EINVAL;
- goto out;
- }
+ if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
+ return -EINVAL;
if (nid == NUMA_NO_NODE) {
/*
* global hstate attribute
*/
if (!(obey_mempolicy &&
- init_nodemask_of_mempolicy(nodes_allowed))) {
- NODEMASK_FREE(nodes_allowed);
- nodes_allowed = &node_states[N_MEMORY];
- }
- } else if (nodes_allowed) {
+ init_nodemask_of_mempolicy(&nodes_allowed)))
+ n_mask = &node_states[N_MEMORY];
+ else
+ n_mask = &nodes_allowed;
+ } else {
/*
* Node specific request. count adjustment happens in
* set_max_huge_pages() after acquiring hugetlb_lock.
*/
- init_nodemask_of_node(nodes_allowed, nid);
- } else {
- /*
- * Node specific request, but we could not allocate the few
- * words required for a node mask. We are unlikely to hit
- * this condition. Since we can not pass down the appropriate
- * node mask, just return ENOMEM.
- */
- err = -ENOMEM;
- goto out;
+ init_nodemask_of_node(&nodes_allowed, nid);
+ n_mask = &nodes_allowed;
}
- err = set_max_huge_pages(h, count, nid, nodes_allowed);
-
-out:
- if (nodes_allowed != &node_states[N_MEMORY])
- NODEMASK_FREE(nodes_allowed);
+ err = set_max_huge_pages(h, count, nid, n_mask);
return err ? err : len;
}
--
2.13.7
On Tue, 2 Apr 2019 15:34:15 +0200 Oscar Salvador <[email protected]> wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
> first determining whether it should be allocated in the stack or dinamically
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
>
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
>
> This reduces some code churn and complexity.
It took a bit of sleuthing to figure out that this patch applies to
Mike's "hugetlbfs: fix potential over/underflow setting node specific
nr_hugepages". Should they be folded together? I'm thinking not.
(Also, should "hugetlbfs: fix potential over/underflow setting node
specific nr_hugepages" have been -stableified? I also think not, but I
bet it happens anyway).
On Tue, 2019-04-02 at 13:01 -0700, Andrew Morton wrote:
> It took a bit of sleuthing to figure out that this patch applies to
> Mike's "hugetlbfs: fix potential over/underflow setting node specific
> nr_hugepages". Should they be folded together? I'm thinking not.
Sorry Andrew, I should have mentioned that this patch was based on
Mike's "hugetlb fix potential over/underflow" patch.
Given said that, I would keep the two patches separated, as that one
is a fix, and this one is a cleanup.
> (Also, should "hugetlbfs: fix potential over/underflow setting node
> specific nr_hugepages" have been -stableified? I also think not, but
> I
> bet it happens anyway).
I am not sure of the consequences in older branches, but if it is not
too much of a hassle, it might be worth? Mike might know better here.
--
Oscar Salvador
SUSE L3
On 4/2/19 6:34 AM, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
^
> first determining whether it should be allocated in the stack or dinamically
^
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
>
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
^
In addition, the possible call stacks after this routine are not too deep.
Worst case is high order page allocation.
>
> This reduces some code churn and complexity.
>
> Signed-off-by: Oscar Salvador <[email protected]>
Not a huge deal, but a few typos in the commit message. Thanks for the
clean up.
Reviewed-by: Mike Kravetz <[email protected]>
--
Mike Kravetz
On 4/2/19 1:01 PM, Andrew Morton wrote:
> On Tue, 2 Apr 2019 15:34:15 +0200 Oscar Salvador <[email protected]> wrote:
>
>> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
>> first determining whether it should be allocated in the stack or dinamically
>> depending on NODES_SHIFT.
>> Right now, it goes the dynamic path whenever the nodemask_t is above 32
>> bytes.
>>
>> Although we could bump it to a reasonable value, the largest a nodemask_t
>> can get is 128 bytes, so since __nr_hugepages_store_common is called from
>> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
>>
>> This reduces some code churn and complexity.
>
> It took a bit of sleuthing to figure out that this patch applies to
> Mike's "hugetlbfs: fix potential over/underflow setting node specific
> nr_hugepages". Should they be folded together? I'm thinking not.
No need to fold. They are separate issues and that over/underflow patch
may already be doing too many things.
> (Also, should "hugetlbfs: fix potential over/underflow setting node
> specific nr_hugepages" have been -stableified? I also think not, but I
> bet it happens anyway).
I don't see a great reason for sending to stable. IIRC, nobody actually
hit this issue: it was found through code inspection.
--
Mike Kravetz
On Tue, Apr 02, 2019 at 03:34:15PM +0200, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
> first determining whether it should be allocated in the stack or dinamically
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
>
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
>
> This reduces some code churn and complexity.
>
> Signed-off-by: Oscar Salvador <[email protected]>
nice cleanup.
Reviewed-by: Naoya Horiguchi <[email protected]>
On 04/02/19 at 03:34pm, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
~ and
> first determining whether it should be allocated in the stack or dinamically
dynamically^^
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
>
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
>
> This reduces some code churn and complexity.
>
> Signed-off-by: Oscar Salvador <[email protected]>
> ---
> mm/hugetlb.c | 36 +++++++++++-------------------------
> 1 file changed, 11 insertions(+), 25 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index f79ae4e42159..9cb2f91af897 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2447,44 +2447,30 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
> unsigned long count, size_t len)
> {
> int err;
> - NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
> + nodemask_t nodes_allowed, *n_mask;
>
> - if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) {
> - err = -EINVAL;
> - goto out;
> - }
> + if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
> + return -EINVAL;
>
> if (nid == NUMA_NO_NODE) {
> /*
> * global hstate attribute
> */
> if (!(obey_mempolicy &&
> - init_nodemask_of_mempolicy(nodes_allowed))) {
> - NODEMASK_FREE(nodes_allowed);
> - nodes_allowed = &node_states[N_MEMORY];
> - }
> - } else if (nodes_allowed) {
> + init_nodemask_of_mempolicy(&nodes_allowed)))
> + n_mask = &node_states[N_MEMORY];
> + else
> + n_mask = &nodes_allowed;
> + } else {
> /*
> * Node specific request. count adjustment happens in
> * set_max_huge_pages() after acquiring hugetlb_lock.
> */
> - init_nodemask_of_node(nodes_allowed, nid);
> - } else {
> - /*
> - * Node specific request, but we could not allocate the few
> - * words required for a node mask. We are unlikely to hit
> - * this condition. Since we can not pass down the appropriate
> - * node mask, just return ENOMEM.
> - */
> - err = -ENOMEM;
> - goto out;
> + init_nodemask_of_node(&nodes_allowed, nid);
> + n_mask = &nodes_allowed;
> }
>
> - err = set_max_huge_pages(h, count, nid, nodes_allowed);
> -
> -out:
> - if (nodes_allowed != &node_states[N_MEMORY])
> - NODEMASK_FREE(nodes_allowed);
> + err = set_max_huge_pages(h, count, nid, n_mask);
>
> return err ? err : len;
> }
> --
> 2.13.7
>