Message ID | 20240920023317.f20c9ecbb2a2f4bf382d831c@linux-foundation.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] MM updates for 6.12-rc1 | expand |
The pull request you sent on Fri, 20 Sep 2024 02:33:17 -0700:
> https://lkml.kernel.org/r/20240906111900.5fcf345e@canb.auug.org.au include/linux/lsm_hooks.h
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/617a814f14b8914271f7a70366d72c6196d17663
Thank you!
Hi Andrew, On Fri, Sep 20, 2024 at 11:34 AM Andrew Morton <akpm@linux-foundation.org> wrote: > Linus, please merge this cycle's batch of MM updates, thanks. > > Conflicts which I'm seeing, along with their linux-next resolutions are > as follows: [...] > kernel/resource.c, vs ea72ce5da228 ("x86/kaslr: Expose and use the end > of the physical memory address space"): > https://lkml.kernel.org/r/20240909100043.60668995@canb.auug.org.au [...] > A build fix for m68k is needed, vs ea72ce5da228 ("x86/kaslr: Expose and > use the end of the physical memory address space"). See > https://lkml.kernel.org/r/87ttenvw0i.fsf@yhuang6-desk2.ccr.corp.intel.com Which is not sufficient, as kisskb reports for m68k: kernel/resource.c: In function ‘gfr_start’: ./include/linux/minmax.h:93:30: error: conversion from ‘long long unsigned int’ to ‘resource_size_t’ {aka ‘unsigned int’} changes value from ‘18446744073709551615’ to ‘4294967295’ [-Werror=overflow] Due to #define PHYSMEM_END (-1ULL) not being correct on 32-bit without LPAE. Presumably this should just take into account the actual size of phys_addr_t. My head is too hazy after Vienna to send a patch now ;-) I bisected this to 99185c10d5d9214d ("resource, kunit: add test case for region_intersects()"), but apparently the offending definition was modified later in commits ea72ce5da22806d5 ("x86/kaslr: Expose and use the end of the physical memory address space") and 617a814f14b89142 ("Merge tag 'mm-stable-2024-09-20-02-31' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm"). > The following changes since commit 431c1646e1f86b949fa3685efc50b660a364c2b6: [...] > "resource: Fix region_intersects() vs add_memory_driver_managed()" from > Huang Ying. Fix a bug in region_intersects() for systems with CXL memory. Gr{oetje,eeting}s, Geert
On Sun, 22 Sept 2024 at 02:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > kernel/resource.c: In function ‘gfr_start’: > ./include/linux/minmax.h:93:30: error: conversion from ‘long long > unsigned int’ to ‘resource_size_t’ {aka ‘unsigned int’} changes value > from ‘18446744073709551615’ to ‘4294967295’ [-Werror=overflow] > > Due to > > #define PHYSMEM_END (-1ULL) > > not being correct on 32-bit without LPAE. Hmm. Can you check if making it be #define PHYSMEM_END ((phys_addr_t)-1) fixes things for you? That said, it would probably be even better if we got rid of these games entirely, and m68k just defined MAX_PHYSMEM_BITS instead. Maybe as a config option, since I assume it's going to be either 24 or 32 depending on CPU (or are there other choices? I used to know the old m68k, but...) Linus
Hi Linus, On Sun, Sep 22, 2024 at 6:35 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sun, 22 Sept 2024 at 02:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > kernel/resource.c: In function ‘gfr_start’: > > ./include/linux/minmax.h:93:30: error: conversion from ‘long long > > unsigned int’ to ‘resource_size_t’ {aka ‘unsigned int’} changes value > > from ‘18446744073709551615’ to ‘4294967295’ [-Werror=overflow] > > > > Due to > > > > #define PHYSMEM_END (-1ULL) > > > > not being correct on 32-bit without LPAE. > > Hmm. Can you check if making it be > > #define PHYSMEM_END ((phys_addr_t)-1) > > fixes things for you? That fixes the warning/error, as expected. > That said, it would probably be even better if we got rid of these > games entirely, and m68k just defined MAX_PHYSMEM_BITS instead. Maybe > as a config option, since I assume it's going to be either 24 or 32 > depending on CPU (or are there other choices? I used to know the old > m68k, but...) Indeed, on 68000 and 68008 it could be 24 resp. 20 ;-) But all systems with a MMU (and even MC68328 without MMU) do support a 32-bit external address space, so 32 seems fine. BTW, other 32-bit architectures are suffering from the same issue (kisskb shows mips, xtensa, parisc, powerpc failures). 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; Gr{oetje,eeting}s, Geert
On Mon, 23 Sept 2024 at 01:09, Geert Uytterhoeven <geert@linux-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