[Top] [All Lists]

Re: [PATCH] xfs: shutdown filesystem if xfs_perag_get fails

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH] xfs: shutdown filesystem if xfs_perag_get fails
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 22 Apr 2013 09:32:51 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <51753EDE.6000301@xxxxxxx>
References: <20130419204102.736961610@xxxxxxx> <20130421174107.007313126@xxxxxxx> <5174603A.8030208@xxxxxxxxxxx> <51753EDE.6000301@xxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
On 4/22/13 8:45 AM, Mark Tinguely wrote:
> On 04/21/13 16:55, Eric Sandeen wrote:
>> On 4/21/13 12:41 PM, Mark Tinguely wrote:
>>> This problem happened locally with a bad inode number from xfs
>>> recovery. xfs_perag_get() can return NULL if given a bad agno.
>>> Most callers of xfs_perag_get() do not check for a NULL before
>>> using the pointer. This patch forces a shutdown of the filesystem
>>> for those callers that do not check the return value rather than
>>> crashing on a dereferenced NULL pointer.
>> Hi Mark -
>> I'm curious, what was the callchain when this happened?  Was it
>> during recovery?  If so, would aborting recovery be more prudent?
>> I might be missing something, but I'm not sure how shutting
>> down avoids a subsequent null ptr deref&  crash.
>> i.e. if a caller does something like:
>>          pag = xfs_perag_get(mp, agno);
>>          spin_lock(&pag->pagb_lock);
>> shutting down in xfs_perag_get doesn't save us from a
>> null pag pointer, would it?
>> Thanks,
>> -Eric
> You are correct, we have to exit the routine(s) to avoid the dereference. Let 
> the callers handle the error.
> Sorry for the noise.

No problem, glad I'm useful on the rare occasion.  ;)

Can you share the backtrace on the null deref you saw?


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