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 6014A38AC83 for ; Thu, 9 Jul 2026 03:43:02 +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=1783568584; cv=none; b=bsGhTI0XIPy8jH5JhV+/HdiFCTzySP3dDrb0LYS5AzipD9cFL4UV+TzerctJACXGugxzIRZeYynZTVGBuIYtWZL9KzEDyPln6dZb4bbo6UI/NN8JK65+LWUCRma0u8oTD4zG1ivu/YoEdiQeJIloXENdZtN3XAVFBXgijho+Oi4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783568584; c=relaxed/simple; bh=9+xFuPnxLkZ0LODqfBFUwgvSDNP4bxjtxLgzTPCHNEY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=I2BR39qPwk9vyhjtIV0hZgo0pv8DwO3iATQwVYWlDmzmBlrrM6pg571iSIlLvqvsOQ8B7G5ilUFF8W5q2HRlUYCsAZz89oPfm4Bxy+3SqbuF/vLOqPN+HyxscR7SF3y3heLn+OODKDFugbidxSBzLMbqVJzGLVuLQe1B5o2n4IA= 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=fORSMNU4; 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="fORSMNU4" 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 CDAD124C0; Wed, 8 Jul 2026 20:42:56 -0700 (PDT) Received: from [10.174.42.219] (unknown [10.174.42.219]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2164A3F66F; Wed, 8 Jul 2026 20:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783568581; bh=9+xFuPnxLkZ0LODqfBFUwgvSDNP4bxjtxLgzTPCHNEY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fORSMNU4zEVwT8g2U1DOTqFo/8e1uD3a/+wgFinKawPjy16yI3GmWrE5EtGTTnbqy Om3fgqpGZdAW9W9K2WneR6tNtN9+pxpuAT3pHkQ7zr4hGqM6cpZIMsmZvlObiaAGfT 1aNfOdNc/3gGQ1w9JgtWFyQA08OcwxSFK7AFLRHU= Message-ID: <40f1a8be-a6a3-4b6b-bab3-e27b16b52983@arm.com> Date: Thu, 9 Jul 2026 09:12:54 +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 V2] mm: Standardize printing for pgtable entries To: Andy Shevchenko Cc: linux-mm@kvack.org, usama.arif@linux.dev, hughd@google.com, willy@infradead.org, ryan.roberts@arm.com, "David Hildenbrand (Arm)" , Andrew Morton , linux-kernel@vger.kernel.org References: <20260708032824.969752-1-anshuman.khandual@arm.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08/07/26 4:47 PM, Andy Shevchenko wrote: > On Wed, Jul 08, 2026 at 08:58:23AM +0530, Anshuman Khandual wrote: > >> 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. > > Why do you still use __auto_* instead of 'auto'? > Please, see the comment in compiler_types.h about this. /* * C23 introduces "auto" as a standard way to define type-inferred * variables, but "auto" has been a (useless) keyword even since K&R C, * so it has always been "namespace reserved." * * Until at some future time we require C23 support, we need the gcc * extension __auto_type, but there is no reason to put that elsewhere * in the source code. */ #if __STDC_VERSION__ < 202311L # define auto __auto_type #endif Alright 'auto' could be used for toolschain both before and after C23. Will do the replacement s/__auto_type/auto