All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Willy Tarreau <w@1wt.eu>
Cc: linux@weissschuh.net, linux-kernel@vger.kernel.org,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH 0/1] tools/nolibc: tests: use volatile to force stack smashing
Date: Tue, 28 Mar 2023 13:01:27 -0700	[thread overview]
Message-ID: <eaff1b76-d420-47ac-8d84-89d01b3cab76@paulmck-laptop> (raw)
In-Reply-To: <ZCM3SF+CySRKhGNv@1wt.eu>

On Tue, Mar 28, 2023 at 08:51:52PM +0200, Willy Tarreau wrote:
> On Tue, Mar 28, 2023 at 11:29:53AM -0700, Paul E. McKenney wrote:
> > I have queued this for the v6.5 merge window, thank you!  If urgency
> > does develop in the next couple of days, please let me know, and I will
> > see what I can do about moving it to the v6.4 pile.
> 
> Thank you!
> 
> > I got this from "make run" (after merging with v6.3-rc3 as discussed
> > earlier):
> > 
> > 	make[1]: Leaving directory '/home/git/linux-build'
> > 	126 test(s) passed.
> > 
> > This differs from your results, so please see below for the run.out file.
> > (I see 126 instances of "[OK]".)
> 
> Oh you're right! I indeed found no FAIL so it was OK for me and I didn't
> pay attention but it's "just" a matter of message appearing on the console
> in the middle of the test:
> 
>   $ diff -u paul.out willy.out  |less
>   --- paul.out    2023-03-28 20:38:40.079920385 +0200
>   +++ willy.out   2023-03-28 20:39:04.534900530 +0200
>   @@ -130,11 +130,11 @@
>    Errors during this test: 0
>    
>    Running test 'protection'
>   -0 -fstackprotector                                               [OK]
>   +0 -fstackprotector [    2.696920] init (47) used greatest stack depth: 14536 bytes left
>   +                                              [OK]
>    Errors during this test: 0
> 
> We've had a few occurrences of garbaged outputs like this, so I think I
> should improve the test to count OK/FAIL/SKIPPED so that we can be more
> confident in the output when seeing 0 FAIL for example. I suspect that
> above it could be related to the long chain we've seen during the 6.3-rc1
> crash, that went down into the random code, because probably that this
> first-time initialization can enlarge the stack a little bit.
> 
> In my case, I just applied all the nolibc patches on top of 6.3-rc4 to
> run the test so our kernels are slightly different (since my branch
> based on rcu-03.20a did still originate from the 6.3-rc1 thus it was
> failing to boot like you faced previously).
> 
> Maybe I should also improve the grep to try to look for patterns looking
> exactly like this (test numer and name followed by a warning).

Good point!

> > But this from "make run-user":
> > 
> > 	  CC      nolibc-test
> > 	124 test(s) passed
> > 
> > The output of "grep -v "\[OK]" run.out" is as follows:
> > 
> > 	Running test 'syscall'
> > 	18 chroot_root                                                  [SKIPPED]
> > 	43 link_dir                                                     [SKIPPED]
> > 	Errors during this test: 0
> > 
> > 	Running test 'stdlib'
> > 	Errors during this test: 0
> > 
> > 	Running test 'protection'
> > 	Errors during this test: 0
> > 
> > 	Total number of errors: 0
> > 	Exiting with status 0
> > 
> > I am guessing is that this is because I am too cowardly to run this
> > test with root privileges, but thought I should run it by you.
> 
> Yes exactly, that's why I've added getuid() support lately, in order to
> skip these two tests when not root (because I cowardly refuse to run
> this test as root as well and don't want to get used to seeing "normal"
> failures).
> 
> Thus what you're seeing is OK overall. There's just this message that
> appears now on top of -rc4, I'll retry later on top of -rc3 (probably
> not before this week-end, I'm still having other stuff to do), but so
> far so good.

Thank you for looking this over!

							Thanx, Paul

      reply	other threads:[~2023-03-28 20:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 16:18 [PATCH 0/1] tools/nolibc: tests: use volatile to force stack smashing Willy Tarreau
2023-03-28 16:18 ` [PATCH 1/1] " Willy Tarreau
2023-03-28 18:29 ` [PATCH 0/1] " Paul E. McKenney
2023-03-28 18:51   ` Willy Tarreau
2023-03-28 20:01     ` Paul E. McKenney [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=eaff1b76-d420-47ac-8d84-89d01b3cab76@paulmck-laptop \
    --to=paulmck@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=w@1wt.eu \
    /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.