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 56880402B96 for ; Wed, 8 Jul 2026 08:43:38 +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=1783500221; cv=none; b=iyRoAmVmuwFMA+vlFMbZL6T8Bzcll2aQoXBNMu/oHS2LM6kL2XzCTGCphSNQfup0jw9SQ9sMiKjZIOoUBhXbuAV+6o1ROuOTjhVyJGlTe8x8h80H+qo+K83UJZ/K0XaXX4WJDk0ODpjoOKtMB7dbLrgh6uVYyKWuog9I+Lb6M9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783500221; c=relaxed/simple; bh=MCK9eENGAIn0ByvV2x9VNERLdyrWsFYGRTi6b6lpGJ8=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=FYAgEQxHxRLB8hmQfxCe0WuA4zqUS5UYEkms3+QUs9lYVhTO/9Z6KL+d2aEH/zIeSjmoRGs8NZ7jCRon5mjpocOVDtxAeVgnWDRRUvVklgtrulnNeBC4rzlS4D5gcn2oFizOyQ73PHoZMHrNz8VBCHWsWPON4HC3GbT2XWRDsbc= 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=JuTeCaJP; 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="JuTeCaJP" 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 D80401650; Wed, 8 Jul 2026 01:43:26 -0700 (PDT) Received: from [10.164.145.253] (J09HK2D2RT.blr.arm.com [10.164.145.253]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C16873F7B4; Wed, 8 Jul 2026 01:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783500211; bh=MCK9eENGAIn0ByvV2x9VNERLdyrWsFYGRTi6b6lpGJ8=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=JuTeCaJPdfGfvfNwkDT9Vihg/6/Zu8Zs+uuYJRWvUxfUPsZJ7R/v1NLC9TP/thJQg wdPrqqvy9Cum3YT19QPDMP/M64YWy128vXZOPC9r0Qy3PmxUMrq05nN4/g/8P7HK1R igecv7wUyuAYJr3WYIL2utYOBp4dc5GzIUPwoi2M= Message-ID: <437505b8-8616-4341-8d19-033d5b6b1d51@arm.com> Date: Wed, 8 Jul 2026 14:13:26 +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 From: Anshuman Khandual Subject: Re: [PATCH V2] 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, ryan.roberts@arm.com, Andrew Morton , linux-kernel@vger.kernel.org References: <20260708032824.969752-1-anshuman.khandual@arm.com> <876c533f-6709-43a0-8595-143a8b9c9201@kernel.org> Content-Language: en-US In-Reply-To: <876c533f-6709-43a0-8595-143a8b9c9201@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08/07/26 1:31 PM, David Hildenbrand (Arm) wrote: > On 7/8/26 05:28, 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) > > I still think you should add your > > Co-developed-by :) OK - will add. > >> Signed-off-by: Anshuman Khandual >> --- >> This patch applies on v7.2-rc2 >> >> Changes in V2: >> >> - Dropped space after ":" during print per Matthew >> - Dropped CONFIG_CPU_BIG_ENDIAN per David >> >> Changes in V1: >> >> https://lore.kernel.org/all/20260707041703.658021-1-anshuman.khandual@arm.com/ >> >> mm/memory.c | 98 ++++++++++++++++++++++++++++++++++++++++------------- >> 1 file changed, 75 insertions(+), 23 deletions(-) >> > > In general, LGTM (I wrote of it, lol) > >> diff --git a/mm/memory.c b/mm/memory.c >> index ff338c2abe92..a2b63af82792 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -519,9 +519,48 @@ static bool is_bad_page_map_ratelimited(void) >> return false; >> } >> >> +#define PTVAL_STR_MAX (32 + 1) /* Max 128-bit value in hex + NUL */ > > We could reduce the stack space for !__SIZEOF_INT128__, but not sure if worth it. > > __print_bad_page_map_pgtable() will currently consume 132 bytes for strings, > guess that's still tolerable. > That's a good point. Are you looking for something like the following where stack space can be saved if __SIZEOF_INT128__ is not supported. #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 Besides will move the macro just before __print_bad_page_map_pgtable() where it gets used.