From: Mark Wielaard <mjw@redhat.com>
To: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Cc: systemtap@sourceware.org
Subject: Re: RFC: improve build-id mismatch error reporting
Date: Tue, 13 Sep 2011 08:38:00 -0000 [thread overview]
Message-ID: <1315903072.3691.3.camel@springer.wildebeest.org> (raw)
In-Reply-To: <84sjo0ri69.fsf@sauna.l.org>
Hi Timo,
On Tue, 2011-09-13 at 10:54 +0300, Timo Juhani Lindfors wrote:
> Fortunately utsname()->version is available to us. It does not have the
> version number but instead the build date but now that I think of it
> this might be even better: people might recompile their custom kernels
> and forget to update the version number. I came up with
>
> --- a/translate.cxx
> +++ b/translate.cxx
> @@ -1210,6 +1210,7 @@
> // just in case modversions didn't.
> o->newline() << "{";
> o->newline(1) << "const char* release = UTS_RELEASE;";
> + o->newline() << "const char* version = UTS_VERSION;";
>
> // NB: This UTS_RELEASE compile-time macro directly checks only that
> // the compile-time kbuild tree matches the compile-time debuginfo/etc.
> @@ -1230,6 +1231,12 @@
> o->newline() << "rc = -EINVAL;";
> o->newline(-1) << "}";
>
> + o->newline() << "if (strcmp (utsname()->version, version)) {";
> + o->newline(1) << "_stp_error (\"module version mismatch (%s vs %s)\", "
> + << "version, utsname()->version);";
> + o->newline() << "rc = -EINVAL;";
> + o->newline(-1) << "}";
> +
> // perform buildid-based checking if able
> o->newline() << "if (_stp_module_check()) rc = -EINVAL;";
>
> @@ -5878,6 +5885,7 @@
> s.op->newline() << "#include <linux/utsname.h>";
> s.op->newline() << "#include <linux/version.h>";
> // s.op->newline() << "#include <linux/compile.h>";
> + s.op->newline() << "#include <generated/compile.h>";
> s.op->newline() << "#include \"loc2c-runtime.h\" ";
> s.op->newline() << "#include \"access_process_vm.h\" ";
>
> which gives output line
>
> ERROR: module version mismatch (#1 SMP Sat Aug 27 16:21:11 UTC 2012 vs #1 SMP Sat Aug 27 16:21:11 UTC 2011)
>
> What do you think?
I like the idea!
We should also include release/UTS_RELEASE in the output, it isn't the
package version, but at least gives a hint of the kernel version
involved.
Only issue is that as the patch already implies, in the past this header
was under include/linux/compile.h instead of
include/generated/compile.h. We might need a runtime/autoconf check for
that.
Thanks,
Mark
next prev parent reply other threads:[~2011-09-13 8:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 7:54 Timo Juhani Lindfors
2011-09-13 8:38 ` Mark Wielaard [this message]
2011-09-20 11:30 ` Timo Juhani Lindfors
2011-09-20 12:52 ` Frank Ch. Eigler
2011-09-21 9:17 ` Timo Juhani Lindfors
2011-09-21 9:19 ` [PATCH] Tell the user if UTS_VERSION does not match running kernel Timo Juhani Lindfors
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=1315903072.3691.3.camel@springer.wildebeest.org \
--to=mjw@redhat.com \
--cc=systemtap@sourceware.org \
--cc=timo.lindfors@iki.fi \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).