[Top] [All Lists]

Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_a

To: Timothy Shimmin <tes@xxxxxxx>
Subject: Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_alias
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 12:53:01 +1100
Cc: Christoph Hellwig <hch@xxxxxx>, Miklos Szeredi <miklos@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <48F7D814.2080705@xxxxxxx>
Mail-followup-to: Timothy Shimmin <tes@xxxxxxx>, Christoph Hellwig <hch@xxxxxx>, Miklos Szeredi <miklos@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <20081015192839.GA867@xxxxxx> <E1KqWzC-00087u-TG@xxxxxxxxxxxxxxxxxxx> <20081016180947.GA26285@xxxxxx> <48F7D814.2080705@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
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

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


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>