linux-kernel - Re: [PATCH V2] mm/page_alloc: Add alloc_contig

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 for Android: free password hash cracker in your pocket

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

Message-ID: <c60b9e95-5c6c-fcb2-c8bb-13e7646ba8ea@arm.com>
Date:   Thu, 17 Oct 2019 10:44:41 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     David Hildenbrand <david@...hat.com>,
        Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, Mike Kravetz <mike.kravetz@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Rientjes <rientjes@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Oscar Salvador <osalvador@...e.de>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Pavel Tatashin <pavel.tatashin@...rosoft.com>,
        Matthew Wilcox <willy@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages()



On 10/16/2019 10:18 PM, David Hildenbrand wrote:
> On 16.10.19 17:31, Anshuman Khandual wrote:
>>
>>
>> On 10/16/2019 06:11 PM, Michal Hocko wrote:
>>> On Wed 16-10-19 14:29:05, David Hildenbrand wrote:
>>>> On 16.10.19 13:51, Michal Hocko wrote:
>>>>> On Wed 16-10-19 16:43:57, Anshuman Khandual wrote:
>>>>>>
>>>>>>
>>>>>> On 10/16/2019 04:39 PM, David Hildenbrand wrote:
>>>>> [...]
>>>>>>> Just to make sure, you ignored my comment regarding alignment
>>>>>>> although I explicitly mentioned it a second time? Thanks.
>>>>>>
>>>>>> I had asked Michal explicitly what to be included for the respin. Anyways
>>>>>> seems like the previous thread is active again. I am happy to incorporate
>>>>>> anything new getting agreed on there.
>>>>>
>>>>> Your patch is using the same alignment as the original code would do. If
>>>>> an explicit alignement is needed then this can be added on top, right?
>>>>>
>>>>
>>>> Again, the "issue" I see here is that we could now pass in numbers that are
>>>> not a power of two. For gigantic pages it was clear that we always have a
>>>> number of two. The alignment does not make any sense otherwise.
>>
>> ALIGN() does expect nr_pages two be power of two otherwise the mask
>> value might not be correct, affecting start pfn value for a zone.
>>
>> #define ALIGN(x, a)                 __ALIGN_KERNEL((x), (a))
>> #define __ALIGN_KERNEL(x, a)            __ALIGN_KERNEL_MASK(x, (typeof(x))(a) - 1)
>> #define __ALIGN_KERNEL_MASK(x, mask)    (((x) + (mask)) & ~(mask))
>>
>>>>
>>>> What I'm asking for is
>>>>
>>>> a) Document "The resulting PFN is aligned to nr_pages" and "nr_pages should
>>>> be a power of two".
>>>
>>> OK, this makes sense.
>> Sure, will add this to the alloc_contig_pages() helper description and
>> in the commit message as well.
> 
> As long as it is documented that implicit alignment will happen, fine with me.
> 
> The thing about !is_power_of2() is that we usually don't need an alignment there (or instead an explicit one). And as I mentioned, the current function might fail easily to allocate a suitable range due to the way the search works (== check aligned blocks only). The search really only provides reliable results when size==alignment and it's a power of two IMHO. Not documenting that is in my opinion misleading - somebody who wants !is_power_of2() and has no alignment requirements should probably rework the function first.
> 
> So with some documentation regarding that

Does this add-on documentation look okay ? Should we also mention about the
possible reduction in chances of success during pfn block search for the
non-power-of-two cases as the implicit alignment will probably turn out to
be bigger than nr_pages itself ?

 * Requested nr_pages may or may not be power of two. The search for suitable
 * memory range in a zone happens in nr_pages aligned pfn blocks. But in case
 * when nr_pages is not power of two, an implicitly aligned pfn block search
 * will happen which in turn will impact allocated memory block's alignment.
 * In these cases, the size (i.e nr_pages) and the alignment of the allocated
 * memory will be different. This problem does not exist when nr_pages is power
 * of two where the size and the alignment of the allocated memory will always
 * be nr_pages.

> 
> Acked-by: David Hildenbrand <david@...hat.com>
>