From: Ralph Campbell <rcampbell@nvidia.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/debug:
Date: Mon, 11 Nov 2019 15:41:37 -0800 [thread overview]
Message-ID: <ccbaea6c-40a0-36a1-6dd9-9ab9d24dd904@nvidia.com> (raw)
In-Reply-To: <20191111150211.9f75292d8c057769603edfb7@linux-foundation.org>
On 11/11/19 3:02 PM, Andrew Morton wrote:
> On Mon, 11 Nov 2019 14:49:35 -0800 Ralph Campbell <rcampbell@nvidia.com> wrote:
>
>> When dumping struct page information, __dump_page() prints the page type
>> with a trailing blank followed by the page flags on a separate line:
>>
>> anon
>> flags: 0x100000000090034(uptodate|lru|active|head|swapbacked)
>>
>> Fix this by using pr_cont() instead of pr_warn() to get a single line:
>>
>> anon flags: 0x100000000090034(uptodate|lru|active|head|swapbacked)
>>
>> Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
>> ---
>> mm/debug.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 8345bb6e4769..752c78721ea0 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -87,7 +87,7 @@ void __dump_page(struct page *page, const char *reason)
>> }
>> BUILD_BUG_ON(ARRAY_SIZE(pageflag_names) != __NR_PAGEFLAGS + 1);
>>
>> - pr_warn("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>> + pr_cont("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>>
>> hex_only:
>> print_hex_dump(KERN_WARNING, "raw: ", DUMP_PREFIX_NONE, 32,
>
> This is the case if PageAnon || PageKsm || mapping. If it is, say,
> PageSlab then we effectively do
>
> pr_warn("stuff-with-no-newline");
> pr_cont("\n");
> pr_cont("flags: ...\n");
>
> does this work OK? what facility level will that "flags: " line get?
I don't see a "\n" in the "mapping" case but the
if (mapping->host && mapping->host->i_dentry.first)
pr_warn("name:\"%pd\" ", dentry)
would end up on a new line.
Ugh. I guess the dentry name could be fairly long.
I guess I will just convert to using "\n".
AFAIK, there is no locking between pr_warn() and pr_cont() so the latter
could get appended to any facility level. But that isn't a problem I
plan to fix.
prev parent reply other threads:[~2019-11-11 23:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 22:49 Ralph Campbell
2019-11-11 23:02 ` Andrew Morton
2019-11-11 23:41 ` Ralph Campbell [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=ccbaea6c-40a0-36a1-6dd9-9ab9d24dd904@nvidia.com \
--to=rcampbell@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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