All of lore.kernel.org
 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: 11+ 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 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 ` [PATCH 4/7] FS-Cache: Use new core assertion macros David Howells
2011-10-12 16:47 ` [PATCH 5/7] CacheFiles: " David Howells
2011-10-12 16:48 ` [PATCH 6/7] AFS: " David Howells
2011-10-12 16:48 ` [PATCH 7/7] RxRPC: " David Howells
2011-10-12 16:57 ` Ingo Molnar [this message]
2011-10-12 17:23   ` [PATCH 1/7] Add assertion support with annotated oopsing 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 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.