From: Dave Chinner <david@fromorbit.com>
To: Timothy Shimmin <tes@sgi.com>
Cc: Christoph Hellwig <hch@lst.de>,
Miklos Szeredi <miklos@szeredi.hu>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_alias
Date: Fri, 17 Oct 2008 12:53:01 +1100 [thread overview]
Message-ID: <20081017015301.GK25906@disturbed> (raw)
In-Reply-To: <48F7D814.2080705@sgi.com>
On Fri, Oct 17, 2008 at 11:11:00AM +1100, Timothy Shimmin wrote:
> Fair enough.
> But XFS_ERROR is used throughout the function.
> I've found the whole idea of when and when not to use XFS_ERROR annoying :)
>
> I've never used it (other than calling it to stay consistent with the code).
> Looking at the code, it is used to BUG and print a msg on particular error codes set in xfs_etrap[] -
> and it does this in xfs_error_trap().
> Can one not decide to do this at any error point?
> I can't see where we hook in to set up xfs_etrap.
You break into the debugger, modify the xfs_etrap array to contain
the set of errors you want to catch, then continue onwards. I've
used this several times in the past couple of months to locate the
source of strange ENOSPC errors...
The conceptual idea is that every point where an error is first
detected gets wrapped with XFS_ERROR() so you don't need to sprinkle
printk's all through the code to find where the error is coming
from.
ISTR the Irix kernel debugger had a command to set the values
in the etrap array - if it did it never got ported to kdb....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2008-10-17 1:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081015192839.GA867@lst.de>
[not found] ` <E1KqWzC-00087u-TG@pomaz-ex.szeredi.hu>
[not found] ` <20081016180947.GA26285@lst.de>
2008-10-17 0:11 ` XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_alias Timothy Shimmin
2008-10-17 1:53 ` Dave Chinner [this message]
2008-10-17 3:04 ` Eric Sandeen
2008-10-17 17:10 ` Christoph Hellwig
2008-10-20 0:49 ` Timothy Shimmin
2008-10-20 9:23 ` Christoph Hellwig
2008-10-20 23:16 ` Timothy Shimmin
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=20081017015301.GK25906@disturbed \
--to=david@fromorbit.com \
--cc=hch@lst.de \
--cc=miklos@szeredi.hu \
--cc=tes@sgi.com \
--cc=xfs@oss.sgi.com \
/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