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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7800C433FE for ; Tue, 19 Oct 2021 11:37:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CBDA7610C7 for ; Tue, 19 Oct 2021 11:37:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235370AbhJSLj3 (ORCPT ); Tue, 19 Oct 2021 07:39:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:60036 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230097AbhJSLj2 (ORCPT ); Tue, 19 Oct 2021 07:39:28 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 25ED0610A1; Tue, 19 Oct 2021 11:37:13 +0000 (UTC) Date: Tue, 19 Oct 2021 12:37:10 +0100 From: Catalin Marinas To: Mike Rapoport Cc: Qian Cai , linux-mm@kvack.org, Andrew Morton , Mike Rapoport , Vladimir Zapolskiy , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH] memblock: exclude NOMAP regions from kmemleak Message-ID: References: <20211013054756.12177-1-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 19, 2021 at 08:45:49AM +0300, Mike Rapoport wrote: > On Mon, Oct 18, 2021 at 11:55:40PM -0400, Qian Cai wrote: > > On 10/13/2021 1:47 AM, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > Vladimir Zapolskiy reports: > > > > > > commit a7259df76702 ("memblock: make memblock_find_in_range method private") > > > invokes a kernel panic while running kmemleak on OF platforms with nomaped > > > regions: > > > > > > Unable to handle kernel paging request at virtual address fff000021e00000 > > > [...] > > > scan_block+0x64/0x170 > > > scan_gray_list+0xe8/0x17c > > > kmemleak_scan+0x270/0x514 > > > kmemleak_write+0x34c/0x4ac > > > > > > Indeed, NOMAP regions don't have linear map entries so an attempt to scan > > > these areas would fault. > > > > > > Prevent such faults by excluding NOMAP regions from kmemleak. > > > > > > Link: https://lore.kernel.org/all/8ade5174-b143-d621-8c8e-dc6a1898c6fb@linaro.org > > > Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private") > > > Signed-off-by: Mike Rapoport > > > Tested-by: Vladimir Zapolskiy > > > > Mike, reverting this commit on the top of today's linux-next fixed the early booting hang > > on an arm64 server with kmemleak. Even with "earlycon", it could only print out those > > lines. > > > > EFI stub: Booting Linux Kernel... > > EFI stub: EFI_RNG_PROTOCOL unavailable > > EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 128k boundary > > EFI stub: ERROR: FIRMWARE BUG: Image BSS overlaps adjacent EFI memory region > > EFI stub: Using DTB from configuration table > > EFI stub: Exiting boot services… > > > > I could help to confirm if it hangs right in the early boot somewhere if needed. > > The kernel config and a log of working kernel would help to start with. I don't think there's much in the log other than the EFI stub above. > > start_kernel() > > setup_arch() > > paging_init() > > map_mem() > > memblock_mark_nomap( Is this actual trace? It would be good to know where exactly it got stuck. > So we have kmemleak_free_part_phys() here. I wonder whether the memblock_mark_nomap() here is too early for kmemleak. We don't have the linear map created, though it shouldn't be an issue as the kernel sections are mapped. Also I think delete_object_part() in kmemleak.c would bail out early as there shouldn't be any prior memblock_alloc for this range. -- Catalin