linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).