Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: "Naresh Kamboju" <naresh.kamboju@linaro.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Anders Roxell" <anders.roxell@linaro.org>,
	"Daniel Díaz" <daniel.diaz@linaro.org>,
	"Justin Cook" <justin.cook@linaro.org>,
	lkft-triage@lists.linaro.org, "Miroslav Benes" <mbenes@suse.cz>,
	"Shuah Khan" <shuah@kernel.org>
Subject: Re: [PATCH 1/2] selftests/lkdtm: Don't clear dmesg when running tests
Date: Wed, 24 Jun 2020 10:39:55 +0200	[thread overview]
Message-ID: <20200624083955.GF8444@alley> (raw)
In-Reply-To: <c5b77970-ecaf-24ad-c34d-134acc1a6063@redhat.com>

On Tue 2020-06-23 23:48:36, Joe Lawrence wrote:
> On 6/22/20 4:51 AM, Naresh Kamboju wrote:
> > On Fri, 8 May 2020 at 12:23, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > > 
> > > It is Very Rude to clear dmesg in test scripts. That's because the
> > > script may be part of a larger test run, and clearing dmesg
> > > potentially destroys the output of other tests.
> > > 
> > > We can avoid using dmesg -c by saving the content of dmesg before the
> > > test, and then using diff to compare that to the dmesg afterward,
> > > producing a log with just the added lines.
> > >
> > > > > > diff --git a/tools/testing/selftests/lkdtm/run.sh b/tools/testing/selftests/lkdtm/run.sh
> > > index dadf819148a4..0b409e187c7b 100755
> > > --- a/tools/testing/selftests/lkdtm/run.sh
> > > +++ b/tools/testing/selftests/lkdtm/run.sh
> > >   # Record and dump the results
> > > -dmesg -c >"$LOG"
> > > +dmesg | diff --changed-group-format='%>' --unchanged-group-format='' "$DMESG" - > "$LOG" || true
> > 
> > We are facing problems with the diff `=%>` part of the option.
> > This report is from the OpenEmbedded environment.
> > We have the same problem from livepatch_testcases.
> > 
> > # selftests lkdtm BUG.sh
> > lkdtm: BUG.sh_ #
> > # diff unrecognized option '--changed-group-format=%>'
> > unrecognized: option_'--changed-group-format=%>' #
> > # BusyBox v1.27.2 (2020-03-30 164108 UTC) multi-call binary.
> > v1.27.2: (2020-03-30_164108 #
> > #
> > : _ #
> > # Usage diff [-abBdiNqrTstw] [-L LABEL] [-S FILE] [-U LINES] FILE1 FILE2
> > diff: [-abBdiNqrTstw]_[-L #
> > # BUG missing 'kernel BUG at' [FAIL]
> > 
> > Full test output log,
> > https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20200621/testrun/2850083/suite/kselftest/test/lkdtm_BUG.sh/log
> > 
> 
> D'oh!  Using diff's changed/unchanged group format was a nice trick to
> easily fetch the new kernel log messages.
> 
> I can't think of any simple alternative off the top of my head, so here's a
> kludgy tested-once awk script:
> 
>  SAVED_DMESG="$(dmesg | tail -n1)"
>  ... tests ...
>  NEW_DMESG=$(dmesg | awk -v last="$SAVED_DMESG" 'p; $0 == last{p=1}')
> 
> I think timestamps should make each log line unique, but this probably won't
> handle kernel log buffer overflow.

The test would fail anyway if there was log buffer overflow.

We could check if the last line was still there and
suggest to increase the log buffer size in the error message.

> Maybe it would be easier to log a known unique test delimiter msg and then
> fetch all new messages after that?

The timestamp should be enough to distinguish any message.

But some visual separator between each test is useful anyway. And
it might include some random string...

Best Regards,
Petr

  reply	other threads:[~2020-06-24  8:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08  6:53 [PATCH 1/2] selftests/lkdtm: Don't clear dmesg when running tests Michael Ellerman
2020-05-08  6:53 ` [PATCH 2/2] selftests/lkdtm: Use grep -E instead of egrep Michael Ellerman
2020-05-08  7:30   ` Kees Cook
2020-05-08  7:30 ` [PATCH 1/2] selftests/lkdtm: Don't clear dmesg when running tests Kees Cook
2020-06-22  8:51 ` Naresh Kamboju
2020-06-24  3:48   ` Joe Lawrence
2020-06-24  8:39     ` Petr Mladek [this message]
2020-06-24 20:12       ` Joe Lawrence
2020-06-26  8:02         ` Petr Mladek
2020-06-26 13:38           ` Joe Lawrence
2020-06-26 15:51             ` Naresh Kamboju
2020-06-25  6:16   ` Kees Cook
2020-06-26 15:50     ` Naresh Kamboju

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=20200624083955.GF8444@alley \
    --to=pmladek@suse.com \
    --cc=anders.roxell@linaro.org \
    --cc=daniel.diaz@linaro.org \
    --cc=joe.lawrence@redhat.com \
    --cc=justin.cook@linaro.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=mbenes@suse.cz \
    --cc=mpe@ellerman.id.au \
    --cc=naresh.kamboju@linaro.org \
    --cc=shuah@kernel.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