xfs
[Top] [All Lists]

Re: [PATCH] xfs: lobotomise xfs_trans_read_buf_map()

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: lobotomise xfs_trans_read_buf_map()
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Wed, 03 Dec 2014 08:09:50 -0600
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20141203105122.GA3727@xxxxxxxxxxxxx>
References: <1417473290-17544-1-git-send-email-david@xxxxxxxxxxxxx> <20141202165930.GA28571@xxxxxxxxxxxxx> <20141202224518.GG18131@dastard> <20141203105122.GA3727@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 12/03/14 04:51, Christoph Hellwig wrote:
On Wed, Dec 03, 2014 at 09:45:18AM +1100, Dave Chinner wrote:
Can you fix the inconsistent return for the trylock case in a follow on
patch?  This difference doesn't look intentional to me, and I would
be surprised if it's correctly handled in the callers.

Ok, I'll do an audit and make this common in a follow up patch. Just
to confirm:

                if (!(flags & XBF_TRYLOCK))
                        return -ENOMEM;
                return -EAGAIN;

is what you want to see, right?

Yes.

Even ENOMEM / EAGAIN could be wrong if _xfs_buf_find() was given an illegal block number - then it would be EFSCORRUPT.

I think we need to push the error message from _xfs_buf_find(). I played with it once and seemed to have lost it and can do it again if no one else has the time.

--Mark.

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