Received: by 10.223.176.46 with SMTP id f43csp448869wra; Fri, 26 Jan 2018 01:19:38 -0800 (PST) X-Google-Smtp-Source: AH8x224sLvLqT3r742GcLw7E8laJw8v1mG0ymzVt3HQflJxrbyAW0ejEohMZ3ItkpQYWA8GSDdJs X-Received: by 2002:a17:902:5417:: with SMTP id d23-v6mr13676420pli.330.1516958377963; Fri, 26 Jan 2018 01:19:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516958377; cv=none; d=google.com; s=arc-20160816; b=wXuPrsaXpTtJCpuRnc358L3+aWiGH7MHubfykg9PIoq/duPO0gy13U9D9bF6zjtgTD uHLFMXYNU0whitg+5X+8v+kz4psEvhDwXZH1rl3bQdJaGAUkU8o64KO2JRv/ViefeOKz +zfimDBaVmxmXCoqzQN0vrMpvcH50DfkBz4sGox9/BxeuMLY4vsfVMEKxZ9AZnHZJ5pP BabGOniljUvoss9OrtD25jfwTBgJrtg8cuQYV6qUdRh64eMUuk80T1te6DvXTphHYIFP IgG21DJ+svBbY96541fHBgmW8e3RBe23ZTruOLWDltvOzkcL+aD75K46nywwux6gC4N4 SIEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=RWSS+6q9398XgTihZ108wzGQ4wKHPQbv8iN2cVXVlpc=; b=W7CTK+xiLLFfEungCJykoqzID6sgoc5vjUHCGcgAP95jW+MZodPE6vcmTi/8oZsVIS tfR0LBkizhqhRxEiruzHvhgHI8wDsAQBM2T3KLY0mqMiTKS1cRagOMmTDCN/p/0JnQd9 tjVGKscADIzHAX1hyNZnuxo987nREWte7xaz3xaXxL7b0mmDikQuy+NtRHXfFQm+eEMn Ej018JacdDAece1OmggtxZXJ6w2u/vh9qq8fr5hr1n6mGYfo8M3gPQDl+wxdwB3c0+sZ zAR6qT7ftR1Aajr4Z0HUOpgoPxBxxeAVzhON2BUHqozOLC6cLj4a0V0oDgsnO+27FFNq VgKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23si6048789pff.403.2018.01.26.01.19.23; Fri, 26 Jan 2018 01:19:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752789AbeAZJSD (ORCPT + 99 others); Fri, 26 Jan 2018 04:18:03 -0500 Received: from mga14.intel.com ([192.55.52.115]:22511 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752690AbeAZJSA (ORCPT ); Fri, 26 Jan 2018 04:18:00 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 01:17:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,415,1511856000"; d="scan'208";a="13638199" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga006.jf.intel.com with ESMTP; 26 Jan 2018 01:17:56 -0800 Message-ID: <1516958276.7000.1271.camel@linux.intel.com> Subject: Re: [RFC PATCH] vsprintf: add flag ZEROPAD handling before crng is ready From: Andy Shevchenko To: Yang Shunyong , me@tobin.cc, Rasmus Villemoes Cc: akpm@linux-foundation.org, joe@perches.com, pantelis.antoniou@konsulko.com, mchehab@kernel.org, adobriyan@gmail.com, linux-kernel@vger.kernel.org, yu.zheng@hxt-semitech.com Date: Fri, 26 Jan 2018 11:17:56 +0200 In-Reply-To: <1516952396-7423-1-git-send-email-shunyong.yang@hxt-semitech.com> References: <1516952396-7423-1-git-send-email-shunyong.yang@hxt-semitech.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Rasmus On Fri, 2018-01-26 at 15:39 +0800, Yang Shunyong wrote: > Before crng is ready, output of "%p" composes of "(ptrval)" and > left padding spaces for alignment as no random address can be > generated. This seems a little strange sometimes. > For example, when irq domain names are built with "%p", the nodes > under /sys/kernel/debug/irq/domains like this, > > [root@y irq]# ls domains/ > default irqchip@ (ptrval)-2 > irqchip@ (ptrval)-4 \_SB_.TCS0.QIC1 \_SB_.TCS0.QIC3 > irqchip@ (ptrval) irqchip@ (ptrval)-3 > \_SB_.TCS0.QIC0 \_SB_.TCS0.QIC2 > > The name "irqchip@ (ptrval)-2" is not so readable in console > output. Yes, this is not best output. > This patch adds ZEROPAD handling in widen_string() and move_right(). > When ZEROPAD is set in spec, it will use '0' for padding. If not > set, it will use ' '. > This patch also sets ZEROPAD in ptr_to_id() before crgn is ready. Did you run tests? Have you added specific test cases to see what's going on for patterns like printf("%0s\n", " (my string)"); ? > Following is the output after applying the patch, > > [root@y irq]# ls domains/ > default irqchip@00000000(ptrval)-2 > irqchip@00000000(ptrval)-4 \_SB_.TCS0.QIC1 \_SB_.TCS0.QIC3 > irqchip@00000000(ptrval) irqchip@00000000(ptrval)-3 \_SB_.TCS0.QIC0 > \_SB_.TCS0.QIC2 > So, for me it looks like curing symptoms. After all, it's debugfs, no one prevents you to fix an output of the certain nodes there. > I am not sure whether crng can get enough random data at very early > stage of system startup (eg. before irq system in the case above) > and the effort to port current random driver to work at that time. > So, this issue may exist some time. > I use '0' for padding in this patch. This should be ok because output > of "%pK" is all '0's when kptr_restrict = 2. I don't know whether > other character, such as 'x', may be more preferable. > > Signed-off-by: Yang Shunyong > --- > lib/vsprintf.c | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 01c3957b2de6..e0b6e1edae31 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -535,14 +535,18 @@ char *special_hex_number(char *buf, char *end, > unsigned long long num, int size) > return number(buf, end, num, spec); > } > > -static void move_right(char *buf, char *end, unsigned len, unsigned > spaces) > +static void move_right(char *buf, char *end, unsigned int len, > + unsigned int spaces, struct printf_spec spec) > { > size_t size; > + char pad; > + > + pad = (spec.flags & ZEROPAD) ? '0' : ' '; > if (buf >= end) /* nowhere to put anything */ > return; > size = end - buf; > if (size <= spaces) { > - memset(buf, ' ', size); > + memset(buf, pad, size); > return; > } > if (len) { > @@ -550,7 +554,7 @@ static void move_right(char *buf, char *end, > unsigned len, unsigned spaces) > len = size - spaces; > memmove(buf + spaces, buf, len); > } > - memset(buf, ' ', spaces); > + memset(buf, pad, spaces); > } > > /* > @@ -565,18 +569,21 @@ static void move_right(char *buf, char *end, > unsigned len, unsigned spaces) > char *widen_string(char *buf, int n, char *end, struct printf_spec > spec) > { > unsigned spaces; > + char pad; > > if (likely(n >= spec.field_width)) > return buf; > /* we want to pad the sucker */ > spaces = spec.field_width - n; > if (!(spec.flags & LEFT)) { > - move_right(buf - n, end, n, spaces); > + move_right(buf - n, end, n, spaces, spec); > return buf + spaces; > } > + > + pad = (spec.flags & ZEROPAD) ? '0' : ' '; > while (spaces--) { > if (buf < end) > - *buf = ' '; > + *buf = pad; > ++buf; > } > return buf; > @@ -1702,6 +1709,8 @@ static char *ptr_to_id(char *buf, char *end, > void *ptr, struct printf_spec spec) > > if (unlikely(!have_filled_random_ptr_key)) { > spec.field_width = default_width; > + spec.flags |= ZEROPAD; > + > /* string length must be less than default_width */ > return string(buf, end, "(ptrval)", spec); > } -- Andy Shevchenko Intel Finland Oy