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. -- Mike Kravetz > > Some other tests for current linux-master: > > cmdline: > hugepagesz=1G hugepages=1 hugepagesz=1G hugepages=2 > dmesg: > HugeTLB: hugepagesz=1G specified twice, ignoring > Unknown kernel command line parameters " hugepagesz=1G hugepages=2" > > 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" > > -- > Peng Liu > .
