linux-kernel - Re: [PATCH] powerpc/mm: Implemented default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 05 Jul 2017 13:09:42 -0300
From:   victora <victora@...ux.vnet.ibm.com>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:     Victor Aoqui <victora@...ibm.com>, linux-kernel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, aneesh.kumar@...ux.vnet.ibm.com,
        mpe@...erman.id.au
Subject: Re: [PATCH] powerpc/mm: Implemented default_hugepagesz verification
 for powerpc

Em 2017-07-05 01:31, Anshuman Khandual escreveu:
> On 07/04/2017 01:35 AM, Victor Aoqui wrote:
>> Implemented default hugepage size verification (default_hugepagesz=)
>> in order to allow allocation of defined number of pages (hugepages=)
>> only for supported hugepage sizes.
>> 
>> Signed-off-by: Victor Aoqui <victora@...ibm.com>
>> ---
>>  arch/powerpc/mm/hugetlbpage.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>> 
>> diff --git a/arch/powerpc/mm/hugetlbpage.c 
>> b/arch/powerpc/mm/hugetlbpage.c
>> index a4f33de..464e72e 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -797,6 +797,21 @@ static int __init hugepage_setup_sz(char *str)
>>  }
>>  __setup("hugepagesz=", hugepage_setup_sz);
>> 
>> +static int __init default_hugepage_setup_sz(char *str)
> 
> The function name should be hugetlb_default_size_setup in
> sync with the generic function hugetlb_default_setup for the
> same parameter default_hugepagesz.
> 

Yes, makes sense to me.

>> +{
>> +        unsigned long long size;
>> +
>> +        size = memparse(str, &str);
>> +
>> +        if (add_huge_page_size(size) != 0) {
> 
> I am little bit confused here. Do we always follow another
> 'hugepages=' element after 'default_hugepagesz' ? If not,
> then we dont have to do 'add_huge_page_size'. But then
> that function checks for valid huge page sizes and skips
> adding hstate if its already added. So I guess it okay.
> 

'default_hugepagesz=' is not always followed by 'hugepages=', but if we 
specify 'hugepages=' along with 'default_hugepagesz=' it will try to 
allocate the hugepage size specified. If the size is not supported by 
hardware, it will try to allocate the number of pages specified with the 
default hugepage size of the arch, which is not the desired behavior. So 
calling add_huge_page_size would verify if the hugepage size is 
supported and in case it's not, hugepages will not be allocated.

>> +                hugetlb_bad_size();
>> +                pr_err("Invalid default huge page size 
>> specified(%llu)\n", size);
> 
> Error message should have 'ppc' some where to indicate that
> the arch rejected the size not core MM.