From: Russell King <rmk+lkml@arm.linux.org.uk>
To: monstr@monstr.eu
Cc: linux-kernel@vger.kernel.org, michal.simek@petalogix.com,
arnd@arndb.de, linux-arch@vger.kernel.org,
fujita.tomonori@lab.ntt.co.jp, akpm@linux-foundation.org,
mingo@elte.hu, joerg.roedel@amd.com
Subject: Re: Generic DMA - BUG_ON
Date: Wed, 20 Jan 2010 10:53:50 +0000 [thread overview]
Message-ID: <20100120105350.GA23394@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1263982111-24123-1-git-send-email-monstr@monstr.eu>
On Wed, Jan 20, 2010 at 11:08:30AM +0100, monstr@monstr.eu wrote:
> Hi All,
>
> I have this patch in my repo. I just added BUG_ON for dma ops.
> The reason for that is if driver not setup ops correctly than
> the system do bad access to any memory space without any visible reason.
> BUG_ON points to it and helps to solve where the problem is.
I have a question of principle to raise here.
If you have code which does:
if (ops->foo)
ops->foo();
and ops is NULL, then this code will oops; you will get a full register
dump and backtrace. You can use this information along with markup_oops.pl
to find out where the problem is.
If you add a BUG_ON() to this, the only additional information you end
up with is (possibly) a nice friendly message which tells you the file
and line number - but you add additional run-time tests to the code.
The question is: is this worth it? Is there some problem with the
original oops that makes the problem hard to find? Should we be using
BUG_ON() to augment normal oopses in this way?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2010-01-20 10:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 10:08 Generic DMA - BUG_ON monstr
2010-01-20 10:08 ` [PATCH] asm-generic: dma: Add BUG_ON for uninitialized dma_ops monstr
2010-01-20 10:48 ` Alexey Dobriyan
2010-01-20 11:00 ` Geert Uytterhoeven
2010-01-20 10:56 ` Joerg Roedel
2010-01-22 1:11 ` FUJITA Tomonori
2010-01-20 10:53 ` Russell King [this message]
2010-01-20 11:00 ` Generic DMA - BUG_ON Joerg Roedel
2010-01-20 11:18 ` Michal Simek
2010-01-20 19:03 ` Arnd Bergmann
2010-01-21 15:51 ` Steven J. Magnani
2010-01-21 17:53 ` Russell King
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=20100120105350.GA23394@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=joerg.roedel@amd.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@petalogix.com \
--cc=mingo@elte.hu \
--cc=monstr@monstr.eu \
/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.