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

[Lorenzo Stoakes <ljs@kernel.org>]

+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