replace-bug-on-with-warn-on-in-mb_find_extent

   1 ext4: replace BUG_ON with WARN_ON in mb_find_extent()
   2
   3 The last BUG_ON in mb_find_extent() is apparently triggering in some
   4 rare cases.  Most of the time it indicates a bug in the buddy bitmap
   5 algorithms, but there are some weird cases where it can trigger when
   6 buddy bitmap is still in memory, but the block bitmap has to be read
   7 from disk, and there is disk or memory corruption such that the block
   8 bitmap and the buddy bitmap are out of sync.
   9
  10 Google-Bug-Id: #33702157
  11
  12 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
  13 ---
  14  fs/ext4/mballoc.c | 12 +++++++++++-
  15  1 file changed, 11 insertions(+), 1 deletion(-)
  16
  17 diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
  18 index 7ae43c59bc79..ec2f64b0e696 100644
  19 --- a/fs/ext4/mballoc.c
  20 +++ b/fs/ext4/mballoc.c
  21 @@ -1556,7 +1556,17 @@ static int mb_find_extent(struct ext4_buddy *e4b, int block,
  22                 ex->fe_len += 1 << order;
  23         }
  24
  25 -       BUG_ON(ex->fe_start + ex->fe_len > (1 << (e4b->bd_blkbits + 3)));
  26 +       if (ex->fe_start + ex->fe_len > (1 << (e4b->bd_blkbits + 3))) {
  27 +               /* Should never happen! (but apparently sometimes does?!?) */
  28 +               WARN_ON(1);
  29 +               ext4_error(e4b->bd_sb, "corruption or bug in mb_find_extent "
  30 +                          "block=%d, order=%d needed=%d ex=%u/%d/%d@%u",
  31 +                          block, order, needed, ex->fe_group, ex->fe_start,
  32 +                          ex->fe_len, ex->fe_logical);
  33 +               ex->fe_len = 0;
  34 +               ex->fe_start = 0;
  35 +               ex->fe_group = 0;
  36 +       }
  37         return ex->fe_len;
  38  }
  39