XFS internal error when NFS client accesses nonexistent inode

[Christoph Hellwig]

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) ==
			    XFS_DINODE_GOOD_VERSION(dip->di_core.di_version);
		if (unlikely(XFS_TEST_ERROR(!di_ok, mp,
						XFS_ERRTAG_ITOBP_INOTOBP,
						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.