On Fri, Oct 12, 2018 at 10:49:31AM -0700, Dan Williams wrote: > [ apologies for the resend, script error ] > > Changes since v6 [1]: > * Rebase on next-20181008 and fixup conflicts with the xarray conversion > and hotplug optimizations > * It has soaked on a 0day visible branch for a few days without any > reports. > > [1]: https://lkml.org/lkml/2018/9/13/104 > > --- > > Hi Andrew, > > Jérôme has reviewed the cleanups, thanks Jérôme. We still disagree on > the EXPORT_SYMBOL_GPL status of the core HMM implementation, but Logan, > Christoph and I continue to support marking all devm_memremap_pages() > derivatives EXPORT_SYMBOL_GPL. > > HMM has been upstream for over a year, with no in-tree users it is clear > it was designed first and foremost for out of tree drivers. It takes > advantage of a facility Christoph and I spearheaded to support > persistent memory. It continues to see expanding use cases with no clear > end date when it will stop attracting features / revisions. It is not > suitable to export devm_memremap_pages() as a stable 3rd party driver > api. > > devm_memremap_pages() is a facility that can create struct page entries > for any arbitrary range and give out-of-tree drivers the ability to > subvert core aspects of page management. It, and anything derived from > it (e.g. hmm, pcip2p, etc...), is a deep integration point into the core > kernel, and an EXPORT_SYMBOL_GPL() interface. > > Commit 31c5bda3a656 "mm: fix exports that inadvertently make put_page() > EXPORT_SYMBOL_GPL" was merged ahead of this series to relieve some of > the pressure from innocent consumers of put_page(), but now we need this > series to address *producers* of device pages. > > More details and justification in the changelogs. The 0day > infrastructure has reported success across 152 configs and this survives > the libnvdimm unit test suite. Aside from the controversial bits the > diffstat is compelling at: > > 7 files changed, 126 insertions(+), 323 deletions(-) > > Note that the series has some minor collisions with Alex's recent series > to improve devm_memremap_pages() scalability [2]. So, whichever you take > first the other will need a minor rebase. > > [2]: https://www.lkml.org/lkml/2018/9/11/10 I am fine with this patchset going in (i reviewed it and tested it with HMM on nouveau), Dan and Christoph did author the original code around devm_memremap_pages() and thus ultimately they are the one who should decide over GPL export or not. Cheers, Jérôme
