From patchwork Sat Dec 2 11:14:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476885 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 5D42AC4167B for ; Sat, 2 Dec 2023 11:14:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DB256B04C9; Sat, 2 Dec 2023 06:14:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 88B4B6B04CB; Sat, 2 Dec 2023 06:14:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 752CA6B04CC; Sat, 2 Dec 2023 06:14:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 668246B04C9 for ; Sat, 2 Dec 2023 06:14:47 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2E0271A0169 for ; Sat, 2 Dec 2023 11:14:47 +0000 (UTC) X-FDA: 81521620614.17.D65A271 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf10.hostedemail.com (Postfix) with ESMTP id 68787C0007 for ; Sat, 2 Dec 2023 11:14:44 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fyhRcylM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701515684; a=rsa-sha256; cv=none; b=l3on4b/52iiHvzDRS/tciXIKnLgl9h6OIavHzomBzzroo5ut3Dt7wvXlH/VDA/brXamxkt DzsnBv/liuRLYzUR83vXN+mF+e+qxLHNK2fAAGnyG6Pc61M6LCR3fB5Xl3W9WpkiH358vJ 90qeJbAq2t6ue74e5D4sMHC6MLmBtAs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fyhRcylM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701515684; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=561K0BGyTpooesF2vZY7Mwtnl+lVJGMkg+53gB719DA=; b=KDc4v6T/nc/L1rB0Ri36ooyyw7gIFUNOiK2tnWqUIS5UDQDwIwIyt8uOtVyy3sreBwXNj5 fCJO7Nui4Vsor+NvEoqo+DiIbb9/PzJ3sxlL+4OkDeMAhHeBd2XQAJQHCDYYwH2xQ+PINJ /8KvBTxVNJf94lH7MWakh7okJcB4GwI= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2c9f62447c2so1268581fa.0 for ; Sat, 02 Dec 2023 03:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515682; x=1702120482; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=561K0BGyTpooesF2vZY7Mwtnl+lVJGMkg+53gB719DA=; b=fyhRcylMlFfSTroV5F4HCSd68zwkCeYp4+QeQxFqla3i2hS0MHmS4s0YegQ4huKInx Yaqaush+Rhmuu2qOhs4yep7zg5xY4PvACvbb5b9+sd+a3+fHojuH0hZq120vPZrc1N1y OCsOJDaAFkm2j4fQKws7nAQzUO9kAih9AA3fKWV79aBdz66vja1sPKPc1U7o7icV51BG psQG1a1Ns4IT4DeD/eXxrdOsvi0lo1muweoBl1GJJDLmAVmDGIzJ42hi1Lu4HGgQje/o NF3o8bXYOq/QrxS0HguS8jOMlncrdjmmqsSpfoZ0MWqQobWy/DttM5XT6O09fyR99+Lx WUQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515682; x=1702120482; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=561K0BGyTpooesF2vZY7Mwtnl+lVJGMkg+53gB719DA=; b=mfWfqydgns28ZsYsc0HehR0jP9GtmAxuKhcg6rGCRFAxkPiEGu/GMAJGw8b9PZVJ/9 CMdxpPK48rGJqpqLJ37s48kjzGktifZWxP0H26YKqCqZFjWqmEPqlUyXJF4kTuLDLkxH wfXvJKNF8L2SfRpcDnDLqHgh7GsJJnD/FMfcYxh0JhyU9Yf2oIbmAEiVm/qYW7oyMKRH n+IcawvIHgch6pLkg89Mj7Ey/Aay15qDpAz33aW8WIWbqqms6ssJgjczM31KdPuhRyzN CdP3Cd4VTG/4SdrOgM0cDgZVHK3wpqXBvxozofCtnTtF84K2qi0Gh6tuRqvaupJr1wbU dynw== X-Gm-Message-State: AOJu0YyfamUqoroua6DeIP0y9MnQYHuUg0NuO3m3gx/VFnay3XdctcNO 0/fYC1CNxA6YHa6PkUEHrTA= X-Google-Smtp-Source: AGHT+IFtuPcs03pVDSegSsFJqR+qgrSu6Yoe7feFmO2GJ9vLYffSE/RHhkzKJ7/saKHyb7BYEvMagA== X-Received: by 2002:a2e:2414:0:b0:2c9:f4af:fb9c with SMTP id k20-20020a2e2414000000b002c9f4affb9cmr238456ljk.22.1701515682230; Sat, 02 Dec 2023 03:14:42 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id i7-20020a2ea367000000b002c72bc28b3bsm700722ljn.52.2023.12.02.03.14.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:41 -0800 (PST) From: Serge Semin To: Thomas Bogendoerfer , Jiaxun Yang , Andrew Morton Cc: Serge Semin , 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: [PATCH v2 0/6] MIPS: mm: Fix some memory-related issues Date: Sat, 2 Dec 2023 14:14:17 +0300 Message-ID: <20231202111430.18059-1-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 68787C0007 X-Stat-Signature: syiwhz8ey78uh5keehnho3u674dua545 X-HE-Tag: 1701515684-972832 X-HE-Meta: U2FsdGVkX1+UEQPPLIPBeQJwuoE4BrRqsap2V4n3RirEY9uETOVMMiM27mLLGPaWUtYg9VYMsrPSsp/fWFGFStrI1saSuNfVzDglwdOnfjdDWXMSRGMbbchhrPSR95yP+fFhC9VZEo/M8BHDZgq4ALsNSp5TAWO7eY/RuCQJ+6lw+HHa4EBibAMWSn4Xafqpi7nrvbBtvYmzt8ndYvZnohZ62zUOMWgNegqNDE1kcua0AKltRD4y0aP5DpxOeTtJj7AlMD5Qy+3L6JMRK75cPlFx67DMJzwzT0fNf2ajeu777i2NjN97kjdipFZEmkCePQteksqqKbyiuq74hD8NPh5GbALCF6hOA6kGaHJ9ym0lbD3S78TiEw817nDGMQ2B04GEb68fA4rTDsqse0ZuKLwlxoW9NyRS0dN9qg0SFZDvm+QwJsvLHwsnanrdEjTKMsrL4KReOElof6lN0aG+fnsHpdCP7qRTYVzLkQhnAXmklJ4ufoaXTY7t4tPRDC4so3Mzmn0OU4tiBS0yHcL29lsdaEmxpo2mDQusYqt9wQs3aRi0lPuyBPpem8pZ5J7uUbc8me2tcesgSnDHxp/B+TmEYr9eDrxBJuMIf8U3NQZ5FsWaQoY3dMos6FE5WrmHpYK1RiUVBeYoUX4ZqLWuRmDUQzeVtai7p8tlDvNaiN9cJfepiB+RCBldnD6MgT0cHiQICWGmotqUyU9zxDbEhEIyk4LWA1H/GJIyfnr7px0rflCo8CMAccS4AA3/Hwzc4KQwGrrCsKdEhM0L638jSEALJQjzjLK+7TEOrkjlyVxxA2GiBgXpVTO2QdrWtiREiPCpzzS/pdvbG/Wr2Gpvrz0bf0ACDPitgB8k2AXutoVngYhAtPitYPzMhnXyYZDMEhq2C3yL0IgMHCvEwAvor4Kbaa/R89WL5GJgtgg3z3EaAp+c0uwkhQ/GJXpf18MCjnhh+Ls6tI6QaGv6liq yx2NWG73 4s4r3zl1eqbuMEPyH0BQ1x3lCEN+yCZxAS8/QWSVZo6MxP4swcSBy2DppueM8W+IpKcpj4Cixjja5Ji4nZhtOQWhxvLUSbJG5BkLoSEKLHq3g+a+dTZFnnouwdKSkZSQ1dgUMRqlTH7EOM/UpT7UCkhQX2i2YqsZaAzQoZqGVCm7Sbvop+/J0Vm38Ve8CtD2zXGmlP9kIfOtlDCXr6POlCEOFtaUn/DsnNhzyW7C1vj521T3mFUVmyqwx6HR7QqlK1fYC5mk3tzhizaDR5rXrPfAxqPUAGi/98iJfQphS2xdZ/x7K0zbRXVKknOwN5rKp/xFyvOQUUwdve7bTJipSuDPhli3Q5QPjvi+WVQcjPXVUeY6nKc109aMxVyFrkSiQARzABBzgjJ3HgDcfERqvPHZrpmb9kO5eH2+eiNgW/6wGWJDU/+VTZa2mqHOP16/8uJjNNf6uOjYIv4v/ymIs2weFH0RUEPf968i9YXTHsb/OqmqEnr7YTTGFabPxEk/HnI0BbaCz8orZu2nH5gA8hQl5ENUfGTywyzB+rNH9+ah+QYfGG6qoTgqxffHi17ryiH26MSO7P2QJMfIG+5dlVOZbIKdxkJZy+BoTn766fslm6IGzeoWm0IzZkAkMVRuk6TBTDbmSnPxYkv6s5RQ+7+xN6pYLwGYBkUl1bI33jTsXhRvuhDdHavMTlejIpNihcR9NufKGFOvK4XRX3G989okCHvI4p3qgKlA3sWt3pKUQJCGTuJchsXd93xlgG2XpgJriTk1/rwHWAh4KqY6H9TQULSFVIctvY6vJJklaM6hbCHDDABs+g7O3j2O94KRA5K6k8NaImQTBDBlZO13jz/JlZPi85Q/O0xC/oRtE+/dXASvogjQbk37EIVEPhrX6+5AZkSeVEyTS5zcm2J1VyXYj8n7uQ0A8junSpUuIBuGkmvd1VaiCMdFYXdvbXm/Z2QQxTuMQF/yxIqkIfSk7cfpOJ++c MvhRnBER WeZpT0hq/b9D9UixuB79QAJZRFTLQ9KMwMwIuMm6W8zWq7YVJLXLKimF438pGSPb 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: 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(-)