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 X-Spam-Level: X-Spam-Status: No, score=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D025C4338F for ; Mon, 23 Aug 2021 15:22:45 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1C39F61284 for ; Mon, 23 Aug 2021 15:22:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1C39F61284 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Eb4Y8inariss9Af6ZLh7xRxxnQ8+r78unGM2829NVTA=; b=08fIRxYwuyC5QG g7vObvlEvTNmUmKENdTnyZXWc95oq/ljTc9lNIWfc0txfSQgNZjH+2ILxJ4gvCPiadP2NwHu72/KU x54eOYRv4bGnxjDgScLI0PuBL9zT3I8LnnVC5ASd4sFKWkOl20fYW7xthVDmpTYFnTBNCer2I9b3Y Bi/rBs+0HrGdhnJf4lqYmlWHHXYFAvUJ/cGhalosJbmDUBiYTY1Qx8G7Os62CT44gGuM3N1fgseTn glSxwjTe+YgZaQsmtT8DlIqjkGIeyZcTpUOj/nFy7h2QoYmhL2mcJKLtK6e7SAXcWoESWKoZ2Gay5 nC37HosCKHs/oa0nMkXw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIBkk-00HPmt-2E; Mon, 23 Aug 2021 15:20:46 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIBkW-00HPjW-Ae; Mon, 23 Aug 2021 15:20:33 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B9C6061406; Mon, 23 Aug 2021 15:20:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629732031; bh=qreQnG9EH+SLqs9cxYafKtRpnrXgjkJipzrUHxRm8AI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RGjW/286CluzlorhZhA12uBlEH3uhRoRK1S/j3K064/Shsa1wyggzEKZ+qBLhJnq4 gRNV2wTAu/HjHiWh2f8lDroX68ilJ+YROIaiewKam0s1N8A50OJJWefyUImpM5E2eF 23BcN2czeN9GNVN/lCJogN+4552M5+pHKvniKKEJEUx8otTEcVGWHyeI3OR3rj1qMi Hi+i0DsYD+9xTYJ7MrtjEFxhLsW1VCy64kf+eN2MBlr4L1PcNpyAXM2UcO+pR7vBQY FLye4cqCOX/Qx8AxadC/oQ1G2/s7ZAxLxG8DqtLBtsk0QFfiMvLtb9egfLJszfwr1w PQAw/Rb0cjfWQ== Date: Mon, 23 Aug 2021 18:20:20 +0300 From: Mike Rapoport To: Rob Herring Cc: Geert Uytterhoeven , Russell King , Nicolas Pitre , Ard Biesheuvel , Linus Walleij , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , Nick Kossifidis , Paul Walmsley , Palmer Dabbelt , Albert Ou , Frank Rowand , Dave Young , Baoquan He , Vivek Goyal , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , "open list:BROADCOM NVRAM DRIVER" , linux-riscv , kexec@lists.infradead.org, Linux-Renesas , Linux Kernel Mailing List Subject: Re: [PATCH v5 1/9] MIPS: Avoid future duplicate elf core header reservation Message-ID: References: <92b6718f5618d5469f67b48fbea189cca0c12f4b.1628670468.git.geert+renesas@glider.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210823_082032_450412_038A4F29 X-CRM114-Status: GOOD ( 35.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 23, 2021 at 09:44:55AM -0500, Rob Herring wrote: > On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport wrote: > > > > On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote: > > > Hi Mike, > > > > > > On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport wrote: > > > > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote: > > > > > Prepare for early_init_fdt_scan_reserved_mem() reserving the memory > > > > > occupied by an elf core header described in the device tree. > > > > > As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before > > > > > mips_reserve_vmcore(), the latter needs to check if the memory has > > > > > already been reserved before. > > > > > > > > Doing memblock_reserve() for the same region is usually fine, did you > > > > encounter any issues without this patch? > > > > > > Does it also work if the same region is part of an earlier larger > > > reservation? I am no memblock expert, so I don't know. > > > I didn't run into any issues, as my MIPS platform is non-DT, but I > > > assume arch/arm64/mm/init.c:reserve_elfcorehdr() had the check for > > > a reason. > > > > The memory will be reserved regardless of the earlier reservation, the > > issue may appear when the reservations are made for different purpose. E.g. > > if there was crash kernel allocation before the reservation of elfcorehdr. > > > > The check in such case will prevent the second reservation, but, at least > > in arch/arm64/mm/init.c:reserve_elfcorehdr() it does not seem to prevent > > different users of the overlapping regions to step on each others toes. > > If the kernel has been passed in overlapping regions, is there > anything you can do other than hope to get a message out? Nothing really. I've been thinking about adding flags to memblock.reserved to at least distinguish firmware regions from the kernel allocations, but I never got to that. > > Moreover, arm64::reserve_elfcorehdr() seems buggy to me, because of there > > is only a partial overlap of the elfcorehdr with the previous reservation, > > the non-overlapping part of elfcorehdr won't get reserved at all. > > What do you suggest as the arm64 version is not the common version? I'm not really familiar with crash dump internals, so I don't know if resetting elfcorehdr_addr to ELFCORE_ADDR_ERR is a good idea. I think at least arm64::reserve_elfcorehdr() should reserve the entire elfcorehdr area regardless of the overlap. Otherwise it might get overwritten by a random memblock_alloc(). > Rob -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel