From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 EFA2B11CA9 for ; Fri, 10 Jul 2026 00:08:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783642099; cv=none; b=bNL5NjJ12PV+YvZENoAlX89+F+2S+hgmN1CKGRY9vv5Eyd4EZQgcEVz//IuGzcX718IR0tho3a7lDEiz5Pz4/H9061qxNrLHvb6JRKVX0KfuXccti8CM5QxBwbk+JJeQ3HTKZAbA8hszuTkXPMzhG33Y/asvu/j8IJCpUZ7CGqw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783642099; c=relaxed/simple; bh=QwEr91u2eJyIjLdPk7UDvFrCN3Mt1OUmrdewCsx9HEU=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=eMoxTSlAyCmtN0ntfx69DS99i81Dp/kQNI10lntVx5WshCJPou5kdBo0MyjU7yP/z/+Ell+ZL7Kjx/BoWysO/CXnmiptuXfI5LYtSvAKtY0dT0mIBaNFznuVrXsEUoNtaw8+Jv6eILG+bhpNpusr9PS+EmKnndC6rcOrtBav3d4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=2S2q+QsA; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="2S2q+QsA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CB971F000E9; Fri, 10 Jul 2026 00:08:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783642097; bh=o1KNst9m0viCssFZX760yV51UEXnWc+mJTMWEKbthB4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=2S2q+QsAZMz8+dQethGHyaKFC+9XY9MLQio0kwqC2KSN9Wq4tu95OilsmGvt4leva S9G32VV8l5HLhH9UPJB/g+uKkoTpVwbTYkiK8tmXi46R42gjMqn6xcVC+3hZvq0Qpy DrqnqIfLFJKVe738s0+ckfVVD5ZovjowCdvj7w9Q= Date: Thu, 9 Jul 2026 17:08:16 -0700 From: Andrew Morton To: Anshuman Khandual Cc: linux-mm@kvack.org, andriy.shevchenko@linux.intel.com, usama.arif@linux.dev, hughd@google.com, willy@infradead.org, ryan.roberts@arm.com, "David Hildenbrand (Arm)" , linux-kernel@vger.kernel.org Subject: Re: [PATCH V3] mm: Standardize printing for pgtable entries Message-Id: <20260709170816.4e876a16eef9a93f41bb1940@linux-foundation.org> In-Reply-To: <20260709044334.1741263-1-anshuman.khandual@arm.com> References: <20260709044334.1741263-1-anshuman.khandual@arm.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 9 Jul 2026 10:13:34 +0530 Anshuman Khandual wrote: > From: "David Hildenbrand (Arm)" > > Bad page map reporting currently stores page table entry values in an > unsigned long long and prints them with fixed 64-bit-oriented format > strings. This is inconsistent across call sites and does not work well for > architectures where page table entry values are not naturally represented > as 64-bit values, such as 32-bit or 128-bit entries. Well grumble. It's a lot of fuss for something which nobody is hurting from. Or are they? What's the actual utility here? > Introduce a common helper to convert raw page table entry values into a > fixed-width hexadecimal string based on the actual entry size. Use it for > bad page map reporting and for dumping the page table walk in > __print_bad_page_map_pgtable(). > > Pass page table entry values to the reporting path as raw bytes together > with their size, instead of forcing them through an unsigned long long. > It keeps the printed output consistent and avoids truncation or misleading > formatting for non-64-bit page table entries. > > --- a/mm/memory.c > +++ b/mm/memory.c > > ... > > +#if defined(__SIZEOF_INT128__) > +#define PTVAL_STR_MAX (32 + 1) /* Max 128-bit value in hex + NUL */ > +#else > +#define PTVAL_STR_MAX (16 + 1) /* Max 64-bit value in hex + NUL */ > +#endif > + > static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long addr) > { > - unsigned long long pgdv, p4dv, pudv, pmdv; > + char pgd_str[PTVAL_STR_MAX]; > + char p4d_str[PTVAL_STR_MAX]; > + char pud_str[PTVAL_STR_MAX]; > + char pmd_str[PTVAL_STR_MAX]; That's another 128b of stack, in a potentially deep code path. Hopefully gcc can reuse the same stack space for some of these but it's not been good at this in the past. > p4d_t p4d, *p4dp; > pud_t pud, *pudp; > pmd_t pmd, *pmdp; > @@ -532,34 +575,34 @@ static void __print_bad_page_map_pgtable(struct mm_struct *mm, unsigned long add > * see locking requirements for print_bad_page_map(). > */ > pgdp = pgd_offset(mm, addr); > - pgdv = pgd_val(*pgdp); > + ptval_to_str(pgd_str, pgd_val(*pgdp)); > > if (!pgd_present(*pgdp) || pgd_leaf(*pgdp)) { > - pr_alert("pgd:%08llx\n", pgdv); > + pr_alert("pgd:%s\n", pgd_str); can this do pr_alert("pgd:%s\n", ptval_to_str(pgd_str, pgd_val(*pgdp))); and eliminate a few locals?