[RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Hajime Tazaki]

Upon a private file mapping request to /dev/zero, it calls
kernel_read() in do_mmap_private(), getting a failure with the message
like: "kernel reads not supported for file /dev/zero", which is because
zero_fops defined in drivers/char/mem.c has both .read and .read_iter
definitions.

Even fixing this issue, the map request to /dev/zero works fine without
errors but the allocated vma isn't marked with anonymous because
mmap_zero_prepare() isn't called under nommu platform, resulting
vma_desc_set_anonymous() isn't called either.

This commit fixes those issues by:
1) use vfs_iter_read() instead to avoid failure at kernel_read()
2) calls .mmap_prepare on private mapping in do_mmap() so that required
   preparations are done even in private mapping.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R. Howlett" <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org (open list:PAGE CACHE)
Fixes: 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops")
Assisted-by: cubic.dev:unspecified
Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
---
 drivers/char/mem.c |  5 ++-
 mm/filemap.c       |  6 ++--
 mm/nommu.c         | 84 ++++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 87 insertions(+), 8 deletions(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 63253d1de5d7..dba24d0a7b33 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -500,11 +500,10 @@ static ssize_t read_zero(struct file *file, char __user *buf,
 
 static int mmap_zero_prepare(struct vm_area_desc *desc)
 {
-#ifndef CONFIG_MMU
-	return -ENOSYS;
-#endif
+#ifdef CONFIG_MMU
 	if (vma_desc_test(desc, VMA_SHARED_BIT))
 		return shmem_zero_setup_desc(desc);
+#endif
 
 	/*
 	 * This is a highly unique situation where we mark a MAP_PRIVATE mapping
diff --git a/mm/filemap.c b/mm/filemap.c
index d721986d5f46..cf02faad86aa 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -4077,7 +4077,7 @@ int generic_file_mmap(struct file *file, struct vm_area_struct *vma)
 }
 int generic_file_mmap_prepare(struct vm_area_desc *desc)
 {
-	return -ENOSYS;
+	return 0;
 }
 int generic_file_readonly_mmap(struct file *file, struct vm_area_struct *vma)
 {
@@ -4085,7 +4085,9 @@ int generic_file_readonly_mmap(struct file *file, struct vm_area_struct *vma)
 }
 int generic_file_readonly_mmap_prepare(struct vm_area_desc *desc)
 {
-	return -ENOSYS;
+	if (is_shared_maywrite(&desc->vma_flags))
+		return -EINVAL;
+	return generic_file_mmap_prepare(desc);
 }
 #endif /* CONFIG_MMU */
 
diff --git a/mm/nommu.c b/mm/nommu.c
index e40990e15831..a29a53c1c80a 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -37,6 +37,7 @@
 
 #include <linux/uaccess.h>
 #include <linux/uio.h>
+#include <linux/major.h>
 #include <asm/tlb.h>
 #include <asm/tlbflush.h>
 #include <asm/mmu_context.h>
@@ -856,6 +857,22 @@ static int validate_mmap_request(struct file *file,
 	return 0;
 }
 
+static int is_file_anonymous(struct file *file)
+{
+	if (!file)
+		return 1;
+
+	if (file->f_path.dentry && file->f_path.dentry->d_inode) {
+		struct inode *inode = file->f_path.dentry->d_inode;
+		/* if the device is /dev/zero */
+		if (S_ISCHR(inode->i_mode) &&
+		    imajor(inode) == MEM_MAJOR && iminor(inode) == 5)
+			return 1;
+	}
+
+	return 0;
+}
+
 /*
  * we've determined that we can make the mapping, now translate what we
  * now know into VMA flags
@@ -869,7 +886,11 @@ static vm_flags_t determine_vm_flags(struct file *file,
 
 	vm_flags = calc_vm_prot_bits(prot, 0) | calc_vm_flag_bits(file, flags);
 
-	if (!file) {
+	/* private and file mapping will be marked anonymous later (do_mmap_private()).
+	 * and /dev/zero is marked by them at .mmap_prepare,
+	 * which should be _before_ this point.
+	 */
+	if (is_file_anonymous(file)) {
 		/*
 		 * MAP_ANONYMOUS. MAP_SHARED is mapped to MAP_PRIVATE, because
 		 * there is no fork().
@@ -923,6 +944,29 @@ static int do_mmap_shared_file(struct vm_area_struct *vma)
 	return -ENODEV;
 }
 
+static ssize_t nommu_read_iter(struct file *file, void *buf,
+			       size_t count, loff_t *pos)
+{
+	struct iov_iter iter;
+	ssize_t ret;
+	size_t done = 0;
+
+	while (done < count) {
+		struct kvec iov = {
+			.iov_base = buf + done,
+			.iov_len = min_t(size_t, count - done, MAX_RW_COUNT),
+		};
+
+		iov_iter_kvec(&iter, ITER_DEST, &iov, 1, iov.iov_len);
+		ret = vfs_iter_read(file, &iter, pos, 0);
+		if (ret <= 0)
+			return done ? done : ret;
+		done += ret;
+	}
+
+	return done;
+}
+
 /*
  * set up a private mapping or an anonymous shared mapping
  */
@@ -993,7 +1037,7 @@ static int do_mmap_private(struct vm_area_struct *vma,
 		fpos = vma->vm_pgoff;
 		fpos <<= PAGE_SHIFT;
 
-		ret = kernel_read(vma->vm_file, base, len, &fpos);
+		ret = nommu_read_iter(vma->vm_file, base, len, &fpos);
 		if (ret < 0)
 			goto error_free;
 
@@ -1080,6 +1124,28 @@ unsigned long do_mmap(struct file *file,
 		vma->vm_file = get_file(file);
 	}
 
+	/* call mmap_prepare function if any */
+	if (!(flags & MAP_SHARED) && !(capabilities & NOMMU_MAP_DIRECT) &&
+	    (vma->vm_file && vma->vm_file->f_op->mmap_prepare)) {
+		struct vm_area_desc desc;
+
+		vma->vm_start = addr;
+		vma->vm_end = addr + len;
+
+		compat_set_desc_from_vma(&desc, vma->vm_file, vma);
+		ret = vma->vm_file->f_op->mmap_prepare(&desc);
+		/* private ramfs/romfs mappings fails with -ENOSYS so,
+		 * fall back to copied mapping.
+		 */
+		if (ret && ret != -ENOSYS)
+			goto error_mmap_prepare;
+
+		ret = __compat_vma_mmap(&desc, vma);
+		if (ret)
+			goto error_mmap_prepare;
+	}
+
+
 	down_write(&nommu_region_sem);
 
 	/* if we want to share, we need to check for regions created by other
@@ -1196,7 +1262,7 @@ unsigned long do_mmap(struct file *file,
 	add_nommu_region(region);
 
 	/* clear anonymous mappings that don't ask for uninitialized data */
-	if (vma_is_anonymous(vma) &&
+	if (is_file_anonymous(vma->vm_file) &&
 	    (!IS_ENABLED(CONFIG_MMAP_ALLOW_UNINITIALIZED) ||
 	     !(flags & MAP_UNINITIALIZED)))
 		memset((void *)region->vm_start, 0,
@@ -1247,6 +1313,18 @@ unsigned long do_mmap(struct file *file,
 	ret = -EINVAL;
 	goto error;
 
+error_mmap_prepare:
+	if (region->vm_file)
+		fput(region->vm_file);
+	kmem_cache_free(vm_region_jar, region);
+	if (vma->vm_file)
+		fput(vma->vm_file);
+	vm_area_free(vma);
+
+	pr_warn("mmap_prepare failed for %lu byte allocation from process %d\n",
+			len, current->pid);
+	return ret;
+
 error_getting_vma:
 	kmem_cache_free(vm_region_jar, region);
 	pr_warn("Allocation of vma for %lu byte allocation from process %d failed\n",
-- 
2.43.0

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Greg Kroah-Hartman]

On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote:
> Upon a private file mapping request to /dev/zero, it calls
> kernel_read() in do_mmap_private(), getting a failure with the message
> like: "kernel reads not supported for file /dev/zero", which is because
> zero_fops defined in drivers/char/mem.c has both .read and .read_iter
> definitions.

Do you actually use a no-mmu system?

> Even fixing this issue, the map request to /dev/zero works fine without
> errors but the allocated vma isn't marked with anonymous because
> mmap_zero_prepare() isn't called under nommu platform, resulting
> vma_desc_set_anonymous() isn't called either.
> 
> This commit fixes those issues by:
> 1) use vfs_iter_read() instead to avoid failure at kernel_read()
> 2) calls .mmap_prepare on private mapping in do_mmap() so that required
>    preparations are done even in private mapping.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Liam R. Howlett" <liam@infradead.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Jann Horn <jannh@google.com>
> Cc: Pedro Falcato <pfalcato@suse.de>
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-mm@kvack.org (open list:PAGE CACHE)
> Fixes: 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops")

Given the age of this issue, I don't think anyone uses no-mmu systems
anymore :(



> Assisted-by: cubic.dev:unspecified
> Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
> ---
>  drivers/char/mem.c |  5 ++-
>  mm/filemap.c       |  6 ++--
>  mm/nommu.c         | 84 ++++++++++++++++++++++++++++++++++++++++++++--
>  3 files changed, 87 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 63253d1de5d7..dba24d0a7b33 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -500,11 +500,10 @@ static ssize_t read_zero(struct file *file, char __user *buf,
>  
>  static int mmap_zero_prepare(struct vm_area_desc *desc)
>  {
> -#ifndef CONFIG_MMU
> -	return -ENOSYS;
> -#endif
> +#ifdef CONFIG_MMU
>  	if (vma_desc_test(desc, VMA_SHARED_BIT))
>  		return shmem_zero_setup_desc(desc);
> +#endif
>  
>  	/*
>  	 * This is a highly unique situation where we mark a MAP_PRIVATE mapping
> diff --git a/mm/filemap.c b/mm/filemap.c
> index d721986d5f46..cf02faad86aa 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -4077,7 +4077,7 @@ int generic_file_mmap(struct file *file, struct vm_area_struct *vma)
>  }
>  int generic_file_mmap_prepare(struct vm_area_desc *desc)
>  {
> -	return -ENOSYS;
> +	return 0;
>  }
>  int generic_file_readonly_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> @@ -4085,7 +4085,9 @@ int generic_file_readonly_mmap(struct file *file, struct vm_area_struct *vma)
>  }
>  int generic_file_readonly_mmap_prepare(struct vm_area_desc *desc)
>  {
> -	return -ENOSYS;
> +	if (is_shared_maywrite(&desc->vma_flags))
> +		return -EINVAL;
> +	return generic_file_mmap_prepare(desc);
>  }
>  #endif /* CONFIG_MMU */
>  
> diff --git a/mm/nommu.c b/mm/nommu.c
> index e40990e15831..a29a53c1c80a 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -37,6 +37,7 @@
>  
>  #include <linux/uaccess.h>
>  #include <linux/uio.h>
> +#include <linux/major.h>
>  #include <asm/tlb.h>
>  #include <asm/tlbflush.h>
>  #include <asm/mmu_context.h>
> @@ -856,6 +857,22 @@ static int validate_mmap_request(struct file *file,
>  	return 0;
>  }
>  
> +static int is_file_anonymous(struct file *file)
> +{
> +	if (!file)
> +		return 1;
> +
> +	if (file->f_path.dentry && file->f_path.dentry->d_inode) {
> +		struct inode *inode = file->f_path.dentry->d_inode;
> +		/* if the device is /dev/zero */
> +		if (S_ISCHR(inode->i_mode) &&
> +		    imajor(inode) == MEM_MAJOR && iminor(inode) == 5)
> +			return 1;
> +	}
> +
> +	return 0;
> +}
> +
>  /*
>   * we've determined that we can make the mapping, now translate what we
>   * now know into VMA flags
> @@ -869,7 +886,11 @@ static vm_flags_t determine_vm_flags(struct file *file,
>  
>  	vm_flags = calc_vm_prot_bits(prot, 0) | calc_vm_flag_bits(file, flags);
>  
> -	if (!file) {
> +	/* private and file mapping will be marked anonymous later (do_mmap_private()).
> +	 * and /dev/zero is marked by them at .mmap_prepare,
> +	 * which should be _before_ this point.
> +	 */

Wrong coding style for the comment, which is very typical of
LLM-generated stuff.  Always rewrite the output of these tools to
actually be sane.

thanks,

greg k-h

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Daniel Palmer]

Hi Greg,

On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:

> Given the age of this issue, I don't think anyone uses no-mmu systems
> anymore :(

There are a few of us using it for hobby stuff[0][1] and there are
apparently people using it for actual commercial stuff.
There was a session about this at LPC 2025...

One of the big problems for nommu seems to be that everyone is
convinced it is completely unused and totally broken. :)

Cheers,

Daniel

0 - Really good example(s) of the 68000 port
https://github.com/crmaykish/mackerel-68k
1 - https://github.com/LinuxMD/linuxmd my version of the 68000 code
with devicetree like those fancy ARM things running on a sega
megadrive.

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Matthew Wilcox]

On Thu, Aug 13, 2026 at 09:19:47PM +0900, Greg Kroah-Hartman wrote:
> On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote:
> > Upon a private file mapping request to /dev/zero, it calls
> > kernel_read() in do_mmap_private(), getting a failure with the message
> > like: "kernel reads not supported for file /dev/zero", which is because
> > zero_fops defined in drivers/char/mem.c has both .read and .read_iter
> > definitions.
> 
> Do you actually use a no-mmu system?

If you look at Hajime's contributions, you'll see they're far from an AI
slopper.

https://lore.kernel.org/linux-mm/?q=hajime+tazaki

> > @@ -869,7 +886,11 @@ static vm_flags_t determine_vm_flags(struct file *file,
> >  
> >  	vm_flags = calc_vm_prot_bits(prot, 0) | calc_vm_flag_bits(file, flags);
> >  
> > -	if (!file) {
> > +	/* private and file mapping will be marked anonymous later (do_mmap_private()).
> > +	 * and /dev/zero is marked by them at .mmap_prepare,
> > +	 * which should be _before_ this point.
> > +	 */
> 
> Wrong coding style for the comment, which is very typical of
> LLM-generated stuff.  Always rewrite the output of these tools to
> actually be sane.

A lot of humans write comments like this too.  Indeed, it used to be
the preferred style for net/

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> Hi Greg,
>
> On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>
> > Given the age of this issue, I don't think anyone uses no-mmu systems
> > anymore :(
>
> There are a few of us using it for hobby stuff[0][1] and there are
> apparently people using it for actual commercial stuff.
> There was a session about this at LPC 2025...
>
> One of the big problems for nommu seems to be that everyone is
> convinced it is completely unused and totally broken. :)

No, the issue is that nobody seems to do any testing or contribute any code
aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
I am missing people's names here!)

There's been situtions where nommu has been broken for a year and _nobody
noticed_.

And yet whenever nommu comes up people always seem to pop up and say how
important it is, then mention a talk etc.

Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
code. Any or all of it :)

Meanwhile we in mm have to _constantly_ fix stuff up in nommu because it's a
total mess and has real maintenance overhead.

Having to account for legacy systems that make no sense in 2026 when you're
trying to make improvements to systems people use, or not being able to do
certain things, really grates after a while.

I mean if you don't believe me git log mm/nommu.c. This overhead reason is why I
now co-maintain it.

So I'm honestly a bit tired of people popping up when the whole 'why nommu'
thing comes up, then disappearing when there's work to be done.

In general - it's not really for those not doing the work to dictate terms to
those who do, IMO.

So while I appreciate you confirming there are users (yes we know :) frankly
that's not the question. The question is - why isn't a downstream kernel enough
for you?

Last time I brought this up I basically got radio silence, a couple times before
that I was told 'nommu has no maintenance overhead and is perfectly good code
and we have products' by somebody who contributes little to nothing in terms of
code and nothing no testing.

So bah humbug.

AFAIC it needs to go and we should never have allowed risc v to add a new nommu
arch.

>
> Cheers,
>
> Daniel
>
> 0 - Really good example(s) of the 68000 port
> https://github.com/crmaykish/mackerel-68k
> 1 - https://github.com/LinuxMD/linuxmd my version of the 68000 code
> with devicetree like those fancy ARM things running on a sega
> megadrive.

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

On Thu, Aug 13, 2026 at 02:22:03PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 13, 2026 at 09:19:47PM +0900, Greg Kroah-Hartman wrote:
> > On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote:
> > > Upon a private file mapping request to /dev/zero, it calls
> > > kernel_read() in do_mmap_private(), getting a failure with the message
> > > like: "kernel reads not supported for file /dev/zero", which is because
> > > zero_fops defined in drivers/char/mem.c has both .read and .read_iter
> > > definitions.
> >
> > Do you actually use a no-mmu system?
>
> If you look at Hajime's contributions, you'll see they're far from an AI
> slopper.
>
> https://lore.kernel.org/linux-mm/?q=hajime+tazaki
>
> > > @@ -869,7 +886,11 @@ static vm_flags_t determine_vm_flags(struct file *file,
> > >
> > >  	vm_flags = calc_vm_prot_bits(prot, 0) | calc_vm_flag_bits(file, flags);
> > >
> > > -	if (!file) {
> > > +	/* private and file mapping will be marked anonymous later (do_mmap_private()).
> > > +	 * and /dev/zero is marked by them at .mmap_prepare,
> > > +	 * which should be _before_ this point.
> > > +	 */
> >
> > Wrong coding style for the comment, which is very typical of
> > LLM-generated stuff.  Always rewrite the output of these tools to
> > actually be sane.
>
> A lot of humans write comments like this too.  Indeed, it used to be
> the preferred style for net/

Yeah Hajime is one of the good guys and I don't think he's a schlopper.

(I do want to review his series, as usual time is against me :)

I do agree with Greg however that nommu is something we should get rid of. See
my other reply here.

Am frankly fed up with people telling us that nommu really matters and giving
talks at conferences but contributing nothing (apart from Hajime, who deserves
respect for walking the walk on that!)

If nommu can be broken for a year with nobody noticing, then maybe it's time to
see if anybody notices us removing it too.

Sadly I think Linus won't share this opinion but as co-maintainer of mm/nommu.c
this is my perspective ;)

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

On Thu, Aug 13, 2026 at 02:32:27PM +0100, Lorenzo Stoakes (ARM) wrote:
> I do agree with Greg however that nommu is something we should get rid of. See
> my other reply here.

Sorry this was an overreach - Greg didn't say that :)

I mean Greg asked if anybody uses nommu, the answer is yes, but the real
question I think is 'is anybody using a very recent kernel who couldn't either
use an older one or maintain a downstream kernel'.

And to that I think the answer is absolutely not.

And if the answer were yes - you must surely be a company with a product
(security concerns on a nommu system is a debatable concept) - and then you need
to put up or shut up IMO.

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Daniel Palmer]

HI Lorenzo,

On Thu, 13 Aug 2026 at 22:30, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> > One of the big problems for nommu seems to be that everyone is
> > convinced it is completely unused and totally broken. :)
>
> No, the issue is that nobody seems to do any testing or contribute any code
> aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> I am missing people's names here!)

> There's been situtions where nommu has been broken for a year and _nobody
> noticed_.
>
> And yet whenever nommu comes up people always seem to pop up and say how
> important it is, then mention a talk etc.

It also broke sometime around LPC 2025, I spotted it, reported it..
and told the people in the room at LPC for the nommu talk that it was
borken and maybe they should take a look. :)
I think I maybe even told Tazaki-san in person that it was currently
broken in the hall outside of the session.

> Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> code. Any or all of it :)

I rebase my 68000 tree on mainline regularly and make sure it still
works. That's how I noticed and reported the above bug.
I have a bunch of stuff that claude fable found, validated with QEMU
and then I checked on real hardware but I'm not sure how to send that
without it getting instantly marked as slop. :(

Cheers,

Daniel

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

On Thu, Aug 13, 2026 at 10:51:39PM +0900, Daniel Palmer wrote:
> HI Lorenzo,
>
> On Thu, 13 Aug 2026 at 22:30, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> > > One of the big problems for nommu seems to be that everyone is
> > > convinced it is completely unused and totally broken. :)
> >
> > No, the issue is that nobody seems to do any testing or contribute any code
> > aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> > I am missing people's names here!)
>
> > There's been situtions where nommu has been broken for a year and _nobody
> > noticed_.
> >
> > And yet whenever nommu comes up people always seem to pop up and say how
> > important it is, then mention a talk etc.
>
> It also broke sometime around LPC 2025, I spotted it, reported it..
> and told the people in the room at LPC for the nommu talk that it was
> borken and maybe they should take a look. :)
> I think I maybe even told Tazaki-san in person that it was currently
> broken in the hall outside of the session.

OK this is what I like to hear :) please report it on-list.

If you do:

$ scripts/get_maintainer.pl mm/nommu.c

And send reports to all people/lists listed it'd be appreciated!

The grumpiness is not the usual mm reception, and certainly not that to bug
reports/patches.

>
> > Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> > code. Any or all of it :)
>
> I rebase my 68000 tree on mainline regularly and make sure it still
> works. That's how I noticed and reported the above bug.
> I have a bunch of stuff that claude fable found, validated with QEMU
> and then I checked on real hardware but I'm not sure how to send that
> without it getting instantly marked as slop. :(

If you check on real hardware and confirm the bug that's not slop that's a
legitimate bug!

I'd ask that you do a human pass over anything produced and rewrite any of the
insane paragraphs it comes up with and then check to make sure it's all valid
first.

And if you can come up with a patch (please human-written though using AI to
help is absolutely fine - I do the same) all the more better.

>
> Cheers,
>
> Daniel

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Greg Kroah-Hartman]

On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> Hi Greg,
> 
> On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> 
> > Given the age of this issue, I don't think anyone uses no-mmu systems
> > anymore :(
> 
> There are a few of us using it for hobby stuff[0][1] and there are
> apparently people using it for actual commercial stuff.
> There was a session about this at LPC 2025...

This patch is fixing a very obvious issue that showed up in the 5.10
kernel, which was released in December 2020.

So I think the fact that no one has reported it before now means that no
one is actually using it :)

thanks,

greg k-h

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Greg Kroah-Hartman]

On Thu, Aug 13, 2026 at 02:22:03PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 13, 2026 at 09:19:47PM +0900, Greg Kroah-Hartman wrote:
> > On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote:
> > > Upon a private file mapping request to /dev/zero, it calls
> > > kernel_read() in do_mmap_private(), getting a failure with the message
> > > like: "kernel reads not supported for file /dev/zero", which is because
> > > zero_fops defined in drivers/char/mem.c has both .read and .read_iter
> > > definitions.
> > 
> > Do you actually use a no-mmu system?
> 
> If you look at Hajime's contributions, you'll see they're far from an AI
> slopper.
> 
> https://lore.kernel.org/linux-mm/?q=hajime+tazaki

That's not what I asked at all.

This patch is fixing /dev/zero which was broken in 2020 for these
systems.  I think my question was a legit one, I was not casting
aspersions about any slop here in any way.

> > > @@ -869,7 +886,11 @@ static vm_flags_t determine_vm_flags(struct file *file,
> > >  
> > >  	vm_flags = calc_vm_prot_bits(prot, 0) | calc_vm_flag_bits(file, flags);
> > >  
> > > -	if (!file) {
> > > +	/* private and file mapping will be marked anonymous later (do_mmap_private()).
> > > +	 * and /dev/zero is marked by them at .mmap_prepare,
> > > +	 * which should be _before_ this point.
> > > +	 */
> > 
> > Wrong coding style for the comment, which is very typical of
> > LLM-generated stuff.  Always rewrite the output of these tools to
> > actually be sane.
> 
> A lot of humans write comments like this too.  Indeed, it used to be
> the preferred style for net/

Yes, but it's not for anything outside of net/

thanks,

greg k-h

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Greg Kroah-Hartman]

On Thu, Aug 13, 2026 at 10:51:39PM +0900, Daniel Palmer wrote:
> HI Lorenzo,
> 
> On Thu, 13 Aug 2026 at 22:30, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> > > One of the big problems for nommu seems to be that everyone is
> > > convinced it is completely unused and totally broken. :)
> >
> > No, the issue is that nobody seems to do any testing or contribute any code
> > aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> > I am missing people's names here!)
> 
> > There's been situtions where nommu has been broken for a year and _nobody
> > noticed_.
> >
> > And yet whenever nommu comes up people always seem to pop up and say how
> > important it is, then mention a talk etc.
> 
> It also broke sometime around LPC 2025, I spotted it, reported it..
> and told the people in the room at LPC for the nommu talk that it was
> borken and maybe they should take a look. :)
> I think I maybe even told Tazaki-san in person that it was currently
> broken in the hall outside of the session.
> 
> > Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> > code. Any or all of it :)
> 
> I rebase my 68000 tree on mainline regularly and make sure it still
> works. That's how I noticed and reported the above bug.
> I have a bunch of stuff that claude fable found, validated with QEMU
> and then I checked on real hardware but I'm not sure how to send that
> without it getting instantly marked as slop. :(

I didn't say anything about slop here, and in fact, _I_ have fixed up an
io_uring nommu bug in the past, using LLM tooling.  I am not objecting
to the use of that tool here at all, I am only commenting on the fact
that this bug has been present since 2020 without anyone noticing before
now, which implies a severe lack of users.

Heck, the out-of-tree ia64 developers report things faster than this :)

