[Top] [All Lists]

Re: XFS internal error when NFS client accesses nonexistent inode

To: Mario Becroft <mb@xxxxxxxxxxxxx>
Subject: Re: XFS internal error when NFS client accesses nonexistent inode
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 1 Jan 2009 12:14:09 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <87zlicfncr.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <87zlicfncr.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Jan 01, 2009 at 03:09:08AM +1300, Mario Becroft wrote:
> I hit a seemingly strange problem today when I xfsdump/restored some
> filesystems from one volume onto another. When I exported the new
> volumes, errors like the following started to occur:
> Dec 31 09:12:46 nfs1 kernel: nfsd: non-standard errno: -117
> Bumping up the XFS debug level revealed the following (full details at
> the end):
> Dec 31 09:12:46 nfs1 kernel: Filesystem "dm-17": XFS internal error 
> xfs_imap_to_bp at line 186 of file fs/xfs/xfs_inode.c.  Caller 
> 0xffffffff80374c48

This is:

                di_ok = be16_to_cpu(dip->di_core.di_magic) ==
                if (unlikely(XFS_TEST_ERROR(!di_ok, mp,
                                                XFS_RANDOM_ITOBP_INOTOBP))) {
                        if (imap_flags & XFS_IMAP_BULKSTAT) {
                                xfs_trans_brelse(tp, bp);
                                return XFS_ERROR(EINVAL);
 here -->               XFS_CORRUPTION_ERROR("xfs_imap_to_bp",
                                                XFS_ERRLEVEL_HIGH, mp, dip);

> After wasting quite a lot of time, I finally realised that this was
> probably caused by NFS clients accessing nonexistent file handles that
> they had open from when the filesystem was previously exported, prior to
> the dump/restore.
> Is my analysis correct? Is an internal error the expected behaviour in
> this case? And can this cause any harm?

That explanation makes a lot of sense.  As seen in the snipplet above
we actually have checks for bulkstat which might hand in invalid inode
numbers, and I think we need to extent this check to nfs export and
the handle ioctls, too as we can get arbitrary inode numbers passed
from a client / user space.  In addition we should probably translate
the error number into something more useful.

I will create a testcase using the handle ioctls for this and provide
a fix to handle this issue more gracefully.

Except for shutting down a perfectly fine filesystem this should
not cause additional damage.

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