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: <a1fa7fa2-914b-366d-9902-e5b784e8428c@shipmail.org>
Date:   Wed, 24 Mar 2021 11:05:40 +0100
From:   Thomas Hellström (Intel) 
        <thomas_os@...pmail.org>
To:     "Williams, Dan J" <dan.j.williams@...el.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "christian.koenig@....com" <christian.koenig@....com>,
        "jgg@...dia.com" <jgg@...dia.com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages


On 3/24/21 10:58 AM, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
>> On 3/23/21 8:52 PM, Williams, Dan J wrote:
>>> On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
>>>> TTM sets up huge page-table-entries both to system- and device
>>>> memory,
>>>> and we don't want gup to assume there are always valid backing struct
>>>> pages for these. For PTEs this is handled by setting the pte_special
>>>> bit,
>>>> but for the huge PUDs and PMDs, we have neither pmd_special nor
>>>> pud_special. Normally, huge TTM entries are identified by looking at
>>>> vma_is_special_huge(), but fast gup can't do that, so as an
>>>> alternative
>>>> define _devmap entries for which there are no backing dev_pagemap as
>>>> special, update documentation and make huge TTM entries _devmap,
>>>> after
>>>> verifying that there is no backing dev_pagemap.
>>> Please do not abuse p{m,u}d_devmap like this. I'm in the process of
>>> removing get_devpagemap() from the gup-fast path [1]. Instead there
>>> should be space for p{m,u}d_special in the page table entries (at least
>>> for x86-64). So the fix is to remove that old assumption that huge
>>> pages can never be special.
>>>
>>> [1]:
>>> http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com
>>>
>> Hmm, yes with that patch it will obviously not work as intended.
>>
>> Given that, I think we'll need to disable the TTM huge pages for now until
>> we can sort out and agree on using a page table entry bit.
> Yeah :-/
>
> I think going full pud/pmd_mkspecial should then also mesh well with
> Jason's request to wrap it all up into a vmf_insert_* helper, so at least
> it would all look rather pretty in the end.

Yes, I agree. Seems like the special (SW1) is available also for huge 
page table entries on x86 AFAICT, although just not implemented. 
Otherwise the SW bits appear completely used up.

The PTE size vmf_insert_pfn__xxx functions either insert one of devmap 
or special.  I think the only users of the huge insert functions apart 
form TTM currently insert devmap so we should probably be able to do the 
same, and then DRM / TTM wouldn't need to care at all about special or not.

/Thomas



> -Daniel