From: Petr Mladek <pmladek@suse.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] Do not print page type when the page has no type
Date: Tue, 30 May 2023 09:35:59 +0200 [thread overview]
Message-ID: <ZHWnX6qdnSKGcpAr@alley> (raw)
In-Reply-To: <ZHTH0QwenlVnch8q@casper.infradead.org>
On Mon 2023-05-29 16:42:09, Matthew Wilcox wrote:
> On Mon, May 29, 2023 at 05:27:29PM +0200, Petr Mladek wrote:
> > On Sun 2023-05-28 17:01:59, Hyeonggon Yoo wrote:
> > > The code mostly looks fine and the patch makes sense to me.
> > > But I'm not sure if it's a nice behavior to print garbage when it does not
> > > have a page type, although I can hardly imagine users of this flag other
> > > than __dump_page(). I'd rather keep printk part unchanged and add
> > > page_has_type() check in __dump_page().
> >
> > I agree with Hyeonggon. The change in __dump_page() makes sense.
> > But vsprintf() should stay clever and do not print garbage.
>
> The caller (and, let's face it, there's only ever going to be one
> caller) shouldn't pass garbage in the first place.
By other words you say that vsprintf() might produce "garbage" when
the given value is invalid. And the check is not worth the complexity.
It might make sense.
Well, we should keep test of the invalid value in test_printf.c. And
it would need to be updated when a new page_type is added because
it would produce another garbage. From this POV, I would prefer to
keep the check in vsprintf.c.
All in all. It is about a compromise. I can't judge how much the extra
page_type_has_type() complicates mm code.
Best Regards,
Petr
prev parent reply other threads:[~2023-05-30 7:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-27 16:48 Matthew Wilcox
2023-05-28 8:01 ` Hyeonggon Yoo
2023-05-29 15:27 ` Petr Mladek
2023-05-29 15:42 ` Matthew Wilcox
2023-05-30 7:35 ` Petr Mladek [this message]
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=ZHWnX6qdnSKGcpAr@alley \
--to=pmladek@suse.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox