From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E9B2C35274 for ; Thu, 21 Dec 2023 14:56:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 896A76B0081; Thu, 21 Dec 2023 09:56:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 843D36B0082; Thu, 21 Dec 2023 09:56:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70CF06B0083; Thu, 21 Dec 2023 09:56:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5E54E6B0081 for ; Thu, 21 Dec 2023 09:56:10 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2BBF61C1741 for ; Thu, 21 Dec 2023 14:56:10 +0000 (UTC) X-FDA: 81591125700.20.5452A7D Received: from elvis.franken.de (elvis.franken.de [193.175.24.41]) by imf16.hostedemail.com (Postfix) with ESMTP id 45C68180022 for ; Thu, 21 Dec 2023 14:56:07 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf16.hostedemail.com: domain of tsbogend@alpha.franken.de designates 193.175.24.41 as permitted sender) smtp.mailfrom=tsbogend@alpha.franken.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703170567; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UW0hIacWwRClFrr/8DcW2x4bNn0lL9O1wZbhzx3d2L8=; b=OKpExle6ZKpeXt8/R2r1Ei5IatJ2ut9MJSnSiYGBN0iYJaBiWaXYzthQam/ztowUyD0kbL SAlwZFRqR7FYwrQlaed6xV3eFhRQ7mwl9KgHWpLgHpScAAjPNEwSvd+QDfsCDrp3uFu51Y Mcq6bK3lA3rVzmrnaXR1JPvfigU8i88= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf16.hostedemail.com: domain of tsbogend@alpha.franken.de designates 193.175.24.41 as permitted sender) smtp.mailfrom=tsbogend@alpha.franken.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703170567; a=rsa-sha256; cv=none; b=Y0U5/1+lVwEXUQzT1t0U+NLoJ4u+J2nMlZuqYViODgsyjksTumNpMnw/dTTvyAzivyehvr hnAYqyiIgGtXDB8iuGCqp7Levb+LbPqYUNAfppKFP2bJdXglccQ8oVH1u3C2SiNvGXpvYA u1zpmYEhXZIDjDFPuQvJ24GlWn928X0= Received: from uucp by elvis.franken.de with local-rmail (Exim 3.36 #1) id 1rGKSq-0002PT-00; Thu, 21 Dec 2023 15:55:56 +0100 Received: by alpha.franken.de (Postfix, from userid 1000) id F34F9C028A; Thu, 21 Dec 2023 15:38:01 +0100 (CET) Date: Thu, 21 Dec 2023 15:38:01 +0100 From: Thomas Bogendoerfer To: Serge Semin Cc: Jiaxun Yang , Andrew Morton , Alexey Malahov , Arnd Bergmann , Aleksandar Rikalo , Aleksandar Rikalo , Dragan Mladjenovic , Christophe Leroy , Baoquan He , Chao-ying Fu , Yinglu Yang , Tiezhu Yang , Mike Rapoport , Matthew Wilcox , Marc Zyngier , linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/6] MIPS: mm: Fix some memory-related issues Message-ID: References: <20231202111430.18059-1-fancer.lancer@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 45C68180022 X-Stat-Signature: fz7c4urhi6hipoz6etapo6p3xbtkwcn8 X-HE-Tag: 1703170567-387103 X-HE-Meta: U2FsdGVkX1/YbcN5iFBL3LHou+xqoLIKiybTSjI0X8eMa4a6veZTccvyBQNxbO5BoGgya7tWQgM/vhgigrv6mhC4HxWeeGqHB4TWfGVyF5QIIElPFdYG9nh8Es21J3eUImzT++MhMqlFlohzt4Yca1nVQaaYPA8EYx1c052Tkc1rvwZ+PbR9sHrXQxCSKBOs/7RmmlvM/b7lkmokYhqbZ1anqR5N+Q63M8no5NqN/YzqGzLWIM/ZY7DWbYbCFsEl0FPsGRWVPB2lZDCBz/NofBIkVamKHulQOy/n/iJ0ZYt3Hqo3/Pd9bKcPLESbJvS65ZuTJCkJbLjJ/lg1DQauep5tGhcEEtppN6d9s5vh8ChxR51nehWBu/tf1FyBEutTTur+5Klz6G0NsBlz0D7S753rmA6RjS6D98xzBIVuN8tRt3IeFtUT8Op6ig8Ls7lmS2Jlngq6odgjN3cYbc7C3iz83t4mp9jqZhWGOXTpNUNa8sQPVceE/+wLjmbjgkn3zLRPwvufvisiyH9Gdbv9zTsb2vM7pWUN4jJ7To7QMjX7HFQt+nL8H6WiLyTVn0Xp9gFtmi98yDll1hJ3EJpjtHlhQhopEW14KINruh7nxaZjk97O8XRdlTqy1Mcj1AVjS4xRuJnhZf2LmjPfalVNbSWfVS1BO08ikw14BUQx2zSqJP2dW4PVS8YUtm7fAo2VoB7hqygDwfVjLsPsUAv8UFdqKYlkr2pwmH4Ov05/p5KSNnZMll4bVgyv4nrBGRTY1eujCPUGDzvVqojExStktrEdfepZmiAilPoHyvDsenKQeVo8OjDfWT9lVdZN5mu4FgNt/aBAfa7Y72AxEPZihxp/OvqOiUEiUy/aBzW4a57U8HxovcaeZ2erOlrEPI8q0IF3N2ybIM1fq33igQDYI7vUUNxp6rQPWnPaOqTrnWCMvNt6W10aMqaNS5tXSdb928dM3adUVNxNxSLdUU9 AqYTgvV7 aFyUMQsMPTt7NxbHF8vmDzb3m7I3oAmBvemwJ5lhCET9wIC1I686r4YOR2EqoPCWZzdp07UwOrD/xVkoK6Xj5ORBF9p9MZqKA4uQFTk63QloiX00q6Yq3lAdl+bXE9AnwajIVYGgKZeahvlNf3tiWNm2Trr9B3+hoUoA77QMSsAkf7gip9MFyQmSiPldMamFDLn7c2Gq7p/NhNQZGoZVHTt3MHEi3H7vzsKKc98laPtdPh74cPWHylTpU63wgVmMMN9iGV/rGnuFL1BYHUOmcrmv4LwAKNQNB0sWa5irzvzO0ZlFwtWldI5fbwFjsNAe5JK5VZnaQ4pgShJHTcffPGWVOLW5J+NzTIlYW13drvxx5p+64bfph0cjNu4cbTb+7+3IGyFGkin7WTT8WnRvyngHD9KPQeq38sTj5gDXe/7jf+zBzAgI/jeaXPCNwxkCBUvwOc1u7BigoX2hWV8KdtUd18GZcqqCQh7+BLKTvqI0J7AP3Wu9LHUKhOKXfzLR8p5EzdNsWrLVm/awW31ksG5Uo/b8amrZy4TSOkPADB1nfu0skmJ7pdvd5jw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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@gmail.com/ > 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 > Cc: Alexey Malahov > Cc: Arnd Bergmann > Cc: Aleksandar Rikalo > Cc: Aleksandar Rikalo > Cc: Dragan Mladjenovic > Cc: Christophe Leroy > Cc: Baoquan He > Cc: Chao-ying Fu > Cc: Yinglu Yang > Cc: Tiezhu Yang > Cc: Mike Rapoport > Cc: Matthew Wilcox (Oracle) > Cc: Marc Zyngier > Cc: linux-mips@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > > 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 ]