All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: David Airlie <airlied@linux.ie>,
	Christian Koenig <christian.koenig@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, Huang Rui <ray.huang@amd.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	Roland Scheidegger <sroland@vmware.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>
Subject: Re: [PATCH] drm/ttm: Do not put non-struct page memory into PUD/PMDs
Date: Tue, 19 Oct 2021 20:56:23 +0200	[thread overview]
Message-ID: <814bbcb0-2942-5ded-0352-e7c67ebceca5@linux.intel.com> (raw)
In-Reply-To: <20211019185208.GY2744544@nvidia.com>


On 10/19/21 20:52, Jason Gunthorpe wrote:
> On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
>> Hi,
>>
>> On 10/19/21 20:21, Jason Gunthorpe wrote:
>>> PUD and PMD entries do not have a special bit.
>>>
>>> get_user_pages_fast() considers any page that passed pmd_huge() as
>>> usable:
>>>
>>> 		if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
>>> 			     pmd_devmap(pmd))) {
>>>
>>> And vmf_insert_pfn_pmd_prot() unconditionally sets
>>>
>>> 	entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
>>>
>>> eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE.
>>>
>>> As such gup_huge_pmd() will try to deref a struct page:
>>>
>>> 	head = try_grab_compound_head(pmd_page(orig), refs, flags);
>>>
>>> and thus crash.
>>>
>>> Prevent this by never using IO memory with vmf_insert_pfn_pud/pmd_prot().
>> Actually I think if fast gup will break even page backed memory since the
>> backing drivers don't assume anybody else takes a refcount / pincount.
>> Normal pages have PTE_SPECIAL and VM_PFNMAP to block that.
> Erk, yes, that is even worse.
>
>> (Side note I was recommended to introduce a PTE_HUGESPECIAL bit for
>> this and basically had  a patch ready but got scared off when trying
>> to handle 64-bit PTE atomic updates on x86-32)
> Right, a PMD_SPECIAL bit is needed to make this work.
Yes, PMD_SPECIAL it was :)
>
>> It might be that we (Intel) try to resurrect this code using
>> PTE_HUGESPECIAL in the near future for i915, but until that, I think
>> it's the safest option to disable it completely.
> Okay, do you want a patch to just delete this function?

That'd be great.

Thanks,

Thomas


>
> Jason

      reply	other threads:[~2021-10-19 18:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-19 18:21 [PATCH] drm/ttm: Do not put non-struct page memory into PUD/PMDs Jason Gunthorpe
2021-10-19 18:49 ` Thomas Hellström
2021-10-19 18:52   ` Jason Gunthorpe
2021-10-19 18:56     ` Thomas Hellström [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=814bbcb0-2942-5ded-0352-e7c67ebceca5@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=ray.huang@amd.com \
    --cc=rcampbell@nvidia.com \
    --cc=sroland@vmware.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.