Nouveau - Aug 2019 - [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at redhat.com>
wrote:
>
> On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe <jgg at
mellanox.com> wrote:
> > >
> > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig
wrote:
> > > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams
wrote:
> > > > > Section alignment constraints somewhat save us here.
The only example
> > > > > I can think of a PMD not containing a uniform pgmap
association for
> > > > > each pte is the case when the pgmap overlaps normal
dram, i.e. shares
> > > > > the same 'struct memory_section' for a given
span. Otherwise, distinct
> > > > > pgmaps arrange to manage their own exclusive sections
(and now
> > > > > subsections as of v5.3). Otherwise the implementation
could not
> > > > > guarantee different mapping lifetimes.
> > > > >
> > > > > That said, this seems to want a better mechanism to
determine "pfn is
> > > > > ZONE_DEVICE".
> > > >
> > > > So I guess this patch is fine for now, and once you provide
a better
> > > > mechanism we can switch over to it?
> > >
> > > What about the version I sent to just get rid of all the strange
> > > put_dev_pagemaps while scanning? Odds are good we will work with
only
> > > a single pagemap, so it makes some sense to cache it once we find
it?
> >
> > Yes, if the scan is over a single pmd then caching it makes sense.
>
> Quite frankly an easier an better solution is to remove the pagemap
> lookup as HMM user abide by mmu notifier it means we will not make
> use or dereference the struct page so that we are safe from any
> racing hotunplug of dax memory (as long as device driver using hmm
> do not have a bug).
Yes, as long as the driver remove is synchronized against HMM
operations via another mechanism then there is no need to take pagemap
references. Can you briefly describe what that other mechanism is?

On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams
wrote:
> On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at
redhat.com> wrote:
> >
> > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe <jgg at
mellanox.com> wrote:
> > > >
> > > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig
wrote:
> > > > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams
wrote:
> > > > > > Section alignment constraints somewhat save us
here. The only example
> > > > > > I can think of a PMD not containing a uniform
pgmap association for
> > > > > > each pte is the case when the pgmap overlaps
normal dram, i.e. shares
> > > > > > the same 'struct memory_section' for a
given span. Otherwise, distinct
> > > > > > pgmaps arrange to manage their own exclusive
sections (and now
> > > > > > subsections as of v5.3). Otherwise the
implementation could not
> > > > > > guarantee different mapping lifetimes.
> > > > > >
> > > > > > That said, this seems to want a better mechanism
to determine "pfn is
> > > > > > ZONE_DEVICE".
> > > > >
> > > > > So I guess this patch is fine for now, and once you
provide a better
> > > > > mechanism we can switch over to it?
> > > >
> > > > What about the version I sent to just get rid of all the
strange
> > > > put_dev_pagemaps while scanning? Odds are good we will work
with only
> > > > a single pagemap, so it makes some sense to cache it once we
find it?
> > >
> > > Yes, if the scan is over a single pmd then caching it makes
sense.
> >
> > Quite frankly an easier an better solution is to remove the pagemap
> > lookup as HMM user abide by mmu notifier it means we will not make
> > use or dereference the struct page so that we are safe from any
> > racing hotunplug of dax memory (as long as device driver using hmm
> > do not have a bug).
> 
> Yes, as long as the driver remove is synchronized against HMM
> operations via another mechanism then there is no need to take pagemap
> references. Can you briefly describe what that other mechanism is?
So if you hotunplug some dax memory i assume that this can only
happens once all the pages are unmapped (as it must have the
zero refcount, well 1 because of the bias) and any unmap will
trigger a mmu notifier callback. User of hmm mirror abiding by
the API will never make use of information they get through the
fault or snapshot function until checking for racing notifier
under lock.

Cheers,
Jérôme

On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse <jglisse at redhat.com>
wrote:
>
> On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at
redhat.com> wrote:
> > >
> > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe <jgg at
mellanox.com> wrote:
> > > > >
> > > > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph
Hellwig wrote:
> > > > > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan
Williams wrote:
> > > > > > > Section alignment constraints somewhat save
us here. The only example
> > > > > > > I can think of a PMD not containing a uniform
pgmap association for
> > > > > > > each pte is the case when the pgmap overlaps
normal dram, i.e. shares
> > > > > > > the same 'struct memory_section' for
a given span. Otherwise, distinct
> > > > > > > pgmaps arrange to manage their own exclusive
sections (and now
> > > > > > > subsections as of v5.3). Otherwise the
implementation could not
> > > > > > > guarantee different mapping lifetimes.
> > > > > > >
> > > > > > > That said, this seems to want a better
mechanism to determine "pfn is
> > > > > > > ZONE_DEVICE".
> > > > > >
> > > > > > So I guess this patch is fine for now, and once
you provide a better
> > > > > > mechanism we can switch over to it?
> > > > >
> > > > > What about the version I sent to just get rid of all
the strange
> > > > > put_dev_pagemaps while scanning? Odds are good we will
work with only
> > > > > a single pagemap, so it makes some sense to cache it
once we find it?
> > > >
> > > > Yes, if the scan is over a single pmd then caching it makes
sense.
> > >
> > > Quite frankly an easier an better solution is to remove the
pagemap
> > > lookup as HMM user abide by mmu notifier it means we will not
make
> > > use or dereference the struct page so that we are safe from any
> > > racing hotunplug of dax memory (as long as device driver using
hmm
> > > do not have a bug).
> >
> > Yes, as long as the driver remove is synchronized against HMM
> > operations via another mechanism then there is no need to take pagemap
> > references. Can you briefly describe what that other mechanism is?
>
> So if you hotunplug some dax memory i assume that this can only
> happens once all the pages are unmapped (as it must have the
> zero refcount, well 1 because of the bias) and any unmap will
> trigger a mmu notifier callback. User of hmm mirror abiding by
> the API will never make use of information they get through the
> fault or snapshot function until checking for racing notifier
> under lock.
Hmm that first assumption is not guaranteed by the dev_pagemap core.
The dev_pagemap end of life model is "disable, invalidate, drain" so
it's possible to call devm_munmap_pages() while pages are still mapped
it just won't complete the teardown of the pagemap until the last
reference is dropped. New references are blocked during this teardown.

However, if the driver is validating the liveness of the mapping in
the mmu-notifier path and blocking new references it sounds like it
should be ok. Might there be GPU driver unit tests that cover this
racing teardown case?