xfs
[Top] [All Lists]

Re: TAKE 988255 - fix instant oops with tracing enabled

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: TAKE 988255 - fix instant oops with tracing enabled
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 14 Oct 2008 16:41:03 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <48F42F12.1010409@xxxxxxx>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, xfs@xxxxxxxxxxx
References: <20081014011747.AC14E58FA1E9@xxxxxxxxxxxxxxxxxxxxxxx> <20081014020556.GH10716@disturbed> <48F42F12.1010409@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Oct 14, 2008 at 03:33:06PM +1000, Lachlan McIlroy wrote:
> Dave Chinner wrote:
>> On Tue, Oct 14, 2008 at 12:17:47PM +1100, Lachlan McIlroy wrote:
>>> fix instant oops with tracing enabled
>>>
>>> We can only read inode->i_count if the inode is actually there and not
>>> a NULL pointer.  This was introduced in one of the recent sync patches.
>>>
>>> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>>
>> BTW, this now means that other pending patches won't apply cleanly....
>>
>
> Yeah this patch hunk didn't apply but was easy to hand merge.  It also
> didn't compile because of a missing comma from the 4th last line.  Can
> you please make sure each of your patch series compile on their own?

I do make sure every patch compiles given the config options a
mainline kernel allows. However, the CONFIG_XFS_TRACE option is not
present in mainline-derived kernels so it's not obvious when
problems occur inside code that isn't easily configurable on
such a kernel....

As it is, I haven't done a CONFIG_XFS_TRACE build for several months
because I've found that I haven't needed tracing to find problems
esoteric problems. Using watchpoints, breakpoints and single
stepping catches problems as they occur rather than needing tracing
to try to work out what went wrong after a problem has occurred.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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