On Sat, Dec 02, 2023 at 02:14:17PM +0300, Serge Semin 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-4 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 and slab 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() 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 or just non-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.
>
> After that goes a patch which adds the slab availability check into the
> ioremap_prot() method. Indeed VM mapping performs the slab allocation in
> the framework of the get_vm_area() method. Thus any other than uncached
> IO-remappings must be proceeded only at the stages when slab is available.
> A similar fix was just recently added to the generic version of
> ioremap_prot() in the framework of commit a5f616483110 ("mm/ioremap: add
> slab availability checking in ioremap_prot").
>
> 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.
>
> Link: https://lore.kernel.org/linux-mips/20231122182419.30633-1-fancer.lancer@xxxxxxxxx/
> Changelog v2:
> - Drop the patches:
> [PATCH 5/7] mm/mm_init.c: Extend init unavailable range doc info
> [PATCH 6/7] mm/mm_init.c: Append '\n' to the unavailable ranges log-message
> since they have been picked up by Andrew. (@Andrew)
> - Replace ioremap_uc() with using ioremap() due to having the former one
> deprecated. (@Arnd)
> - Add a new patch:
> [PATCH v2 5/6] mips: mm: add slab availability checking in ioremap_prot
> picked up from the generic ioremap_prot() implementation.
> - Extend early DMI mem remapping patch log with a note regarding the unsynched
> caches concern. (@Jiaxun)
>
> Signed-off-by: Serge Semin <fancer.lancer@xxxxxxxxx>
> Cc: Alexey Malahov <Alexey.Malahov@xxxxxxxxxxxxxxxxxxxx>
> Cc: Arnd Bergmann <arnd@xxxxxxxx>
> Cc: Aleksandar Rikalo <aleksandar.rikalo@xxxxxxxxxx>
> Cc: Aleksandar Rikalo <arikalo@xxxxxxxxx>
> Cc: Dragan Mladjenovic <dragan.mladjenovic@xxxxxxxxxx>
> Cc: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
> Cc: Baoquan He <bhe@xxxxxxxxxx>
> Cc: Chao-ying Fu <cfu@xxxxxxxxxxxx>
> Cc: Yinglu Yang <yangyinglu@xxxxxxxxxxx>
> Cc: Tiezhu Yang <yangtiezhu@xxxxxxxxxxx>
> Cc: Mike Rapoport <rppt@xxxxxxxxxx>
> Cc: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
> Cc: Marc Zyngier <maz@xxxxxxxxxx>
> Cc: linux-mips@xxxxxxxxxxxxxxx
> Cc: linux-mm@xxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx
>
> Serge Semin (6):
> 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
> mips: mm: add slab availability checking in ioremap_prot
> 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 +++++++++-------
> arch/mips/mm/ioremap.c | 4 ++++
> 5 files changed, 18 insertions(+), 10 deletions(-)
series applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
