From: Ingo Molnar <mingo@elte.hu>
To: David Howells <dhowells@redhat.com>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/7] Add assertion support with annotated oopsing
Date: Wed, 12 Oct 2011 18:57:22 +0200 [thread overview]
Message-ID: <20111012165719.GA18407@elte.hu> (raw)
In-Reply-To: <20111012164717.539.44368.stgit@warthog.procyon.org.uk>
* David Howells <dhowells@redhat.com> wrote:
> Add the ability to create an annotated oops report. This is useful for
> displaying the output of assertion failures where direct display of the values
> being checked is of greater value than the register dump.
>
> This could technically be done simply by issuing one or more printk() calls
> followed by a BUG() but in practice this has a serious disadvantage in that
> people reporting a bug usually seem to take the "cut here" line literally and
> discard everything prior to it when making a report - thus eliminating the most
> important bit of information after the file/line number.
>
> There are number of possible solutions to this. I've used the last in this
> list:
>
> (1) Emit the "cut here" line early, suppressing the one produced by the BUG()
> handler. This would allow the annotation to be formed of multiple
> printk() calls.
>
> (2) Get rid of the "cut here" line entirely.
>
> (3) Pass the annotation through to the exception handler. For practical
> reasons, this limits the number of annotations to a single format string
> and parameters. This means that a va_list has to be passed through and
> thence to vprintk() - which should be okay. It also requires arch support
> to retrieve the annotation data.
>
>
> This facility can be made use of by #including <linux/assert.h> and then
> calling:
>
> void assertion_failed(const char *fmt, ...);
>
> This prints a report that looks like:
>
> ------------[ cut here ]------------
> ASSERTION FAILED at fs/dcache.c:863!
> invalid opcode: 0000 [#1] SMP
> ...
>
> if fmt is NULL and:
>
> ------------[ cut here ]------------
> ASSERTION FAILED at fs/dcache.c:863!
> Dentry 0xffff880032675ed8{i=242,n=Documents} still in use (1) [unmount of nfs 12:01]
> invalid opcode: 0000 [#1] SMP
> ...
>
> otherwise.
>
> For this to work the arch code must provide two things:
>
> #define arch_assertion_failed(struct assertion_failure *desc)
>
> to perform the oops and:
>
> #define arch_assertion_failure(struct pt_regs *regs)
>
> for report_bug() to find whether or not an assertion failure occurred and, if
> so, return a pointer to its description as passed to arch_assertion_failure().
>
> If arch_assertion_failed() is not defined, then the code will fall back to
> doing a printk() and a BUG().
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> arch/x86/include/asm/bug.h | 14 ++++++++++++++
> include/asm-generic/bug.h | 1 +
> include/linux/assert.h | 36 ++++++++++++++++++++++++++++++++++++
> kernel/panic.c | 31 +++++++++++++++++++++++++++++++
> lib/bug.c | 16 ++++++++++++++++
> 5 files changed, 98 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/assert.h
Looks useful, but i'd suggest to make this a variant of the standard
BUG_ON()/WARN_ON() checks we already have, not an explicit assert().
BUG_ON_VERBOSE() or such.
I find assert()'s inversion confusing when mixed with
WARN_ON()/BUG_ON().
Likewise, the message of:
ASSERTION FAILED at fs/dcache.c:863!
is rather confusing to me (i never know how the condition printed is
to be interpreted) - why not use the usual 'BUG: ...' message
convention?
Thanks,
Ingo
next prev parent reply other threads:[~2011-10-12 16:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-12 16:47 [PATCH 1/7] Add assertion support with annotated oopsing David Howells
2011-10-12 16:47 ` [PATCH 2/7] Add assertion checking macros David Howells
2011-10-12 16:47 ` David Howells
2011-10-12 17:43 ` Jiri Slaby
2011-10-12 20:36 ` David Howells
2011-10-12 16:47 ` [PATCH 3/7] Make shrink_dcache_for_umount_subtree() use the core assertion code David Howells
2011-10-12 16:47 ` David Howells
2011-10-12 16:47 ` [PATCH 4/7] FS-Cache: Use new core assertion macros David Howells
2011-10-12 16:47 ` David Howells
2011-10-12 16:47 ` [PATCH 5/7] CacheFiles: " David Howells
2011-10-12 16:47 ` David Howells
2011-10-12 16:48 ` [PATCH 6/7] AFS: " David Howells
2011-10-12 16:48 ` David Howells
2011-10-12 16:48 ` [PATCH 7/7] RxRPC: " David Howells
2011-10-12 16:48 ` David Howells
2011-10-12 16:57 ` Ingo Molnar [this message]
2011-10-12 16:57 ` [PATCH 1/7] Add assertion support with annotated oopsing Ingo Molnar
2011-10-12 17:23 ` David Howells
2011-10-12 17:23 ` David Howells
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=20111012165719.GA18407@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).