Skip to content
Snippets Groups Projects
  1. May 30, 2019
  2. May 25, 2019
  3. May 24, 2019
  4. May 22, 2019
    • Theodore Ts'o's avatar
      ext4: don't perform block validity checks on the journal inode · 0a944e8a
      Theodore Ts'o authored
      
      Since the journal inode is already checked when we added it to the
      block validity's system zone, if we check it again, we'll just trigger
      a failure.
      
      This was causing failures like this:
      
      [   53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode
      #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0)
      [   53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8
      [   53.938480] Aborting journal on device sda-8.
      
      ... but only if the system was under enough memory pressure that
      logical->physical mapping for the journal inode gets pushed out of the
      extent cache.  (This is why it wasn't noticed earlier.)
      
      Fixes: 345c0dbf ("ext4: protect journal inode's blocks using block_validity")
      Reported-by: default avatarDan Rue <dan.rue@linaro.org>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Tested-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      0a944e8a
    • Andreas Gruenbacher's avatar
      gfs2: Fix sign extension bug in gfs2_update_stats · 5a5ec83d
      Andreas Gruenbacher authored
      
      Commit 4d207133 changed the types of the statistic values in struct
      gfs2_lkstats from s64 to u64.  Because of that, what should be a signed
      value in gfs2_update_stats turned into an unsigned value.  When shifted
      right, we end up with a large positive value instead of a small negative
      value, which results in an incorrect variance estimate.
      
      Fixes: 4d207133 ("gfs2: Make statistics unsigned, suitable for use with do_div()")
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Cc: stable@vger.kernel.org # v4.4+
      5a5ec83d
  5. May 21, 2019
  6. May 20, 2019
    • Darrick J. Wong's avatar
      xfs: don't reserve per-AG space for an internal log · 5cd213b0
      Darrick J. Wong authored
      
      It turns out that the log can consume nearly all the space in an AG, and
      when this happens this it's possible that there will be less free space
      in the AG than the reservation would try to hide.  On a debug kernel
      this can trigger an ASSERT in xfs/250:
      
      XFS: Assertion failed: xfs_perag_resv(pag, XFS_AG_RESV_METADATA)->ar_reserved + xfs_perag_resv(pag, XFS_AG_RESV_RMAPBT)->ar_reserved <= pag->pagf_freeblks + pag->pagf_flcount, file: fs/xfs/libxfs/xfs_ag_resv.c, line: 319
      
      The log is permanently allocated, so we know we're never going to have
      to expand the btrees to hold any records associated with the log space.
      We therefore can treat the space as if it doesn't exist.
      
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarEric Sandeen <sandeen@redhat.com>
      5cd213b0
  7. May 18, 2019
  8. May 17, 2019
  9. May 16, 2019
Loading