LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Jerome Glisse <jglisse@redhat.com>
Cc: Dave Airlie <airlied@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Logan Gunthorpe <logang@deltatee.com>,
	Christoph Hellwig <hch@lst.de>, Michal Hocko <mhocko@suse.com>,
	Linux MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] mm: rework hmm to use devm_memremap_pages
Date: Tue, 5 Jun 2018 18:33:04 -0700	[thread overview]
Message-ID: <CAPcyv4gsS4xDXahZdOggURBHS2y-oJ5tPG9vXPDdY2p6jPufxA@mail.gmail.com> (raw)
In-Reply-To: <20180606000822.GE4423@redhat.com>

On Tue, Jun 5, 2018 at 5:08 PM, Jerome Glisse <jglisse@redhat.com> wrote:
> On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
[..]
>> I want the EXPORT_SYMBOL_GPL on devm_memremap_pages() primarily for
>> development purposes. Any new users of devm_memremap_pages() should be
>> aware that they are subscribing to the whims of the core-VM, i.e. the
>> ongoing evolution of 'struct page', and encourage those drivers to be
>> upstream to improve the implementation, and consolidate use cases. I'm
>> not qualified to comment on your "nor will it change anyone's legal
>> position.", but I'm saying it's in the Linux kernel's best interest
>> that new users of this interface assume they need to be GPL.
>
> Note that HMM isolate the device driver from struct page as long as
> the driver only use HMM helpers to get to the information it needs.
> I intend to be pedantic about that with any driver using HMM. I want
> HMM to be an impedance layer that provide stable and simple API to
> device driver while preserving freedom of change to mm.
>

I would not classify redefining put_page() and recompiling the
entirety of the kernel to turn on HMM as "isolating the driver from
'struct page'". HMM is instead isolating these out of drivers from
ever needing to go upstream.

Unless the nouveau patches are using the entirety of what is already
upstream for HMM, we should look to pare HMM back.

There is plenty of precedent of building a large capability
out-of-tree and piecemeal merging it later, so I do not buy the
"chicken-egg" argument. The change in the export is to make sure we
don't repeat this backward "merge first, ask questions later" mistake
in the future as devm_memremap_pages() is continuing to find new users
like peer-to-peer DMA support and Linux is better off if that
development is upstream. From a purely technical standpoint
devm_memremap_pages() is EXPORT_SYMBOL_GPL because it hacks around
several implementation details in the core kernel to achieve its goal,
and it leaks new assumptions all over the kernel. It is strictly not a
self contained interface.

  reply	other threads:[~2018-06-06  1:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 22:35 Dan Williams
2018-05-21 22:35 ` [PATCH 1/5] mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL Dan Williams
2018-05-22  6:29   ` Christoph Hellwig
2018-05-21 22:35 ` [PATCH 2/5] mm, devm_memremap_pages: handle errors allocating final devres action Dan Williams
2018-05-21 23:10   ` Andrew Morton
2018-05-22  0:07     ` Dan Williams
2018-05-22 16:42       ` Logan Gunthorpe
2018-05-22 16:56         ` Dan Williams
2018-05-22 17:03           ` Logan Gunthorpe
2018-05-22 17:25             ` Dan Williams
2018-05-22 17:36               ` Logan Gunthorpe
2018-05-22  6:30   ` Christoph Hellwig
2018-05-21 22:35 ` [PATCH 3/5] mm, hmm: use devm semantics for hmm_devmem_{add, remove} Dan Williams
2018-05-22  6:30   ` Christoph Hellwig
2018-05-21 22:35 ` [PATCH 4/5] mm, hmm: replace hmm_devmem_pages_create() with devm_memremap_pages() Dan Williams
2018-05-22  6:31   ` Christoph Hellwig
2018-05-22 17:13   ` Logan Gunthorpe
2018-05-22 21:38     ` Dan Williams
2018-05-21 22:35 ` [PATCH 5/5] mm, hmm: mark hmm_devmem_{add, add_resource} EXPORT_SYMBOL_GPL Dan Williams
2018-05-22  6:32   ` Christoph Hellwig
2018-05-22 21:31     ` Andrew Morton
2018-06-05 18:24       ` Jerome Glisse
2018-05-24  0:10 ` [PATCH 0/5] mm: rework hmm to use devm_memremap_pages Jerome Glisse
2018-05-24  3:18   ` Dan Williams
2018-05-24  6:35     ` Christoph Hellwig
2018-05-29 22:22     ` Dave Airlie
2018-05-29 22:31       ` Dan Williams
2018-05-29 23:00         ` Dave Airlie
2018-05-29 23:33           ` Dan Williams
2018-06-05 18:48             ` Jerome Glisse
2018-06-05 22:19               ` Dave Airlie
2018-06-05 23:06                 ` Dan Williams
2018-06-06  0:08                   ` Jerome Glisse
2018-06-06  1:33                     ` Dan Williams [this message]
2018-06-06  7:14                       ` Christoph Hellwig
2018-06-07 14:16                       ` Jerome Glisse
2018-06-07 18:39                         ` Dan Williams

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=CAPcyv4gsS4xDXahZdOggURBHS2y-oJ5tPG9vXPDdY2p6jPufxA@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@lst.de \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mhocko@suse.com \
    --subject='Re: [PATCH 0/5] mm: rework hmm to use devm_memremap_pages' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).