From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEAE82D876A for ; Tue, 7 Jul 2026 19:16:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783451764; cv=none; b=ACXwMysl8Q9caTIDblfq+oxyOx+XaVzxvt3bxnY42XANwDC7rf0Aij1TuyYipnWRr3nG1p0RRbsNxbxvvTDbht0QdHn6ewhrsp31P8N5P+kantB/Bll3NFSAOLsyjnLT/mcGyKVRxUhPOwYmtujAZDb54ebqW776SZlYRNKdK4w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783451764; c=relaxed/simple; bh=YYv+Azzncfc806TCY1O19z1RcCesehMz8DbN9t72/sA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MoWfSrpwfcKBiqJ3hPCmbu7mW3BPfS/F0RMjgm478MfcdAZ7X5no3+cgTDce9cFdk9CKRAOFdhKl2QcbvQaxOvyo4WzVBcvQt8F6eaTz7zd3sulAPf/haoWFAS9MnlmLTTv5m7tNI54bug2Uuzwp2T134UtEP/iCTmFzrsAVtPU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S+MYElig; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S+MYElig" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F2111F000E9; Tue, 7 Jul 2026 19:16:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783451763; bh=LurUoFlksu0iHTOZFjUCHWNI5YLKr1ommwx8975HPUY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=S+MYEligJcni74qa/hJeahb0ju+jbDQeyYLcJBszHm2orBDAup/lw9IOwqk5Gct24 /GNnUgxLlQ5Tqj8aHLX7fdyAlDX31heB5XlSfZk7aHvNhP+8Me2UJpPKSgNtymlWE8 Bc1YQsy7+lAX7g++4GO7UUhfp4FnZvslok7AXZoV2PNIFQfGL/YxCMWFY4XCbJKBlL DF+KzU0tbBM0Jr/jpXhuqCgefyQ3MCpljit8Ff3lHDXab6pGHEQ944HjGX43Wy+9G8 fikcykz8DqsP/cn0DeOIY1JPCY0pU0IjynsLyWCbX0jo1Jo1DWOraEXfzezhmGmUef +1r320RTv8Ylg== Date: Tue, 7 Jul 2026 20:15:53 +0100 From: Lorenzo Stoakes To: Hajime Tazaki Cc: geert@linux-m68k.org, akpm@linux-foundation.org, willy@infradead.org, liam@infradead.org, vbabka@kernel.org, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, gerg@uclinux.org Subject: Re: [PATCH] mm: nommu: point to the write iterator upon split_vma Message-ID: References: <20260702012546.665383-1-thehajime@gmail.com> <20260705152708.582fd8d87561f600da23c0a7@linux-foundation.org> <20260705222343.5d5c78cbb54839c5efcaabf5@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jul 06, 2026 at 09:57:51PM +0900, Hajime Tazaki wrote: > On Mon, 06 Jul 2026 20:51:36 +0900, > Lorenzo Stoakes wrote: > > This crops up now and again and people point to uses, but fails to address the > > real issue here. > > > > Nobody (aside from Hajime - thank you!) who uses nommu maintains or contributes > > to it, or _even tests_ it as far as I can tell. > > > > We broken nommu for a year I think it was? And there wasn't one report. > > > > The last time I raised this, I was admonished and told there are critical arm32 > > nommu devices that absolutely _must_ have the latest kernel and this is > > perfectly working code. > > > > And riscv also introduced (and I'm so very surprised Linus allowed it) a brand > > new nommu architecture (!!) > > > > And yet... > > > > If this is really so important, can those who care perhaps help out a bit? At > > least with testing? > > > > I'm a bit fed up of it really. > > > > As far as hobbyist retro stuff and upstream goes, I am sympathetic, I came from > > being a hobbyist (though not retro), and would be one again if I couldn't do it > > as a job. > > > > But retro people do NOT need the latest kernel. As far as I'm concerned, museum > > piece support should be ripped out, and those who care run downstream kernels. > > > > As for the 'critical products' that must use nommu - PLEASE start > > contributing. Please start testing. Anything. > > > > Again thank you Hajime for doing the one thing that really counts here - > > contributing to the nommu code. > > > > Anyway, as to what Matthew said - 100% I am for us ripping it out. > > > > But it's not up to me, and unfortunately I think we'll get a clammer of voices > > saying how important it is, and silence again when it comes to do any of the > > work. > > as nommu started for embedded devices which are not easy to test, I > agree that it is also not easy (in my opinion) to maintain. Indeed. > > indeed, buildroot images for nommu targets (with qemu) are available, > but running/testing each of commit to the kernel tree give me more > than 1 hour to rebuild the images (including userspace build with long > flat binary conversion, etc) (which I'm playing under github actions > with riscv-nommu). I've struggled to even get the buildroot images to work in any way. Right now I don't have a clear nommu test setup other than building nommu_virt_defconfig for riscv. > > # yes, should use ccache :) :)) > > one of the goal which I am with nommu UML (*1) is to provide an > environment which can be tested in a simple way; runs on x86 > machines. An extension to UML means that you can also use KUnit > infrastructure. Yeah. Well indeed my raising the 'please let us pull this out' was initially a push back on that, because if we were going to pull it then that work would work against it, but then it became clear that that dream wasn't possible. And that makes your work on that REALLY REALLY USEFUL :) so do cc me and ping me on any respin and I'll try to find time to help. > > LTP (Linux Test Project) dropped the nommu tests 2 years ago (*2) > (which is pity), but the reason is similar: no maintainers appeared > when the project asked. Yeah and it's just the same thing overall with all of this. The companies who are apparently dependent on this need to _actually pay people to do some even rudimentary testing_. nommu.c is co-maintained by me and Liam simply because we have done more to fix issues with it than nearly anybody else recently. It's just a burden that we took on. I'd far rather see an invested mm person take over if we do indeed have to live with it :) I also wonder if we couldn't find a way to implement it in a more maintainable way, perhaps as a 'virtual' mmu system somehow? I simply don't have the bandwidth for that myself, unfortunately. > > I wish to be here to improve this situation, both mm/nommu subsystem > and LTP, as well as any !CONFIG_MMU code in kernel tree. This patch > is actually discovered during LTP (re-)integration with nommu kernel, > which I'm going to propose to LTP. Your work is appreciated and welcome, thank you! :) > > I hope this helps a bit. You're definitely helping here and again, much appreciated! > > > *1 https://lore.kernel.org/all/cover.1770170302.git.thehajime@gmail.com/ > *2 https://lore.kernel.org/ltp/20240105131135.GA1484621@pevik/ > > -- Hajime Cheers, Lorenzo