From: Eric Sandeen <sandeen@sandeen.net>
To: Timothy Shimmin <tes@sgi.com>, 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: Thu, 16 Oct 2008 22:04:58 -0500 [thread overview]
Message-ID: <48F800DA.1030002@sandeen.net> (raw)
In-Reply-To: <20081017015301.GK25906@disturbed>
Dave Chinner wrote:
> 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.
bleah :)
Could these just be turned into tracepoints eventually? Or maybe for
now allow modifying the array via proc or something... would be easier
to ask a user to do that if you don't have direct access to their kdb
console ;) It is a handy thing to have, though.
-Eric
next prev parent reply other threads:[~2008-10-17 3:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-15 19:28 [PATCH] prevent NULL returns from d_obtain_alias Christoph Hellwig
2008-10-16 17:50 ` Miklos Szeredi
2008-10-16 18:09 ` Christoph Hellwig
2008-10-17 0:11 ` XFS_ERROR use - was " Timothy Shimmin
2008-10-17 1:53 ` Dave Chinner
2008-10-17 3:04 ` Eric Sandeen [this message]
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=48F800DA.1030002@sandeen.net \
--to=sandeen@sandeen.net \
--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 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.