1. 26 Mar, 2018 21 commits
  2. 22 Mar, 2018 3 commits
    • Shawn Lin's avatar
      mmc: block: Delete gendisk before cleaning up the request queue · 57678e5a
      Shawn Lin authored
      dd if=/dev/urandom of=/dev/mmcblk1 bs=4k count=10000
      with a SD card hotplug during transfer reports a warning below
      introduced by commit a063057d ("block: Fix a race between
      request queue removal and the block cgroup controller"). So we
      should now remove the disk, partition and bdi sysfs attributes
      before cleaning up the request queue associated with the disk.
      
      [  410.331226] mmc1: card 59b4 removed
      [  410.348583] WARNING: CPU: 0 PID: 5 at block/blk-core.c:785
      blk_cleanup_queue+0x138/0x140
      [  410.349294] Modules linked in:
      [  410.349570] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted
      4.16.0-rc6-next-20180321-00004-gc2ad6a7 #263
      [  410.350363] Hardware name: Excavator-RK3399 Board (DT)
      [  410.350819] Workqueue: events_freezable mmc_rescan
      [  410.351242] pstate: 60000005 (nZCv daif -PAN -UAO)
      [  410.351663] pc : blk_cleanup_queue+0x138/0x140
      [  410.352054] lr : blk_cleanup_queue+0xac/0x140
      [  410.352436] sp : ffff0000092cbb90
      [  410.352727] x29: ffff0000092cbb90 x28: 0000000000000000
      [  410.353195] x27: ffff8000f6f23030 x26: ffff00000904e610
      [  410.353662] x25: ffff8000f17cc808 x24: ffff8000f1038200
      [  410.354128] x23: 0000000000000060 x22: 0000000000000000
      [  410.354595] x21: ffff8000f11748d8 x20: ffff8000f1038200
      [  410.355061] x19: ffff8000f1174200 x18: 0000ffff936347d8
      [  410.355528] x17: 0000ffff935b93c0 x16: ffff0000081263f8
      [  410.355994] x15: 0000000000000000 x14: 0000000000000400
      [  410.356461] x13: 0000000000000001 x12: 0000000000000001
      [  410.356927] x11: 0000000000000040 x10: ffff8000f2400028
      [  410.357393] x9 : ffff8000f2400040 x8 : 0000000000000000
      [  410.357860] x7 : ffff8000f6f3a340 x6 : ffff8000f6f3a340
      [  410.358326] x5 : ffff8000f2400000 x4 : ffff8000f6f3a340
      [  410.358792] x3 : 0000000000000000 x2 : 39c1333e45670800
      [  410.359259] x1 : 0000000000000000 x0 : 0000000000000003
      [  410.359726] Call trace:
      [  410.359943]  blk_cleanup_queue+0x138/0x140
      [  410.360305]  mmc_cleanup_queue+0x2c/0x48
      [  410.360652]  mmc_blk_remove_req+0x1c/0x98
      [  410.361005]  mmc_blk_remove+0x180/0x1c0
      [  410.361343]  mmc_bus_remove+0x1c/0x28
      [  410.361670]  device_release_driver_internal+0x154/0x1f0
      [  410.362128]  device_release_driver+0x14/0x20
      [  410.362504]  bus_remove_device+0xc8/0x108
      [  410.362858]  device_del+0x120/0x350
      [  410.363167]  mmc_remove_card+0x5c/0xb8
      [  410.363498]  mmc_sd_detect+0x40/0x78
      [  410.363813]  mmc_rescan+0x19c/0x368
      [  410.364123]  process_one_work+0x1ac/0x318
      [  410.364477]  worker_thread+0x50/0x450
      [  410.364801]  kthread+0xf8/0x128
      [  410.365081]  ret_from_fork+0x10/0x18
      [  410.365395] ---[ end trace 268e87a46c28968c ]---
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      57678e5a
    • Mikulas Patocka's avatar
      Fix slab name "biovec-(1<<(21-12))" · bd5c4fac
      Mikulas Patocka authored
      I'm getting a slab named "biovec-(1<<(21-12))". It is caused by unintended
      expansion of the macro BIO_MAX_PAGES. This patch renames it to biovec-max.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org	# v4.14+
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      bd5c4fac
    • Mikulas Patocka's avatar
      block: use 32-bit blk_status_t on Alpha · 6e2fb221
      Mikulas Patocka authored
      Early alpha processors cannot write a single byte or word; they read 8
      bytes, modify the value in registers and write back 8 bytes.
      
      The type blk_status_t is defined as one byte, it is often written
      asynchronously by I/O completion routines, this asynchronous modification
      can corrupt content of nearby bytes if these nearby bytes can be written
      simultaneously by another CPU.
      
      - one example of such corruption is the structure dm_io where
        "blk_status_t status" is written by an asynchronous completion routine
        and "atomic_t io_count" is modified synchronously
      - another example is the structure dm_buffer where "unsigned hold_count"
        is modified synchronously from process context and "blk_status_t
        write_error" is modified asynchronously from bio completion routine
      
      This patch fixes the bug by changing the type blk_status_t to 32 bits if
      we are on Alpha and if we are compiling for a processor that doesn't have
      the byte-word-extension.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org	# 4.13+
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      6e2fb221
  3. 19 Mar, 2018 16 commits