linux-kernel - Re: [PATCH] mm/hugetlb: avoid weird message in hugetlb

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]

Message-ID: <aec9dc31-6858-3d3d-405e-8fc270167c4f@redhat.com>
Date:   Mon, 13 Apr 2020 17:21:41 -0400
From:   Nitesh Narayan Lal <nitesh@...hat.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>,
        "Longpeng (Mike)" <longpeng2@...wei.com>
Cc:     arei.gonglei@...wei.com, huangzhichao@...wei.com,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Qian Cai <cai@....pw>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH] mm/hugetlb: avoid weird message in hugetlb_init


On 4/13/20 2:33 PM, Mike Kravetz wrote:
> On 4/10/20 8:47 AM, Nitesh Narayan Lal wrote:
>> Hi Mike,
>>
>> On platforms that support multiple huge page sizes when 'hugepagesz' is not
>> specified before 'hugepages=', hugepages are not allocated. (For example
>> if we are requesting 1GB hugepages)
> Hi Nitesh,
>
> This should only be an issue with gigantic huge pages.  This is because
> hugepages=X not following a hugepagesz=Y specifies the number of huge pages
> of default size to allocate.  It does not currently work for gigantic pages.

I see, since we changed the default hugepages to gigantic pages and we missed
'hugepagesz=' no page were allocated of any type.

> In the other thread, I provided this explanation as to why:
> It comes about because we do not definitively set the default huge page size
> until after command line processing (in hugetlb_init).  And, we must
> preallocate gigantic huge pages during command line processing because that
> is when the bootmem allocater is available.
>
> I will be looking into modifying this behavior to allocate the pages as
> expected, even for gigantic pages.

Nice, looking forward to it.

>
>> In terms of reporting meminfo and /sys/kernel/../nr_hugepages reports the
>> expected results but if we use sysctl vm.nr_hugepages then it reports a non-zero
>> value as it reads the max_huge_pages from the default hstate instead of
>> nr_huge_pages.
>> AFAIK nr_huge_pages is the one that indicates the number of huge pages that are
>> successfully allocated.
>>
>> Does vm.nr_hugepages is expected to report the maximum number of hugepages? If
>> so, will it not make sense to rename the procname?
>>
>> However, if we expect nr_hugepages to report the number of successfully
>> allocated hugepages then we should use nr_huge_pages in
>> hugetlb_sysctl_handler_common().
> This looks like a bug.  Neither sysctl or the /proc file should be reporting
> a non-zero value if huge pages do not exist.

Yeap, as I mentioned it reports max_huge_pages instead of the nr_huge_pages.

-- 
Thanks
Nitesh



Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)