From: Matthew Wilcox <willy@infradead.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] vsprintf: Make %pGp print the hex value
Date: Tue, 12 Oct 2021 17:11:19 +0100 [thread overview]
Message-ID: <YWWzp4H8X+Tzgtth@casper.infradead.org> (raw)
In-Reply-To: <2b8bd086-f0cc-80ff-b36a-83b49c523482@rasmusvillemoes.dk>
On Tue, Oct 12, 2021 at 01:57:09PM +0200, Rasmus Villemoes wrote:
> On 12/10/2021 13.32, Matthew Wilcox wrote:
> > On Tue, Oct 12, 2021 at 11:55:50AM +0200, Rasmus Villemoes wrote:
> >> ...default_flag_spec has '.flags = SPECIAL | SMALL,', i.e. what one
> >> would get from %#x . I'm guessing that's what upsets 0-day.
> >>
> >> Geez it would be nice if 0day actually reported the "Expected foo, but
> >> bar was emitted to the buffer".
> >
> > It's there; you just have to dive into the dmesg.xz to get it:
> >
> > [ 48.607787][ T1214] test_printf: vsnprintf(buf, 256, "%pGp", ...) returned 33, expected 29
> > [ 48.616106][ T1214] test_printf: vsnprintf(buf, 18, "%pGp", ...) returned 33, expected 29
> > [ 48.624292][ T1214] test_printf: vsnprintf(buf, 0, "%pGp", ...) returned 33, expected 29
> > [ 48.632403][ T1214] test_printf: kvasprintf(..., "%pGp", ...) returned '0x0(node=0|zone=0|lastcpupid=0x0)', expected 'node=0|zone=0|lastcpupid=0x0)'
> > [ 48.645741][ T1214] test_printf: vsnprintf(buf, 256, "%pGp", ...) returned 33, expected 29
> > [ 48.654023][ T1214] test_printf: vsnprintf(buf, 23, "%pGp", ...) returned 33, expected 29
> > [ 48.662218][ T1214] test_printf: vsnprintf(buf, 0, "%pGp", ...) returned 33, expected 29
> > [ 48.670327][ T1214] test_printf: kvasprintf(..., "%pGp", ...) returned '0x0(node=0|zone=0|lastcpupid=0x0)', expected 'node=0|zone=0|lastcpupid=0x0)'
> > [ 48.683670][ T1214] test_printf: vsnprintf(buf, 256, "%pGp", ...) returned 88, expected 71
> > [ 48.691937][ T1214] test_printf: vsnprintf(buf, 64, "%pGp", ...) returned 88, expected 71
> > [ 48.700128][ T1214] test_printf: vsnprintf(buf, 0, "%pGp", ...) returned 88, expected 71
> > [ 48.708249][ T1214] test_printf: kvasprintf(..., "%pGp", ...) returned '0x4fffffc008003c(uptodate|dirty|lru|active|swapbacked|node=1|zone=1|lastcpupid=0x1fffff)', expected 'uptodate|dirty|lru|active|swapbacked|node=1|zone=1|lastcpupid=0x1fffff)'
> > [ 48.730275][ T1214] test_printf: failed 12 out of 420 tests
> >
> > So you're right, it's missing the 0x,
>
> Ah, it's actually missing the whole '0xfoo(' because you're not updating
> 'size' after the first
>
> + snprintf(cmp_buf + size, BUF_SIZE - size, "%x(", flags);
>
> so the next write to cmp_buf overwrites whatever you wrote here.
>
> > but I still don't know how to run this self-test.
>
> Neither do I, when I created test_printf.c I made sure it ran on boot if
> built-in, and that's certainly how I've been testing vsprintf.c patches
> in the past. Maybe the kstm crowd can explain how to get that to work as
> expected.
Got it. It was running; just wasn't being captured by the kernel
messages output on my test system. If I ssh in to the test system and
examine dmesg, it's there.
Now, this isn't quite enough;
- snprintf(cmp_buf + size, BUF_SIZE - size, "%x(", flags);
+ snprintf(cmp_buf + size, BUF_SIZE - size, "%#x(", flags);
+ size = strlen(cmp_buf);
The problem is that the test suite doesn't pass in a full flags.
It passes in some pageflags and then ORs in the zone, nid, etc
after printing some of the flags. So I had to restructure the
test a bit to print the full hex number. What do you think?
+++ b/lib/test_printf.c
@@ -610,11 +610,15 @@ page_flags_test(int section, int node, int zone, int last_cpupid,
{
unsigned long values[] = {section, node, zone, last_cpupid, kasan_tag};
unsigned long page_flags = 0;
+ unsigned long test_flags = flags & PAGEFLAGS_MASK;
unsigned long size = 0;
bool append = false;
int i;
- snprintf(cmp_buf + size, BUF_SIZE - size, "%x(", flags);
+ for (i = 0; i < ARRAY_SIZE(values); i++)
+ test_flags |= (values[i] & pft[i].mask) << pft[i].shift;
+ snprintf(cmp_buf + size, BUF_SIZE - size, "%#lx(", test_flags);
+ size = strlen(cmp_buf);
flags &= PAGEFLAGS_MASK;
if (flags) {
page_flags |= flags;
It's a bit duplicative of what's below, and I'm far from sure about the
testing of bits that fall outside PAGEFLAGS_MASK. It doesn't feel like a
great test in that it's not testing how pGp would get used. Maybe that
points to a small defect in pGp -- shouldn't it print something for
unknown bits being set?
prev parent reply other threads:[~2021-10-12 16:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 19:38 Matthew Wilcox (Oracle)
2021-10-12 8:46 ` [vsprintf] 97265529aa: kernel-selftests.lib.printf.sh.fail kernel test robot
2021-10-12 9:55 ` [PATCH] vsprintf: Make %pGp print the hex value Rasmus Villemoes
2021-10-12 11:11 ` Matthew Wilcox
2021-10-12 11:32 ` Matthew Wilcox
2021-10-12 11:57 ` Rasmus Villemoes
2021-10-12 16:11 ` Matthew Wilcox [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=YWWzp4H8X+Tzgtth@casper.infradead.org \
--to=willy@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=vbabka@suse.cz \
/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