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 0305C3909B1 for ; Thu, 9 Jul 2026 03:54:40 +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=1783569282; cv=none; b=K4zWxHMcK6NjKu4cdBJ5YJJyJi4rdeXyxE6U2juu2PuWzZ9tHnoQ66vqYCJlEQTNRv+ssBVic7GmRBnHF/zh5jDomUY0VlIRRpp16NBjVLdgB5bcixhjGICFAUEuHlYZDCEWTv8F7QD1Wh6gbiWgnUobniGarSFrX/D9GtCIp/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783569282; c=relaxed/simple; bh=oTE+JmeWYAD6NTmOgsILFCPn/1/522DGucnZMSxv3kc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KNdO00LoKHOwSOEsbj2yf06ghjPjrdT5zEaAV0ovurF3k6f/rincblh6LKmvS3trbN5dCzM/12HITKWLXoN7jjR2b0QYY6h9XZDKXY0fPyeE8ZlsmSUmUJF3ST3LjFdkC5jab6NUnjl5UqpTAB/Sm4HKt5GHQWx4H6Wy4w8vhNI= 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=j/6D3+61; 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="j/6D3+61" 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 C4D9A24C0; Wed, 8 Jul 2026 20:54:35 -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 66C873F66F; Wed, 8 Jul 2026 20:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783569280; bh=oTE+JmeWYAD6NTmOgsILFCPn/1/522DGucnZMSxv3kc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=j/6D3+61mRTAgBHjRLQiEBVYJCJVN2AYi+leI7Q5sTXNeLuZx5nbKeuJjl+W5gDgG WH9IbSjXDru6k/s9cTfnyQe7WbQ/BUUTW4mg9NPsugJD6Yp803s3T0cA3wqw8RFq2l ZpIlasq3T6FoGqEfC4DNBtAbclLB5MKgEWUzOef4= Message-ID: Date: Thu, 9 Jul 2026 09:24:34 +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: "David Hildenbrand (Arm)" , Ryan Roberts , 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: <20260708032824.969752-1-anshuman.khandual@arm.com> <25cde246-540f-4ab4-b541-0b7313c57954@arm.com> <76f24730-46de-4583-9189-ff7ba28c741d@kernel.org> <724a080a-bd4b-4fab-a890-c6a97ebff77f@arm.com> <1e6be746-44b5-485c-8adb-4a21b7a3d03d@kernel.org> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <1e6be746-44b5-485c-8adb-4a21b7a3d03d@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08/07/26 6:28 PM, David Hildenbrand (Arm) wrote: > On 7/8/26 14:43, Ryan Roberts wrote: >> On 08/07/2026 12:27, David Hildenbrand (Arm) wrote: >>> On 7/8/26 13:22, Ryan Roberts wrote: >>>> >>>> Not sure if it's worth doing something like this?: >>>> >>>> #define PTVAL_STR_MAX \ >>>> (MAX(MAX(MAX(MAX(sizeof(pteval_t), sizeof(pmdval_t)), \ >>>> sizeof(pudval_t)), \ >>>> sizeof(p4dval_t)), \ >>>> sizeof(pgdval_t)) + 1) >>>> >>>> Would probably save stack space for 32bit arches? >>> >>> Do we really care about that? This is about a corner cases error reporting right >>> now. >> >> Fair enough, it just seemed like an obvious and simple (very minor) improvement. >> >>> >>>> >>>> >>>> I think arm64 code also does pte printing, which you also need to fix up for >>>> D128 support. Perhaps this could be moved to a header for reuse? >>> >>> We could do that as a second step, right? >> >> Sure, but why churn it twice? Anyway, no strong opinion, you're the boss :) > > I'd say, if we're going to reuse this code for the arm64 pieces as well, we'd > best send it along the arm64 pieces, and figure out where to place it for > arm64's use right away. > > If we'll defer the arm64 changes, I'd also defer deciding where we'd be moving > it to. Sounds better to have this printing problem taken care in generic MM first as this change looks self contained. Subsequently rebase D128 series as required.