thanks,

greg k-h

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

+cc Christoph

On Thu, Aug 13, 2026 at 11:02:18PM +0900, Greg Kroah-Hartman wrote:
> On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> > Hi Greg,
> >
> > On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> >
> > > Given the age of this issue, I don't think anyone uses no-mmu systems
> > > anymore :(
> >
> > There are a few of us using it for hobby stuff[0][1] and there are
> > apparently people using it for actual commercial stuff.
> > There was a session about this at LPC 2025...
>
> This patch is fixing a very obvious issue that showed up in the 5.10
> kernel, which was released in December 2020.
>
> So I think the fact that no one has reported it before now means that no
> one is actually using it :)

Maybe Christoph has a view on this?

I brought this up a couple years ago and he claimed there are commerical
products which use the latest long-term stable kernel (6.18 at the time of
writing).

See https://lore.kernel.org/linux-mm/20241122123833.GA26432@lst.de/

Christoph - can you explain why none of these vendors encountered any of these
bugs or breakages?

If they are doing fixes that are downstream only, then that argues against
upstream nommu.

If they are not, in fact, using long term stable kernels, that argues against
upstream nommu.

The fact they seem to be assigning zero resource to upstream also argues against
upstream nommu.

nommu continues to be a ongoing burden for core mm that interferes with work on
real architectures on a fairly regularly basis, which argues against upstream
nommu.

