From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EF23C433E0 for ; Mon, 22 Feb 2021 12:38:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ED4CE64F14 for ; Mon, 22 Feb 2021 12:38:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED4CE64F14 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6CC426B0078; Mon, 22 Feb 2021 07:38:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 67B7D6B007B; Mon, 22 Feb 2021 07:38:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 590568D0005; Mon, 22 Feb 2021 07:38:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 450A26B0078 for ; Mon, 22 Feb 2021 07:38:21 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 07E1F83FB for ; Mon, 22 Feb 2021 12:38:21 +0000 (UTC) X-FDA: 77845856802.10.4C90F6F Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf10.hostedemail.com (Postfix) with ESMTP id ED2C3407F8D0 for ; Mon, 22 Feb 2021 12:38:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1613997499; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5gs7qei1LjxxGt8o7TsGXkD1pF4Wvb6ryeWApuTDRZU=; b=NUEf0Dr1i+sQwilBf0DBdSEBzWMb68dKIInfyq+tZgg4UWMYR3bK7jVII4F1gC/03VljdQ pLOH96CGNx4A9RHLexu1yW0se6vUsPtXf9vGtc492wkhvWwL+N0/hB2GX/QBtlke/5VPqo 7UnIaz5/LGQnFaMi8F9t4PJSmCKP72M= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E7C0AAD2B; Mon, 22 Feb 2021 12:38:18 +0000 (UTC) Date: Mon, 22 Feb 2021 13:38:17 +0100 From: Petr Mladek To: Yafang Shao Cc: willy@infradead.org, andriy.shevchenko@linux.intel.com, david@redhat.com, linmiaohe@huawei.com, vbabka@suse.cz, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, rostedt@goodmis.org, sergey.senozhatsky@gmail.com, joe@perches.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 3/3] vsprintf: dump full information of page flags in pGp Message-ID: References: <20210215155141.47432-1-laoar.shao@gmail.com> <20210215155141.47432-4-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210215155141.47432-4-laoar.shao@gmail.com> X-Stat-Signature: w9wwxudyzbw388cy7go46yap8mij7sub X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: ED2C3407F8D0 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf10; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613997495-36878 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, first, I am sorry for the late reply. I have marked the thread as proceed by mistake last week... On Mon 2021-02-15 23:51:41, Yafang Shao wrote: > Currently the pGp only shows the names of page flags, rather than > the full information including section, node, zone, last cpupid and > kasan tag. While it is not easy to parse these information manually > because there're so many flavors. Let's interpret them in pGp as well. > > To be compitable with the existed format of pGp, the new introduced ones > also use '|' as the separator, then the user tools parsing pGp won't > need to make change, suggested by Matthew. The new information is > tracked onto the end of the existed one. > > One example of the output in mm/slub.c as follows, > - Before the patch, > [ 6343.396602] Slab 0x000000004382e02b objects=33 used=3 fp=0x000000009ae06ffc flags=0x17ffffc0010200(slab|head) > > - After the patch, > [ 8448.272530] Slab 0x0000000090797883 objects=33 used=3 fp=0x00000000790f1c26 flags=0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff) > > The documentation and test cases are also updated. The output of the > test cases as follows, > [11585.830272] test_printf: loaded. > [11585.830454] test_printf: all 388 tests passed > [11585.831401] test_printf: unloaded. > > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > +static > +char *format_page_flags(char *buf, char *end, unsigned long flags) > +{ > + unsigned long main_flags = flags & (BIT(NR_PAGEFLAGS) - 1); > + bool append = false; > + int i; > + > + /* Page flags from the main area. */ > + if (main_flags) { > + buf = format_flags(buf, end, main_flags, pageflag_names); > + append = true; > + } > + > + /* Page flags from the fields area */ > + for (i = 0; i < ARRAY_SIZE(pff); i++) { > + /* Skip undefined fields. */ > + if (!pff[i].width) > + continue; > + > + /* Format: Flag Name + '=' (equals sign) + Number + '|' (separator) */ > + if (append) { > + if (buf < end) > + *buf = '|'; > + buf++; > + } > + > + buf = string(buf, end, pff[i].name, *pff[i].spec); I have found one more small issue. The purpose of the flag-specific printk_spec is to define the format how the value is printed. The name of the flag should be printed using default_str_spec. It works because the string is printed as-is with both default_dec_spec and default_flag_spec. But it would be better to use the string format. > + if (buf < end) > + *buf = '='; > + buf++; > + buf = number(buf, end, (flags >> pff[i].shift) & pff[i].mask, > + *pff[i].spec); > + > + append = true; > + } > + > + return buf; > +} Otherwise, the patch looks to me. The issue is cosmetic and might be fixed either by re-spinning just this patch or by a followup patch. Either way, feel free to use: Reviewed-by: Petr Mladek Another question where to push this change. It is pity the we finalized it in the middle of the merge window. It has to spend at least few days in linux-next. I would like to hear from Andy before I push it into linux-next. There is still theoretical chance to get it into 5.12 when Linus prolongs the merge window by one week. it has been delayed by a long lasting power outage. Best Regards, Petr