Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 22 Sep 2018 15:26:59 +1000
From:   Dave Chinner <dchinner@redhat.com>
To:     Ben Hutchings <ben@decadent.org.uk>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        akpm@linux-foundation.org, Christoph Hellwig <hch@lst.de>,
        Wen Xu <wen.xu@gatech.edu>,
        Carlos Maiolino <cmaiolino@redhat.com>,
        "Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH 3.16 52/63] xfs: validate cached inodes are free when
 allocated
Message-ID: <20180922052659.GC19103@rh>
References: <lsq.1537575341.194909669@decadent.org.uk>
 <lsq.1537575342.534061407@decadent.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <lsq.1537575342.534061407@decadent.org.uk>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Sep 22, 2018 at 01:15:42AM +0100, Ben Hutchings wrote:
> 3.16.58-rc1 review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Dave Chinner <dchinner@redhat.com>
> 
> commit afca6c5b2595fc44383919fba740c194b0b76aff upstream.
> 
> A recent fuzzed filesystem image cached random dcache corruption
> when the reproducer was run. This often showed up as panics in
> lookup_slow() on a null inode->i_ops pointer when doing pathwalks.
.....
> [bwh: Backported to 3.16:
>  - Look up mode in XFS inode, not VFS inode
>  - Use positive error codes, and EIO instead of EFSCORRUPTED]

Again, why EIO?

And ....
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
>  fs/xfs/xfs_icache.c | 73 +++++++++++++++++++++++++++++----------------
>  1 file changed, 48 insertions(+), 25 deletions(-)
> 
> --- a/fs/xfs/xfs_icache.c
> +++ b/fs/xfs/xfs_icache.c
> @@ -133,6 +133,46 @@ xfs_inode_free(
>  }
>  
>  /*
> + * If we are allocating a new inode, then check what was returned is
> + * actually a free, empty inode. If we are not allocating an inode,
> + * then check we didn't find a free inode.
> + *
> + * Returns:
> + *	0		if the inode free state matches the lookup context
> + *	ENOENT		if the inode is free and we are not allocating
> + *	EFSCORRUPTED	if there is any state mismatch at all

You changed the code but not the comment.

Cheers,

Dave.
-- 
Dave Chinner
dchinner@redhat.com