Messages in this thread Patch in this message | | | Date | Thu, 31 Mar 2022 14:11:30 -0700 | Subject | Re: [PATCH] hugetlb: Fix hugepages_setup when deal with pernode | From | Mike Kravetz <> |
| |
On 3/31/22 04:23, liupeng (DM) wrote: > On 2022/3/30 1:43, Mike Kravetz wrote: >> On 3/28/22 20:59, liupeng (DM) wrote: >>> On 2022/3/29 10:46, Mike Kravetz wrote: >>>> Yes, I agree that the change is needed and the current behavior is >>>> unacceptable. >>>> >>>> One remaining question is the change from returning '0' to '1' in the case >>>> of error. I do understand this is to prevent the invalid parameter string >>>> from being passed to init. It may not be correct/right, but in every other >>>> case where an invalid parameter in encountered in hugetlb command line >>>> processing we return "0". Should we perhaps change all these other places >>>> to be consistent? I honestly do not know what is the appropriate behavior >>>> in these situations. >>> Thank you for your carefulness and question. >>> >>> I have checked default_hugepagesz_setup and hugepages_setup will both print >>> some information before return '0', so there is no need to print again in >>> "Unknown kernel command line parameters". >>> >>> Should I send another patch to repair the rest "return 0" in hugetlb? >> I would suggest two patches: >> >> 1) Fix the issue with invalid nodes specified. However, leave the "return 0" >> behavior in hugepages_setup to be consistent with the rest of the code. >> This patch can be sent to stable with "Fixes: b5389086ad7b" tag as it >> addresses an existing issue. >> 2) Clean up the places where we return 0 and it would be better to return 1. >> No cc stable here and just let the changes target future releases. > I have tried to write a patch as your suggestion, but the best way I can carry it > out is the original patch. To meet "Fix invalid nodes issue and leave thereturn > 0 behavior", I have to add the following redundant code: > > invalid: > pr_warn("HugeTLB: Invalid hugepages parameter %s\n", p); > + > + /* Allocate gigantic hstates for successfully parsed parameters*/ > + if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate)) > + hugetlb_hstate_alloc_pages(parsed_hstate); > + last_mhp = mhp; > return 0; >
I was thinking something like the attached (untested). It is very similar to your original code.
-- Mike Kravetzdiff --git a/mm/hugetlb.c b/mm/hugetlb.c index f294db835f4b..4deea62dbbac 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4126,6 +4126,7 @@ static int __init hugepages_setup(char *s) int count; unsigned long tmp; char *p = s; + int ret = 1; if (!parsed_valid_hugepagesz) { pr_warn("HugeTLB: hugepages=%s does not follow a valid hugepagesz, ignoring\n", s); @@ -4184,6 +4185,7 @@ static int __init hugepages_setup(char *s) } } +out: /* * Global state is always initialized later in hugetlb_init. * But we need to allocate gigantic hstates here early to still @@ -4194,11 +4196,12 @@ static int __init hugepages_setup(char *s) last_mhp = mhp; - return 1; + return ret; invalid: pr_warn("HugeTLB: Invalid hugepages parameter %s\n", p); - return 0; + ret = 0; + goto out; } __setup("hugepages=", hugepages_setup); | |