Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp726941pxb; Tue, 2 Feb 2021 16:51:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJy/wOgjGnTvFpmZum9nTlvE4dp24H+KHNK1tXX6BnKOKdkUCvEbDtczDEvw1kOr/+Zhek4V X-Received: by 2002:a17:906:1a11:: with SMTP id i17mr651830ejf.278.1612313497008; Tue, 02 Feb 2021 16:51:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612313497; cv=none; d=google.com; s=arc-20160816; b=tWHkJ3LK4Vu3bzjC7K/xrZX/5L0LnQFp1HFNKxsVeNHMFTD4RYz97ddUMHllTImZ4Z QEQsCalrmkleScSbhQFQzptsYdldtMni+jt+M3x2m1BNzz5Km3IjfNy9BtAdTCWj5G2W dOOq2UKRmsc1gE/dnAiZmW8YVRIr8eW/IgDsORP5Akb2igiaaNFD34JP5Iuy2fqCGYvP tV708twRJ1ENRXIE2zQgYHEAaprT1hvvzO3eHAI8094HeVzWpudNzbFMlSRLPk2Gnb8N bYpRhtENzVcZOHiK5w9TFVFtQZb2/7WE5JMnsRFDecwXoUL1a4+QDHD/BcRXrAPi7oGg qf2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=3hz19TF2JROt6xvTiAYHx8FU5yLbxQH428pKwbOX3Ig=; b=DKeDa72wF7Vzl/ufLSya4Q5m6WlcRi6ZrHc6obQG9+XBbDw8kJ7wYs7PtH8I4OqXy1 eb7JkMbHJxqBd4pxmQTIvsg9+aROQSEBQI4ib+fHjLo+6QEJoCv2Fx5pnWjRdNuFkk7H 1swXcui2JM1CkYhH0US/+kQ2F4Iv9JzGraXWjVTjynoWvbjCSwzV7bhNb/IBLX24rkEw DeNy3vstjcSuA+7vBV+HeEKPH4CmWYondi5NMJXEkVHDyk9JlDiJj98EajN85ULZYUXi nqBKfTl8hbVYB9ckevAZNgr4lJDndKs+W/iFeuBegrF0UuuXDQHUnFJ2G5aZghW0vnJd 4uFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dabbelt-com.20150623.gappssmtp.com header.s=20150623 header.b=voIIhR8+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y11si247276edp.516.2021.02.02.16.51.13; Tue, 02 Feb 2021 16:51:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@dabbelt-com.20150623.gappssmtp.com header.s=20150623 header.b=voIIhR8+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240250AbhBBUK5 (ORCPT + 99 others); Tue, 2 Feb 2021 15:10:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240447AbhBBUHW (ORCPT ); Tue, 2 Feb 2021 15:07:22 -0500 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9610C06174A for ; Tue, 2 Feb 2021 12:06:41 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id y142so7106226pfb.3 for ; Tue, 02 Feb 2021 12:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=3hz19TF2JROt6xvTiAYHx8FU5yLbxQH428pKwbOX3Ig=; b=voIIhR8+FopW32VevxJctVUrftIUn1iEu53Ov6JhrKhnxBC+usWT5fPD3K8rS5fslG cNpGKnZyl7Lv2JOe1m3J70I2MDA5E/354+yxtkzPt27SAsxW3kQZr+qg9CjydbNQ4STb ISUUhxKwJWKwtAYMkcm3/No3Te06fHBO9CJ5nFSO/c314+F8Z06vpTUVvW0/Y4VmQGsV MVdp43xJfjusjEThxvEjbjipcxBXOFbUVA1FVoO8sdjqmgzxVHK3LH4PuVXZobn5mr3b ZswtsEWv1jF4eJ0hOHsHpbzrqBbELbYNiUsttWbsWS5Kkv+inkOq85MzP9/fjqdh7Ef4 Zriw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=3hz19TF2JROt6xvTiAYHx8FU5yLbxQH428pKwbOX3Ig=; b=GA+VQKvJqqozNMFcl3JEA2sz/EB35b87rrgM2V+AEY+5vaFP8/lYxSXDDT7nyojgVY B045hr5VlO/l94MN5xByYYuIpB7jn4gAqrbaNjzFhdiMISRw+LdfhLqvDojrFrTU8NE/ v2zh8jh7ZqGr/0PosXpXjO/WLSWgfZul1gfR1GHuQsU5fxZ3YOYlMim1XiFbwNeFkUPT cXbq31s6wIsYavjP6d06l2jqRi79P51G36MPVtBQLAT0Fex1+yv+/8nBDzd9r1DjhgdY A8uQn8MyW53JJ9SbkvxZXVrcoD5SgdfLGc1bPYD72HwT/e/GqsmjEAu9sRV3pK488WRY dPoQ== X-Gm-Message-State: AOAM532jyk1ksAHbHNufIRCw/91M6Zqt5raaLcg6wzued3yQpm4aJXj0 IIKhvG05E+Bc0qlqAvNn2T/XlpKfBB2Sog== X-Received: by 2002:a63:357:: with SMTP id 84mr24020307pgd.13.1612296401148; Tue, 02 Feb 2021 12:06:41 -0800 (PST) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id 11sm22747061pgz.22.2021.02.02.12.06.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 12:06:40 -0800 (PST) Date: Tue, 02 Feb 2021 12:06:40 -0800 (PST) X-Google-Original-Date: Tue, 02 Feb 2021 12:06:38 PST (-0800) Subject: Re: [PATCH] arch_numa: fix common code printing of phys_addr_t In-Reply-To: <0d6fb1da-6b14-7f54-3f4c-4697c88a14f7@infradead.org> CC: linux-kernel@vger.kernel.org, lkp@intel.com, Atish Patra From: Palmer Dabbelt To: rdunlap@infradead.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 01 Feb 2021 19:51:07 PST (-0800), rdunlap@infradead.org wrote: > On 2/1/21 7:36 PM, Palmer Dabbelt wrote: >> On Wed, 27 Jan 2021 19:55:33 PST (-0800), rdunlap@infradead.org wrote: >>> Fix build warnings in the arch_numa common code: >>> >>> ../include/linux/kern_levels.h:5:18: warning: format '%Lx' expects argument of type 'long long unsigned int', but argument 3 has type 'phys_addr_t' {aka 'unsigned int'} [-Wformat=] >>> ../drivers/base/arch_numa.c:360:56: note: format string is defined here >>>   360 |    pr_warn("Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n", >>> ../drivers/base/arch_numa.c:435:39: note: format string is defined here >>>   435 |  pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1); >>> >>> Fixes: ae3c107cd8be ("numa: Move numa implementation to common code") >>> Signed-off-by: Randy Dunlap >>> Reported-by: kernel test robot >>> Cc: Atish Patra >>> Cc: Palmer Dabbelt >>> --- >>>  drivers/base/arch_numa.c |   13 +++++++------ >>>  1 file changed, 7 insertions(+), 6 deletions(-) >>> >>> --- linux-next-20210125.orig/drivers/base/arch_numa.c >>> +++ linux-next-20210125/drivers/base/arch_numa.c >>> @@ -355,11 +355,12 @@ static int __init numa_register_nodes(vo >>>      /* Check that valid nid is set to memblks */ >>>      for_each_mem_region(mblk) { >>>          int mblk_nid = memblock_get_region_node(mblk); >>> +        phys_addr_t start = mblk->base; >>> +        phys_addr_t end = mblk->base + mblk->size - 1; >>> >>>          if (mblk_nid == NUMA_NO_NODE || mblk_nid >= MAX_NUMNODES) { >>> -            pr_warn("Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n", >>> -                mblk_nid, mblk->base, >>> -                mblk->base + mblk->size - 1); >>> +            pr_warn("Warning: invalid memblk node %d [mem %pap-%pap]\n", >>> +                mblk_nid, &start, &end); >>>              return -EINVAL; >>>          } >>>      } >>> @@ -427,14 +428,14 @@ out_free_distance: >>>  static int __init dummy_numa_init(void) >>>  { >>>      phys_addr_t start = memblock_start_of_DRAM(); >>> -    phys_addr_t end = memblock_end_of_DRAM(); >>> +    phys_addr_t end = memblock_end_of_DRAM() - 1; >>>      int ret; >>> >>>      if (numa_off) >>>          pr_info("NUMA disabled\n"); /* Forced off on command line. */ >>> -    pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1); >>> +    pr_info("Faking a node at [mem %pap-%pap]\n", &start, &end); >>> >>> -    ret = numa_add_memblk(0, start, end); >>> +    ret = numa_add_memblk(0, start, end + 1); >>>      if (ret) { >>>          pr_err("NUMA init failed\n"); >>>          return ret; >> >> Thanks, this is on for-next.  Did you, by any chance, find %Lx documented >> anywhere?  It's not ISO C and the GCC source code says it's a GNU extension, >> but I couldn't find it in the documentation (or even where to add it, which I >> guess is how I forgot to send my version fo the patch). > > 'man sprintf' says this: > > As a nonstandard extension, the GNU implementations treats ll and L as > synonyms, so that one can, for example, write llg (as a synonym for the > standards-compliant Lg) and Ld (as a synonym for the standards compli- > ant lld). Such usage is nonportable. > > > and linux/lib/vsprintf.c has some handling for it: > > if (qualifier == 'L') > spec->type = FORMAT_TYPE_LONG_LONG; > > and > > case 'L': > if (is_sign) > *va_arg(args, long long *) = val.s; > else > *va_arg(args, unsigned long long *) = val.u; > break; > > > Does that help? The manpage does it, I guess I just wasn't reading closely enough. Thanks!