From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CB774385D8B for ; Tue, 7 Jul 2026 08:58:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783414739; cv=none; b=HC46gjuXO20BHMncCj0f0iA1N2fWqacz8qOVfGXPJn3xlhMCaE4afpN4HuJ6PyT0N2JdcKvVYo7yxPnzPTKmG26MpLRtcTOqffPwfs9ylrH06Z04saOcWx8+kFgvZ4ml1WydcTaDv5UmoLMa3xXalHn3nxlDrN2WX3AisNcNjnM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783414739; c=relaxed/simple; bh=vy65AfeKcM9JM0/EN7cdtimmzBIvOMxJ8F0u/aP5ezw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rVqbRdIfeBZ/1SjxzO/1pLFKGC6AfoO3+HeY8y1qPtYRKWH3A4DSnpKnDK5jqOLQMhz5CqMjmPPutzWNcxe6W0fXWcENGwwpC5gX47QAgLcF29QqXI4A4oC6qCriiVO9B/x3lof3V7BqhHWwK7EnNv5fjZ6WfJNiY3v0BQVs3Mo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=dulQMMmn; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="dulQMMmn" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1DB482B; Tue, 7 Jul 2026 01:58:51 -0700 (PDT) Received: from [10.174.42.191] (unknown [10.174.42.191]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2647A3F85F; Tue, 7 Jul 2026 01:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783414735; bh=vy65AfeKcM9JM0/EN7cdtimmzBIvOMxJ8F0u/aP5ezw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dulQMMmnCkJuz3jkS1i/8I+q5kXKdSZouMk2DqiF/Y/xCOt/C0g51KuE5ViN0xdFU 3SxQhpPlQd65nhPNyl1MPeBHEgLhwwvDcs7/Uzzwacc0ZnDxJU0wFOOZjF5y7jy7qI hjsoHbuAU2gsbvJ/1koYZS3TlAEdqYnjKTs5ENWA= Message-ID: Date: Tue, 7 Jul 2026 14:28:43 +0530 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] mm: Standardize printing for pgtable entries To: "David Hildenbrand (Arm)" , linux-mm@kvack.org Cc: andriy.shevchenko@linux.intel.com, usama.arif@linux.dev, hughd@google.com, willy@infradead.org, Andrew Morton , linux-kernel@vger.kernel.org References: <20260707041703.658021-1-anshuman.khandual@arm.com> <5c128db1-7f82-4e2c-b029-5623880ea56d@kernel.org> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <5c128db1-7f82-4e2c-b029-5623880ea56d@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/07/26 12:38 PM, David Hildenbrand (Arm) wrote: > On 7/7/26 06:17, 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. >> >> 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. >> >> Cc: Andrew Morton >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: David Hildenbrand (Arm) > > You should add a Co-developed-by here :) Have not done much changes from your original patch :) > >> Signed-off-by: Anshuman Khandual >> --- > > [...] > >> + >> +static void ptval_bytes_to_hex_str(char *buf, size_t buf_size, const void *entry, size_t entry_size) >> +{ >> + if (WARN_ON_ONCE(buf_size < entry_size * 2 + 1)) { >> + snprintf(buf, buf_size, "overflow"); >> + return; >> + } >> + >> + switch (entry_size) { >> + case sizeof(u32): >> + snprintf(buf, buf_size, "%08x", *(const u32 *)entry); >> + break; >> + case sizeof(u64): >> + snprintf(buf, buf_size, "%016llx", *(const u64 *)entry); >> + break; >> +#if defined(__SIZEOF_INT128__) >> + case sizeof(u128): { >> + const u64 *val = entry; >> + >> + if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)) >> + snprintf(buf, buf_size, "%016llx%016llx", val[0], val[1]); >> + else >> + snprintf(buf, buf_size, "%016llx%016llx", val[1], val[0]); >> + break; > > As discussed, can we simplify that by casting to (u128) and then shifting the > values into place? which would be something like the following - had similar construct in D128 RFC V2 series as well. snprintf(buf, buf_size, "%016llx%016llx", (unsigned long long)*(const u128 *)entry >> 64), (unsigned long long)*(const u128 *)entry; I did think about it but is not the proposed chunk bit cleaner instead and easier to follow. Do you have concern regarding u64 pointers into u128 then accessed in chunks ? Regardless don't have a strong opinion either way.