1. 29 May, 2019 2 commits
  2. 27 May, 2019 2 commits
    • Jan Kara's avatar
      block: Don't revalidate bdev of hidden gendisk · 31cb1d64
      Jan Kara authored
      When hidden gendisk is revalidated, there's no point in revalidating
      associated block device as there's none. We would thus just create new
      bdev inode, report "detected capacity change from 0 to XXX" message and
      evict the bdev inode again. Avoid this pointless dance and confusing
      message in the kernel log.
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      31cb1d64
    • Jan Kara's avatar
      loop: Don't change loop device under exclusive opener · 33ec3e53
      Jan Kara authored
      Loop module allows calling LOOP_SET_FD while there are other openers of
      the loop device. Even exclusive ones. This can lead to weird
      consequences such as kernel deadlocks like:
      
      mount_bdev()				lo_ioctl()
        udf_fill_super()
          udf_load_vrs()
            sb_set_blocksize() - sets desired block size B
            udf_tread()
              sb_bread()
                __bread_gfp(bdev, block, B)
      					  loop_set_fd()
      					    set_blocksize()
                  - now __getblk_slow() indefinitely loops because B != bdev
                    block size
      
      Fix the problem by disallowing LOOP_SET_FD ioctl when there are
      exclusive openers of a loop device.
      
      [Deliberately chosen not to CC stable as a user with priviledges to
      trigger this race has other means of taking the system down and this
      has a potential of breaking some weird userspace setup]
      
      Reported-and-tested-by: syzbot+10007d66ca02b08f0e60@syzkaller.appspotmail.com
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      33ec3e53
  3. 26 May, 2019 1 commit
  4. 25 May, 2019 5 commits
  5. 24 May, 2019 30 commits