From patchwork Sat Dec 2 11:14:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476879 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aIb1a2xl" Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31D2C194; Sat, 2 Dec 2023 03:14:46 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2c9c18e7990so39412951fa.2; Sat, 02 Dec 2023 03:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515684; x=1702120484; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FkjKzmOgBIAZEWmOEC5zndYMsC69jtjEuyfNzanPv9Q=; b=aIb1a2xlanRmJRQvfu0w/i9I6vTTO1xFVMxukOV9B8j2sWy3du/kUImAQQOKk/qnKA ocq0vTx5jrjBQ13lhz801ZgLE0HBQuguhLymIi6R1BpgDXzEnJBTHSQfjuDort9xodWX R3NxSWc9oFmGLDTlFzh41u7JUWr5yDEAVQvNebbTgXTwq9hHiSpzo19ml860IHA3Jp9F 8k60/H6ljjWZ66hpZtUoIJGnKyomshXvILEC/mIriE8PlyknzC3P/0I5jKMdhnz4WASd wgV2wlQM3tXhfY5CMHiGW3Ujb3zoXjz9kbdIzoUXhsO7n6BZSRPgUrzjJ5GA1v2PsxPY tgfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515684; x=1702120484; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FkjKzmOgBIAZEWmOEC5zndYMsC69jtjEuyfNzanPv9Q=; b=HMwu9OiGAg9+qgXPjuAiovKbmMp//IgcvmJ6DcZfSDQ8gVYVtzaWIy22OvPJZMedTt cQwQCDYWaWyrJxg9zUOphmbfdRSrX4kE7RxKWiVdzyoRapmHSRUBaNt41B3I4fv72TpO SbFSRBL+DJKLLi5IqqWzlViO37cy6lTs3Yl2+B19lLqhqof2q8yOb9RjoAi8dAmsXCjZ 6DsOvcxiO3IUchh38zY7fiewQ2W3IRxjmCnXijsZattbodiwEF95kOOnFoKvd4jLtE+4 D8YJ3RW2nsfNH5pYsakx2yP48qXispwtljGmMn9w2w9Gd4OQYldV85cm5TGyR+ZjoXXY WCMQ== X-Gm-Message-State: AOJu0YzEc4dj2qUqfNWSFpf9LaATDK+zDUaKpkaG2iXlWjjvjV7+rhwq D8L1tekPSiZS13u393g6TxU= X-Google-Smtp-Source: AGHT+IHA6+EuRkpkyQ96D47YDeUbDMbpN9C7dhAq1xKmSnGXQA8pEXs0hCR4j4mKPT0f09fQoTKiOg== X-Received: by 2002:ac2:5a46:0:b0:50b:c4e3:b601 with SMTP id r6-20020ac25a46000000b0050bc4e3b601mr1409652lfn.66.1701515684172; Sat, 02 Dec 2023 03:14:44 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id o12-20020ac24e8c000000b0050bbf6b1f74sm690720lfr.232.2023.12.02.03.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:43 -0800 (PST) From: Serge Semin To: Thomas Bogendoerfer , Jiaxun Yang , Andrew Morton , Tiezhu Yang , Huacai Chen , Yinglu Yang Cc: Serge Semin , Alexey Malahov , Arnd Bergmann , Aleksandar Rikalo , Aleksandar Rikalo , Dragan Mladjenovic , Christophe Leroy , Baoquan He , Chao-ying Fu , Mike Rapoport , Matthew Wilcox , Marc Zyngier , linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/6] mips: dmi: Fix early remap on MIPS32 Date: Sat, 2 Dec 2023 14:14:18 +0300 Message-ID: <20231202111430.18059-2-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> References: <20231202111430.18059-1-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 dmi_early_remap() has been defined as ioremap_cache() which on MIPS32 gets to be converted to the VM-based mapping. DMI early remapping is performed at the setup_arch() stage with no VM available. So calling the dmi_early_remap() for MIPS32 causes the system to crash at the early boot time. Fix that by converting dmi_early_remap() to the uncached remapping which is always available on both 32 and 64-bits MIPS systems. Note this change shall not cause any regressions on the current DMI support implementation because on the early boot-up stage neither MIPS32 nor MIPS64 has the cacheable ioremapping support anyway. Fixes: be8fa1cb444c ("MIPS: Add support for Desktop Management Interface (DMI)") Signed-off-by: Serge Semin --- Note even though this patch is fully correct from the current ioremap()-based semantics point of view and shall fix the denoted problem, Jiaxun thinks that it's better to provide a different fix since dmi_early_remap() doesn't work correctly on even Loongson64 - the only currently DMI-equipped platform. In v1 discussion he promised to provide a better fix for the problem. Until then let's consider this patch as the only currently available solution. Changelog v2: - Replace ioremap_uc() with using ioremap() due to having the former one deprecated. (@Arnd) - Extend patch log with a note regarding the unsynched caches concern. (@Jiaxun) --- arch/mips/include/asm/dmi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/dmi.h b/arch/mips/include/asm/dmi.h index 27415a288adf..dc397f630c66 100644 --- a/arch/mips/include/asm/dmi.h +++ b/arch/mips/include/asm/dmi.h @@ -5,7 +5,7 @@ #include #include -#define dmi_early_remap(x, l) ioremap_cache(x, l) +#define dmi_early_remap(x, l) ioremap(x, l) #define dmi_early_unmap(x, l) iounmap(x) #define dmi_remap(x, l) ioremap_cache(x, l) #define dmi_unmap(x) iounmap(x) From patchwork Sat Dec 2 11:14:19 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476880 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ISJDB0Yi" Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96357181; Sat, 2 Dec 2023 03:14:47 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50bca79244fso4266237e87.3; Sat, 02 Dec 2023 03:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515686; x=1702120486; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zoxEo8hjT6ynXu2QIn5RXNLR4Bk19U6JI/QFXIIvaMA=; b=ISJDB0Yi3s46Hj/mjAwIHThxqr1SrXH0/ojUZwFUo0e1moJLtGRGyBXxX8VT33E5Ty 7IRPtxayv1BTFzwK2MikPg8mvmSk28AsmimR+37Svlqu3MkH9Px6KvcilfUGLClAJdmU YSMJfXjcEBFpMHBPHlz5jn6edJvgnHFZeclVbvzy8KgviIwulhmJ3WwG4B2BjVvVVNjt p0FAXplemjvruM3lt1Kfpsh/mll9GFlWoBBtxoQCYV4/+L1zc5RGs6k4oa5ktE7brW1b zgYMhBqNCKogdfqXQNc217Wyd4pnEg+KBR6MzZT8sY5fxM+UcXZR83XriC7x7B5FiTb6 o7lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515686; x=1702120486; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zoxEo8hjT6ynXu2QIn5RXNLR4Bk19U6JI/QFXIIvaMA=; b=HKcEgn1k39aL4iqOzfkC92ad78zW2E1O3y7U3SY7JHmJTbueeS+OXsDwX1rQa5jxR3 44mVIITkDWDXT6YT8cBA9EA/8zX5tguPD8WKQu2g+vDR2ryVDjg8EFPmsSiVrj2NHug+ FZiwlyHgRN5nANJzNOmhDbDzmqn7IdDhtls4jzQ/25d5lAtd597uzroL5eesKQWfMN61 L2imd3TgtNcSwZstBAuOdHOFUw5N8qv5rjiFNNxO17aAUC57+XLnkjCpRlNKRqSNMySX gOBsKB66Wsyllal1GeVIR3rSn8hW7DWjgBZmY6hNDpDoeIa5NiOzjwjT9JTzhm5d5ozv Nu2Q== X-Gm-Message-State: AOJu0YyDCANue1obym7oXyd4kzAIw/q91B0Aq4MLK9n/X60F5gyrmmIJ vUIGrBSY75QHRxLlYy4fxvI= X-Google-Smtp-Source: AGHT+IFkxeL1RwTUhTnJP1CUm9Cbq+eu0HhVMHbrUruBo9ZhC8OKhsQl8pDOslnE74g1kgJTDtHEmw== X-Received: by 2002:a05:6512:3113:b0:50b:e277:ef7 with SMTP id n19-20020a056512311300b0050be2770ef7mr528257lfb.139.1701515685791; Sat, 02 Dec 2023 03:14:45 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id o18-20020a05651205d200b0050aaa813895sm690382lfo.132.2023.12.02.03.14.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:45 -0800 (PST) From: Serge Semin To: Thomas Bogendoerfer , Jiaxun Yang , Andrew Morton , Paul Burton 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 2/6] mips: Fix incorrect max_low_pfn adjustment Date: Sat, 2 Dec 2023 14:14:19 +0300 Message-ID: <20231202111430.18059-3-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> References: <20231202111430.18059-1-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 max_low_pfn variable is incorrectly adjusted if the kernel is built with high memory support and the later is detected in a running system, so the memory which actually can be directly mapped is getting into the highmem zone. See the ZONE_NORMAL range on my MIPS32r5 system: > Zone ranges: > DMA [mem 0x0000000000000000-0x0000000000ffffff] > Normal [mem 0x0000000001000000-0x0000000007ffffff] > HighMem [mem 0x0000000008000000-0x000000020fffffff] while the zones are supposed to look as follows: > Zone ranges: > DMA [mem 0x0000000000000000-0x0000000000ffffff] > Normal [mem 0x0000000001000000-0x000000001fffffff] > HighMem [mem 0x0000000020000000-0x000000020fffffff] Even though the physical memory within the range [0x08000000;0x20000000] belongs to MMIO on our system, we don't really want it to be considered as high memory since on MIPS32 that range still can be directly mapped. Note there might be other problems caused by the max_low_pfn variable misconfiguration. For instance high_memory variable is initialize with virtual address corresponding to the max_low_pfn PFN, and by design it must define the upper bound on direct map memory, then end of the normal zone. That in its turn potentially may cause problems in accessing the memory by means of the /dev/mem and /dev/kmem devices. Let's fix the discovered misconfiguration then. It turns out the commit a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") didn't introduce the max_low_pfn adjustment quite correct. If the kernel is built with high memory support and the system is equipped with high memory, the max_low_pfn variable will need to be initialized with PFN of the most upper directly reachable memory address so the zone normal would be correctly setup. On MIPS that PFN corresponds to PFN_DOWN(HIGHMEM_START). If the system is built with no high memory support and one is detected in the running system, we'll just need to adjust the max_pfn variable to discard the found high memory from the system and leave the max_low_pfn as is, since the later will be less than PFN_DOWN(HIGHMEM_START) anyway by design of the for_each_memblock() loop performed a bit early in the bootmem_init() method. Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") Signed-off-by: Serge Semin --- arch/mips/kernel/setup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 2d2ca024bd47..0461ab49e8f1 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -321,11 +321,11 @@ static void __init bootmem_init(void) panic("Incorrect memory mapping !!!"); if (max_pfn > PFN_DOWN(HIGHMEM_START)) { + max_low_pfn = PFN_DOWN(HIGHMEM_START); #ifdef CONFIG_HIGHMEM - highstart_pfn = PFN_DOWN(HIGHMEM_START); + highstart_pfn = max_low_pfn; highend_pfn = max_pfn; #else - max_low_pfn = PFN_DOWN(HIGHMEM_START); max_pfn = max_low_pfn; #endif } From patchwork Sat Dec 2 11:14:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476881 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iYGsUZMO" Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D93918C; Sat, 2 Dec 2023 03:14:49 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-50be8ced3ddso322698e87.1; Sat, 02 Dec 2023 03:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515687; x=1702120487; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PuBq2+K/7D2dQZmzmoJVP8xhMAQEZQpTZUllDtcXKL0=; b=iYGsUZMOwNSi4kcBYQExtlBzOL7XefsKZ5eR2tw8hEQuPNy9PHBlrO3w1bTwrZOoFo JDOvO/QTiUgkfshqsOWlpbPvJtSicW5Ydydn4HR1Vm7kjW9qUye2iZGA3zBnAXftfC3t 5IGbtfrLLigaocsuNvSzG2jG+NyUjBkN5VV+7yfR+vC/EQ9HOrULvoAUnfEUj54/aPk0 a5PEAMVRHNh56knGg0gcspRzKUYeAleRgRaEfglxDl5p3piPTTahzB5/TKP7sEv2wxxz FbqcIo3usdS85p88gvgKP22SSmwFvPAApHNoSMifhdhvXI2Pv8kl5GzFifIV734WxLky Pbbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515687; x=1702120487; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PuBq2+K/7D2dQZmzmoJVP8xhMAQEZQpTZUllDtcXKL0=; b=Q6pKU/ufN1KhpM8TPmm8mROJMKhL9R3J14cutH9canbup+bl75RmEGWOdYS4AKx0p2 /m/6C+gfcOlPBip/WR1AYuq56qODYf3yaTeIIDwMIE/FF3o1/C7UCWY9kbfyYEW/gvMq GodE/D1S0EAc5AJEnWxhrIwWzw5f5xaM9GsFG1+5ZN+3zdH/rb2RzEjUDZ9Jiw6iLI9Y 1FjLprZZZkDtALZjoY5WskdHJWhWD9YdESoVTk7OFOZ+hGJ7I99fIHu5GS3vDJh9V8/L yJPCLz7Q1yYZqYl61D+wHDlr3YzZ5ELQ0DZ84JLcfjHjmK1PQq+EL8qWH3/J7GIVLku3 vTGA== X-Gm-Message-State: AOJu0YyPUrP580s/BX1IsSWQ/B8YT2QL6iMIiiZErf5ncUTWV1i8mI3B fZMLjo0Nm0xU5wZ/f8oWUdw= X-Google-Smtp-Source: AGHT+IG7kVjMeVBgDP3m5uSVWIH3RtNl20t5xeaTlMHlt3DR8NIK3nAoVqSfOvnQ8yp9IiRrmZ7zGQ== X-Received: by 2002:a05:6512:1593:b0:50b:d764:8811 with SMTP id bp19-20020a056512159300b0050bd7648811mr2125188lfb.93.1701515687394; Sat, 02 Dec 2023 03:14:47 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id o10-20020ac24e8a000000b00507a5f385f0sm693135lfr.266.2023.12.02.03.14.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:46 -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, stable@vger.kernel.org Subject: [PATCH v2 3/6] mips: Fix max_mapnr being uninitialized on early stages Date: Sat, 2 Dec 2023 14:14:20 +0300 Message-ID: <20231202111430.18059-4-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> References: <20231202111430.18059-1-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 max_mapnr variable is utilized in the pfn_valid() method in order to determine the upper PFN space boundary. Having it uninitialized effectively makes any PFN passed to that method invalid. That in its turn causes the kernel mm-subsystem occasion malfunctions even after the max_mapnr variable is actually properly updated. For instance, pfn_valid() is called in the init_unavailable_range() method in the framework of the calls-chain on MIPS: setup_arch() +-> paging_init() +-> free_area_init() +-> memmap_init() +-> memmap_init_zone_range() +-> init_unavailable_range() Since pfn_valid() always returns "false" value before max_mapnr is initialized in the mem_init() method, any flatmem page-holes will be left in the poisoned/uninitialized state including the IO-memory pages. Thus any further attempts to map/remap the IO-memory by using MMU may fail. In particular it happened in my case on attempt to map the SRAM region. The kernel bootup procedure just crashed on the unhandled unaligned access bug raised in the __update_cache() method: > Unhandled kernel unaligned access[#1]: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc1-XXX-dirty #2056 > ... > Call Trace: > [<8011ef9c>] __update_cache+0x88/0x1bc > [<80385944>] ioremap_page_range+0x110/0x2a4 > [<80126948>] ioremap_prot+0x17c/0x1f4 > [<80711b80>] __devm_ioremap+0x8c/0x120 > [<80711e0c>] __devm_ioremap_resource+0xf4/0x218 > [<808bf244>] sram_probe+0x4f4/0x930 > [<80889d20>] platform_probe+0x68/0xec > ... Let's fix the problem by initializing the max_mapnr variable as soon as the required data is available. In particular it can be done right in the paging_init() method before free_area_init() is called since all the PFN zone boundaries have already been calculated by that time. Cc: stable@vger.kernel.org Signed-off-by: Serge Semin --- Note I don't really know since what point that problem actually exists. Based on the commits log it might had been persistent even before the boot_mem_map allocator was dropped. On the other hand I hadn't seen it actually come out before moving my working tree from kernel 6.5-rc4 to 6.7-rc1. So after updating the kernel I got the unhandled unaligned access BUG() due to the access to compound head pointer the __update_cache() method (see the commit log). After enabling the DEBUG_VM config I managed to find out that the IO-memory pages were just left uninitialized and poisoned: > page:81367080 is uninitialized and poisoned (pfn 8192) > page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) > Kernel bug detected[#1]: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc1-00298-g88721b1a9ad5-dirty > $ 0 : 00000000 812d0000 00000034 dced7cdf > $ 4 : dced7cdf 00594000 10000000 ffff00fe > $ 8 : 8196bfe0 00000000 00000001 818458c0 > $12 : 00000000 00000000 00000000 00000216 > $16 : 00002800 81227b80 00000000 00000000 > $20 : 00000000 00000000 00000000 00000000 > $24 : 0000022b 818458c0 > $28 : 81968000 8196be68 00000000 803a0920 > Hi : 00000000 > Lo : 00000000 > epc : 8039d2a4 BUG+0x0/0x4 > ra : 803a0920 post_alloc_hook+0x0/0x128 > Status: 10000003 KERNEL EXL IE > Cause : 00800424 (ExcCode 09) > PrId : 0001a830 (MIPS P5600) > Modules linked in: > Process swapper/0 (pid: 1, threadinfo=81968000, task=819a0000, tls=00000000) > Stack : 00000000 8101ccb0 00000000 8196bd00 00000000 80359768 818a8300 00000001 > 81139088 8114438c 8042e4f8 81297a2c 81297a2c 81255e90 819a1b50 dced7cdf > 81297a2c 81297a2c 00000000 81227b80 00000000 81241168 811394b0 00000000 > 81140000 80e2cee0 00000000 00000000 00000000 00000000 00000000 819b0000 > 81140000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > ... > Call Trace: > [<8039d2a4>] BUG+0x0/0x4 > [<803a0920>] post_alloc_hook+0x0/0x128 > > Code: 01001025 03e00008 24020001 <000c000d> 2403003c 27bdffd0 afb2001c 3c12812f 8e4269e4 Which in its turn made me digging deeper into the way the MMIO-space pages are initialized. That's how I got into the pfn_valid() and init_unavailable_range() working improperly on my setup. Anyway none of the problems above I spotted on kernel 6.5-rc4. So what actually triggered having them finally popped up isn't that easy to be foundn seeing the involved code hasn't changed much. --- arch/mips/mm/init.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c index 5dcb525a8995..6e368a4658b5 100644 --- a/arch/mips/mm/init.c +++ b/arch/mips/mm/init.c @@ -422,7 +422,12 @@ void __init paging_init(void) (highend_pfn - max_low_pfn) << (PAGE_SHIFT - 10)); max_zone_pfns[ZONE_HIGHMEM] = max_low_pfn; } + + max_mapnr = highend_pfn ? highend_pfn : max_low_pfn; +#else + max_mapnr = max_low_pfn; #endif + high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT); free_area_init(max_zone_pfns); } @@ -458,13 +463,6 @@ void __init mem_init(void) */ BUILD_BUG_ON(IS_ENABLED(CONFIG_32BIT) && (PFN_PTE_SHIFT > PAGE_SHIFT)); -#ifdef CONFIG_HIGHMEM - max_mapnr = highend_pfn ? highend_pfn : max_low_pfn; -#else - max_mapnr = max_low_pfn; -#endif - high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT); - maar_init(); memblock_free_all(); setup_zero_pages(); /* Setup zeroed pages. */ From patchwork Sat Dec 2 11:14:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476882 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HfZFF7nN" Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 248A6197; Sat, 2 Dec 2023 03:14:51 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-50bd8efb765so2280969e87.1; Sat, 02 Dec 2023 03:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515689; x=1702120489; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=v4UHd4uT25TxSUzWPqsFRoZZNpRl4b4/7589i+JJ+rU=; b=HfZFF7nN/oDW4wix+atLctYMRShwcmwalhtabQ9cZATlVxB4WAgWsV9+TiFCSHbuFv ACUiiH5ol6NAIK8jI9ak/uBkf47n2TyfMrJIZMYI9E3K1kiQZ0Kk7XNkIDV+keeT2Rfn SWmztovrDAcAZ6gI6PqmxXchUplEyyzZMmrjeB2+kPLuym4iOHqTpmBBW8OexEHLiF46 ItDckB54zXmycUXLaj92EE1O8yDAergFxGFs8Cym17KNreMn+SO8YPNGRJNOTnMaWjOL FH+fEVdol9uxzx/4mG9mFuWlNi3FVaUQqNMThsJVFyWe6LmLU+v3lQNvPq8BTM1+bIrz ynyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515689; x=1702120489; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v4UHd4uT25TxSUzWPqsFRoZZNpRl4b4/7589i+JJ+rU=; b=nW6NltFONyARU5kc7AkU8yM7Ajykvm+STK4Q/VI2jpcgLyl6BMxB1Bj81umdrqoSUm FxEXzzOuPq+7WhGfBsnMCmCkGI8NRZ6murZZZQqvetGXHhph4nKtS03MMDJsdtsYL+Bd DbCCkXyQC+8nAxvaRDYNa5T2d5pEt+2wdI/ijhWkdg+KSGNjLHooBst1Y4dFFkBVY87H 4Uw3BBHPPZ00/EPveF1ZKM2gnNDT+4fRnEq/RsUb46641cNRAhXdzeYl62vY+iQ74pxF zTkXHVIHj+5x/kIpgWKcFrlzyvAyUnjwPae/vQLsO5d5uxQVfbeox5qH164BLgfH5g1U mt4w== X-Gm-Message-State: AOJu0Ywx4O3m++gIMOld3b9kqfHhTZP8yPcyHSB8rqK3GXHGgwe8oM/b aDnkTE5qAhAWhbgJkO09Frs= X-Google-Smtp-Source: AGHT+IFfdPNpiwefBvmuORgudPwNl6+kLbXV7fHeB560V9AMzknQFD1jotIAw/L6yW8iedkhemVsqg== X-Received: by 2002:a05:6512:110c:b0:50b:d764:969d with SMTP id l12-20020a056512110c00b0050bd764969dmr1786496lfg.129.1701515689264; Sat, 02 Dec 2023 03:14:49 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id c6-20020ac25f66000000b0050bed336e0csm66231lfc.162.2023.12.02.03.14.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:48 -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 4/6] mips: Optimize max_mapnr init procedure Date: Sat, 2 Dec 2023 14:14:21 +0300 Message-ID: <20231202111430.18059-5-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> References: <20231202111430.18059-1-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 max_mapnr defines the upper boundary of the pages space in the system. Currently in case if HIGHMEM is available it's calculated based on the upper high memory PFN limit value. Seeing there is a case when it isn't fully correct let's optimize out the max_mapnr variable initialization procedure to cover all the handled in the paging_init() method cases: 1. If CPU has DC-aliases, then high memory is unavailable so the PFNs upper boundary is determined by max_low_pfn. 2. Otherwise if high memory is available, use highend_pfn value representing the upper high memory PFNs limit. 3. Otherwise no high memory is available so set max_mapnr with the low-memory upper limit. Signed-off-by: Serge Semin --- Since I haven't seen any problem with the denoted misconfiguration on my setup, the patch isn't marked as fixes, but is supposed to be considered as an optimization. --- arch/mips/mm/init.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c index 6e368a4658b5..b2dce07116e8 100644 --- a/arch/mips/mm/init.c +++ b/arch/mips/mm/init.c @@ -421,9 +421,13 @@ void __init paging_init(void) " %ldk highmem ignored\n", (highend_pfn - max_low_pfn) << (PAGE_SHIFT - 10)); max_zone_pfns[ZONE_HIGHMEM] = max_low_pfn; - } - max_mapnr = highend_pfn ? highend_pfn : max_low_pfn; + max_mapnr = max_low_pfn; + } else if (highend_pfn) { + max_mapnr = highend_pfn; + } else { + max_mapnr = max_low_pfn; + } #else max_mapnr = max_low_pfn; #endif From patchwork Sat Dec 2 11:14:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476883 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZLWynJYZ" Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4184198; Sat, 2 Dec 2023 03:14:52 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-50be9e6427dso261994e87.1; Sat, 02 Dec 2023 03:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515691; x=1702120491; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1T4NHCKaEUJcD00hRH2cGzkJVzfRK4nR9CtS9DswDWw=; b=ZLWynJYZqs1lHeaNgkBKy4vWVZ0nmHjrnx/qKSxjxNzIdYwgwg/Xxz6lM/+WbrtVi2 OFnCFdmhD0bjMvM0WR8Rc2+Fl4/OlHz4Jcb3NCq0XEq41xU6/U0vDQIAqpSAJLlOKwyo p445N2Kv/3o8zgsLSBMtp1rt08G+fR56EBssOxmkjEieKKG2ESFkX1g2P3jaDwKl8fEj p3YZnw0jdlSET/DBPIwcQPkvmFTG0Jb0um45otdW2qP70I5hIG2lyCiaqiHMqHiFHLUx qJkKykUY+gzslby3cUyamaBYRixsq5DSJT23rh2W6LKBRA2VqRl7El6H5TwODuM7p4W/ HMNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515691; x=1702120491; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1T4NHCKaEUJcD00hRH2cGzkJVzfRK4nR9CtS9DswDWw=; b=CRxRjgZhO+qDHjKueDqgjcT7/dy9HS/DNz0clSwnllVCdSNHwYhlxC7dl4JjubvUcP gqn/aRHiCthu5IfgbMA5PqLENX3shSaEReMK6WqVYoSIvoP98td7A5hljDey5ovfGdDn 3L46RyJgiq/tcFqRVkFeIMG0aTTwZefhenDBJ2AaZyCvoC0WUbXtvdA9pjSWbi/to8vy aL0U7EotBwB8i4pUSJ46r/leDjTaAGD8A4QB8G71weZ1aTySYwq4yNqQf/Y5H3TxA5Ai D9IEIuCd8GpW7Bji7TyqOcZ3sYZUDZYNKT+h4IPswqy9uEFJWLHPBx9KtoLHdnrM3i+g rxRQ== X-Gm-Message-State: AOJu0YyNqEGM7IsVnMCK3X79HkNk8oN0UNwmmsHOrFKJYlWUVGhgX8r8 ntUZUIsE/l8LmJEVpGbwea0= X-Google-Smtp-Source: AGHT+IGCOXEU6dk6EGZWe/MP0XMGJO+yiD5xEQj5BjaTp5rOtf5nyoi67HG1zxO63b1IPn8ZI6EKlA== X-Received: by 2002:a05:6512:2316:b0:50b:d764:801d with SMTP id o22-20020a056512231600b0050bd764801dmr1888678lfu.80.1701515691032; Sat, 02 Dec 2023 03:14:51 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id b27-20020a0565120b9b00b0050aab07eb9fsm200142lfv.139.2023.12.02.03.14.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:50 -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 5/6] mips: mm: add slab availability checking in ioremap_prot Date: Sat, 2 Dec 2023 14:14:22 +0300 Message-ID: <20231202111430.18059-6-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> References: <20231202111430.18059-1-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Recent commit a5f616483110 ("mm/ioremap: add slab availability checking in ioremap_prot") added the slab availability check to the generic ioremap_prot() implementation. It is reasonable to be done for the MIPS32-specific method too since it also relies on the get_vm_area_caller() function (by means of get_vm_area()) which requires the slab allocator being up and running before being called. Signed-off-by: Serge Semin --- arch/mips/mm/ioremap.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/mips/mm/ioremap.c b/arch/mips/mm/ioremap.c index b6dad2fd5575..d8243d61ef32 100644 --- a/arch/mips/mm/ioremap.c +++ b/arch/mips/mm/ioremap.c @@ -72,6 +72,10 @@ void __iomem *ioremap_prot(phys_addr_t phys_addr, unsigned long size, flags == _CACHE_UNCACHED) return (void __iomem *) CKSEG1ADDR(phys_addr); + /* Early remaps should use the unmapped regions til' VM is available */ + if (WARN_ON_ONCE(!slab_is_available())) + return NULL; + /* * Don't allow anybody to remap RAM that may be allocated by the page * allocator, since that could lead to races & data clobbering. From patchwork Sat Dec 2 11:14:23 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 13476884 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H+V5pyiV" Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AECF1B3; Sat, 2 Dec 2023 03:14:54 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-50be9e6427dso262008e87.1; Sat, 02 Dec 2023 03:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701515693; x=1702120493; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ygdtXD6vQmhTkyIIFbEZLW4cEgmK3nTQybwd/aOy/dw=; b=H+V5pyiVslE0Vdy0IxLksla4ZkUfMHpLREjrSgY0+IoU7vWZInF6iAEa6hmnT4frdH 3i/HG4vhM5WiKTy8E2HWfCWEvc5v4ZiIIRkH/sZNN5c3v2QGXW5HQTZxLM+ac0xI08zd s9q0TyKqzM9mhh4Z6lVCaVnJnyYJV12VUOd/tDO6XQnl2rcPRjWXONC0Xt3Rw9eFXi6F vmKB11P3wvb53KJ5iFubeyCWl7CAz5pznJJ9ObMpPRQk14uaBlW3AV81OvZSKexfXNTv 95J0nX28HD6hjKc9z8rnPfgydHA4cH+oRgrQyOecW1Dc0cg9SbJmVCgA8BIuVNT0dhU7 p3pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701515693; x=1702120493; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ygdtXD6vQmhTkyIIFbEZLW4cEgmK3nTQybwd/aOy/dw=; b=xUMnzUFZkwBjZp1O9/o3/DDwuFWDvsxdu/d5nWtjqXJUF7yXl6Plv103syXL7LRTcR aBCp5LqoAAIk+Dxygn9tpUAUL3uCKQUHqyCDsGlbgLkYCFVG1fqTDaajEtrNkzLY/oIK QLVj9/K16CtM20bQMU46x9agPav3Rvp/wfYzWJ6+N/pseUYj6QkhLlDgTr+YN3VrvVaC KANvc4Lg5uHDxBGB1/RagUaylW9Wjfo8ifLaRbSyeaxvySAm3rk1IemHsdg/dZgbTBux O1f267VDXVYNz81WuMLnFmLAzqvJqz1OSJHbMKmIBlh9YtsfrGZJb2QMHKNtT0Rk/qKF g0dw== X-Gm-Message-State: AOJu0Yy/nVYkWIeGGOA0xxyDwIGBEISVFGwasQ9ycdsH+4lgQgevV1sJ IgzuMXD3XMnzovcM1hMOiIQ= X-Google-Smtp-Source: AGHT+IFScOFSCgDmnBrEbGs2UJA5K5JEy5fdtO2oKyTDCGHtKc+hpIQHzB67DbaHrlLa/RzVHh6mJA== X-Received: by 2002:ac2:44cf:0:b0:50b:df82:3137 with SMTP id d15-20020ac244cf000000b0050bdf823137mr805626lfm.43.1701515692770; Sat, 02 Dec 2023 03:14:52 -0800 (PST) Received: from localhost ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id o8-20020ac24bc8000000b0050bde3d7ed4sm309731lfq.147.2023.12.02.03.14.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:14:52 -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 6/6] mips: Set dump-stack arch description Date: Sat, 2 Dec 2023 14:14:23 +0300 Message-ID: <20231202111430.18059-7-fancer.lancer@gmail.com> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com> References: <20231202111430.18059-1-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In the framework of the MIPS architecture the mips_set_machine_name() method is defined to set the machine name. The name currently is only used in the /proc/cpuinfo file content generation. Let's have it utilized to mach-personalize the dump-stack data too in a way it's done on ARM, ARM64, RISC-V, etc. Signed-off-by: Serge Semin --- arch/mips/kernel/prom.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c index f88ce78e13e3..6062e6fa589a 100644 --- a/arch/mips/kernel/prom.c +++ b/arch/mips/kernel/prom.c @@ -28,6 +28,8 @@ __init void mips_set_machine_name(const char *name) strscpy(mips_machine_name, name, sizeof(mips_machine_name)); pr_info("MIPS: machine is %s\n", mips_get_machine_name()); + + dump_stack_set_arch_desc(name); } char *mips_get_machine_name(void)