On Sat, Apr 13, 2024 at 07:46:03PM -0600, Andreas Dilger wrote: > As to whether the 0xfffff000 address itself is valid for riscv32 is > outside my realm, but given that RAM is cheap it doesn't seem unlikely > to have 4GB+ of RAM and want to use it all. The riscv32 might consider > reserving this page address from allocation to avoid similar issues in > other parts of the code, as is done with the NULL/0 page address. Not a chance. *Any* page mapped there is a serious bug on any 32bit box. Recall what ERR_PTR() is... On any architecture the virtual addresses in range (unsigned long)-512.. (unsigned long)-1 must never resolve to valid kernel objects. In other words, any kind of wraparound here is asking for an oops on attempts to access the elements of buffer - kernel dereference of (char *)0xfffff000 on a 32bit box is already a bug. It might be getting an invalid pointer, but arithmetical overflows are irrelevant.
