From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C155C239E6C for ; Wed, 25 Mar 2026 01:24:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774401865; cv=none; b=rDO+LlSeXJ1JNg28hliVbj8COWMLlZHvQQNuLHY4z3l6rqQccvPx5OKuTFDsWfwc3GCVzOu0FFHK+rPB988RJkhZwVYVlLBRuBUXaYCcllHIP37QJAw1iAjL7oKr5hsYCKDRiHR1v6HPyITOe/vTkvmTkem9/56v0fSoLbPmCWE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774401865; c=relaxed/simple; bh=HmYsbKwFs4P5opJoMQMaxNmUmh60o8lPuHPw/FnXv3k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ls3CIZocZO3ewS4xJ5/T188wkhu9JMayqq1ODtQ0wHTC6njVqu+v5+NRZf2/E+ipeks3W8lSR/+ktH2wNhHdLDCT74S5xyazf0Tg7GavlwZWq/6xHU0L4DcS/HDP8hOeCOuIwzw1CMTVGXoTElF7xd53pE/9XhJbxY7hIOltZOQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g5/PSVdV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g5/PSVdV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BD33C19424; Wed, 25 Mar 2026 01:24:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774401865; bh=HmYsbKwFs4P5opJoMQMaxNmUmh60o8lPuHPw/FnXv3k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g5/PSVdVo9XAywDdtLl+uLMNuZalgJhlZk9qbPWvpmrnQ0fxSIPK/jUiMm4jZ16M2 gQRW3NewP3ajzbI8wXcRzQXiisY4+A9S2QJnfwe4V/OphKcnLt1NLuBQAMI8soaZK5 aBpVVerB8tA7HXy+scQNFno3GWDF+JkIIYlaWFDOcfoI9yjS2cKosJ/+XBSeRreDkR 4CpO0APDkQfaf8ku9KvXYTqhtmJU9ozUJQ4EPAFtxE0kV5m8pGVOz0deG6OBe9CEHM PXyVFFA7ujEkA6+eVpRkjq/diAx3ppU/L6RzJZNPCpyF1mDXT+w+Ue7fjG9p6DwOco JTxtrT0Jik7UQ== From: SeongJae Park To: "Guilherme G. Piccoli" Cc: SeongJae Park , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net, Andrew Morton , Mike Rapoport , Steven Rostedt Subject: Re: [PATCH v4 2/2] mm/memblock: Add reserve_mem debugfs info Date: Tue, 24 Mar 2026 18:24:23 -0700 Message-ID: <20260325012423.85658-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260324012839.1991765-2-gpiccoli@igalia.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Mon, 23 Mar 2026 22:22:18 -0300 "Guilherme G. Piccoli" wrote: > When using the "reserve_mem" parameter, users aim at having an > area that (hopefully) persists across boots, so pstore infrastructure > (like ramoops module) can make use of that to save oops/ftrace logs, > for example. > > There is no easy way to determine if this kernel parameter is properly > set though; the kernel doesn't show information about this memory in > memblock debugfs, neither in /proc/iomem nor dmesg. This is a relevant > information for tools like kdumpst[0], to determine if it's reliable > to use the reserved area as ramoops persistent storage; checking only > /proc/cmdline is not sufficient as it doesn't tell if the reservation > effectively succeeded or not. > > Add here a new file under memblock debugfs showing properly set memory > reservations, with name and size as passed to "reserve_mem". Notice that > if no "reserve_mem=" is passed on command-line or if the reservation > attempts fail, the file is not created. > > [0] https://aur.archlinux.org/packages/kdumpst > > Cc: Andrew Morton > Cc: Mike Rapoport > Cc: Steven Rostedt > Cc: SeongJae Park > Signed-off-by: Guilherme G. Piccoli Reviewed-by: SeongJae Park Thanks, SJ [...]