[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