Re: [PATCH mm-unstable v2 06/16] mm: csky: Introduce arch_mmap_hint()

From: Andrew Morton <akpm@linux-foundation.org>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Kalesh Singh <kaleshsingh@google.com>,
	lorenzo.stoakes@oracle.com, vbabka@suse.cz,
	yang@os.amperecomputing.com, riel@surriel.com, david@redhat.com,
	minchan@kernel.org, jyescas@google.com, linux@armlinux.org.uk,
	tsbogend@alpha.franken.de, James.Bottomley@hansenpartnership.com,
	ysato@users.sourceforge.jp, dalias@libc.org,
	glaubitz@physik.fu-berlin.de, davem@davemloft.net,
	andreas@gaisler.com, tglx@linutronix.de, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, chris@zankel.net,
	jcmvbkbc@gmail.com, bhelgaas@google.com, jason.andryuk@amd.com,
	leitao@debian.org, linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
	loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-mm@kvack.org,
	kernel-team@android.com, android-mm@google.com
Subject: Re: [PATCH mm-unstable v2 06/16] mm: csky: Introduce arch_mmap_hint()
Date: Thu, 12 Dec 2024 17:39:34 -0800	[thread overview]
Message-ID: <20241212173934.4dc429716acd4c71a76e15c2@linux-foundation.org> (raw)
In-Reply-To: <vc2uhcysgosapznbuookcj5677w43a4kzxbotwqub237ccawww@i3pbqiacdwsx>

On Thu, 12 Dec 2024 16:40:10 -0500 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:

> * Kalesh Singh <kaleshsingh@google.com> [241211 18:28]:
> > Introduce csky arch_mmap_hint() and define HAVE_ARCH_MMAP_HINT.
> > This is a preparatory patch, no functional change is introduced.
> 
> This also looks like it has changed the validation order and potentially
> introduced functional changes?
> 
> All these stem from the same cloned code (sparc32 iirc), but were not
> updated when the cloned code was updated.  This is why I am against
> arch_* code.  We should find a better way to unify the code so that
> there is nothing different.  You seem to have gotten some of the shared
> code together, but some still exists.
> 
> In the addresses, there are upper and lower limits, and sometimes
> "colours".  Could we not just define the upper/lower limits in each arch
> and if colour is used?  Maybe this is complicated with 32/64 handled
> both in the 64 bit code.
> 
> Is there any plan to unite this code further?
> 
> We have had errors for many years in cloned but not updated code.  I
> really wish there was more information in the cover letter on what is
> going on here.  I'd like to try and reduce the arch_ code to, basically
> nothing.
> 
> I was also disappointed that I wasn't Cc'ed because I've spent a lot of
> time in this code and this area.  I am probably the last one to crawl
> through and change any of this.

Thanks, I removed this version of this series from mm-unstable.