xfs: bmap debugging should never panic the system

Source kernel commit: cec572561a748396c783c1ea91a289816d3c4f18

Don't panic() the system if the bmap records are garbage, just call
ASSERT which gives us the same backtrace but enables developers to
control if the system goes down or not.  This makes debugging with
generic/388 much easier because it won't reboot the machine midway
through a run just because btree_read_bufl returns EIO when the fs has
already shut down.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>

diff --git a/libxfs/xfs_bmap.c b/libxfs/xfs_bmap.c
index 5b4f8c24599ebb584b1697c6d596a5152f7a2515..b1a4e0b46122307e3d8934a50db70b22ce52960f 100644 (file)
--- a/libxfs/xfs_bmap.c
+++ b/libxfs/xfs_bmap.c
@@ -303,8 +303,9 @@ xfs_check_block(
                                xfs_warn(mp, "%s: thispa(%d) == pp(%d) %Ld",
                                        __func__, j, i,
                                        (unsigned long long)be64_to_cpu(*thispa));
-                               panic("%s: ptrs are equal in node\n",
+                               xfs_err(mp, "%s: ptrs are equal in node\n",
                                        __func__);
+                               xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
                        }
                }
        }
@@ -474,7 +475,8 @@ error0:
 error_norelse:
        xfs_warn(mp, "%s: BAD after btree leaves for %d extents",
                __func__, i);
-       panic("%s: CORRUPTED BTREE OR SOMETHING", __func__);
+       xfs_err(mp, "%s: CORRUPTED BTREE OR SOMETHING", __func__);
+       xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
        return;
 }