From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 18195406278 for ; Thu, 9 Jul 2026 10:10:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783591805; cv=none; b=ZgAEcR+jAHBAazY/tWKIXPxmewiaeubVpEmgQ+z9YkG3aeZkZ4alzf/GndRE+8sXoJWj8xuqpn+xLUu/2g1EPbjEEE6a4i/cy471MUZ9TzhlFXcBb0Caa3sClY+AQfAQnJf/vZWFlh/qOCY0gecCgGciZL1GHG5yoHua1ZP6wQ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783591805; c=relaxed/simple; bh=TrkqQ7zhIvszvZQqIOqflT0qGCkULvjhp3ccrpYQwsk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XlZjfqTOzn+GeuA3eooE9zQ+pGX7qPa0ZODIMeixQIT9bNl8P52NO7MCDm057kCEGHPvD4hYlg9xi8g/5wXQY3a7KA8QEtk/8AcC2b6PYOgjfZ7h8YculTFarHGfm8D2jLgliIxb79U3g0xJ1iVRhY2QAyxtd+9h9qFrv6fA2ac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=XnorzKQt; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="XnorzKQt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783591804; x=1815127804; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=TrkqQ7zhIvszvZQqIOqflT0qGCkULvjhp3ccrpYQwsk=; b=XnorzKQtyq/tyita3/n4GWrqF8uuxxA19y/TrWTGVy0hfDbJlqvrgf/6 LUeKcgv98kZnucUOPuaLi+g7d5ZtXC0BM5M9E7Mib6Mh1pA2h72xo8qF4 /DqJ7/5ArXF/BUFMIBvi/0avV6evYpE88Fo65kIq4BnYXIw2tCzmdlkpy nnJdaaJ6WHOMOsg0g37E+rC0bC+1dLkT7UhKNryoGXsx2BnftugsL2EZO rZFSHmzrJteO+sqH5Zmni5/12aa96GYUS8Hhy0D7wtph1u2kX5v7x+NtX M7a/VAl5C7KKHvv5MB1O4afbZR49yOYqoxfMyL0VMfwA4YlXCrrvCHXZe g==; X-CSE-ConnectionGUID: IS8uEQUFSHOjagTMcqp3vA== X-CSE-MsgGUID: BO0sPASgRUOK92HoOu5Xkw== X-IronPort-AV: E=McAfee;i="6800,10657,11841"; a="94915647" X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="94915647" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2026 03:10:03 -0700 X-CSE-ConnectionGUID: IXvYTLiZTAyIwc8bXB5rHA== X-CSE-MsgGUID: ovnBkPJvScql75QTvZzjTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="254056645" Received: from ettammin-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.245.235]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2026 03:10:01 -0700 Date: Thu, 9 Jul 2026 13:09:53 +0300 From: Andy Shevchenko To: "David Hildenbrand (Arm)" Cc: Anshuman Khandual , Petr Mladek , linux-mm@kvack.org, usama.arif@linux.dev, hughd@google.com, willy@infradead.org, ryan.roberts@arm.com, Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH V3] mm: Standardize printing for pgtable entries Message-ID: References: <20260709044334.1741263-1-anshuman.khandual@arm.com> 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-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Thu, Jul 09, 2026 at 11:12:58AM +0200, David Hildenbrand (Arm) wrote: > On 7/9/26 09:40, Andy Shevchenko wrote: > > On Thu, Jul 09, 2026 at 10:13:34AM +0530, Anshuman Khandual wrote: > >> Cc: Andrew Morton > >> Cc: linux-mm@kvack.org > >> Cc: linux-kernel@vger.kernel.org > > > > FWIW, you may move these to be after... > > We generally don't handle it like that in MM. Maybe one day we'll switch over > and document it accordingly. > > For now, having selected patches doing this differently is not any helpful. Can you elaborate "differently"? Except a big noise and churn in the commit message I do not see any benefit of doing the "old" way. Lately I saw some patch-bot messages from Andrew, I assume he updates his scripts towards newer tooling, which may be a good sign that the (good) changes are still possible. [...] > >> +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): > >> + snprintf(buf, buf_size, "%016llx%016llx", > >> + (unsigned long long)(*(const u128 *)entry >> 64), > >> + (unsigned long long)*(const u128 *)entry); > >> + break; > >> +#endif > >> + default: > >> + snprintf(buf, buf_size, "unsupported"); > >> + break; > >> + } > >> +} > >> + > >> +#define ptval_to_str(buf, val) \ > >> + do { \ > >> + auto __val = (val); \ > >> + \ > >> + ptval_bytes_to_hex_str((buf), sizeof(buf), &__val, sizeof(__val)); \ > >> + } while (0) > >> + > >> +#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 > > > > The above is quite duplicative with what we have in lib/vsprintf.c. Have you considered > > using something from there instead? (Yes, it might require some functions to be wrapped > > or dropped from static.) > > Which part in particular do you have in mind? > > num_to_str() does not apply due to the u128. > > We could have u128 variant that we would only provide with __SIZEOF_INT128__ > > int num128_to_str(char *buf, int size, u128 num, unsigned int width) > > And then have the code pass the value instead of a pointer to the value. A bit > tricky to handle this based on conditional __SIZEOF_INT128__ support, but could > be done. > > Not sure if that is really what we want here, though. ptval_bytes_to_hex_str() > is pretty ... simple :) > > I didn't immediately spot a replacement for PTVAL_STR_MAX. I referred mostly to special_hex_number(). > So it would be good if you could clarify what you had in mind, thanks! -- With Best Regards, Andy Shevchenko