I'm curious to learn what the arguments _for_ upstream nommu are?

>
> thanks,
>
> greg k-h

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Geert Uytterhoeven]

CC Jeff

On Thu, 13 Aug 2026 at 16:11, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
>
> +cc Christoph
>
> On Thu, Aug 13, 2026 at 11:02:18PM +0900, Greg Kroah-Hartman wrote:
> > On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> > > Hi Greg,
> > >
> > > On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > >
> > > > Given the age of this issue, I don't think anyone uses no-mmu systems
> > > > anymore :(
> > >
> > > There are a few of us using it for hobby stuff[0][1] and there are
> > > apparently people using it for actual commercial stuff.
> > > There was a session about this at LPC 2025...
> >
> > This patch is fixing a very obvious issue that showed up in the 5.10
> > kernel, which was released in December 2020.
> >
> > So I think the fact that no one has reported it before now means that no
> > one is actually using it :)
>
> Maybe Christoph has a view on this?
>
> I brought this up a couple years ago and he claimed there are commerical
> products which use the latest long-term stable kernel (6.18 at the time of
> writing).
>
> See https://lore.kernel.org/linux-mm/20241122123833.GA26432@lst.de/
>
> Christoph - can you explain why none of these vendors encountered any of these
> bugs or breakages?
>
> If they are doing fixes that are downstream only, then that argues against
> upstream nommu.
>
> If they are not, in fact, using long term stable kernels, that argues against
> upstream nommu.
>
> The fact they seem to be assigning zero resource to upstream also argues against
> upstream nommu.
>
> nommu continues to be a ongoing burden for core mm that interferes with work on
> real architectures on a fairly regularly basis, which argues against upstream
> nommu.
>
> I'm curious to learn what the arguments _for_ upstream nommu are?
>
> >
> > thanks,
> >
> > greg k-h
>
> --
> Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

