From: Jerome Glisse <jglisse@redhat.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
dan.j.williams@intel.com, ldufour@linux.vnet.ibm.com
Subject: Re: [PATCH] mm/dev_pfn: Exclude MEMORY_DEVICE_PRIVATE while computing virtual address
Date: Mon, 20 May 2019 15:27:21 -0400 [thread overview]
Message-ID: <20190520192721.GA4049@redhat.com> (raw)
In-Reply-To: <cb8cbd57-9220-aba9-7579-dbcf35f02672@arm.com>
On Mon, May 20, 2019 at 11:07:38AM +0530, Anshuman Khandual wrote:
> On 05/18/2019 03:20 AM, Andrew Morton wrote:
> > On Fri, 17 May 2019 16:08:34 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >
> >> The presence of struct page does not guarantee linear mapping for the pfn
> >> physical range. Device private memory which is non-coherent is excluded
> >> from linear mapping during devm_memremap_pages() though they will still
> >> have struct page coverage. Just check for device private memory before
> >> giving out virtual address for a given pfn.
> >
> > I was going to give my standard "what are the user-visible runtime
> > effects of this change?", but...
> >
> >> All these helper functions are all pfn_t related but could not figure out
> >> another way of determining a private pfn without looking into it's struct
> >> page. pfn_t_to_virt() is not getting used any where in mainline kernel.Is
> >> it used by out of tree drivers ? Should we then drop it completely ?
> >
> > Yeah, let's kill it.
> >
> > But first, let's fix it so that if someone brings it back, they bring
> > back a non-buggy version.
>
> Makes sense.
>
> >
> > So... what (would be) the user-visible runtime effects of this change?
>
> I am not very well aware about the user interaction with the drivers which
> hotplug and manage ZONE_DEVICE memory in general. Hence will not be able to
> comment on it's user visible runtime impact. I just figured this out from
> code audit while testing ZONE_DEVICE on arm64 platform. But the fix makes
> the function bit more expensive as it now involve some additional memory
> references.
A device private pfn can never leak outside code that does not understand it
So this change is useless for any existing users and i would like to keep the
existing behavior ie never leak device private pfn.
Cheers,
Jérôme
next prev parent reply other threads:[~2019-05-20 19:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 10:38 [PATCH] mm/dev_pfn: Exclude MEMORY_DEVICE_PRIVATE while computing virtual address Anshuman Khandual
2019-05-17 21:50 ` Andrew Morton
2019-05-20 5:37 ` Anshuman Khandual
2019-05-20 19:00 ` Dan Williams
2019-05-20 19:27 ` Jerome Glisse [this message]
2019-05-20 19:33 ` Dan Williams
2019-05-21 2:08 ` Anshuman Khandual
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=20190520192721.GA4049@redhat.com \
--to=jglisse@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=dan.j.williams@intel.com \
--cc=ldufour@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.