| Message ID | 20231122182419.30633-1-fancer.lancer@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | MIPS: mm: Fix some memory-related issues | expand |
On Wed, 22 Nov 2023 21:23:58 +0300 Serge Semin <fancer.lancer@gmail.com> wrote: > Just recently I've rebased my MIPS32-related work from kernel 6.5-rc4 onto > the latest kernel 6.7-rc1 and immediately got into a bootup-time > mm-related bug (see patches 3-5 in this series). After fixing it I decided > it was time to submit for review the generic MIPS code fixes which I have > been collecting in my local repo for the last year. I was going to submit > them a bit later after I finished working on a patchset with my SoC > arch-specific changes, but since it was getting bigger and bigger, it > turned to be reasonable to spill out the generic part of series right away > especially seeing it might get to be useful in the most recent kernel. It would have been better to separate out the two tiny unrelated MM patches from this series. I'll steal them - if they later turn up via the MIPS tree then that's OK.
On Wed, Nov 22, 2023 at 10:29:00AM -0800, Andrew Morton wrote: > On Wed, 22 Nov 2023 21:23:58 +0300 Serge Semin <fancer.lancer@gmail.com> wrote: > > > Just recently I've rebased my MIPS32-related work from kernel 6.5-rc4 onto > > the latest kernel 6.7-rc1 and immediately got into a bootup-time > > mm-related bug (see patches 3-5 in this series). After fixing it I decided > > it was time to submit for review the generic MIPS code fixes which I have > > been collecting in my local repo for the last year. I was going to submit > > them a bit later after I finished working on a patchset with my SoC > > arch-specific changes, but since it was getting bigger and bigger, it > > turned to be reasonable to spill out the generic part of series right away > > especially seeing it might get to be useful in the most recent kernel. > > It would have been better to separate out the two tiny unrelated MM > patches from this series. One of them isn't completely unrelated to the series content. The biggest problem I fixed in the patch [PATCH 3/7] mips: Fix max_mapnr being uninitialized on early stages Link: https://lore.kernel.org/linux-mips/20231122182419.30633-4-fancer.lancer@gmail.com/ of this series. I was sure that it was a correct fix at least for having the pfn_valid() method working incorrectly, but I had doubts whether the memory mapped IO pages were supposed to be left uninitialized by the arch code relying on the init_unavailable_range() doing that especially seeing it was printing a warning about having unavailable ranges. If it turned out to be incorrect I would have needed to drop the patch [PATCH 5/7] mm/mm_init.c: Extend init unavailable range doc info Link: https://lore.kernel.org/linux-mips/20231122182419.30633-6-fancer.lancer@gmail.com/ and fix that problem too in the framework of the MIPS arch. My alternative assumption regarding that problem was that the arch-code should have used memblock_reserve() method for the IO ranges, so then the calls-chain: mem_init() +-> memblock_free_all() +-> free_low_memory_core_early() +-> memmap_init_reserved_pages() +-> memmap_init_reserved_pages(v) +-> for_each_reserved_mem_region(region) +-> reserve_bootmem_region(start, end, nid); would have properly initialized the IO-pages reserved earlier by means of the memblock_reserve() method. But it turned out that reserve_bootmem_region() was available only when CONFIG_DEFERRED_STRUCT_PAGE_INIT was enabled which didn't seem to be widespreadly utilized in the arch code. Not finding a better option I decided to stick to the solution relying on the init_unavailable_range() method doing the trick and just fix the method kdoc. Seeing you accepted the patch [PATCH 5/7] mm/mm_init.c: Extend init unavailable range doc info it was a correct decision. > I'll steal them - if they later turn up via > the MIPS tree then that's OK. Ok. Thanks for picking them up. I'll drop those two patches from the series on v2. -Serge(y)
Just recently I've rebased my MIPS32-related work from kernel 6.5-rc4 onto the latest kernel 6.7-rc1 and immediately got into a bootup-time mm-related bug (see patches 3-5 in this series). After fixing it I decided it was time to submit for review the generic MIPS code fixes which I have been collecting in my local repo for the last year. I was going to submit them a bit later after I finished working on a patchset with my SoC arch-specific changes, but since it was getting bigger and bigger, it turned to be reasonable to spill out the generic part of series right away especially seeing it might get to be useful in the most recent kernel. So this series starts with the MIPS-specific dmi_early_remap() implementation fix. It is utilized by the DMI driver in the framework of the dmi_setup() method, which is called at the very early boot stage - in setup_arch((). No VM available at that stage which is required for the ioremap_cache() to properly work. Thus it was a mistake to have the dmi_early_remap() macro-function defined as ioremap_cache(). It should have been ioremap_uc() in first place. After that goes a fix for the high-memory zone PFNs calculation procedure on MIPS. It turned out that after some not that recent commit the IO-memory PFNs got to the high-memory even though they were directly reachable, thus should have been left in the normal zone. Then a series of fixes for the recently discovered mm-bug is presented. Any attempt to re-map the IO-memory with the cached attribute caused the bootup procedure to crash with the "Unhandled kernel unaligned access" message. After some digging I found out that the problem was in the uninitialized IO-memory pages. Please see the patch "mips: Fix max_mapnr being uninitialized on early stages" description for the detailed explanation of the problem and suggested fix. Afterwards I submitted several cleanup patches for the MIPS/mm and generic mm code. The patchset is closed with a small improvement which sets the MIPS board/machine name to the dump-stack module in order to print arch-personalized oopses in the same way as it's done on ARM, ARM64, RISC-V, etc. That's it for today.) Thanks for review in advance. Any tests are very welcome. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com> Cc: Aleksandar Rikalo <arikalo@gmail.com> Cc: Dragan Mladjenovic <dragan.mladjenovic@syrmia.com> Cc: Chao-ying Fu <cfu@wavecomp.com> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Yinglu Yang <yangyinglu@loongson.cn>, Cc: Tiezhu Yang <yangtiezhu@loongson.cn> Cc: Marc Zyngier <maz@kernel.org> Cc: linux-mips@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Serge Semin (7): mips: dmi: Fix early remap on MIPS32 mips: Fix incorrect max_low_pfn adjustment mips: Fix max_mapnr being uninitialized on early stages mips: Optimize max_mapnr init procedure mm/mm_init.c: Extend init unavailable range doc info mm/mm_init.c: Append '\n' to the unavailable ranges log-message mips: Set dump-stack arch description arch/mips/include/asm/dmi.h | 2 +- arch/mips/kernel/prom.c | 2 ++ arch/mips/kernel/setup.c | 4 ++-- arch/mips/mm/init.c | 16 +++++++++------- mm/mm_init.c | 3 ++- 5 files changed, 16 insertions(+), 11 deletions(-)