All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: "Christoph Lameter" <cl@linux.com>,
	"Pekka Enberg" <penberg@kernel.org>,
	"David Rientjes" <rientjes@google.com>,
	"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
	"Joe Perches" <joe@perches.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Matthew WilCox" <willy@infradead.org>,
	"David Hildenbrand" <david@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v3 3/4] mm, printk: introduce new format %pGt for page_type
Date: Thu, 29 Dec 2022 22:30:58 +0900	[thread overview]
Message-ID: <Y62WkiG3dSWOKL1i@hyeyoo> (raw)
In-Reply-To: <Y6HSutM8pmoKxQWp@alley>

On Tue, Dec 20, 2022 at 04:20:26PM +0100, Petr Mladek wrote:
> On Sun 2022-12-18 19:19:00, Hyeonggon Yoo wrote:
> > %pGp format is used to print 'flags' field of struct page.
> > As some page flags (e.g. PG_buddy, see page-flags.h for more details)
> > are set in page_type field, introduce %pGt format which provides
> > human readable output of page_type.
> > 
> > Note that the sense of bits are different in page_type. if page_type is
> > 0xffffffff, no flags are set. if PG_slab (0x00100000) flag is set,
> > page_type is 0xffefffff. Clearing a bit means we set the bit.
> > 
> > Bits in page_type are inverted when printing page type names.
> > 
> > --- a/Documentation/core-api/printk-formats.rst
> > +++ b/Documentation/core-api/printk-formats.rst
> > @@ -575,12 +575,13 @@ The field width is passed by value, the bitmap is passed by reference.
> >  Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
> >  printing cpumask and nodemask.
> >  
> > -Flags bitfields such as page flags, gfp_flags
> > +Flags bitfields such as page flags, page_type, gfp_flags
> >  ---------------------------------------------
> 
> Please, underline the entire title. Otherwise, "make htmldoc"
> complains ;-)
> 
>     /prace/kernel/linux/Documentation/core-api/printk-formats.rst:579: WARNING: Title underline too short.
>     Flags bitfields such as page flags, page_type, gfp_flags

Still not getting used to rst format ;)
Will fix, thanks!

> 
> 
> >  
> >  ::
> >  
> >  	%pGp	0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff)
> > +	%pGt	0xffefffff(slab)
> >  	%pGg	GFP_USER|GFP_DMA32|GFP_NOWARN
> >  	%pGv	read|exec|mayread|maywrite|mayexec|denywrite
> >  
> 
> Please, explain this also in the paragraph below these examples.
> I would personally refactor it to an itemized list, something like:
> 
> <proposal>
> For printing flags bitfields as a collection of symbolic constants that
> would construct the value. The type of flags is given by the third
> character. Currently supported are:
> 
> 	- p - [p]age flags, expects value of type (``unsigned long *``)
> 	- t - page [t]ype, expects value of type (``unsigned int *``)
> 	- v - [v]ma_flags, expects value of type (``unsigned long *``)
> 	- g - [g]fp_flags, expects value of type (``gfp_t *``)
> 
> The flag names and print order depends on the particular type.
> </proposal>

The proposal sounds reasonable to me,
will adjust in next version.

> Rant:
> Sigh, it looks a bit error prone when similar pointer modifiers
> expects pointers to different types. I wish there was a way how
> to check the passed pointer type at compilation time. But it
> is generic problem with these %p* modifiers.

From my limited knowledge, it seems that there is no way to check
this :/

> 
> Otherwise the patch looks fine for the vsprinf side.

Thank you for looking at this!

> 
> Best Regards,
> Petr

-- 
Thanks,
Hyeonggon


  reply	other threads:[~2022-12-29 13:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-18 10:18 [RFC v3 0/4] move PG_slab flag to page_type Hyeonggon Yoo
2022-12-18 10:18 ` [RFC v3 1/4] mm/hwpoison: remove MF_MSG_SLAB from action_page_types Hyeonggon Yoo
2022-12-20 23:53   ` HORIGUCHI NAOYA(堀口 直也)
2022-12-21 17:00     ` Andy Shevchenko
2022-12-29 13:18       ` Hyeonggon Yoo
2022-12-29 13:17     ` Hyeonggon Yoo
2022-12-18 10:18 ` [RFC v3 2/4] mm: move PG_slab flag to page_type Hyeonggon Yoo
2023-01-12 16:27   ` Vlastimil Babka
2023-01-30  4:34     ` Hyeonggon Yoo
2023-01-30  5:11       ` Matthew Wilcox
2023-02-03 16:00         ` Hyeonggon Yoo
2023-02-03 16:19           ` Matthew Wilcox
2023-02-08 13:56             ` Hyeonggon Yoo
2023-02-03 16:04         ` David Hildenbrand
2023-02-08  9:44           ` Mike Rapoport
2023-02-08 10:13             ` David Hildenbrand
2022-12-18 10:19 ` [RFC v3 3/4] mm, printk: introduce new format %pGt for page_type Hyeonggon Yoo
2022-12-18 19:32   ` kernel test robot
2022-12-19  9:44   ` Andy Shevchenko
2022-12-19 19:35     ` Randy Dunlap
2022-12-20 10:58       ` Andy Shevchenko
2022-12-29 13:35         ` Hyeonggon Yoo
2022-12-20 15:20   ` Petr Mladek
2022-12-29 13:30     ` Hyeonggon Yoo [this message]
2022-12-18 10:19 ` [RFC v3 4/4] mm/debug: use %pGt to print page_type in dump_page() Hyeonggon Yoo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y62WkiG3dSWOKL1i@hyeyoo \
    --to=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=cl@linux.com \
    --cc=david@redhat.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=penberg@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.