yes, mmap is almost not called by in tree code directly, so it's fine to call memalign. so, it's simple to fix by option 1. If some bad effect happens, we can add an option later.
On Fri, Oct 9, 2026 at 11:35 PM <[email protected]> wrote: > Hello, > > as far as AVR - small 8 bit target - is concerned, it would IMO be > preferred to avoid calling memalign. I remember a recent change that > pulled mm_memalign into the build, consuming more than 1% of total > program memory. (The change was later tweaked so memalign was again not > called.) > > That said, if variant 1 only affects build when mmap is used, that's > probably OK - on device this small, there is not much use for mmap > anyway (at least as far as I can imagine.) > > On 2026-10-09 13:18, Marco C. wrote: > > Hello, > > > > mmap() with MAP_ANONYMOUS returns memory from the heap: > > fs/mmap/fs_anonmap.c allocates it with kumm_zalloc() (or > > fs_heap_zalloc()). The address therefore has the alignment of malloc(), > > not of a page. > > > > POSIX does not say in so many words that mmap() without MAP_FIXED > > returns a page-aligned address. But it says that "the system performs > > mapping operations over whole pages", munmap() and mprotect() act on > > the > > whole pages that contain the range, and both "may require that addr be > > a > > multiple of the page size" (EINVAL otherwise). So a portable program > > can > > only release or protect what mmap() returned if it is page-aligned, and > > with a heap address the pages it shares with other data cannot be > > unmapped or protected safely. Linux, the BSDs and macOS return > > page-aligned addresses, and programs (page allocators, garbage > > collectors) rely on it. For example: > > > > void *p = mmap(NULL, len, PROT_READ | PROT_WRITE, > > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > > long pg = sysconf(_SC_PAGESIZE); > > assert(((uintptr_t)p & (pg - 1)) == 0); /* fails on NuttX */ > > > > A comment in fs_anonmap.c already notes that a kernel build could use > > pgalloc() for this. > > > > Possible directions: > > > > 1. Small fix, all builds: allocate with kumm_memalign() at the page > > size > > and round the length up to a whole page. It costs up to one page of > > heap per mapping. > > 2. Kernel builds with CONFIG_ARCH_ADDRENV: map real pages into the > > address environment with pgalloc(), so that munmap() and mprotect() > > can work on parts of a mapping. This is more work. > > 3. Both: 1 now, 2 later for kernel builds. > > > > Is 1 acceptable as a bug fix without a Kconfig option, given the memory > > cost on small targets? Or should the alignment depend on an option? > > > > Thanks, > > Marco Casaroli >
