[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