[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210323135217.GD2356281@nvidia.com>
Date: Tue, 23 Mar 2021 10:52:17 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Thomas Hellström (Intel)
<thomas_os@...pmail.org>
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 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
Jason
Powered by blists - more mailing lists