Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 14 Apr 2024 03:15:55 +0100 | From | Al Viro <> | Subject | Re: riscv32 EXT4 splat, 6.8 regression? |
| |
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.
| ![\](/images/icornerr.gif) |