The subject isn't great - before you're not allowed to mmap /dev/zero _at
all_ on nommu, here you try to allow it.

I'm kinda against it to be honest, nommu has been functioning... I'll not
say perfectly fine, given it's broken in many ways that nobody ever
reports, but I'd say instead 'the same as it was' with no issue.

And you're not really explaining why you need this.

You're not correctly supporting MAP_SHARED-/dev/zero AFAICT at all, it'll
just... actually I don't know what it'll do


On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote:
> Upon a private file mapping request to /dev/zero, it calls
> kernel_read() in do_mmap_private(), getting a failure with the message
> like: "kernel reads not supported for file /dev/zero", which is because
> zero_fops defined in drivers/char/mem.c has both .read and .read_iter
> definitions.

Can this be broken out into its own separate fix please.

It's not about /dev/zero at all but rather being able to MAP_PRIVATE-map
literally anything with .read and .read_iter.

>
> Even fixing this issue, the map request to /dev/zero works fine without
> errors but the allocated vma isn't marked with anonymous because
> mmap_zero_prepare() isn't called under nommu platform, resulting
> vma_desc_set_anonymous() isn't called either.

"Resulting _in_ vma_desc_set_anonymous() _not being_ called either" is clearer.

>
> This commit fixes those issues by:

Already 'issues' suggests >1 patch would be a better idea :)

