Re: Re: [PATCH v15 01/14] mm/page_ext: Export lookup_page_ext() to GPL modules

From: SeongJae Park <sjpark@amazon.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: David Hildenbrand <david@redhat.com>,
	SeongJae Park <sjpark@amazon.com>, <akpm@linux-foundation.org>,
	SeongJae Park <sjpark@amazon.de>, <Jonathan.Cameron@huawei.com>,
	<aarcange@redhat.com>, <acme@kernel.org>,
	<alexander.shishkin@linux.intel.com>, <amit@kernel.org>,
	<benh@kernel.crashing.org>, <brendan.d.gregg@gmail.com>,
	<brendanhiggins@google.com>, <cai@lca.pw>,
	<colin.king@canonical.com>, <corbet@lwn.net>, <dwmw@amazon.com>,
	<foersleo@amazon.de>, <irogers@google.com>, <jolsa@redhat.com>,
	<kirill@shutemov.name>, <mark.rutland@arm.com>, <mgorman@suse.de>,
	<minchan@kernel.org>, <mingo@redhat.com>, <namhyung@kernel.org>,
	<peterz@infradead.org>, <rdunlap@infradead.org>,
	<riel@surriel.com>, <rientjes@google.com>, <rostedt@goodmis.org>,
	<sblbir@amazon.com>, <shakeelb@google.com>, <shuah@kernel.org>,
	<sj38.park@gmail.com>, <snu@amazon.de>, <vbabka@suse.cz>,
	<vdavydov.dev@gmail.com>, <yang.shi@linux.alibaba.com>,
	<ying.huang@intel.com>, <linux-damon@amazon.com>,
	<linux-mm@kvack.org>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH v15 01/14] mm/page_ext: Export lookup_page_ext() to GPL modules
Date: Mon, 8 Jun 2020 19:48:16 +0200	[thread overview]
Message-ID: <20200608174816.19222-1-sjpark@amazon.com> (raw)
In-Reply-To: <20200608154917.GA8408@infradead.org> (raw)

On Mon, 8 Jun 2020 08:49:17 -0700 Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jun 08, 2020 at 01:53:23PM +0200, David Hildenbrand wrote:
> > > @@ -131,6 +131,7 @@ struct page_ext *lookup_page_ext(const struct page *page)
> > >  					MAX_ORDER_NR_PAGES);
> > >  	return get_entry(base, index);
> > >  }
> > > +EXPORT_SYMBOL_GPL(lookup_page_ext);
> > >  
> > >  static int __init alloc_node_page_ext(int nid)
> > >  {
> > > 
> > 
> > I've been told to always smuggle new EXPORTs into the patch that
> > actually needs it (and cc relevant people on that patch instead).
> 
> A separate patch for anything remotely controversial really helps it
> to stick out, so I think keeping it separate is a very good practice.

I have no strong preference here.  So if no further comments are given, in the
next spin, I will keep this separate, but will mention exactly what future
commit needs this change, so that it can be easily squashed later, if
necessary.

Thanks,
SeongJae Park