[PATCH] tmpfs/ramfs: Let memfd_create() work on nommu

[PATCH] tmpfs/ramfs: Let memfd_create() work on nommu

[Daniel Palmer]

Currently trying to use memfd_create() on nommu returns
an error with errno set to EFBIG. The manpage memfd_create()
doesn't have EFBIG as a possible error value.

Doing some digging this is coming from 0 getting passed as
newsize to ramfs_nommu_expand_for_mapping() and that getting
into get_order() and there "The result is undefined if the size is 0".

Whatever comes out of get_order() is then used in the following
logic and that results in the EFBIG that causes the syscall
to fail and the errno in userspace.

If newsize is 0 there is nothing to do so just return.

Roughly tested on m68k nommu by creating a process, creating
an memfd, forking another process, mmap()ing the memfd in the
child, writing into the mapping, then mmap()ing in the parent
and checking that the right data is there.

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---

Really not sure if this is correct. It works for me but on
nommu a lot of things just work because there is no MMU to
shout about badness.

Maybe shashiko will say this is a dumb patch and explain
the proper fix. :)

Also I had almost no idea who to send this to from the output
of get_maintainer.pl.

 fs/ramfs/file-nommu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index 2f79bcb89d2e..fb471bf88ab7 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -69,6 +69,9 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
 	gfp_t gfp = mapping_gfp_mask(inode->i_mapping);
 
 	/* make various checks */
+	if (!newsize)
+		return 0;
+
 	order = get_order(newsize);
 	if (unlikely(order > MAX_PAGE_ORDER))
 		return -EFBIG;
-- 
2.53.0

Re: [PATCH] tmpfs/ramfs: Let memfd_create() work on nommu

[Lorenzo Stoakes]

+cc Liam

On Sat, May 23, 2026 at 10:04:45PM +0900, Daniel Palmer wrote:
> Currently trying to use memfd_create() on nommu returns
> an error with errno set to EFBIG. The manpage memfd_create()
> doesn't have EFBIG as a possible error value.
>
> Doing some digging this is coming from 0 getting passed as
> newsize to ramfs_nommu_expand_for_mapping() and that getting
> into get_order() and there "The result is undefined if the size is 0".
>
> Whatever comes out of get_order() is then used in the following
> logic and that results in the EFBIG that causes the syscall
> to fail and the errno in userspace.
>
> If newsize is 0 there is nothing to do so just return.
>
> Roughly tested on m68k nommu by creating a process, creating
> an memfd, forking another process, mmap()ing the memfd in the
> child, writing into the mapping, then mmap()ing in the parent
> and checking that the right data is there.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>

I don't really have the setup to check it, but I don't see a problem with
this so:

Acked-by: Lorenzo Stoakes <ljs@kernel.org>

> ---
>
> Really not sure if this is correct. It works for me but on
> nommu a lot of things just work because there is no MMU to
> shout about badness.

:)

>
> Maybe shashiko will say this is a dumb patch and explain
> the proper fix. :)

No see below I think this is correct.

>
> Also I had almost no idea who to send this to from the output
> of get_maintainer.pl.

Yeah this file doesn't really belong anywhere... the mm bits of nommu are
(ostensibly :P) maintained by me and Liam though.

>
>  fs/ramfs/file-nommu.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
> index 2f79bcb89d2e..fb471bf88ab7 100644
> --- a/fs/ramfs/file-nommu.c
> +++ b/fs/ramfs/file-nommu.c
> @@ -69,6 +69,9 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
>  	gfp_t gfp = mapping_gfp_mask(inode->i_mapping);
>
>  	/* make various checks */
> +	if (!newsize)
> +		return 0;
> +

Hmm yeah get_order() literally says the result is undefined if you input 0,
and it bizarrely returns BITS_PER_LONG - PAGE_SHIFT in that case.

So this isn't correctly handling 0 size at all.

Also in the case of a mmu, this function collapses to a stub that just
returns 0 and the rest of __shmem_file_setup() runs fine if size == 0.

So yeah this is probably right!

>  	order = get_order(newsize);
>  	if (unlikely(order > MAX_PAGE_ORDER))
>  		return -EFBIG;
> --
> 2.53.0
>
>
>

Cheers, Lorenzo

Re: [PATCH] tmpfs/ramfs: Let memfd_create() work on nommu

[Andrew Morton]

On Sat, 23 May 2026 22:04:45 +0900 Daniel Palmer <daniel@thingy.jp> wrote:

> Currently trying to use memfd_create() on nommu returns
> an error with errno set to EFBIG. The manpage memfd_create()
> doesn't have EFBIG as a possible error value.
> 
> Doing some digging this is coming from 0 getting passed as
> newsize to ramfs_nommu_expand_for_mapping() and that getting
> into get_order() and there "The result is undefined if the size is 0".
> 
> Whatever comes out of get_order() is then used in the following
> logic and that results in the EFBIG that causes the syscall
> to fail and the errno in userspace.
> 
> If newsize is 0 there is nothing to do so just return.
> 
> Roughly tested on m68k nommu by creating a process, creating
> an memfd, forking another process, mmap()ing the memfd in the
> child, writing into the mapping, then mmap()ing in the parent
> and checking that the right data is there.
> 

Old patch, older code.   Thanks.

> Really not sure if this is correct. It works for me but on
> nommu a lot of things just work because there is no MMU to
> shout about badness.
> 
> Maybe shashiko will say this is a dumb patch and explain
> the proper fix. :)

Sashiko had no complaints but it seems to have found some unrelated
bugs:

	https://sashiko.dev/#/patchset/20260523130445.1101818-1-daniel@thingy.jp

(tmpfs calls "ramfs_nommu" code.  Who knew?)

> Also I had almost no idea who to send this to from the output
> of get_maintainer.pl.

I suspect most would prefer it's someone else, but this is viro/brauner
stuff, if anyone)

> --- a/fs/ramfs/file-nommu.c
> +++ b/fs/ramfs/file-nommu.c
> @@ -69,6 +69,9 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
>  	gfp_t gfp = mapping_gfp_mask(inode->i_mapping);
>  
>  	/* make various checks */
> +	if (!newsize)
> +		return 0;
> +
>  	order = get_order(newsize);
>  	if (unlikely(order > MAX_PAGE_ORDER))
>  		return -EFBIG;

Oh well, thanks, I'll toss it onto the pile and see what happens.

Re: [PATCH] tmpfs/ramfs: Let memfd_create() work on nommu

[Daniel Palmer]

Hi Andrew,

On Tue, 30 Jun 2026 at 12:58, Andrew Morton <akpm@linux-foundation.org> wrote:
> Sashiko had no complaints but it seems to have found some unrelated
> bugs:
>
>         https://sashiko.dev/#/patchset/20260523130445.1101818-1-daniel@thingy.jp

I took a look at this, made my own fix, fed it to fable check/clean it
up and it seems to think after its fixes the sashiko reported issues
will be corrected.
I asked fable if it thought there was anything else major in the same
file and there are a few minor things but apparently the bugs sashiko
reported are the major issues.

Once I've tested it a bit more I'll send it.

Thanks,

Daniel