> 1) use vfs_iter_read() instead to avoid failure at kernel_read()
> 2) calls .mmap_prepare on private mapping in do_mmap() so that required
>    preparations are done even in private mapping.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Liam R. Howlett" <liam@infradead.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Jann Horn <jannh@google.com>
> Cc: Pedro Falcato <pfalcato@suse.de>
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-mm@kvack.org (open list:PAGE CACHE)
> Fixes: 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops")

Yeah as Greg says, it really suggests nobody is using mainline nommu in any
serious way given this is from 5.10 and would require avoiding /dev/zero in
a way that seems kinda unlikely.

Should be Cc: stable also but not as a combined patch, the mmap_prepare
bits only came in recently.

> Assisted-by: cubic.dev:unspecified

Unspecified? :)

Really the best approach nowadays is:

Assisted-by: LLM # it wrote the whole thing

or:

Assisted-by: LLM # it merely complimented my dress sense

Or whatever :)

> Signed-off-by: Hajime Tazaki <thehajime@gmail.com>

In general this is opening up whole new areas of code to nommu and given
nobody seems to be testing anything I'm not sure I'm ok with it.

Since forever /dev/zero's been disabled for mmap in nommu. So I don't
really see the point in making it work at quite a lot of risk here +
necessitating doing some more nommu stuff in unrelated areas.

In any case, it's probably worth waiting for me to do my follow up series
on /dev/zero next cycle, which will inform how it will look for real
arches.

It's worth breaking the read_iter fixup out of it though probably, and the
mmap_prepare support.

