lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHk-=wh1ZaVh2Tsc9tyXM7O1sL0eArxWHiqszZLj+MWe+f3Pwg@mail.gmail.com>
Date: Mon, 23 Sep 2024 09:13:44 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, 
	mm-commits@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Huang Ying <ying.huang@...el.com>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] MM updates for 6.12-rc1

On Mon, 23 Sept 2024 at 01:09, Geert Uytterhoeven <geert@...ux-m68k.org> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