[RFC PATCH 03/13] um: nommu: memory handling

Hajime Tazaki thehajime at gmail.com
Sat Oct 26 00:24:51 PDT 2024


On Sat, 26 Oct 2024 00:15:06 +0900,
Johannes Berg wrote:
> 
> On Fri, 2024-10-25 at 21:55 +0900, Hajime Tazaki wrote:
> > > 
> > > Should that really do _nothing_? Perhaps it's not called at all in no-
> > > MMU, but then you don't need it, but otherwise it seems it should do
> > > something even if it's just panic()?
> > 
> > it is called also in !MMU.  I'll think to figure out how the function
> > is shared.
> 
> Feels like it should do something then? Why not print like before? If it
> happens in userspace we kill it, otherwise not sure what even happens...

the function report_enomem() is defined in tlb.c, used in several
places (trap.c, os-Linux/skas/process.c) but in !MMU the tlb.c
is filtered-out from compilation but uses trap.c so, it causes missing
symbols.

I can move the report_enomem() function to somewhere else, like mem.c,
but all the current usage of report_enomem() is MMU dependent
procedure so, I thought it is fine without doing anything.

> > > 	mmap64(....
> > > 	       MAP_SHARED | MAP_FIXED |
> > > 		IS_ENABLED(CONFIG_MMU) ? MAP_ANONYMOUS : 0,
> > > 	       ...);
> > 
> > since this is part under os-Linux and we cannot use kconfig.h (IIUC)
> > feature (e.g., IS_ENABLED). but I'll reformat it to simplify instead
> > of duplicating same lines.
> 
> Oh, missed that, sorry
> 
> still I guess putting
> 
> #ifndef CONFIG_MMU
> 	| MAP_ANONYMOUS
> #endif
> 
> might be nicer.

I thought the same thing.  Will fix it.

-- Hajime



More information about the linux-um mailing list