linux-kernel - Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

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: <ea011a3d-d9f8-77b7-9624-f2ae4777f019@shipmail.org>
Date:   Tue, 23 Mar 2021 16:05:08 +0100
From:   Thomas Hellström (Intel) 
        <thomas_os@...pmail.org>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     dri-devel@...ts.freedesktop.org,
        Christian Koenig <christian.koenig@....com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages


On 3/23/21 2:52 PM, Jason Gunthorpe wrote:
> On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellström (Intel) wrote:
>> diff --git a/mm/gup.c b/mm/gup.c
>> index e40579624f10..1b6a127f0bdd 100644
>> +++ b/mm/gup.c
>> @@ -1993,6 +1993,17 @@ static void __maybe_unused undo_dev_pagemap(int *nr, int nr_start,
>>   }
>>   
>>   #ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
>> +/*
>> + * If we can't determine whether or not a pte is special, then fail immediately
>> + * for ptes. Note, we can still pin HugeTLB as it is guaranteed not to be
>> + * special. For THP, special huge entries are indicated by xxx_devmap()
>> + * returning true, but a corresponding call to get_dev_pagemap() will
>> + * return NULL.
>> + *
>> + * For a futex to be placed on a THP tail page, get_futex_key requires a
>> + * get_user_pages_fast_only implementation that can pin pages. Thus it's still
>> + * useful to have gup_huge_pmd even if we can't operate on ptes.
>> + */
> Why move this comment? I think it was correct where it was

Yes, you're right. I misread it to refer to the actual code in the 
gup_pte_range function rather than to the empty version. I'll move it back.

/Thomas


>
> Jason