1. 27 1月, 2020 1 次提交
  2. 24 1月, 2020 1 次提交
  3. 23 1月, 2020 2 次提交
  4. 16 1月, 2020 1 次提交
  5. 15 1月, 2020 1 次提交
  6. 09 1月, 2020 2 次提交
    • M
      fs: move guard_bio_eod() after bio_set_op_attrs · 83c9c547
      Ming Lei 提交于
      Commit 85a8ce62 ("block: add bio_truncate to fix guard_bio_eod")
      adds bio_truncate() for handling bio EOD. However, bio_truncate()
      doesn't use the passed 'op' parameter from guard_bio_eod's callers.
      
      So bio_trunacate() may retrieve wrong 'op', and zering pages may
      not be done for READ bio.
      
      Fixes this issue by moving guard_bio_eod() after bio_set_op_attrs()
      in submit_bh_wbc() so that bio_truncate() can always retrieve correct
      op info.
      
      Meantime remove the 'op' parameter from guard_bio_eod() because it isn't
      used any more.
      
      Cc: Carlos Maiolino <cmaiolino@redhat.com>
      Cc: linux-fsdevel@vger.kernel.org
      Fixes: 85a8ce62 ("block: add bio_truncate to fix guard_bio_eod")
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      
      Fold in kerneldoc and bio_op() change.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      83c9c547
    • C
      block: mark zone-mgmt bios with REQ_SYNC · 8e42d239
      Chaitanya Kulkarni 提交于
      In the current implementation, final zone-mgmt request is issued with
      submit_bio_wait() which marks the bio REQ_SYNC. This is needed since
      immediate action is expected for zone-mgmt requests as these are
      blocking operations. This also bypasses the scheduler in the
      blk_mq_make_request() and dispatches the request directly into the
      hw ctx.
      
      This patch marks all the chained bios REQ_SYNC so that we can have
      above-mentioned behavior for non-final bios also.
      Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: NBob Liu <bob.liu@oracle.com>
      Signed-off-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      8e42d239
  7. 07 1月, 2020 2 次提交
  8. 30 12月, 2019 1 次提交
    • M
      block: fix splitting segments on boundary masks · 429120f3
      Ming Lei 提交于
      We ran into a problem with a mpt3sas based controller, where we would
      see random (and hard to reproduce) file corruption). The issue seemed
      specific to this controller, but wasn't specific to the file system.
      After a lot of debugging, we find out that it's caused by segments
      spanning a 4G memory boundary. This shouldn't happen, as the default
      setting for segment boundary masks is 4G.
      
      Turns out there are two issues in get_max_segment_size():
      
      1) The default segment boundary mask is bypassed
      
      2) The segment start address isn't taken into account when checking
         segment boundary limit
      
      Fix these two issues by removing the bypass of the segment boundary
      check even if the mask is set to the default value, and taking into
      account the actual start address of the request when checking if a
      segment needs splitting.
      
      Cc: stable@vger.kernel.org # v5.1+
      Reviewed-by: NChris Mason <clm@fb.com>
      Tested-by: NChris Mason <clm@fb.com>
      Fixes: dcebd755 ("block: use bio_for_each_bvec() to compute multi-page bvec count")
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      
      Dropped const on the page pointer, ppc page_to_phys() doesn't mark the
      page as const...
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      429120f3
  9. 29 12月, 2019 1 次提交
    • M
      block: add bio_truncate to fix guard_bio_eod · 85a8ce62
      Ming Lei 提交于
      Some filesystem, such as vfat, may send bio which crosses device boundary,
      and the worse thing is that the IO request starting within device boundaries
      can contain more than one segment past EOD.
      
      Commit dce30ca9 ("fs: fix guard_bio_eod to check for real EOD errors")
      tries to fix this issue by returning -EIO for this situation. However,
      this way lets fs user code lose chance to handle -EIO, then sync_inodes_sb()
      may hang for ever.
      
      Also the current truncating on last segment is dangerous by updating the
      last bvec, given bvec table becomes not immutable any more, and fs bio
      users may not retrieve the truncated pages via bio_for_each_segment_all() in
      its .end_io callback.
      
      Fixes this issue by supporting multi-segment truncating. And the
      approach is simpler:
      
      - just update bio size since block layer can make correct bvec with
      the updated bio size. Then bvec table becomes really immutable.
      
      - zero all truncated segments for read bio
      
      Cc: Carlos Maiolino <cmaiolino@redhat.com>
      Cc: linux-fsdevel@vger.kernel.org
      Fixed-by: dce30ca9 ("fs: fix guard_bio_eod to check for real EOD errors")
      Reported-by: syzbot+2b9e54155c8c25d8d165@syzkaller.appspotmail.com
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      85a8ce62
  10. 21 12月, 2019 7 次提交
    • A
      compat_ioctl: block: handle Persistent Reservations · b2c0fcd2
      Arnd Bergmann 提交于
      These were added to blkdev_ioctl() in linux-5.5 but not
      blkdev_compat_ioctl, so add them now.
      
      Cc: <stable@vger.kernel.org> # v4.4+
      Fixes: bbd3e064 ("block: add an API for Persistent Reservations")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      
      Fold in followup patch from Arnd with missing pr.h header include.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b2c0fcd2
    • A
      compat_ioctl: block: handle add zone open, close and finish ioctl · 4b43f31d
      Arnd Bergmann 提交于
      These were added to blkdev_ioctl() in linux-5.5 but not
      blkdev_compat_ioctl, so add them now.
      
      Fixes: e876df1f ("block: add zone open, close and finish ioctl support")
      Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      4b43f31d
    • A
      compat_ioctl: block: handle BLKGETZONESZ/BLKGETNRZONES · 21d37340
      Arnd Bergmann 提交于
      These were added to blkdev_ioctl() in v4.20 but not blkdev_compat_ioctl,
      so add them now.
      
      Cc: <stable@vger.kernel.org> # v4.20+
      Fixes: 72cd8757 ("block: Introduce BLKGETZONESZ ioctl")
      Fixes: 65e4e3ee ("block: Introduce BLKGETNRZONES ioctl")
      Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      21d37340
    • A
      compat_ioctl: block: handle BLKREPORTZONE/BLKRESETZONE · 673bdf8c
      Arnd Bergmann 提交于
      These were added to blkdev_ioctl() but not blkdev_compat_ioctl,
      so add them now.
      
      Cc: <stable@vger.kernel.org> # v4.10+
      Fixes: 3ed05a98 ("blk-zoned: implement ioctls")
      Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      673bdf8c
    • Y
      block: fix memleak when __blk_rq_map_user_iov() is failed · 3b7995a9
      Yang Yingliang 提交于
      When I doing fuzzy test, get the memleak report:
      
      BUG: memory leak
      unreferenced object 0xffff88837af80000 (size 4096):
        comm "memleak", pid 3557, jiffies 4294817681 (age 112.499s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          20 00 00 00 10 01 00 00 00 00 00 00 01 00 00 00   ...............
        backtrace:
          [<000000001c894df8>] bio_alloc_bioset+0x393/0x590
          [<000000008b139a3c>] bio_copy_user_iov+0x300/0xcd0
          [<00000000a998bd8c>] blk_rq_map_user_iov+0x2f1/0x5f0
          [<000000005ceb7f05>] blk_rq_map_user+0xf2/0x160
          [<000000006454da92>] sg_common_write.isra.21+0x1094/0x1870
          [<00000000064bb208>] sg_write.part.25+0x5d9/0x950
          [<000000004fc670f6>] sg_write+0x5f/0x8c
          [<00000000b0d05c7b>] __vfs_write+0x7c/0x100
          [<000000008e177714>] vfs_write+0x1c3/0x500
          [<0000000087d23f34>] ksys_write+0xf9/0x200
          [<000000002c8dbc9d>] do_syscall_64+0x9f/0x4f0
          [<00000000678d8e9a>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      If __blk_rq_map_user_iov() is failed in blk_rq_map_user_iov(),
      the bio(s) which is allocated before this failing will leak. The
      refcount of the bio(s) is init to 1 and increased to 2 by calling
      bio_get(), but __blk_rq_unmap_user() only decrease it to 1, so
      the bio cannot be freed. Fix it by calling blk_rq_unmap_user().
      Reviewed-by: NBob Liu <bob.liu@oracle.com>
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      3b7995a9
    • B
      block: Fix a lockdep complaint triggered by request queue flushing · b3c6a599
      Bart Van Assche 提交于
      Avoid that running test nvme/012 from the blktests suite triggers the
      following false positive lockdep complaint:
      
      ============================================
      WARNING: possible recursive locking detected
      5.0.0-rc3-xfstests-00015-g1236f7d60242 #841 Not tainted
      --------------------------------------------
      ksoftirqd/1/16 is trying to acquire lock:
      000000000282032e (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0
      
      but task is already holding lock:
      00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&fq->mq_flush_lock)->rlock);
        lock(&(&fq->mq_flush_lock)->rlock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      1 lock held by ksoftirqd/1/16:
       #0: 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0
      
      stack backtrace:
      CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       dump_stack+0x67/0x90
       __lock_acquire.cold.45+0x2b4/0x313
       lock_acquire+0x98/0x160
       _raw_spin_lock_irqsave+0x3b/0x80
       flush_end_io+0x4e/0x1d0
       blk_mq_complete_request+0x76/0x110
       nvmet_req_complete+0x15/0x110 [nvmet]
       nvmet_bio_done+0x27/0x50 [nvmet]
       blk_update_request+0xd7/0x2d0
       blk_mq_end_request+0x1a/0x100
       blk_flush_complete_seq+0xe5/0x350
       flush_end_io+0x12f/0x1d0
       blk_done_softirq+0x9f/0xd0
       __do_softirq+0xca/0x440
       run_ksoftirqd+0x24/0x50
       smpboot_thread_fn+0x113/0x1e0
       kthread+0x121/0x140
       ret_from_fork+0x3a/0x50
      
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Ming Lei <ming.lei@redhat.com>
      Cc: Hannes Reinecke <hare@suse.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b3c6a599
    • B
      block: Fix the type of 'sts' in bsg_queue_rq() · c44a4edb
      Bart Van Assche 提交于
      This patch fixes the following sparse warnings:
      
      block/bsg-lib.c:269:19: warning: incorrect type in initializer (different base types)
      block/bsg-lib.c:269:19:    expected int sts
      block/bsg-lib.c:269:19:    got restricted blk_status_t [usertype]
      block/bsg-lib.c:286:16: warning: incorrect type in return expression (different base types)
      block/bsg-lib.c:286:16:    expected restricted blk_status_t
      block/bsg-lib.c:286:16:    got int [assigned] sts
      
      Cc: Martin Wilck <mwilck@suse.com>
      Fixes: d46fe2cb ("block: drop device references in bsg_queue_rq()")
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c44a4edb
  11. 19 12月, 2019 2 次提交
  12. 18 12月, 2019 1 次提交
  13. 17 12月, 2019 1 次提交
    • T
      iocost: over-budget forced IOs should schedule async delay · d7bd15a1
      Tejun Heo 提交于
      When over-budget IOs are force-issued through root cgroup,
      iocg_kick_delay() adjusts the async delay accordingly but doesn't
      actually schedule async throttle for the issuing task.  This bug is
      pretty well masked because sooner or later the offending threads are
      gonna get directly throttled on regular IOs or have async delay
      scheduled by mem_cgroup_throttle_swaprate().
      
      However, it can affect control quality on filesystem metadata heavy
      operations.  Let's fix it by invoking blkcg_schedule_throttle() when
      iocg_kick_delay() says async delay is needed.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Fixes: 7caa4715 ("blkcg: implement blk-iocost")
      Cc: stable@vger.kernel.org
      Reported-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      d7bd15a1
  14. 13 12月, 2019 1 次提交
  15. 12 12月, 2019 1 次提交
    • L
      block: fix NULL pointer dereference in account statistics with IDE · ecb6186c
      Logan Gunthorpe 提交于
      The IDE driver creates some passthru requests which never get
      submitted to the block layer in such a way that blk_account_io_start()
      gets called. However, the driver still calls __blk_mq_end_request() in
      ide_end_rq() which will call blk_account_io_completion() which tries
      to dereferences req->part which is never set. See ide_prep_sense() for
      an example of where these requests come from.
      
      To fix this, blk_account_io_completion() and blk_account_io_done()
      should do nothing if req->part is not set.
      
      The back trace of this bug is:
      
          BUG: kernel NULL pointer dereference, address: 000002ac
          #PF: supervisor write access in kernel mode
          #PF: error_code(0x0002) - not-present page
          *pde = 00000000
          Oops: 0002 [#1]
          CPU: 0 PID: 237 Comm: kworker/0:1H Not tainted
          5.4.0-rc2-00011-g48d9b0d4 #1
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1
          04/01/2014
          Workqueue: kblockd drive_rq_insert_work
          EIP: blk_account_io_completion+0x7a/0xf0
          Code: 89 54 24 08 31 d2 89 4c 24 04 31 c9 c7 04 24 02 00 00 00 c1 ee
          09 e8 f5 21 a6 ff e8 70 5c a7 ff 8b 53 60 8d 04 bd 00 00 00 00 <01> b4
          02 ac 02 00 00 8b 9a 88 02 00 00 85 db 74 11 85 d2 74 51 8b
          EAX: 00000000 EBX: f5b80000 ECX: 00000000 EDX: 00000000
          ESI: 00000000 EDI: 00000000 EBP: f3031e70 ESP: f3031e54
          DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010046
          CR0: 80050033 CR2: 000002ac CR3: 03c25000 CR4: 000406d0
          Call Trace:
           <IRQ>
            blk_update_request+0x85/0x420
            ide_end_rq+0x38/0xa0
            ide_complete_rq+0x3d/0x70
            cdrom_newpc_intr+0x258/0xba0
            ide_intr+0x135/0x250
            __handle_irq_event_percpu+0x3e/0x250
            handle_irq_event_percpu+0x1f/0x50
            handle_irq_event+0x32/0x60
            handle_level_irq+0x6c/0x110
            handle_irq+0x72/0xa0
            </IRQ>
            do_IRQ+0x45/0xad
            common_interrupt+0x115/0x11c
      
      Fixes: 48d9b0d4 ("block: account statistics for passthrough requests")
      Reported-by: Nkernel test robot <rong.a.chen@intel.com>
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ecb6186c
  16. 10 12月, 2019 2 次提交
  17. 06 12月, 2019 1 次提交
    • J
      block: fix memleak of bio integrity data · ece841ab
      Justin Tee 提交于
      7c20f116 ("bio-integrity: stop abusing bi_end_io") moves
      bio_integrity_free from bio_uninit() to bio_integrity_verify_fn()
      and bio_endio(). This way looks wrong because bio may be freed
      without calling bio_endio(), for example, blk_rq_unprep_clone() is
      called from dm_mq_queue_rq() when the underlying queue of dm-mpath
      is busy.
      
      So memory leak of bio integrity data is caused by commit 7c20f116.
      
      Fixes this issue by re-adding bio_integrity_free() to bio_uninit().
      
      Fixes: 7c20f116 ("bio-integrity: stop abusing bi_end_io")
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by Justin Tee <justin.tee@broadcom.com>
      
      Add commit log, and simplify/fix the original patch wroten by Justin.
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ece841ab
  18. 05 12月, 2019 1 次提交
    • H
      bfq-iosched: Ensure bio->bi_blkg is valid before using it · 08802ed6
      Hou Tao 提交于
      bio->bi_blkg will be NULL when the issue of the request
      has bypassed the block layer as shown in the following oops:
      
       Internal error: Oops: 96000005 [#1] SMP
       CPU: 17 PID: 2996 Comm: scsi_id Not tainted 5.4.0 #4
       Call trace:
        percpu_counter_add_batch+0x38/0x4c8
        bfqg_stats_update_legacy_io+0x9c/0x280
        bfq_insert_requests+0xbac/0x2190
        blk_mq_sched_insert_request+0x288/0x670
        blk_execute_rq_nowait+0x140/0x178
        blk_execute_rq+0x8c/0x140
        sg_io+0x604/0x9c0
        scsi_cmd_ioctl+0xe38/0x10a8
        scsi_cmd_blk_ioctl+0xac/0xe8
        sd_ioctl+0xe4/0x238
        blkdev_ioctl+0x590/0x20e0
        block_ioctl+0x60/0x98
        do_vfs_ioctl+0xe0/0x1b58
        ksys_ioctl+0x80/0xd8
        __arm64_sys_ioctl+0x40/0x78
        el0_svc_handler+0xc4/0x270
      
      so ensure its validity before using it.
      
      Fixes: fd41e603 ("bfq-iosched: stop using blkg->stat_bytes and ->stat_ios")
      Signed-off-by: NHou Tao <houtao1@huawei.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      08802ed6
  19. 04 12月, 2019 1 次提交
  20. 03 12月, 2019 5 次提交
  21. 22 11月, 2019 2 次提交
  22. 21 11月, 2019 1 次提交
  23. 19 11月, 2019 1 次提交
  24. 18 11月, 2019 1 次提交