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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 1F1E0C4167B for ; Wed, 6 Dec 2023 21:36:15 +0000 (UTC) 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=olixTCFKlr6VVwUGdS280SMoqzjR+Sd2LjJ9bxvmJ7g=; b=u81iuBK3HTpUr+ s9pBJgLS18w0P1kUhU3aIv2VhwUgU2bBURGYQkTtO8HMuqrmWX60+i0RkGxKc/evEgLnHxNm4ce9a wnjC/IvFQGnJmmFDW4N97wSFshEea8WvuGH4BAr/HG+h8a0zWOx0OPF2lVg/BrrA1/Wjl83bv/3s1 TdCyffYbUA8eHp08TV4hk9qCCBaSQpED2koKjJEKqtEqqbdUVZrz6qRkDw6SVAcVcc1Nae3nPKMCU 2TkJR4KJhF7SQs3DURRmi0CPCgUfxowuVn470QSRMy+TR6HAhcbcRev6LYPIbol/VpJDTvqaZzA6V JFoxl7KKPyDo1UEI6jlA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rAzYb-00BKle-1Y; Wed, 06 Dec 2023 21:35:49 +0000 Received: from mail-oa1-f42.google.com ([209.85.160.42]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rAzYY-00BKlD-2p for linux-arm-kernel@lists.infradead.org; Wed, 06 Dec 2023 21:35:48 +0000 Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-1f0f94943d9so168765fac.2 for ; Wed, 06 Dec 2023 13:35:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701898545; x=1702503345; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bUl/NKtFWY2Pbxm24jhjwpwyECFZQPzTNZTNK5JPvSo=; b=XKTotXo/jKvo5O0Y0QDVEEIN7YsH4OoZxP3FvWnrwD1Gjkcb9TGoNouLXqjS3+v24c x5KtphgmDlo7bzDrm2NUHhQTgCXWzY13i5JNh3yGTBw27fdteVqy0iz1GjpUo2VEU87w s+1A1Kmrq8M+gWvVrLdLMbk0ywn+4e+u0TXoC5CZ2RKtScGQjoNeLVlJwuGVdyBOV8R7 JzU7rlFTIYnBH4XuyNMoFqK54ljGkKo/IwgO4kf6+fPELbx54INuMV+eU0iF4ksHu8d/ wGrxvSy85/wCZ7moj5QSOfSYvINkE66YuPhnnM5eXDXsgWwbspKZWZQJ0/qlVwrog2Sk Jy6Q== X-Gm-Message-State: AOJu0YzmLmts+LV4OW4bPCe9jWo1PEb2SZ04p0JggUNmZT7FNwTeTDtA 7VF4HLZPqiswS1dpR8Sr1Q== X-Google-Smtp-Source: AGHT+IGHBQtY2ZCMQH40OjOJ13+Qp+jdVac/J+rmapcPibZzkALYHXrCY/oe6cfQHnvMLu7oUDa+xg== X-Received: by 2002:a05:6870:7e01:b0:1fb:75b:2baf with SMTP id wx1-20020a0568707e0100b001fb075b2bafmr1430168oab.107.1701898545570; Wed, 06 Dec 2023 13:35:45 -0800 (PST) Received: from herring.priv (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id x4-20020a05683000c400b006d8811cbc3csm116925oto.29.2023.12.06.13.35.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Dec 2023 13:35:45 -0800 (PST) Received: (nullmailer pid 3364587 invoked by uid 1000); Wed, 06 Dec 2023 21:35:43 -0000 Date: Wed, 6 Dec 2023 15:35:43 -0600 From: Rob Herring To: Oreoluwa Babatunde Cc: catalin.marinas@arm.com, will@kernel.org, frowand.list@gmail.com, dinguyen@kernel.org, chenhuacai@kernel.org, tsbogend@alpha.franken.de, jonas@southpole.se, stefan.kristiansson@saunalahti.fi, shorne@gmail.com, mpe@ellerman.id.au, ysato@users.sourceforge.jp, dalias@libc.org, glaubitz@physik.fu-berlin.de, richard@nod.at, anton.ivanov@cambridgegreys.com, johannes@sipsolutions.net, chris@zankel.net, jcmvbkbc@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, kernel@quicinc.com Subject: Re: [RFC PATCH v2 0/6] Dynamic allocation of reserved_mem array. Message-ID: <20231206213543.GB3345785-robh@kernel.org> References: <20231204185409.19615-1-quic_obabatun@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231206_133546_941249_F7DB50AE X-CRM114-Status: GOOD ( 33.26 ) 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, Dec 04, 2023 at 10:54:03AM -0800, Oreoluwa Babatunde wrote: > The reserved_mem array is used to store the data of the different > reserved memory regions specified in the DT of a device. > The array stores information such as the name, node, starting address, > and size of a reserved memory region. > > The array is currently statically allocated with a size of > MAX_RESERVED_REGIONS(64). This means that any system that specifies a > number of reserved memory regions greater than MAX_RESERVED_REGIONS(64) > will not have enough space to store the information for all the regions. > > Therefore, this series extends the use of a static array for > reserved_mem, and introduces a dynamically allocated array using > memblock_alloc() based on the number of reserved memory regions > specified in the DT. > > Memory gotten from memblock_alloc() is only writable after paging_init() > is called, but the reserved memory regions need to be reserved before > then so that the system does not create page table mappings for them. > > Reserved memory regions can be divided into 2 groups. > i) Statically-placed reserved memory regions > i.e. regions defined in the DT using the @reg property. > ii) Dynamically-placed reserved memory regions. > i.e. regions specified in the DT using the @alloc_ranges > and @size properties. > > It is possible to call memblock_reserve() and memblock_mark_nomap() on > the statically-placed reserved memory regions and not need to save them > to the array until after paging_init(), but this is not possible for the > dynamically-placed reserved memory because the starting address of these > regions need to be stored somewhere after they are allocated. > > Therefore, this series achieves the allocation and population of the > reserved_mem array in two steps: > > 1. Before paging_init() > Before paging_init() is called, iterate through the reserved_mem > nodes in the DT and do the following: > - Allocate memory for dynamically-placed reserved memory regions and > store their starting address in the static allocated reserved_mem > array. > - Call memblock_reserve() and memblock_mark_nomap() on all the > reserved memory regions as needed. > - Count the total number of reserved_mem nodes in the DT. > > 2. After paging_init() > After paging_init() is called: > - Allocate new memory for the reserved_mem array based on the number > of reserved memory nodes in the DT. > - Transfer all the information that was stored in the static array > into the new array. > - Store the rest of the reserved_mem regions in the new array. > i.e. the statically-placed regions. > > The static array is no longer needed after this point, but there is > currently no obvious way to free the memory. Therefore, the size of the > initial static array is now defined using a config option. A config option is not going to work here. > Because the array is used only before paging_init() to store the > dynamically-placed reserved memory regions, the required size can vary > from device to device. Therefore, scaling it can help get some memory > savings. > > A possible solution to freeing the memory for the static array will be > to mark it as __initdata. This will automatically free the memory once > the init process is done running. > The reason why this is not pursued in this series is because of > the possibility of a use-after-free. > If the dynamic allocation of the reserved_mem array fails, then future > accesses of the reserved_mem array will still be referencing the static > array. When the init process ends and the memory is freed up, any > further attempts to use the reserved_mem array will result in a > use-after-free. If memory allocation for the reserved_mem array fails so early in boot, you've got much bigger problems. Use __initdata, and just WARN if allocation fails and continue on (so hopefully the console is brought up and someone can see the WARN). Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel