On Mon, 23 Sept 2024 at 01:09, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> BTW2, the following may not work with the default PHYSMEM_END due
> to integer overflow, on both 32-bit and 64-bit:
>
> mm/sparse.c: unsigned long max_sparsemem_pfn = (PHYSMEM_END + 1) >>
> PAGE_SHIFT;
Good point.
I've committed a truly disgusting hack, which makes the default
PHYSMEM_END in the absence of a MAX_PHYSMEM_BITS value be
(a) always a 64-bit type (ie unsigned long long)
(b) be the maximum value to fit in 'phys_addr_t'
(c) _but_ with the high bit always clear in 64 bits
so it's basically either 0xffff_ffff or 0x7fff_ffff_ffff_ffff.
The disgusting macro I came up for this for this is
# define PHYSMEM_END (((phys_addr_t)-1)&~(1ULL<<63))
and no, I'm not proud of it. This is all horrendous.
We need to fix it properly, with the proper fix probably being to
always have a valid value for MAX_PHYSMEM_BITS (and no, 64 is not a
valid value due to the overflow issue) but the quick hack hopefully
gets the build going.
Of course, I don't have the m68k cross-environment set up, thus the
"hopefully". Let's see if this works.
Linus
