From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7607925B098 for ; Mon, 15 Jun 2026 03:33:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781494438; cv=none; b=KUU1Zc05cvPAXA1HFb5l/mX/eaICxfsyiJyDzt0RhnxYUB9iWkZGeTwnXfJYnudL5izr5yEoXU8zbkcvMcMyfbWpB1UWkBnEin++OAuyPAOlAtTf4QaSQDFVHfNrLBvyPHDByeDkajTW+rAJcpWlczLlE9cjlD9I264MuohCWok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781494438; c=relaxed/simple; bh=7CYnTAuVR8rZg2/zzNHVJX1whHtFmlFtEUUksdZQ1Ds=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=H2RWGMXaKsi+cRlDS8o2M/vzQ/m8NS0HCY6Ltxau9t/uxVA8QdW0ltGXBdqUEd6kc5i2H4jqVjKz/Ogbn0R1QDZq4T/46dhDRtM05Fx93MrS/VUg+jTfIH/miHolrIMvykDbodeCNPUTOXqeKF4oPdHkx0bc3qyb7UzeV/fSawo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=O50y6H8J; arc=none smtp.client-ip=209.85.215.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O50y6H8J" Received: by mail-pg1-f194.google.com with SMTP id 41be03b00d2f7-c85a2c012e5so790655a12.1 for ; Sun, 14 Jun 2026 20:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781494437; x=1782099237; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4N4VN4U8dWKYBPdGLpmGB0dN8xMC6v/gON67oih3Zak=; b=O50y6H8J6c4qWl6eVw1XNtHsT9ahZ0OIDDwECLSdjSt/CU1FH7WR9IH9YkyYhHHM0q S/0W2JckPF9EROW8XBBpnsZzxQZ7Wevoe8Ot95rszy0pkCdA4PylTJ8EASTafppy4lSO 2ZwAmAgZsoGqk3HGdvEY8eJeTIlbrw7RH5vO7OR8FSUyrOUqMoRim0zgfLm6EWpeyfY+ p8QrKNU98vTvMmJtN+NLYYULd8fhymD7YGqnvbmZyouPdWBOZ98MSVcUTl0rAXVtwmMs kynPQRD/ZSaQphYp6pya83KEjhY3VAAIFz+QLA3CYg/nMLws30qKGcOkIw8sYznVLtgd j/1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781494437; x=1782099237; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4N4VN4U8dWKYBPdGLpmGB0dN8xMC6v/gON67oih3Zak=; b=icNGEAWryTLfKvBI7ZprIEtYJumZd0BHvsY0ZrrMNUMnMCZ9E7KBwMbR78lzeJjD0d Ghr//fNHIAqLhM8U0DUpEDAhNtBsviEgQ6SZUldcUyPN56A7ZbX2A5/e7k4eAWO772od F44lf2paqS8RfjaBMIZLZWxUBUUQIcf7JF1jaXma+YUWTJXJ1JOV/AqPhVfO92ghRZ/a szX9BU3rzFBsA1EG53THc5UPQxj9SHIdqomKFXLuj7YbHSr3cWXwcwFr5Y0b0b8v4B8y 4Yynpo9YH2yRu8GJIJV/NaN3zZCn5xLyOw1pFPfKLYuyTG0Nhp5DbsEQEKj9ejtKvkir yH3w== X-Forwarded-Encrypted: i=1; AFNElJ/sk0PMrtPe1mfLFapQgeG1EZTRvelsbHPdxfrEC6vQmxLdPyqMvJDdZk7z5pIJuPQFXTtsGyayUVn/5kc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywq+gcTvon/5ev7A9oRya8lsp270VnPxgnt4XOP1X8y1jF6ehtX Ypjzs/iX9ptJ7Y7N5BSEr6Lv/Ws2tbaNJDHb/0NrxoH3MU5hcHqPeulD X-Gm-Gg: Acq92OG4FVah3it2Zeb5phck8/c9+cD6U2HMv9d9tXEOu+cTP6Pz4/SupWRDAtLf46Y EigVdn+EWlYtTnZhksy50CbKvNWDrWzCHbNbVDBQaKW1YdiwWrm1S3A82LsN3gOYujF60Vd5aZ+ C7/jyLkVVA7SpDeaQik3tPWCvu65+A488U4zspupVpVZqK5NjFeRESQqmgBuQmnE1Y71k+EfDLn pmslr7Tl6lKIL/Q8ryL7ZJPb1Fk2uUIpyA0uOeLjGjJYSLhCF/SvpX6UAhlPstvc7Cipnex7T71 7Uo7TtN8U/GtMGHE/gmsx26A0mv37AjUkPb/xScui6cjHZsdR9hO1G5zifWvvEj8kbbX1YpneOz ui+C/stWssOrHSpT4y0a4QTjDO1r9qcY9ZBMYHRgbkai4hFK9RYVJDFB8xHjzoWzcU6Xx6273DF letPL7VN6d+pGgpgKAJZSi7zAdl/Tl386o0I/g1IkIDA== X-Received: by 2002:a05:6a21:6813:b0:3a2:d629:16a2 with SMTP id adf61e73a8af0-3b783b757e9mr14493609637.10.1781494436758; Sun, 14 Jun 2026 20:33:56 -0700 (PDT) Received: from [10.125.112.20] ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434b035ce6sm8650381b3a.49.2026.06.14.20.33.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jun 2026 20:33:56 -0700 (PDT) Message-ID: <894d7c33-8e14-4ba5-b774-14062ece39f2@gmail.com> Date: Mon, 15 Jun 2026 11:33:34 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 05/11] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late() To: Rob Herring Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, kexec@lists.infradead.org, iommu@lists.linux.dev, zhaomeijing@lixiang.com, catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org, kernel@xen0n.name, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, saravanak@kernel.org, akpm@linux-foundation.org, bhe@redhat.com, rppt@kernel.org, pasha.tatashin@soleen.com, pratyush@kernel.org, ruirui.yang@linux.dev, m.szyprowski@samsung.com, robin.murphy@arm.com, quic_obabatun@quicinc.com References: <20260527032917.3385849-1-chenwandun1@gmail.com> <20260527032917.3385849-6-chenwandun1@gmail.com> <20260612144122.GA974326-robh@kernel.org> Content-Language: en-US From: Wandun In-Reply-To: <20260612144122.GA974326-robh@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/12/26 22:41, Rob Herring wrote: > On Wed, May 27, 2026 at 11:29:11AM +0800, Wandun Chen wrote: >> From: Wandun Chen >> >> Prepare for storing /memreserve/ entries in the reserved_mem array. >> alloc_reserved_mem_array is skipped if the device tree lacks a >> /reserved-memory node, pointer 'reserved_mem' continues to reference >> the reserved_mem_array which lives in __initdata, storing >> /memreserve/ entries into reserved_mem_array would result in metadata >> loss, and an out-of-bounds memory access will occur if the device >> tree contains more than MAX_RESERVED_REGIONS /memreserve/ entries. >> >> So split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late(), >> and call alloc_reserved_mem_array() whether or not there is a >> /reserved-memory node. >> >> No functional change. >> The actual /memreserve/ population is added in a follow-up patch. >> >> Signed-off-by: Wandun Chen >> --- >> drivers/of/fdt.c | 7 +++++-- >> drivers/of/of_private.h | 1 + >> drivers/of/of_reserved_mem.c | 6 +----- >> 3 files changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c >> index 82f7327c59ea..83a2a474831e 100644 >> --- a/drivers/of/fdt.c >> +++ b/drivers/of/fdt.c >> @@ -1284,8 +1284,11 @@ void __init unflatten_device_tree(void) >> { >> void *fdt = initial_boot_params; >> >> - /* Save the statically-placed regions in the reserved_mem array */ >> - fdt_scan_reserved_mem_late(); >> + /* Attempt dynamic allocation of a new reserved_mem array */ >> + if (fdt && alloc_reserved_mem_array()) { >> + /* Save the statically-placed regions in the reserved_mem array */ >> + fdt_scan_reserved_mem_late(); > > Can we make this just: > > alloc_reserved_mem_array(); > fdt_scan_reserved_mem_late(); > > We already check !fdt in fdt_scan_reserved_mem_late(). Thanks for you review, Rob. The reason I kept the fdt check is that total_reserved_mem_cnt is wrong when fdt is NULL, early_init_fdt_scan_reserved_mem() returns early in that case, so fdt_scan_reserved_mem() never runs, and total_reserved_mem_cnt stays at MAX_RESERVED_REGIONS. Calling alloc_reserved_mem_array() unconditionally would allocate unnecessarily memory. A better fix might be to make total_reserved_mem_cnt always correct, add a !fdt check at the top of fdt_scan_reserved_mem() that sets total_reserved_mem_cnt to 0, and let early_init_fdt_scan_reserved_mem() call it even when initial_boot_params is NULL. Then alloc_reserved_mem_array() could naturally skip allcation when that count is 0, and we can drop the outer fdt guard. There is still separate UAF issue (fixed in patch3) if we don't check the return value of alloc_reserved_mem_array(). With the fdt_scan_reserved_mem() fix for total_reserved_mem_cnt, the call site in unflatten_device_tree() becomes: if (alloc_reserved_mem_array()) { fdt_scan_reserved_mem_late(); } How does that sound? Best regards, Wandun > > Rob