> ---
>  drivers/char/mem.c |  5 ++-
>  mm/filemap.c       |  6 ++--
>  mm/nommu.c         | 84 ++++++++++++++++++++++++++++++++++++++++++++--
>  3 files changed, 87 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 63253d1de5d7..dba24d0a7b33 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -500,11 +500,10 @@ static ssize_t read_zero(struct file *file, char __user *buf,
>
>  static int mmap_zero_prepare(struct vm_area_desc *desc)
>  {
> -#ifndef CONFIG_MMU
> -	return -ENOSYS;
> -#endif

> +#ifdef CONFIG_MMU
>  	if (vma_desc_test(desc, VMA_SHARED_BIT))
>  		return shmem_zero_setup_desc(desc);
> +#endif

This is pretty horrible already :(

You're also letting VMA_SHARED_BIT be a return 0 noop, that
seems... unwise?

You can use IS_ENABLED(CONFIG_MMU) to make things vastly less terrible,
e.g.:

	static int mmap_zero_prepare(struct vm_area_desc *desc)
	{
		if (!vma_desc_is_cow_mapping(desc)) {
			if (!IS_ENABLED(CONFIG_MMU))
				return -ENOSYS;
			return shmem_zero_setup_desc(desc);
		}
		...
	}

But again, I don't really feel that nommu should be enabling this and I'm
changing the /dev/zero stuff anyway.

>
>  	/*
>  	 * This is a highly unique situation where we mark a MAP_PRIVATE mapping
> diff --git a/mm/filemap.c b/mm/filemap.c
> index d721986d5f46..cf02faad86aa 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -4077,7 +4077,7 @@ int generic_file_mmap(struct file *file, struct vm_area_struct *vma)
>  }
>  int generic_file_mmap_prepare(struct vm_area_desc *desc)
>  {
> -	return -ENOSYS;
> +	return 0;

Err, no, making this a noop breaks it?

I'm not really hugely fine with you making this be the same as CONFIG_MMU
either as I am not confident in the change being correctly audited given
the until-recently total lack of testing of nommu, and now very limited, as
well intentioned as it might be testing.

I would prefer anything that currently doesn't function with nommu to
remain so.

>  }
>  int generic_file_readonly_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> @@ -4085,7 +4085,9 @@ int generic_file_readonly_mmap(struct file *file, struct vm_area_struct *vma)
>  }
>  int generic_file_readonly_mmap_prepare(struct vm_area_desc *desc)
>  {
> -	return -ENOSYS;
> +	if (is_shared_maywrite(&desc->vma_flags))
> +		return -EINVAL;
> +	return generic_file_mmap_prepare(desc);

Again same objections as above re: doing real-arch stuff in nommu.

>  }
>  #endif /* CONFIG_MMU */
>
> diff --git a/mm/nommu.c b/mm/nommu.c
> index e40990e15831..a29a53c1c80a 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -37,6 +37,7 @@
>
>  #include <linux/uaccess.h>
>  #include <linux/uio.h>
> +#include <linux/major.h>
>  #include <asm/tlb.h>
>  #include <asm/tlbflush.h>
>  #include <asm/mmu_context.h>
> @@ -856,6 +857,22 @@ static int validate_mmap_request(struct file *file,
>  	return 0;
>  }
>
> +static int is_file_anonymous(struct file *file)
> +{

As stated on the cover, I don't adore this and that's all changing soon
anyway.


> +	if (!file)
> +		return 1;

It's 2026 use a bool please.

> +
> +	if (file->f_path.dentry && file->f_path.dentry->d_inode) {
> +		struct inode *inode = file->f_path.dentry->d_inode;
> +		/* if the device is /dev/zero */
> +		if (S_ISCHR(inode->i_mode) &&
> +		    imajor(inode) == MEM_MAJOR && iminor(inode) == 5)
> +			return 1;

This is horrible really. The /dev/zero stuff I'm doing kinda had to do
_something_ this this (in a roundabout way) - well I thought so - anyway :)

But yeah again wait for me to do /dev/zero follow up.

> +	}
> +
> +	return 0;
> +}
> +
>  /*
>   * we've determined that we can make the mapping, now translate what we
>   * now know into VMA flags
> @@ -869,7 +886,11 @@ static vm_flags_t determine_vm_flags(struct file *file,
>
>  	vm_flags = calc_vm_prot_bits(prot, 0) | calc_vm_flag_bits(file, flags);
>
> -	if (!file) {
> +	/* private and file mapping will be marked anonymous later (do_mmap_private()).
> +	 * and /dev/zero is marked by them at .mmap_prepare,
> +	 * which should be _before_ this point.
> +	 */
> +	if (is_file_anonymous(file)) {

You're kinda throwing in a bunch of random stuff in 1 patch you really need
to break things out more.

>  		/*
>  		 * MAP_ANONYMOUS. MAP_SHARED is mapped to MAP_PRIVATE, because
>  		 * there is no fork().
> @@ -923,6 +944,29 @@ static int do_mmap_shared_file(struct vm_area_struct *vma)
>  	return -ENODEV;
>  }
>
> +static ssize_t nommu_read_iter(struct file *file, void *buf,
> +			       size_t count, loff_t *pos)
> +{
> +	struct iov_iter iter;
> +	ssize_t ret;
> +	size_t done = 0;
> +
> +	while (done < count) {
> +		struct kvec iov = {
> +			.iov_base = buf + done,
> +			.iov_len = min_t(size_t, count - done, MAX_RW_COUNT),
> +		};
> +
> +		iov_iter_kvec(&iter, ITER_DEST, &iov, 1, iov.iov_len);
> +		ret = vfs_iter_read(file, &iter, pos, 0);
> +		if (ret <= 0)
> +			return done ? done : ret;
> +		done += ret;
> +	}
> +
> +	return done;
> +}
> +
>  /*
>   * set up a private mapping or an anonymous shared mapping
>   */
> @@ -993,7 +1037,7 @@ static int do_mmap_private(struct vm_area_struct *vma,
>  		fpos = vma->vm_pgoff;
>  		fpos <<= PAGE_SHIFT;
>
> -		ret = kernel_read(vma->vm_file, base, len, &fpos);
> +		ret = nommu_read_iter(vma->vm_file, base, len, &fpos);

Hmm so now you just assume there's always a .read_iter and error out if
there isn't one?

Seems questionable.

>  		if (ret < 0)
>  			goto error_free;
>
> @@ -1080,6 +1124,28 @@ unsigned long do_mmap(struct file *file,
>  		vma->vm_file = get_file(file);
>  	}
>
> +	/* call mmap_prepare function if any */
> +	if (!(flags & MAP_SHARED) && !(capabilities & NOMMU_MAP_DIRECT) &&
> +	    (vma->vm_file && vma->vm_file->f_op->mmap_prepare)) {

> +		struct vm_area_desc desc;
> +
> +		vma->vm_start = addr;
> +		vma->vm_end = addr + len;
> +
> +		compat_set_desc_from_vma(&desc, vma->vm_file, vma);
> +		ret = vma->vm_file->f_op->mmap_prepare(&desc);
> +		/* private ramfs/romfs mappings fails with -ENOSYS so,
> +		 * fall back to copied mapping.
> +		 */
> +		if (ret && ret != -ENOSYS)
> +			goto error_mmap_prepare;
> +
> +		ret = __compat_vma_mmap(&desc, vma);
> +		if (ret)
> +			goto error_mmap_prepare;
> +	}

Again break out code into separate functions please!

I invented this compat mmap_prepare stuff to handle stacked file system
mounts, and I intend to remove it once the mmap_prepare conversion is
complete.

But I suppose... maybe stuff could be migrated to nommu.c at that point as
a local fixup just for it.

Probably worth breaking this out as a separate patch too then so
mmap_prepare is properly supported in nommu otherwise stuff will break
there, eventually (with X year lag possibly inf on reporting of course ;)

> +
> +
>  	down_write(&nommu_region_sem);
>
>  	/* if we want to share, we need to check for regions created by other
> @@ -1196,7 +1262,7 @@ unsigned long do_mmap(struct file *file,
>  	add_nommu_region(region);
>
>  	/* clear anonymous mappings that don't ask for uninitialized data */
> -	if (vma_is_anonymous(vma) &&
> +	if (is_file_anonymous(vma->vm_file) &&

As above re: this function.

>  	    (!IS_ENABLED(CONFIG_MMAP_ALLOW_UNINITIALIZED) ||
>  	     !(flags & MAP_UNINITIALIZED)))
>  		memset((void *)region->vm_start, 0,
> @@ -1247,6 +1313,18 @@ unsigned long do_mmap(struct file *file,
>  	ret = -EINVAL;
>  	goto error;
>
> +error_mmap_prepare:
> +	if (region->vm_file)
> +		fput(region->vm_file);
> +	kmem_cache_free(vm_region_jar, region);
> +	if (vma->vm_file)
> +		fput(vma->vm_file);
> +	vm_area_free(vma);
> +
> +	pr_warn("mmap_prepare failed for %lu byte allocation from process %d\n",
> +			len, current->pid);
> +	return ret;
> +
>  error_getting_vma:
>  	kmem_cache_free(vm_region_jar, region);
>  	pr_warn("Allocation of vma for %lu byte allocation from process %d failed\n",
> --
> 2.43.0
>

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Hajime Tazaki]

Hello Greg,

thank you for your time to look at this patch.

On Thu, 13 Aug 2026 21:19:47 +0900,
Greg Kroah-Hartman wrote:
> 
> On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote:
> > Upon a private file mapping request to /dev/zero, it calls
> > kernel_read() in do_mmap_private(), getting a failure with the message
> > like: "kernel reads not supported for file /dev/zero", which is because
> > zero_fops defined in drivers/char/mem.c has both .read and .read_iter
> > definitions.
> 
> Do you actually use a no-mmu system?

yes, and wish to use in future.

I'm going to make a long story short;

nommu kernel is originally for embedded devices but I wish to use for
virtualization.

I gave a talk to explain this motivation below (which you also had a
keynote remotely).  I'm not make a summary for this talk in this
email, but am happy to explain again if needed.

https://www.netdevconf.info/0x1A/sessions/talk/improving-debuggability-of-nommu-code-with-uml.html
https://speakerdeck.com/thehajime/nommu-uml-netdev-0x1a/

> > Even fixing this issue, the map request to /dev/zero works fine without
> > errors but the allocated vma isn't marked with anonymous because
> > mmap_zero_prepare() isn't called under nommu platform, resulting
> > vma_desc_set_anonymous() isn't called either.
> > 
> > This commit fixes those issues by:
> > 1) use vfs_iter_read() instead to avoid failure at kernel_read()
> > 2) calls .mmap_prepare on private mapping in do_mmap() so that required
> >    preparations are done even in private mapping.
> > 
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> > Cc: Jan Kara <jack@suse.cz>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: "Liam R. Howlett" <liam@infradead.org>
> > Cc: Lorenzo Stoakes <ljs@kernel.org>
> > Cc: Vlastimil Babka <vbabka@kernel.org>
> > Cc: Jann Horn <jannh@google.com>
> > Cc: Pedro Falcato <pfalcato@suse.de>
> > Cc: linux-fsdevel@vger.kernel.org
> > Cc: linux-mm@kvack.org (open list:PAGE CACHE)
> > Fixes: 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops")
> 
> Given the age of this issue, I don't think anyone uses no-mmu systems
> anymore :(

I tend to agree; nommu systems does have less users than others.
but I believe this doesn't mean there are no users.

I should also explain more, but I found this issue via a Sashiko
review, which pointed me as a different comment, but when I tried to
reproduce that case pointed by the review, which is about the use of
check `vma->vm_file` v.s., `vma_is_anonymous(vma)`, I found that
/dev/zero is not able to map on nommu kernel.

https://sashiko.dev/#/patchset/20260710054648.924005-1-thehajime%40gmail.com
https://sashiko.dev/#/message/m2cxwvti7z.wl-thehajime%40gmail.com

The alternate path of open()=>read() of /dev/zero works fine as it
doesn't use kernel_read().


I also understand what you feel from the age of this issue (almost 6
years old), and that is exactly why I start implementing test cases in
kselftest, which is currently not able to run (even build) for nommu
platforms.  This series also includes the extension to kselftest
([4,5,6/6] patches are for that).


> > -	if (!file) {
> > +	/* private and file mapping will be marked anonymous later (do_mmap_private()).
> > +	 * and /dev/zero is marked by them at .mmap_prepare,
> > +	 * which should be _before_ this point.
> > +	 */
> 
> Wrong coding style for the comment, which is very typical of
> LLM-generated stuff.  Always rewrite the output of these tools to
> actually be sane.

this is my fault.

As I mentioned in the Assisted-by tag, I indeed used an AI review
system (which is cubic.dev), but I wrote this comment by my hand.

Because I thought this part is not easy to follow and felt that I need
additional explanation rather than just showing diff.

since checkpatch.pl doesn't complain this, I didn't carefully look at
the style of this comment block.

I will update this (as well as bunch of comments from Sashiko).

thanks,
-- Hajime

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Hajime Tazaki]

Hello Lorenzo,

On Thu, 13 Aug 2026 22:29:38 +0900,
Lorenzo Stoakes (ARM) wrote:
> 
> On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> > Hi Greg,
> >
> > On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> >
> > > Given the age of this issue, I don't think anyone uses no-mmu systems
> > > anymore :(
> >
> > There are a few of us using it for hobby stuff[0][1] and there are
> > apparently people using it for actual commercial stuff.
> > There was a session about this at LPC 2025...
> >
> > One of the big problems for nommu seems to be that everyone is
> > convinced it is completely unused and totally broken. :)
> 
> No, the issue is that nobody seems to do any testing or contribute any code
> aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> I am missing people's names here!)
> 
> There's been situtions where nommu has been broken for a year and _nobody
> noticed_.
> 
> And yet whenever nommu comes up people always seem to pop up and say how
> important it is, then mention a talk etc.
> 
> Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> code. Any or all of it :)
> 
> Meanwhile we in mm have to _constantly_ fix stuff up in nommu because it's a
> total mess and has real maintenance overhead.
> 
> Having to account for legacy systems that make no sense in 2026 when you're
> trying to make improvements to systems people use, or not being able to do
> certain things, really grates after a while.
> 
> I mean if you don't believe me git log mm/nommu.c. This overhead reason is why I
> now co-maintain it.

after spending more times to look at code, fixing issues, finding
other flaws, etc, now I become to understand what you meant in past
emails, when you're saying a more maintainable way of implementation
of nommu.c.

Since I wish to use nommu.c in future with the latest kernel, I'd like
to contribute it for, let's say, refactoring the nommu component which
mm subsystem currently has.

but for the moment, I wish to start with introducing test cases from
very basic checks (which is in the [6/6] patch of this series).
Without such a base, we may not have any chances to improve this nasty
situation of nommu component in mm subsystem.

# this motivation also applies to LTP (linux test project) which
  currently doesn't support running tests on nommu platforms (I've
  already started).

And also as I mentioned before, ideally the code should be maintained
by people who use it.  And if I claimed that I used/use/will use
nommu.c, I wish to maintain this, or at least wish to help to decrease
the overhead of maintainers.  This series is a very fist step toward
this.

I hope it clarifies a bit for your concerns,
-- Hajime

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Lorenzo Stoakes (ARM)]

On Fri, Aug 14, 2026 at 09:42:57PM +0900, Hajime Tazaki wrote:
>
> Hello Lorenzo,
>
> On Thu, 13 Aug 2026 22:29:38 +0900,
> Lorenzo Stoakes (ARM) wrote:
> >
> > On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> > > Hi Greg,
> > >
> > > On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > >
> > > > Given the age of this issue, I don't think anyone uses no-mmu systems
> > > > anymore :(
> > >
> > > There are a few of us using it for hobby stuff[0][1] and there are
> > > apparently people using it for actual commercial stuff.
> > > There was a session about this at LPC 2025...
> > >
> > > One of the big problems for nommu seems to be that everyone is
> > > convinced it is completely unused and totally broken. :)
> >
> > No, the issue is that nobody seems to do any testing or contribute any code
> > aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> > I am missing people's names here!)
> >
> > There's been situtions where nommu has been broken for a year and _nobody
> > noticed_.
> >
> > And yet whenever nommu comes up people always seem to pop up and say how
> > important it is, then mention a talk etc.
> >
> > Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> > code. Any or all of it :)
> >
> > Meanwhile we in mm have to _constantly_ fix stuff up in nommu because it's a
> > total mess and has real maintenance overhead.
> >
> > Having to account for legacy systems that make no sense in 2026 when you're
> > trying to make improvements to systems people use, or not being able to do
> > certain things, really grates after a while.
> >
> > I mean if you don't believe me git log mm/nommu.c. This overhead reason is why I
> > now co-maintain it.
>
> after spending more times to look at code, fixing issues, finding
> other flaws, etc, now I become to understand what you meant in past
> emails, when you're saying a more maintainable way of implementation
> of nommu.c.

Yes :)

Thanks for having some empathy about this :) It seems a lot of the nommu
advocates simply assume it's little or no overhead and is 'working
code'. No and no.

I know Liam had to do a _lot_ of work on maple tree to make things work
there, for instance.

And the recent VMA flags changes have had to be heavily updated to account
for nommu.

And the list goes on. New features have to touch it all the time to avoid
build failures even, and etc. etc.

It's a really absurd situation to be honest and the RoI isn't there at all.

There's a reason I keep going on about this :)

>
> Since I wish to use nommu.c in future with the latest kernel, I'd like
> to contribute it for, let's say, refactoring the nommu component which
> mm subsystem currently has.
>
> but for the moment, I wish to start with introducing test cases from
> very basic checks (which is in the [6/6] patch of this series).
> Without such a base, we may not have any chances to improve this nasty
> situation of nommu component in mm subsystem.
>
> # this motivation also applies to LTP (linux test project) which
>   currently doesn't support running tests on nommu platforms (I've
>   already started).
>
> And also as I mentioned before, ideally the code should be maintained
> by people who use it.  And if I claimed that I used/use/will use
> nommu.c, I wish to maintain this, or at least wish to help to decrease
> the overhead of maintainers.  This series is a very fist step toward
> this.
>
> I hope it clarifies a bit for your concerns,

Thanks, and I appreciate that you're actually doing work here, but I'm not
sure a single person suffices for this, as well intentioned as you are.

