From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 509762EDD70 for ; Thu, 9 Jul 2026 11:54:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783598084; cv=none; b=lOgUG9q50wiZ/oyJkMRyUxrXuC9E5bquqmQdNAPSS78RECBWVcPoKSpltendsep7mMXWUtITn3/hQZ5X5GpWGmIecuftlyH9Z1iiuYxOM3w7KHBpgTx8FmoTP23JFHdZ7cNyLGj2LntMm1oa2Xh7xcL4yGwcQqHR/e7BaO4Bo1M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783598084; c=relaxed/simple; bh=5bsRsa5pptjNQSJi/7ecvl6kZTK9O+Ae+0CnnqVjmU0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b88IEmhNZXLmaLX7vBdCcZFw+QlH90v4dJgUMCFFmPZrOh7zFBbpPz3zXX3PKJGnA6ZkQ7kKhPS9WOMtobPeRwc5hw6tECeaqlMvzOCQ82z73SAELGBDmBsDnJlmstWjD9Jg1CrSj92nOrXV5tqUjBRuPVpFiWff0zI9GXllR8Y= 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=Ul779aks; arc=none smtp.client-ip=198.175.65.16 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="Ul779aks" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783598084; x=1815134084; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=5bsRsa5pptjNQSJi/7ecvl6kZTK9O+Ae+0CnnqVjmU0=; b=Ul779aks0J5hjVXY6BzKiMfcmFmXzhZ+1htnBjAGuzmDdtjMGnELnGQD lpSf5RuQwvV5AaxzBLQ/LtFHZDlNZBe3YbzAyTZLchj4Gvb4p7maNf1PK Aclx+MjqrNp/yIpDPo+5A6a9ECVm1n8yJOwjEkBeloYSDKbIk8YYkTgK5 lU44CPZAnnS6UXoj3+GWoYsUsTCWoQXsQVBtuGQhcGrpn9UzooNfjZazZ uENyB7LTDBxqKoOPgXHu+JZrbBitokesnRWhPA/xAkmTA/vmA8DSdRTLQ wIg6HrkX4YgOgYfHoHAQYzCqXIbjkQ3AoVlXI8Bg7VGgSUEk+1Ia891QZ Q==; X-CSE-ConnectionGUID: 8h6DetG2TXSHkR2X14zazg== X-CSE-MsgGUID: x3YtDg76S+Sg/nA+C/xoVQ== X-IronPort-AV: E=McAfee;i="6800,10657,11841"; a="84468258" X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="84468258" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2026 04:54:43 -0700 X-CSE-ConnectionGUID: QgWH0aTBSbmRrg4couPFmw== X-CSE-MsgGUID: IMCYNFYWR4W4LPlx1dFX2g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="254684281" Received: from ettammin-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.245.235]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2026 04:54:40 -0700 Date: Thu, 9 Jul 2026 14:54:38 +0300 From: Andy Shevchenko To: Anshuman Khandual Cc: "David Hildenbrand (Arm)" , 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 04:42:30PM +0530, Anshuman Khandual wrote: > On 09/07/26 4:13 PM, Andy Shevchenko wrote: > > On Thu, Jul 09, 2026 at 12:24:08PM +0200, David Hildenbrand (Arm) wrote: > >> On 7/9/26 12:13, Andy Shevchenko wrote: > >>> On Thu, Jul 09, 2026 at 01:11:46PM +0300, Andy Shevchenko wrote: > >>>> On Thu, Jul 09, 2026 at 11:15:27AM +0200, Petr Mladek wrote: ... > >>>>> But maybe you had something particular in mind. > >>>> > >>>> Yes, I was thinking of a wrapper on top of special_hex_number(). It takes size > >>>> as an argument and hence will work even for 128-bit cases. > >>> > >>> Okay, the argument is limited to 64-bit in there. But I don't think it's a big > >>> impediment. > >> > >> Rewrite number() / create a new 128bit variants to avoid 3 simple snprintf() > >> statements? :) > >> > >> Hm ... > > > > Since it's slowly spreading (I mean 128-bit types), I think sooner or later we > > would do it anyway. For now we can just have a wrapper on top of number() > > (yes, special_hex_number() probably too special for this case) to print it. > > And yes, avoiding sprintf() in this case seems beneficial to me, we will have > > one implementation of how we print pointers. > > We followed this approach in a self contained manner inside core > MM in order to avoid adding new printk format. TBH don't see too > much value in again trying to create factored common code between > with lib/vsprintf.c As David mentioned this may not be worth it. I'm not fighting to death for this, just my observations, so we see that majority of people agree with leaving this one independent on lib/vsprintf.c implementation. -- With Best Regards, Andy Shevchenko