All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"willy@infradead.org" <willy@infradead.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"jrdr.linux@gmail.com" <jrdr.linux@gmail.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"minchan@kernel.org" <minchan@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	Linux-graphics-maintainer <Linux-graphics-maintainer@vmware.com>,
	"mhocko@suse.com" <mhocko@suse.com>,
	"ying.huang@intel.com" <ying.huang@intel.com>,
	"riel@surriel.com" <riel@surriel.com>
Subject: Re: [RFC PATCH RESEND 2/3] mm: Add an apply_to_pfn_range interface
Date: Thu, 21 Mar 2019 16:24:46 -0400	[thread overview]
Message-ID: <20190321202445.GA15074@redhat.com> (raw)
In-Reply-To: <c9d05087a0fb9002145aa2f7c58552615a694e9e.camel@vmware.com>

On Thu, Mar 21, 2019 at 07:59:35PM +0000, Thomas Hellstrom wrote:
> On Thu, 2019-03-21 at 09:52 -0400, Jerome Glisse wrote:
> > On Thu, Mar 21, 2019 at 01:22:35PM +0000, Thomas Hellstrom wrote:
> > > This is basically apply_to_page_range with added functionality:
> > > Allocating missing parts of the page table becomes optional, which
> > > means that the function can be guaranteed not to error if
> > > allocation
> > > is disabled. Also passing of the closure struct and callback
> > > function
> > > becomes different and more in line with how things are done
> > > elsewhere.
> > > 
> > > Finally we keep apply_to_page_range as a wrapper around
> > > apply_to_pfn_range
> > 
> > The apply_to_page_range() is dangerous API it does not follow other
> > mm patterns like mmu notifier. It is suppose to be use in arch code
> > or vmalloc or similar thing but not in regular driver code. I see
> > it has crept out of this and is being use by few device driver. I am
> > not sure we should encourage that.
> 
> I can certainly remove the EXPORT of the new apply_to_pfn_range() which
> will make sure its use stays within the mm code. I don't expect any
> additional usage except for the two address-space utilities.
> 
> I'm looking for examples to see how it could be more in line with the
> rest of the mm code. The main difference from the pattern in, for
> example, page_mkclean() seems to be that it's lacking the
> mmu_notifier_invalidate_start() and mmu_notifier_invalidate_end()?
> Perhaps the intention is to have the pte leaf functions notify on pte
> updates? How does this relate to arch_enter_lazy_mmu() which is called
> outside of the page table locks? The documentation appears a bit
> scarce...

Best is to use something like walk_page_range() and have proper mmu
notifier in the callback. The apply_to_page_range() is broken for
huge page (THP) and other things like that. Thought you should not
have THP within mmap of a device file (at least i do not thing any
driver does that).

Cheers,
Jérôme

  reply	other threads:[~2019-03-21 20:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 13:22 [RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory Thomas Hellstrom
2019-03-21 13:22 ` [RFC PATCH RESEND 1/3] mm: Allow the [page|pfn]_mkwrite callbacks to drop the mmap_sem Thomas Hellstrom
2019-03-21 13:22   ` Thomas Hellstrom
2019-03-21 13:22 ` [RFC PATCH RESEND 2/3] mm: Add an apply_to_pfn_range interface Thomas Hellstrom
2019-03-21 13:22   ` Thomas Hellstrom
2019-03-21 13:52   ` Jerome Glisse
2019-03-21 19:59     ` Thomas Hellstrom
2019-03-21 19:59       ` Thomas Hellstrom
2019-03-21 20:24       ` Jerome Glisse [this message]
2019-03-21 13:22 ` [RFC PATCH RESEND 3/3] mm: Add write-protect and clean utilities for address space ranges Thomas Hellstrom
2019-03-21 13:22   ` Thomas Hellstrom
2019-03-21 14:12   ` Jerome Glisse
2019-03-21 20:29     ` Thomas Hellstrom
2019-03-21 20:29       ` Thomas Hellstrom
2019-03-21 21:07       ` Jerome Glisse
2019-03-21 21:07         ` Jerome Glisse
2019-03-21 13:46 ` [RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory Jerome Glisse
2019-03-21 19:51   ` Thomas Hellstrom
2019-03-21 20:28     ` Jerome Glisse
2019-03-21 20:28       ` Jerome Glisse

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=20190321202445.GA15074@redhat.com \
    --to=jglisse@redhat.com \
    --cc=Linux-graphics-maintainer@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jrdr.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=thellstrom@vmware.com \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    /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.