And as reviewed, these changes seem to be adding _more_ maintainership
overhead rather than less, I fear.

I believe nommu is pretty broken across many domains (it's fun to set
claude on it for instance).

And we've already spoken about broken things that have sat around for
a long time.

The way it's implemented now is just horrendous in any case, if we were
forced to keep it in the upstream kernel then the correct solution would be
something that somehow 'emulates' an mmu system.

But I'm not sure that's even workable, and likely implies heavy
maintainership headaches.

> -- Hajime
>

--
Cheers, Lorenzo

Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

[Hajime Tazaki]

On Fri, 14 Aug 2026 22:02:21 +0900,
Lorenzo Stoakes (ARM) wrote:
> 
> On Fri, Aug 14, 2026 at 09:42:57PM +0900, Hajime Tazaki wrote:
> >
> > Hello Lorenzo,
> >
> > On Thu, 13 Aug 2026 22:29:38 +0900,
> > Lorenzo Stoakes (ARM) wrote:
> > >
> > > On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> > > > Hi Greg,
> > > >
> > > > On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > > Given the age of this issue, I don't think anyone uses no-mmu systems
> > > > > anymore :(
> > > >
> > > > There are a few of us using it for hobby stuff[0][1] and there are
> > > > apparently people using it for actual commercial stuff.
> > > > There was a session about this at LPC 2025...
> > > >
> > > > One of the big problems for nommu seems to be that everyone is
> > > > convinced it is completely unused and totally broken. :)
> > >
> > > No, the issue is that nobody seems to do any testing or contribute any code
> > > aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> > > I am missing people's names here!)
> > >
> > > There's been situtions where nommu has been broken for a year and _nobody
> > > noticed_.
> > >
> > > And yet whenever nommu comes up people always seem to pop up and say how
> > > important it is, then mention a talk etc.
> > >
> > > Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> > > code. Any or all of it :)
> > >
> > > Meanwhile we in mm have to _constantly_ fix stuff up in nommu because it's a
> > > total mess and has real maintenance overhead.
> > >
> > > Having to account for legacy systems that make no sense in 2026 when you're
> > > trying to make improvements to systems people use, or not being able to do
> > > certain things, really grates after a while.
> > >
> > > I mean if you don't believe me git log mm/nommu.c. This overhead reason is why I
> > > now co-maintain it.
> >
> > after spending more times to look at code, fixing issues, finding
> > other flaws, etc, now I become to understand what you meant in past
> > emails, when you're saying a more maintainable way of implementation
> > of nommu.c.
> 
> Yes :)
> 
> Thanks for having some empathy about this :) It seems a lot of the nommu
> advocates simply assume it's little or no overhead and is 'working
> code'. No and no.

indeed, agree.

> I know Liam had to do a _lot_ of work on maple tree to make things work
> there, for instance.

yes, I also encountered an issue involving maple tree on nommu (with
some crash of UML), and initially it was not really sure what was
going on.  It was not an issue of maple-tree itself but the usage of
it was not correct.

> And the recent VMA flags changes have had to be heavily updated to account
> for nommu.
> 
> And the list goes on. New features have to touch it all the time to avoid
> build failures even, and etc. etc.
> 
> It's a really absurd situation to be honest and the RoI isn't there at all.
> 
> There's a reason I keep going on about this :)

I still understand your pains.

> >
> > Since I wish to use nommu.c in future with the latest kernel, I'd like
> > to contribute it for, let's say, refactoring the nommu component which
> > mm subsystem currently has.
> >
> > but for the moment, I wish to start with introducing test cases from
> > very basic checks (which is in the [6/6] patch of this series).
> > Without such a base, we may not have any chances to improve this nasty
> > situation of nommu component in mm subsystem.
> >
> > # this motivation also applies to LTP (linux test project) which
> >   currently doesn't support running tests on nommu platforms (I've
> >   already started).
> >
> > And also as I mentioned before, ideally the code should be maintained
> > by people who use it.  And if I claimed that I used/use/will use
> > nommu.c, I wish to maintain this, or at least wish to help to decrease
> > the overhead of maintainers.  This series is a very fist step toward
> > this.
> >
> > I hope it clarifies a bit for your concerns,
> 
> Thanks, and I appreciate that you're actually doing work here, but I'm not
> sure a single person suffices for this, as well intentioned as you are.

I agree.

I wish that having public test cases would motivate other people to
fix/improve/extend code (because his/her patch has less regressions),
to make this initial attempt useful for broader audience.

So initially this is just a one-man contribution, and I also think
it's not sufficient, but I'm always motivated (and assumed) that an
initial contribution could open the doors to the any other people.

> And as reviewed, these changes seem to be adding _more_ maintainership
> overhead rather than less, I fear.

for this /dev/zero patch in a current shape, I agree.

for other fixes to the shrink/split flaws, I will try to improve it to
let less overhead to maintain (by addressing your comments).

> I believe nommu is pretty broken across many domains (it's fun to set
> claude on it for instance).

ah, I also have thought about that.

> And we've already spoken about broken things that have sat around for
> a long time.
> 
> The way it's implemented now is just horrendous in any case, if we were
> forced to keep it in the upstream kernel then the correct solution would be
> something that somehow 'emulates' an mmu system.
> 
> But I'm not sure that's even workable, and likely implies heavy
> maintainership headaches.

Indeed, an emulation of mmu would be one promising direction.
I would like to spend more time to compare other alternatives for this
goal (which might not be a trivial hack).

-- Hajime