linux-kernel - Re: [RFC 3/8] mm: Isolate coherent device memory nodes from HugeTLB allocation paths

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]

Date:   Tue, 25 Oct 2016 18:25:49 +1100
From:   Balbir Singh <bsingharora@...il.com>
To:     "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Cc:     mhocko@...e.com, js1304@...il.com, vbabka@...e.cz, mgorman@...e.de,
        minchan@...nel.org, akpm@...ux-foundation.org
Subject: Re: [RFC 3/8] mm: Isolate coherent device memory nodes from HugeTLB
 allocation paths



On 25/10/16 18:17, Balbir Singh wrote:
> 
> 
> On 25/10/16 15:15, Aneesh Kumar K.V wrote:
>> Dave Hansen <dave.hansen@...el.com> writes:
>>
>>> On 10/23/2016 09:31 PM, Anshuman Khandual wrote:
>>>> This change is part of the isolation requiring coherent device memory nodes
>>>> implementation.
>>>>
>>>> Isolation seeking coherent device memory node requires allocation isolation
>>>> from implicit memory allocations from user space. Towards that effect, the
>>>> memory should not be used for generic HugeTLB page pool allocations. This
>>>> modifies relevant functions to skip all coherent memory nodes present on
>>>> the system during allocation, freeing and auditing for HugeTLB pages.
>>>
>>> This seems really fragile.  You had to hit, what, 18 call sites?  What
>>> are the odds that this is going to stay working?
>>
>>
>> I guess a better approach is to introduce new node_states entry such
>> that we have one that excludes coherent device memory numa nodes. One
>> possibility is to add N_SYSTEM_MEMORY and N_MEMORY.
>>
>> Current N_MEMORY becomes N_SYSTEM_MEMORY and N_MEMORY includes
>> system and device/any other memory which is coherent.
>>
> 
> I thought of this as well, but I would rather see N_COHERENT_MEMORY
> as a flag. The idea being that some device memory is a part of
> N_MEMORY, but N_COHERENT_MEMORY gives it additional attributes
> 
>> All the isolation can then be achieved based on the nodemask_t used for
>> allocation. So for allocations we want to avoid from coherent device we
>> use N_SYSTEM_MEMORY mask or a derivative of that and where we are ok to
>> allocate from CDM with fallbacks we use N_MEMORY.
>>
> 
> I suspect its going to be easier to exclude N_COHERENT_MEMORY.
> 
>> All nodes zonelist will have zones from the coherent device nodes but we
>> will not end up allocating from coherent device node zone due to the
>> node mask used.
>>
>>
>> This will also make sure we end up allocating from the correct coherent
>> device numa node in the presence of multiple of them based on the
>> distance of the coherent device node from the current executing numa
>> node.
>>
> 
> The idea is good overall, but I think its going to be good to document
> the exclusions with the flags
> 

FWIW,, some of this is present in 8/8

Balbir