On Sat, 14 Dec 2024 05:01:58 +0900,
Eric W. Biederman wrote:
> >> Last time I looked the regular binfmt_elf works just fine
> >> without an mmu. I looked again and at a quick skim the
> >> regular elf loader still looks like it will work without
> >> an MMU.
> >
> > I'm wondering how you looked at it and how you see that it works
> > without MMU.
>
> I got as far as seeing that vm_mmap should work. As all of the
> bits for mmap to work, are present in both mmu and nommu.
hmm, at least MAP_FIXED doesn't work in current mm/nommu.c.
# also documented at Documentation/admin-guide/mm/nommu-mmap.rst.
> > I also wish to use the regular binfmt_elf, but it doesn't allow me to
> > compile with !CONFIG_MMU right now.
>
> Then I may simply be confused. Where does the compile fail?
> Is it somewhere in Kconfig?
>
> I could be completely confused. It has happened before.
If I applied to below in addition to my whole patchset,
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index 419ba0282806..b34d0578a22f 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -4,7 +4,6 @@ menu "Executable file formats"
config BINFMT_ELF
bool "Kernel support for ELF binaries"
- depends on MMU
select ELFCORE
default y
help
@@ -58,7 +57,7 @@ config ARCH_USE_GNU_PROPERTY
config BINFMT_ELF_FDPIC
bool "Kernel support for FDPIC ELF binaries"
default y if !BINFMT_ELF
- depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
+ depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
select ELFCORE
help
ELF FDPIC binaries are based on ELF, but allow the individual load
this is the output from `make ARCH=um`.
GEN Makefile
CALL ../scripts/checksyscalls.sh
CC fs/binfmt_elf.o
In file included from ./arch/x86/include/generated/asm/rwonce.h:1,
from ../include/linux/compiler.h:317,
from ../include/linux/build_bug.h:5,
from ../include/linux/container_of.h:5,
from ../include/linux/list.h:5,
from ../include/linux/module.h:12,
from ../fs/binfmt_elf.c:13:
../fs/binfmt_elf.c: In function ʽload_elf_binaryʼ:
../include/asm-generic/rwonce.h:44:71: error: lvalue required as unary ʽ&ʼ operand
44 | #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
| ^
../include/asm-generic/rwonce.h:50:9: note: in expansion of macro ʽ__READ_ONCEʼ
50 | __READ_ONCE(x); \
| ^~~~~~~~~~~
../fs/binfmt_elf.c:1006:49: note: in expansion of macro ʽREAD_ONCEʼ
1006 | const int snapshot_randomize_va_space = READ_ONCE(randomize_va_space);
|
I avoided this issue (with nasty MAP_FIXED workaround) but there seems
to be still a lot of things that I need to fix to work with nommu.
> I just react a little strongly to the assertion that elf_fdpic is
> the only path when I don't see why that should be.
>
> Especially for an architecture like user-mode-linux where I would expect
> it to run the existing binaries for a port.
I understand your concern, and will try to work on improving this
situation a bit.
Another naive question: are there any past attempts to do the similar
thing (binfmt_elf without MMU) ?
-- Hajime
