| Message ID | 20220413032915.251254-4-liupeng256@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | hugetlb: Fix some incorrect behavior | expand |
On 4/13/2022 11:29 AM, Peng Liu wrote: > When __setup() return '0', using invalid option values causes the > entire kernel boot option string to be reported as Unknown. Hugetlb > calls __setup() and will return '0' when set invalid parameter > string. > > The following phenomenon is observed: > cmdline: > hugepagesz=1Y hugepages=1 > dmesg: > HugeTLB: unsupported hugepagesz=1Y > HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring > Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" > > Since hugetlb will print warning/error information before return for > invalid parameter string, just use return '1' to avoid print again. > > Signed-off-by: Peng Liu <liupeng256@huawei.com> LGTM. Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
On Wed, Apr 13, 2022 at 03:29:14AM +0000, Peng Liu wrote: > When __setup() return '0', using invalid option values causes the > entire kernel boot option string to be reported as Unknown. Hugetlb > calls __setup() and will return '0' when set invalid parameter > string. > > The following phenomenon is observed: > cmdline: > hugepagesz=1Y hugepages=1 > dmesg: > HugeTLB: unsupported hugepagesz=1Y > HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring > Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" > > Since hugetlb will print warning/error information before return for > invalid parameter string, just use return '1' to avoid print again. > Can't return -EINVAL? It is weird to return 1 on failure. Thanks.
On 2022/4/13 15:55, Muchun Song wrote: > On Wed, Apr 13, 2022 at 03:29:14AM +0000, Peng Liu wrote: >> When __setup() return '0', using invalid option values causes the >> entire kernel boot option string to be reported as Unknown. Hugetlb >> calls __setup() and will return '0' when set invalid parameter >> string. >> >> The following phenomenon is observed: >> cmdline: >> hugepagesz=1Y hugepages=1 >> dmesg: >> HugeTLB: unsupported hugepagesz=1Y >> HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring >> Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" >> >> Since hugetlb will print warning/error information before return for >> invalid parameter string, just use return '1' to avoid print again. >> > Can't return -EINVAL? It is weird to return 1 on failure. > > Thanks. > > . Not against "return -EINVAL", but consistent with: 1d02b444b8d1 ("tracing: Fix return value of __setup handlers")
On Wed, Apr 13, 2022 at 04:16:11PM +0800, liupeng (DM) wrote: > > On 2022/4/13 15:55, Muchun Song wrote: > > On Wed, Apr 13, 2022 at 03:29:14AM +0000, Peng Liu wrote: > > > When __setup() return '0', using invalid option values causes the > > > entire kernel boot option string to be reported as Unknown. Hugetlb > > > calls __setup() and will return '0' when set invalid parameter > > > string. > > > > > > The following phenomenon is observed: > > > cmdline: > > > hugepagesz=1Y hugepages=1 > > > dmesg: > > > HugeTLB: unsupported hugepagesz=1Y > > > HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring > > > Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" > > > > > > Since hugetlb will print warning/error information before return for > > > invalid parameter string, just use return '1' to avoid print again. > > > > > Can't return -EINVAL? It is weird to return 1 on failure. > > > > Thanks. > > > > . > > Not against "return -EINVAL", but consistent with: > 1d02b444b8d1 ("tracing: Fix return value of __setup handlers") I think it is better not return 1. I don't think it's a good habit we should follow. Thanks. Thanks.
On 2022/4/13 16:21, Muchun Song wrote: > On Wed, Apr 13, 2022 at 04:16:11PM +0800, liupeng (DM) wrote: >> On 2022/4/13 15:55, Muchun Song wrote: >>> On Wed, Apr 13, 2022 at 03:29:14AM +0000, Peng Liu wrote: >>>> When __setup() return '0', using invalid option values causes the >>>> entire kernel boot option string to be reported as Unknown. Hugetlb >>>> calls __setup() and will return '0' when set invalid parameter >>>> string. >>>> >>>> The following phenomenon is observed: >>>> cmdline: >>>> hugepagesz=1Y hugepages=1 >>>> dmesg: >>>> HugeTLB: unsupported hugepagesz=1Y >>>> HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring >>>> Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" >>>> >>>> Since hugetlb will print warning/error information before return for >>>> invalid parameter string, just use return '1' to avoid print again. >>>> >>> Can't return -EINVAL? It is weird to return 1 on failure. >>> >>> Thanks. >>> >>> . >> Not against "return -EINVAL", but consistent with: >> 1d02b444b8d1 ("tracing: Fix return value of __setup handlers") > I think it is better not return 1. I don't think it's a good habit we > should follow. /* * NOTE: __setup functions return values: * @fn returns 1 (or non-zero) if the option argument is "handled" * and returns 0 if the option argument is "not handled". */ #define __setup(str, fn) \ __setup_param(str, fn, fn, 0) 1 or -EINVAL should ok, and most __setup return 1 for know ;) > Thanks. > > Thanks. > > .
On Wed, Apr 13, 2022 at 04:45:30PM +0800, Kefeng Wang wrote: > > On 2022/4/13 16:21, Muchun Song wrote: > > On Wed, Apr 13, 2022 at 04:16:11PM +0800, liupeng (DM) wrote: > > > On 2022/4/13 15:55, Muchun Song wrote: > > > > On Wed, Apr 13, 2022 at 03:29:14AM +0000, Peng Liu wrote: > > > > > When __setup() return '0', using invalid option values causes the > > > > > entire kernel boot option string to be reported as Unknown. Hugetlb > > > > > calls __setup() and will return '0' when set invalid parameter > > > > > string. > > > > > > > > > > The following phenomenon is observed: > > > > > cmdline: > > > > > hugepagesz=1Y hugepages=1 > > > > > dmesg: > > > > > HugeTLB: unsupported hugepagesz=1Y > > > > > HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring > > > > > Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" > > > > > > > > > > Since hugetlb will print warning/error information before return for > > > > > invalid parameter string, just use return '1' to avoid print again. > > > > > > > > > Can't return -EINVAL? It is weird to return 1 on failure. > > > > > > > > Thanks. > > > > > > > > . > > > Not against "return -EINVAL", but consistent with: > > > 1d02b444b8d1 ("tracing: Fix return value of __setup handlers") > > I think it is better not return 1. I don't think it's a good habit we > > should follow. > /* > * NOTE: __setup functions return values: > * @fn returns 1 (or non-zero) if the option argument is "handled" > * and returns 0 if the option argument is "not handled". > */ > #define __setup(str, fn) \ > __setup_param(str, fn, fn, 0) > > > 1 or -EINVAL should ok, and most __setup return 1 for know ;) > Got it. Thanks. Seems like a lot of users make mistakes in this regard [1]. Reviewed-by: Muchun Song <songmuchun@bytedance.com> [1] https://lore.kernel.org/all/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru/
On 4/12/22 20:29, Peng Liu wrote: > When __setup() return '0', using invalid option values causes the > entire kernel boot option string to be reported as Unknown. Hugetlb > calls __setup() and will return '0' when set invalid parameter > string. > > The following phenomenon is observed: > cmdline: > hugepagesz=1Y hugepages=1 > dmesg: > HugeTLB: unsupported hugepagesz=1Y > HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring > Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" > > Since hugetlb will print warning/error information before return for > invalid parameter string, just use return '1' to avoid print again. > > Signed-off-by: Peng Liu <liupeng256@huawei.com> > --- > mm/hugetlb.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) Thank you for cleaning this up! Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
On Wed, 13 Apr 2022, Peng Liu wrote: >When __setup() return '0', using invalid option values causes the >entire kernel boot option string to be reported as Unknown. Hugetlb >calls __setup() and will return '0' when set invalid parameter >string. > >The following phenomenon is observed: > cmdline: > hugepagesz=1Y hugepages=1 > dmesg: > HugeTLB: unsupported hugepagesz=1Y > HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring > Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" > >Since hugetlb will print warning/error information before return for >invalid parameter string, just use return '1' to avoid print again. > >Signed-off-by: Peng Liu <liupeng256@huawei.com> >Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> >Reviewed-by: Muchun Song <songmuchun@bytedance.com> >Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 1930b6341f7e..2e4d8d9fb7c6 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4149,7 +4149,7 @@ static int __init hugepages_setup(char *s) if (!parsed_valid_hugepagesz) { pr_warn("HugeTLB: hugepages=%s does not follow a valid hugepagesz, ignoring\n", s); parsed_valid_hugepagesz = true; - return 0; + return 1; } /* @@ -4165,7 +4165,7 @@ static int __init hugepages_setup(char *s) if (mhp == last_mhp) { pr_warn("HugeTLB: hugepages= specified twice without interleaving hugepagesz=, ignoring hugepages=%s\n", s); - return 0; + return 1; } while (*p) { @@ -4176,7 +4176,7 @@ static int __init hugepages_setup(char *s) if (p[count] == ':') { if (!hugetlb_node_alloc_supported()) { pr_warn("HugeTLB: architecture can't support node specific alloc, ignoring!\n"); - return 0; + return 1; } if (!node_online(tmp)) goto invalid; @@ -4218,7 +4218,7 @@ static int __init hugepages_setup(char *s) invalid: pr_warn("HugeTLB: Invalid hugepages parameter %s\n", p); hugepages_clear_pages_in_node(); - return 0; + return 1; } __setup("hugepages=", hugepages_setup); @@ -4239,7 +4239,7 @@ static int __init hugepagesz_setup(char *s) if (!arch_hugetlb_valid_size(size)) { pr_err("HugeTLB: unsupported hugepagesz=%s\n", s); - return 0; + return 1; } h = size_to_hstate(size); @@ -4254,7 +4254,7 @@ static int __init hugepagesz_setup(char *s) if (!parsed_default_hugepagesz || h != &default_hstate || default_hstate.max_huge_pages) { pr_warn("HugeTLB: hugepagesz=%s specified twice, ignoring\n", s); - return 0; + return 1; } /* @@ -4285,14 +4285,14 @@ static int __init default_hugepagesz_setup(char *s) parsed_valid_hugepagesz = false; if (parsed_default_hugepagesz) { pr_err("HugeTLB: default_hugepagesz previously specified, ignoring %s\n", s); - return 0; + return 1; } size = (unsigned long)memparse(s, NULL); if (!arch_hugetlb_valid_size(size)) { pr_err("HugeTLB: unsupported default_hugepagesz=%s\n", s); - return 0; + return 1; } hugetlb_add_hstate(ilog2(size) - PAGE_SHIFT);
When __setup() return '0', using invalid option values causes the entire kernel boot option string to be reported as Unknown. Hugetlb calls __setup() and will return '0' when set invalid parameter string. The following phenomenon is observed: cmdline: hugepagesz=1Y hugepages=1 dmesg: HugeTLB: unsupported hugepagesz=1Y HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" Since hugetlb will print warning/error information before return for invalid parameter string, just use return '1' to avoid print again. Signed-off-by: Peng Liu <liupeng256@huawei.com> --- mm/hugetlb.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)