An error occurred fetching the project authors.
  1. 08 Jan, 2021 1 commit
  2. 07 Jan, 2021 1 commit
    • Satya Tangirala's avatar
      fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb · 04a6a536
      Satya Tangirala authored
      freeze/thaw_bdev() currently use bdev->bd_fsfreeze_count to infer
      whether or not bdev->bd_fsfreeze_sb is valid (it's valid iff
      bd_fsfreeze_count is non-zero). thaw_bdev() doesn't nullify
      bd_fsfreeze_sb.
      
      But this means a freeze_bdev() call followed by a thaw_bdev() call can
      leave bd_fsfreeze_sb with a non-null value, while bd_fsfreeze_count is
      zero. If freeze_bdev() is called again, and this time
      get_active_super() returns NULL (e.g. because the FS is unmounted),
      we'll end up with bd_fsfreeze_count > 0, but bd_fsfreeze_sb is
      *untouched* - it stays the same (now garbage) value. A subsequent
      thaw_bdev() will decide that the bd_fsfreeze_sb value is legitimate
      (since bd_fsfreeze_count > 0), and attempt to use it.
      
      Fix this by always setting bd_fsfreeze_sb to NULL when
      bd_fsfreeze_count is successfully decremented to 0 in thaw_sb().
      Alternatively, we could set bd_fsfreeze_sb to whatever
      get_active_super() returns in freeze_bdev() whenever bd_fsfreeze_count
      is successfully incremented to 1 from 0 (which can be achieved cleanly
      by moving the line currently setting bd_fsfreeze_sb to immediately
      after the "sync:" label, but it might be a little too subtle/easily
      overlooked in future).
      
      This fixes the currently panicking xfstests generic/085.
      
      Fixes: 040f04bd ("fs: simplify freeze_bdev/thaw_bdev")
      Signed-off-by: default avatarSatya Tangirala <satyat@google.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      04a6a536
  3. 29 Dec, 2020 1 commit
  4. 22 Dec, 2020 2 commits
  5. 01 Dec, 2020 20 commits
  6. 16 Nov, 2020 2 commits
  7. 05 Oct, 2020 1 commit
  8. 23 Sep, 2020 3 commits
  9. 10 Sep, 2020 2 commits
  10. 08 Sep, 2020 1 commit
    • Jan Kara's avatar
      block: Do not discard buffers under a mounted filesystem · 384d87ef
      Jan Kara authored
      Discarding blocks and buffers under a mounted filesystem is hardly
      anything admin wants to do. Usually it will confuse the filesystem and
      sometimes the loss of buffer_head state (including b_private field) can
      even cause crashes like:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      PGD 0 P4D 0
      Oops: 0002 [#1] SMP PTI
      CPU: 4 PID: 203778 Comm: jbd2/dm-3-8 Kdump: loaded Tainted: G O     --------- -  - 4.18.0-147.5.0.5.h126.eulerosv2r9.x86_64 #1
      Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 1.57 08/11/2015
      RIP: 0010:jbd2_journal_grab_journal_head+0x1b/0x40 [jbd2]
      ...
      Call Trace:
       __jbd2_journal_insert_checkpoint+0x23/0x70 [jbd2]
       jbd2_journal_commit_transaction+0x155f/0x1b60 [jbd2]
       kjournald2+0xbd/0x270 [jbd2]
      
      So if we don't have block device open with O_EXCL already, claim the
      block device while we truncate buffer cache. This makes sure any
      exclusive block device user (such as filesystem) cannot operate on the
      device while we are discarding buffer cache.
      Reported-by: default avatarYe Bin <yebin10@huawei.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      [axboe: fix !CONFIG_BLOCK error in truncate_bdev_range()]
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      384d87ef
  11. 02 Sep, 2020 4 commits
  12. 01 Sep, 2020 2 commits