1. 04 Oct, 2018 1 commit
    • Andy Whitcroft's avatar
      floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl · 04bc4dd8
      Andy Whitcroft authored
      commit 65eea8edc315589d6c993cf12dbb5d0e9ef1fe4e upstream.
      
      The final field of a floppy_struct is the field "name", which is a pointer
      to a string in kernel memory.  The kernel pointer should not be copied to
      user memory.  The FDGETPRM ioctl copies a floppy_struct to user memory,
      including this "name" field.  This pointer cannot be used by the user
      and it will leak a kernel address to user-space, which will reveal the
      location of kernel code and data and undermine KASLR protection.
      
      Model this code after the compat ioctl which copies the returned data
      to a previously cleared temporary structure on the stack (excluding the
      name pointer) and copy out to userspace from there.  As we already have
      an inparam union with an appropriate member and that memory is already
      cleared even for read only calls make use of that as a temporary store.
      
      Based on an initial patch by Brian Belleville.
      
      CVE-2018-7755
      Signed-off-by: 's avatarAndy Whitcroft <apw@canonical.com>
      Broke up long line.
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04bc4dd8
  2. 19 Sep, 2018 2 commits
  3. 09 Sep, 2018 1 commit
  4. 05 Sep, 2018 2 commits
  5. 24 Aug, 2018 2 commits
  6. 17 Jul, 2018 2 commits
  7. 11 Jul, 2018 1 commit
    • Lars Ellenberg's avatar
      drbd: fix access after free · 0ce6c464
      Lars Ellenberg authored
      commit 64dafbc9530c10300acffc57fae3269d95fa8f93 upstream.
      
      We have
        struct drbd_requests { ... struct bio *private_bio;  ... }
      to hold a bio clone for local submission.
      
      On local IO completion, we put that bio, and in case we want to use the
      result later, we overload that member to hold the ERR_PTR() of the
      completion result,
      
      Which, before v4.3, used to be the passed in "int error",
      so we could first bio_put(), then assign.
      
      v4.3-rc1~100^2~21 4246a0b6 block: add a bi_error field to struct bio
      changed that:
        	bio_put(req->private_bio);
       -	req->private_bio = ERR_PTR(error);
       +	req->private_bio = ERR_PTR(bio->bi_error);
      
      Which introduces an access after free,
      because it was non obvious that req->private_bio == bio.
      
      Impact of that was mostly unnoticable, because we only use that value
      in a multiple-failure case, and even then map any "unexpected" error
      code to EIO, so worst case we could potentially mask a more specific
      error with EIO in a multiple failure case.
      
      Unless the pointed to memory region was unmapped, as is the case with
      CONFIG_DEBUG_PAGEALLOC, in which case this results in
      
        BUG: unable to handle kernel paging request
      
      v4.13-rc1~70^2~75 4e4cbee9 block: switch bios to blk_status_t
      changes it further to
        	bio_put(req->private_bio);
        	req->private_bio = ERR_PTR(blk_status_to_errno(bio->bi_status));
      
      And blk_status_to_errno() now contains a WARN_ON_ONCE() for unexpected
      values, which catches this "sometimes", if the memory has been reused
      quickly enough for other things.
      
      Should also go into stable since 4.3, with the trivial change around 4.13.
      
      Cc: stable@vger.kernel.org
      Fixes: 4246a0b6 block: add a bi_error field to struct bio
      Reported-by: 's avatarSarah Newman <srn@prgmr.com>
      Signed-off-by: 's avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ce6c464
  8. 03 Jul, 2018 1 commit
    • Dongsheng Yang's avatar
      rbd: flush rbd_dev->watch_dwork after watch is unregistered · 76022230
      Dongsheng Yang authored
      commit 23edca864951250af845a11da86bb3ea63522ed2 upstream.
      
      There is a problem if we are going to unmap a rbd device and the
      watch_dwork is going to queue delayed work for watch:
      
      unmap Thread                    watch Thread                  timer
      do_rbd_remove
        cancel_tasks_sync(rbd_dev)
                                      queue_delayed_work for watch
        destroy_workqueue(rbd_dev->task_wq)
          drain_workqueue(wq)
          destroy other resources in wq
                                                                    call_timer_fn
                                                                      __queue_work()
      
      Then the delayed work escape the cancel_tasks_sync() and
      destroy_workqueue() and we will get an user-after-free call trace:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
        PGD 0 P4D 0
        Oops: 0000 [#1] SMP PTI
        Modules linked in:
        CPU: 7 PID: 0 Comm: swapper/7 Tainted: G           OE     4.17.0-rc6+ #13
        Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
        RIP: 0010:__queue_work+0x6a/0x3b0
        RSP: 0018:ffff9427df1c3e90 EFLAGS: 00010086
        RAX: ffff9427deca8400 RBX: 0000000000000000 RCX: 0000000000000000
        RDX: ffff9427deca8400 RSI: ffff9427df1c3e50 RDI: 0000000000000000
        RBP: ffff942783e39e00 R08: ffff9427deca8400 R09: ffff9427df1c3f00
        R10: 0000000000000004 R11: 0000000000000005 R12: ffff9427cfb85970
        R13: 0000000000002000 R14: 000000000001eca0 R15: 0000000000000007
        FS:  0000000000000000(0000) GS:ffff9427df1c0000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000000 CR3: 00000004c900a005 CR4: 00000000000206e0
        Call Trace:
         <IRQ>
         ? __queue_work+0x3b0/0x3b0
         call_timer_fn+0x2d/0x130
         run_timer_softirq+0x16e/0x430
         ? tick_sched_timer+0x37/0x70
         __do_softirq+0xd2/0x280
         irq_exit+0xd5/0xe0
         smp_apic_timer_interrupt+0x6c/0x130
         apic_timer_interrupt+0xf/0x20
      
      [ Move rbd_dev->watch_dwork cancellation so that rbd_reregister_watch()
        either bails out early because the watch is UNREGISTERED at that point
        or just gets cancelled. ]
      
      Cc: stable@vger.kernel.org
      Fixes: 99d16943 ("rbd: retry watch re-registration periodically")
      Signed-off-by: 's avatarDongsheng Yang <dongsheng.yang@easystack.cn>
      Reviewed-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76022230
  9. 26 Jun, 2018 3 commits
  10. 30 May, 2018 4 commits
    • Ming Lei's avatar
      block: null_blk: fix 'Invalid parameters' when loading module · a6494884
      Ming Lei authored
      [ Upstream commit 66231ad3e2886ba99fbf440cea44cab547e5163f ]
      
      On ARM64, the default page size has been 64K on some distributions, and
      we should allow ARM64 people to play null_blk.
      
      This patch fixes the issue by extend page bitmap size for supporting
      other non-4KB PAGE_SIZE.
      
      Cc: Bart Van Assche <Bart.VanAssche@wdc.com>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Kyungchan Koh <kkc6196@fb.com>,
      Cc: weiping zhang <zhangweiping@didichuxing.com>
      Cc: Yi Zhang <yi.zhang@redhat.com>
      Reported-by: 's avatarYi Zhang <yi.zhang@redhat.com>
      Signed-off-by: 's avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a6494884
    • Maurizio Lombardi's avatar
      cdrom: do not call check_disk_change() inside cdrom_open() · e6e5de32
      Maurizio Lombardi authored
      [ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]
      
      when mounting an ISO filesystem sometimes (very rarely)
      the system hangs because of a race condition between two tasks.
      
      PID: 6766   TASK: ffff88007b2a6dd0  CPU: 0   COMMAND: "mount"
       #0 [ffff880078447ae0] __schedule at ffffffff8168d605
       #1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49
       #2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995
       #3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
       #4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod]
       #5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50
       #6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3
       #7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs]
       #8 [ffff880078447da8] mount_bdev at ffffffff81202570
       #9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
      #10 [ffff880078447e28] mount_fs at ffffffff81202d09
      #11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f
      #12 [ffff880078447ea8] do_mount at ffffffff81220fee
      #13 [ffff880078447f28] sys_mount at ffffffff812218d6
      #14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
          RIP: 00007fd9ea914e9a  RSP: 00007ffd5d9bf648  RFLAGS: 00010246
          RAX: 00000000000000a5  RBX: ffffffff81698c49  RCX: 0000000000000010
          RDX: 00007fd9ec2bc210  RSI: 00007fd9ec2bc290  RDI: 00007fd9ec2bcf30
          RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000010
          R10: 00000000c0ed0001  R11: 0000000000000206  R12: 00007fd9ec2bc040
          R13: 00007fd9eb6b2380  R14: 00007fd9ec2bc210  R15: 00007fd9ec2bcf30
          ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b
      
      This task was trying to mount the cdrom.  It allocated and configured a
      super_block struct and owned the write-lock for the super_block->s_umount
      rwsem. While exclusively owning the s_umount lock, it called
      sr_block_ioctl and waited to acquire the global sr_mutex lock.
      
      PID: 6785   TASK: ffff880078720fb0  CPU: 0   COMMAND: "systemd-udevd"
       #0 [ffff880078417898] __schedule at ffffffff8168d605
       #1 [ffff880078417900] schedule at ffffffff8168dc59
       #2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605
       #3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838
       #4 [ffff8800784179d0] down_read at ffffffff8168cde0
       #5 [ffff8800784179e8] get_super at ffffffff81201cc7
       #6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de
       #7 [ffff880078417a40] flush_disk at ffffffff8123a94b
       #8 [ffff880078417a88] check_disk_change at ffffffff8123ab50
       #9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
      #10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod]
      #11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
      #12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
      #13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
      #14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7
      #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
      #16 [ffff880078417d00] do_last at ffffffff8120d53d
      #17 [ffff880078417db0] path_openat at ffffffff8120e6b2
      #18 [ffff880078417e48] do_filp_open at ffffffff8121082b
      #19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
      #20 [ffff880078417f70] sys_open at ffffffff811fde4e
      #21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
          RIP: 00007f29438b0c20  RSP: 00007ffc76624b78  RFLAGS: 00010246
          RAX: 0000000000000002  RBX: ffffffff81698c49  RCX: 0000000000000000
          RDX: 00007f2944a5fa70  RSI: 00000000000a0800  RDI: 00007f2944a5fa70
          RBP: 00007f2944a5f540   R8: 0000000000000000   R9: 0000000000000020
          R10: 00007f2943614c40  R11: 0000000000000246  R12: ffffffff811fde4e
          R13: ffff880078417f78  R14: 000000000000000c  R15: 00007f2944a4b010
          ORIG_RAX: 0000000000000002  CS: 0033  SS: 002b
      
      This task tried to open the cdrom device, the sr_block_open function
      acquired the global sr_mutex lock. The call to check_disk_change()
      then saw an event flag indicating a possible media change and tried
      to flush any cached data for the device.
      As part of the flush, it tried to acquire the super_block->s_umount
      lock associated with the cdrom device.
      This was the same super_block as created and locked by the previous task.
      
      The first task acquires the s_umount lock and then the sr_mutex_lock;
      the second task acquires the sr_mutex_lock and then the s_umount lock.
      
      This patch fixes the issue by moving check_disk_change() out of
      cdrom_open() and let the caller take care of it.
      Signed-off-by: 's avatarMaurizio Lombardi <mlombard@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6e5de32
    • Bhavesh Davda's avatar
      xen-blkfront: move negotiate_mq to cover all cases of new VBDs · 9238d1fa
      Bhavesh Davda authored
      [ Upstream commit 7ed8ce1c5fc7cf25b3602c73bef897a3466a6645 ]
      
      negotiate_mq should happen in all cases of a new VBD being discovered by
      xen-blkfront, whether called through _probe() or a hot-attached new VBD
      from dom-0 via xenstore. Otherwise, hot-attached new VBDs are left
      configured without multi-queue.
      Signed-off-by: 's avatarBhavesh Davda <bhavesh.davda@oracle.com>
      Reviewed-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9238d1fa
    • Gustavo A. R. Silva's avatar
      nbd: fix return value in error handling path · 615bf75c
      Gustavo A. R. Silva authored
      [ Upstream commit 0979962f5490abe75b3e2befb07a564fa0cf631b ]
      
      It seems that the proper value to return in this particular case is the
      one contained into variable new_index instead of ret.
      
      Addresses-Coverity-ID: 1465148 ("Copy-paste error")
      Fixes: e46c7287 ("nbd: add a basic netlink interface")
      Reviewed-by: 's avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: 's avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      615bf75c
  11. 25 May, 2018 2 commits
    • Omar Sandoval's avatar
      loop: fix LOOP_GET_STATUS lock imbalance · 36096441
      Omar Sandoval authored
      commit bdac616db9bbadb90b7d6a406144571015e138f7 upstream.
      
      Commit 2d1d4c1e591f made loop_get_status() drop lo_ctx_mutex before
      returning, but the loop_get_status_old(), loop_get_status64(), and
      loop_get_status_compat() wrappers don't call loop_get_status() if the
      passed argument is NULL. The callers expect that the lock is dropped, so
      make sure we drop it in that case, too.
      
      Reported-by: syzbot+31e8daa8b3fc129e75f2@syzkaller.appspotmail.com
      Fixes: 2d1d4c1e591f ("loop: don't call into filesystem while holding lo_ctl_mutex")
      Signed-off-by: 's avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36096441
    • Omar Sandoval's avatar
      loop: don't call into filesystem while holding lo_ctl_mutex · c18270ac
      Omar Sandoval authored
      commit 2d1d4c1e591fd40bd7dafd868a249d7d00e215d5 upstream.
      
      We hit an issue where a loop device on NFS was stuck in
      loop_get_status() doing vfs_getattr() after the NFS server died, which
      caused a pile-up of uninterruptible processes waiting on lo_ctl_mutex.
      There's no reason to hold this lock while we wait on the filesystem;
      let's drop it so that other processes can do their thing. We need to
      grab a reference on lo_backing_file while we use it, and we can get rid
      of the check on lo_device, which has been unnecessary since commit
      a34c0ae9ebd6 ("[PATCH] loop: remove the bio remapping capability") in
      the linux-history tree.
      Signed-off-by: 's avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c18270ac
  12. 29 Apr, 2018 8 commits
    • Finn Thain's avatar
      block/swim: Fix IO error at end of medium · d82923c0
      Finn Thain authored
      commit 5a13388d7aa1177b98d7168330ecbeeac52f844d upstream.
      
      Reading to the end of a 720K disk results in an IO error instead of EOF
      because the block layer thinks the disk has 2880 sectors. (Partly this
      is a result of inverted logic of the ONEMEG_MEDIA bit that's now fixed.)
      
      Initialize the density and head count in swim_add_floppy() to agree
      with the device size passed to set_capacity() during drive probe.
      
      Call set_capacity() again upon device open, after refreshing the density
      and head count values.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d82923c0
    • Finn Thain's avatar
      block/swim: Fix array bounds check · 06dc2e91
      Finn Thain authored
      commit 7ae6a2b6cc058005ee3d0d2b9ce27688e51afa4b upstream.
      
      In the floppy_find() function in swim.c is a call to
      get_disk(swd->unit[drive].disk). The actual parameter to this call
      can be a NULL pointer when drive == swd->floppy_count. This causes
      an oops in get_disk().
      
      Data read fault at 0x00000198 in Super Data (pc=0x1be5b6)
      BAD KERNEL BUSERR
      Oops: 00000000
      Modules linked in: swim_mod ipv6 mac8390
      PC: [<001be5b6>] get_disk+0xc/0x76
      SR: 2004  SP: 9a078bc1  a2: 0213ed90
      d0: 00000000    d1: 00000000    d2: 00000000    d3: 000000ff
      d4: 00000002    d5: 02983590    a0: 02332e00    a1: 022dfd64
      Process dd (pid: 285, task=020ab25b)
      Frame format=B ssw=074d isc=4a88 isb=6732 daddr=00000198 dobuf=00000000
      baddr=001be5bc dibuf=bfffffff ver=f
      Stack from 022dfca4:
              00000000 0203fc00 0213ed90 022dfcc0 02982936 00000000 00200000 022dfd08
              0020f85a 00200000 022dfd64 02332e00 004040fc 00000014 001be77e 022dfd64
              00334e4a 001be3f8 0800001d 022dfd64 01c04b60 01c04b70 022aba80 029828f8
              02332e00 022dfd2c 001be7ac 0203fc00 00200000 022dfd64 02103a00 01c04b60
              01c04b60 0200e400 022dfd68 000e191a 00200000 022dfd64 02103a00 0800001d
              00000000 00000003 000b89de 00500000 02103a00 01c04b60 02103a08 01c04c2e
      Call Trace: [<02982936>] floppy_find+0x3e/0x4a [swim_mod]
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<0020f85a>] kobj_lookup+0xde/0x132
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<001be77e>] get_gendisk+0x0/0x130
       [<00334e4a>] mutex_lock+0x0/0x2e
       [<001be3f8>] disk_block_events+0x0/0x6c
       [<029828f8>] floppy_find+0x0/0x4a [swim_mod]
       [<001be7ac>] get_gendisk+0x2e/0x130
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<000e191a>] __blkdev_get+0x32/0x45a
       [<00200000>] uart_remove_one_port+0x1a2/0x260
       [<000b89de>] complete_walk+0x0/0x8a
       [<000e1e22>] blkdev_get+0xe0/0x29a
       [<000e1fdc>] blkdev_open+0x0/0xb0
       [<000b89de>] complete_walk+0x0/0x8a
       [<000e1fdc>] blkdev_open+0x0/0xb0
       [<000e01cc>] bd_acquire+0x74/0x8a
       [<000e205c>] blkdev_open+0x80/0xb0
       [<000e1fdc>] blkdev_open+0x0/0xb0
       [<000abf24>] do_dentry_open+0x1a4/0x322
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<000b89de>] complete_walk+0x0/0x8a
       [<000baa62>] link_path_walk+0x0/0x48e
       [<000ba3f8>] inode_permission+0x20/0x54
       [<000ac0e4>] vfs_open+0x42/0x78
       [<000bc372>] path_openat+0x2b2/0xeaa
       [<000bc0c0>] path_openat+0x0/0xeaa
       [<0004463e>] __irq_wake_thread+0x0/0x4e
       [<0003a45a>] task_tick_fair+0x18/0xc8
       [<000bd00a>] do_filp_open+0xa0/0xea
       [<000abae0>] do_sys_open+0x11a/0x1ee
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<000abbf4>] SyS_open+0x1e/0x22
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<00002b40>] syscall+0x8/0xc
       [<00020000>] __do_proc_douintvec+0x22/0x27e
       [<0000c00b>] dyadic+0x1/0x28
      Code: 4e5e 4e75 4e56 fffc 2f0b 2f02 266e 0008 <206b> 0198 4a88 6732 2428 002c 661e 486b 0058 4eb9 0032 0b96 588f 4a88 672c 2008
      Disabling lock debugging due to kernel taint
      
      Fix the array index bounds check to avoid this.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 8852ecd9 ("[PATCH] m68k: mac - Add SWIM floppy support")
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: 's avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06dc2e91
    • Finn Thain's avatar
      block/swim: Select appropriate drive on device open · 8c37ac3c
      Finn Thain authored
      commit b3906535ccc6cd04c42f9b1c7e31d1947b3ebc74 upstream.
      
      The driver supports internal and external FDD units so the floppy_open
      function must not hard-code the drive location.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c37ac3c
    • Finn Thain's avatar
      block/swim: Rename macros to avoid inconsistent inverted logic · cdb0d5fa
      Finn Thain authored
      commit 56a1c5ee54f69dd767fb61d301883dc919ddc259 upstream.
      
      The Sony drive status bits use active-low logic. The swim_readbit()
      function converts that to 'C' logic for readability. Hence, the
      sense of the names of the status bit macros should not be inverted.
      
      Mostly they are correct. However, the TWOMEG_DRIVE, MFM_MODE and
      TWOMEG_MEDIA macros have inverted sense (like MkLinux). Fix this
      inconsistency and make the following patches less confusing.
      
      The same problem affects swim3.c so fix that too.
      
      No functional change.
      
      The FDHD drive status bits are documented in sonydriv.cpp from MAME
      and in swimiii.h from MkLinux.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cdb0d5fa
    • Finn Thain's avatar
      block/swim: Remove extra put_disk() call from error path · f359e87f
      Finn Thain authored
      commit c1d6207cc0eef2a7f8551f9c7420d8776268f6e1 upstream.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Fixes: 103db8b2 ("[PATCH] swim: stop sharing request queue across multiple gendisks")
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: 's avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f359e87f
    • Finn Thain's avatar
      block/swim: Don't log an error message for an invalid ioctl · b7100feb
      Finn Thain authored
      commit 8e2ab5a4efaac77fb93e5b5b109d0b3976fdd3a0 upstream.
      
      The 'eject' shell command may send various different ioctl commands.
      This leads to error messages on the console even though the FDEJECT
      ioctl succeeds.
      
      ~# eject floppy
      SWIM floppy_ioctl: unknown cmd 21257
      SWIM floppy_ioctl: unknown cmd 1
      
      Don't log an error message for an invalid ioctl, just do as the
      swim3 driver does and return -ENOTTY.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: 's avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7100feb
    • Finn Thain's avatar
      block/swim: Check drive type · 0dd9146a
      Finn Thain authored
      commit 8a500df63d07d8aee44b7ee2c54e462e47ce93ec upstream.
      
      The SWIM chip is compatible with GCR-mode Sony 400K/800K drives but
      this driver only supports MFM mode. Therefore only Sony FDHD drives
      are supported. Skip incompatible drives.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dd9146a
    • Finn Thain's avatar
      m68k/mac: Don't remap SWIM MMIO region · 43f8a4f2
      Finn Thain authored
      commit b64576cbf36afa5fabf3b31f62a1994c429ef855 upstream.
      
      For reasons I don't understand, calling ioremap() then iounmap() on
      the SWIM MMIO region causes a hang on 68030 (but not on 68040).
      
      ~# modprobe swim_mod
      SWIM floppy driver Version 0.2 (2008-10-30)
      SWIM device not found !
      watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [modprobe:285]
      Modules linked in: swim_mod(+)
      Format 00  Vector: 0064  PC: 000075aa  Status: 2000    Not tainted
      ORIG_D0: ffffffff  D0: d00c0000  A2: 007c2370  A1: 003f810c
      A0: 00040000  D5: d0096800  D4: d0097e00
      D3: 00000001  D2: 00000003  D1: 00000000
      Non-Maskable Interrupt
      Modules linked in: swim_mod(+)
      PC: [<000075ba>] __iounmap+0x24/0x10e
      SR: 2000  SP: 007abc48  a2: 007c2370
      d0: d00c0000    d1: 000001a0    d2: 00000019    d3: 00000001
      d4: d0097e00    d5: d0096800    a0: 00040000    a1: 003f810c
      Process modprobe (pid: 285, task=007c2370)
      Frame format=0
      Stack from 007abc7c:
              ffffffed 00000000 006a4060 004712e0 007abca0 000076ea d0080000 00080000
              010bb4b8 007abcd8 010ba542 d0096000 00000000 00000000 00000001 010bb59c
              00000000 007abf30 010bb4b8 0047760a 0047763c 00477612 00616540 007abcec
              0020a91a 00477600 0047760a 010bb4cc 007abd18 002092f2 0047760a 00333b06
              007abd5c 00000000 0047760a 010bb4cc 00404f90 004776b8 00000001 007abd38
              00209446 010bb4cc 0047760a 010bb4cc 0020938e 0031f8be 00616540 007abd64
      Call Trace: [<000076ea>] iounmap+0x46/0x5a
       [<00080000>] shrink_page_list+0x7f6/0xe06
       [<010ba542>] swim_probe+0xe4/0x496 [swim_mod]
       [<0020a91a>] platform_drv_probe+0x20/0x5e
       [<002092f2>] driver_probe_device+0x21c/0x2b8
       [<00333b06>] mutex_lock+0x0/0x2e
       [<00209446>] __driver_attach+0xb8/0xce
       [<0020938e>] __driver_attach+0x0/0xce
       [<0031f8be>] klist_next+0x0/0xa0
       [<00207562>] bus_for_each_dev+0x74/0xba
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<00333b06>] mutex_lock+0x0/0x2e
       [<00208e44>] driver_attach+0x1a/0x1e
       [<0020938e>] __driver_attach+0x0/0xce
       [<00207e26>] bus_add_driver+0x188/0x234
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<00209894>] driver_register+0x58/0x104
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<010bd000>] swim_init+0x0/0x2c [swim_mod]
       [<0020a7be>] __platform_driver_register+0x38/0x3c
       [<010bd028>] swim_init+0x28/0x2c [swim_mod]
       [<000020dc>] do_one_initcall+0x38/0x196
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<00075008>] __free_pages+0x0/0x38
       [<000045c0>] mangle_kernel_stack+0x30/0xda
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<003331cc>] mutex_unlock+0x0/0x3e
       [<00333b06>] mutex_lock+0x0/0x2e
       [<0005ced4>] do_init_module+0x42/0x266
       [<010bd000>] swim_init+0x0/0x2c [swim_mod]
       [<000344c0>] blocking_notifier_call_chain+0x0/0x20
       [<0005eda0>] load_module+0x1a30/0x1e70
       [<0000465d>] mangle_kernel_stack+0xcd/0xda
       [<00331c64>] __generic_copy_from_user+0x0/0x46
       [<0033256e>] _cond_resched+0x0/0x32
       [<00331b9c>] memset+0x0/0x98
       [<0033256e>] _cond_resched+0x0/0x32
       [<0005f25c>] SyS_init_module+0x7c/0x112
       [<00002000>] _start+0x0/0x8
       [<00002000>] _start+0x0/0x8
       [<00331c82>] __generic_copy_from_user+0x1e/0x46
       [<0005f2b2>] SyS_init_module+0xd2/0x112
       [<0000465d>] mangle_kernel_stack+0xcd/0xda
       [<00002b40>] syscall+0x8/0xc
       [<0000465d>] mangle_kernel_stack+0xcd/0xda
       [<0008c00c>] pcpu_balance_workfn+0xb2/0x40e
      Code: 2200 7419 e4a9 e589 2841 d9fc 0000 1000 <2414> 7203 c282 7602 b681 6600 0096 0242 fe00 0482 0000 0000 e9c0 11c3 ed89 2642
      
      There's no need to call ioremap() for the SWIM address range, as it lies
      within the usual IO device region at 0x5000 0000, which has already been
      mapped by head.S.
      
      Remove the redundant ioremap() and iounmap() calls to fix the hang.
      
      Cc: Laurent Vivier <lvivier@redhat.com>
      Cc: stable@vger.kernel.org # v4.14+
      Tested-by: 's avatarStan Johnson <userm57@yahoo.com>
      Signed-off-by: 's avatarFinn Thain <fthain@telegraphics.com.au>
      Acked-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43f8a4f2
  13. 19 Apr, 2018 1 commit
    • Tetsuo Handa's avatar
      block/loop: fix deadlock after loop_set_status · 51a9580d
      Tetsuo Handa authored
      commit 1e047eaa upstream.
      
      syzbot is reporting deadlocks at __blkdev_get() [1].
      
      ----------------------------------------
      [   92.493919] systemd-udevd   D12696   525      1 0x00000000
      [   92.495891] Call Trace:
      [   92.501560]  schedule+0x23/0x80
      [   92.502923]  schedule_preempt_disabled+0x5/0x10
      [   92.504645]  __mutex_lock+0x416/0x9e0
      [   92.510760]  __blkdev_get+0x73/0x4f0
      [   92.512220]  blkdev_get+0x12e/0x390
      [   92.518151]  do_dentry_open+0x1c3/0x2f0
      [   92.519815]  path_openat+0x5d9/0xdc0
      [   92.521437]  do_filp_open+0x7d/0xf0
      [   92.527365]  do_sys_open+0x1b8/0x250
      [   92.528831]  do_syscall_64+0x6e/0x270
      [   92.530341]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      [   92.931922] 1 lock held by systemd-udevd/525:
      [   92.933642]  #0: 00000000a2849e25 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x73/0x4f0
      ----------------------------------------
      
      The reason of deadlock turned out that wait_event_interruptible() in
      blk_queue_enter() got stuck with bdev->bd_mutex held at __blkdev_put()
      due to q->mq_freeze_depth == 1.
      
      ----------------------------------------
      [   92.787172] a.out           S12584   634    633 0x80000002
      [   92.789120] Call Trace:
      [   92.796693]  schedule+0x23/0x80
      [   92.797994]  blk_queue_enter+0x3cb/0x540
      [   92.803272]  generic_make_request+0xf0/0x3d0
      [   92.807970]  submit_bio+0x67/0x130
      [   92.810928]  submit_bh_wbc+0x15e/0x190
      [   92.812461]  __block_write_full_page+0x218/0x460
      [   92.815792]  __writepage+0x11/0x50
      [   92.817209]  write_cache_pages+0x1ae/0x3d0
      [   92.825585]  generic_writepages+0x5a/0x90
      [   92.831865]  do_writepages+0x43/0xd0
      [   92.836972]  __filemap_fdatawrite_range+0xc1/0x100
      [   92.838788]  filemap_write_and_wait+0x24/0x70
      [   92.840491]  __blkdev_put+0x69/0x1e0
      [   92.841949]  blkdev_close+0x16/0x20
      [   92.843418]  __fput+0xda/0x1f0
      [   92.844740]  task_work_run+0x87/0xb0
      [   92.846215]  do_exit+0x2f5/0xba0
      [   92.850528]  do_group_exit+0x34/0xb0
      [   92.852018]  SyS_exit_group+0xb/0x10
      [   92.853449]  do_syscall_64+0x6e/0x270
      [   92.854944]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      [   92.943530] 1 lock held by a.out/634:
      [   92.945105]  #0: 00000000a2849e25 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x3c/0x1e0
      ----------------------------------------
      
      The reason of q->mq_freeze_depth == 1 turned out that loop_set_status()
      forgot to call blk_mq_unfreeze_queue() at error paths for
      info->lo_encrypt_type != NULL case.
      
      ----------------------------------------
      [   37.509497] CPU: 2 PID: 634 Comm: a.out Tainted: G        W        4.16.0+ #457
      [   37.513608] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
      [   37.518832] RIP: 0010:blk_freeze_queue_start+0x17/0x40
      [   37.521778] RSP: 0018:ffffb0c2013e7c60 EFLAGS: 00010246
      [   37.524078] RAX: 0000000000000000 RBX: ffff8b07b1519798 RCX: 0000000000000000
      [   37.527015] RDX: 0000000000000002 RSI: ffffb0c2013e7cc0 RDI: ffff8b07b1519798
      [   37.529934] RBP: ffffb0c2013e7cc0 R08: 0000000000000008 R09: 47a189966239b898
      [   37.532684] R10: dad78b99b278552f R11: 9332dca72259d5ef R12: ffff8b07acd73678
      [   37.535452] R13: 0000000000004c04 R14: 0000000000000000 R15: ffff8b07b841e940
      [   37.538186] FS:  00007fede33b9740(0000) GS:ffff8b07b8e80000(0000) knlGS:0000000000000000
      [   37.541168] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   37.543590] CR2: 00000000206fdf18 CR3: 0000000130b30006 CR4: 00000000000606e0
      [   37.546410] Call Trace:
      [   37.547902]  blk_freeze_queue+0x9/0x30
      [   37.549968]  loop_set_status+0x67/0x3c0 [loop]
      [   37.549975]  loop_set_status64+0x3b/0x70 [loop]
      [   37.549986]  lo_ioctl+0x223/0x810 [loop]
      [   37.549995]  blkdev_ioctl+0x572/0x980
      [   37.550003]  block_ioctl+0x34/0x40
      [   37.550006]  do_vfs_ioctl+0xa7/0x6d0
      [   37.550017]  ksys_ioctl+0x6b/0x80
      [   37.573076]  SyS_ioctl+0x5/0x10
      [   37.574831]  do_syscall_64+0x6e/0x270
      [   37.576769]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      ----------------------------------------
      
      [1] https://syzkaller.appspot.com/bug?id=cd662bc3f6022c0979d01a262c318fab2ee9b56fSigned-off-by: 's avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: 's avatarsyzbot <bot+48594378e9851eab70bcd6f99327c7db58c5a28a@syzkaller.appspotmail.com>
      Fixes: ecdd0959 ("block/loop: fix race between I/O and set_status")
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: Jens Axboe <axboe@fb.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51a9580d
  14. 15 Mar, 2018 1 commit
    • Ross Zwisler's avatar
      loop: Fix lost writes caused by missing flag · 5f9113db
      Ross Zwisler authored
      commit 1d037577c323e5090ce281e96bc313ab2eee5be2 upstream.
      
      The following commit:
      
      commit aa4d8616 ("block: loop: switch to VFS ITER_BVEC")
      
      replaced __do_lo_send_write(), which used ITER_KVEC iterators, with
      lo_write_bvec() which uses ITER_BVEC iterators.  In this change, though,
      the WRITE flag was lost:
      
      -       iov_iter_kvec(&from, ITER_KVEC | WRITE, &kvec, 1, len);
      +       iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len);
      
      This flag is necessary for the DAX case because we make decisions based on
      whether or not the iterator is a READ or a WRITE in dax_iomap_actor() and
      in dax_iomap_rw().
      
      We end up going through this path in configurations where we combine a PMEM
      device with 4k sectors, a loopback device and DAX.  The consequence of this
      missed flag is that what we intend as a write actually turns into a read in
      the DAX code, so no data is ever written.
      
      The very simplest test case is to create a loopback device and try and
      write a small string to it, then hexdump a few bytes of the device to see
      if the write took.  Without this patch you read back all zeros, with this
      you read back the string you wrote.
      
      For XFS this causes us to fail or panic during the following xfstests:
      
      	xfs/074 xfs/078 xfs/216 xfs/217 xfs/250
      
      For ext4 we have a similar issue where writes never happen, but we don't
      currently have any xfstests that use loopback and show this issue.
      
      Fix this by restoring the WRITE flag argument to iov_iter_bvec().  This
      causes the xfstests to all pass.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@vger.kernel.org
      Fixes: commit aa4d8616 ("block: loop: switch to VFS ITER_BVEC")
      Reviewed-by: 's avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: 's avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: 's avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f9113db
  15. 22 Feb, 2018 1 commit
  16. 16 Feb, 2018 2 commits
  17. 03 Feb, 2018 2 commits
    • David Disseldorp's avatar
      null_blk: fix dev->badblocks leak · 2e194c9c
      David Disseldorp authored
      
      [ Upstream commit 1addb798e93893d33c8dfab743cd44f09fd7719a ]
      
      null_alloc_dev() allocates memory for dev->badblocks, but cleanup
      currently only occurs in the configfs release codepath, missing a number
      of other places.
      
      This bug was found running the blktests block/010 test, alongside
      kmemleak:
      rapido1:/blktests# ./check block/010
      ...
      rapido1:/blktests# echo scan > /sys/kernel/debug/kmemleak
      [  306.966708] kmemleak: 32 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
      rapido1:/blktests# cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffff88001f86d000 (size 4096):
        comm "modprobe", pid 231, jiffies 4294892415 (age 318.252s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff814b0379>] kmemleak_alloc+0x49/0xa0
          [<ffffffff810f180f>] kmem_cache_alloc+0x9f/0xe0
          [<ffffffff8124e45f>] badblocks_init+0x2f/0x60
          [<ffffffffa0019fae>] 0xffffffffa0019fae
          [<ffffffffa0021273>] nullb_device_badblocks_store+0x63/0x130 [null_blk]
          [<ffffffff810004cd>] do_one_initcall+0x3d/0x170
          [<ffffffff8109fe0d>] do_init_module+0x56/0x1e9
          [<ffffffff8109ebd7>] load_module+0x1c47/0x26a0
          [<ffffffff8109f819>] SyS_finit_module+0xa9/0xd0
          [<ffffffff814b4f60>] entry_SYSCALL_64_fastpath+0x13/0x94
      
      Fixes: 2f54a613 ("nullb: badbblocks support")
      Reviewed-by: 's avatarShaohua Li <shli@fb.com>
      Signed-off-by: 's avatarDavid Disseldorp <ddiss@suse.de>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e194c9c
    • Linus Torvalds's avatar
      loop: fix concurrent lo_open/lo_release · d5e06a18
      Linus Torvalds authored
      commit ae665016 upstream.
      
      范龙飞 reports that KASAN can report a use-after-free in __lock_acquire.
      The reason is due to insufficient serialization in lo_release(), which
      will continue to use the loop device even after it has decremented the
      lo_refcnt to zero.
      
      In the meantime, another process can come in, open the loop device
      again as it is being shut down. Confusion ensues.
      Reported-by: 's avatar范龙飞 <long7573@126.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5e06a18
  18. 17 Jan, 2018 2 commits
  19. 20 Dec, 2017 1 commit
  20. 30 Nov, 2017 1 commit