1. 04 Dec, 2022 2 commits
    • Jens Axboe's avatar
      Merge tag 'floppy-for-6.2' of https://github.com/evdenis/linux-floppy into for-6.2/block · b1476451
      Jens Axboe authored
      Pull floppy fix from Denis:
      
      "Floppy patch for 6.2
      
       The patch from Yuan Can fixes a memory leak in floppy init code.
      
       Signed-off-by: Denis Efremov <efremov@linux.com>"
      
      * tag 'floppy-for-6.2' of https://github.com/evdenis/linux-floppy:
        floppy: Fix memory leak in do_floppy_init()
      b1476451
    • Yuan Can's avatar
      floppy: Fix memory leak in do_floppy_init() · f8ace2e3
      Yuan Can authored
      A memory leak was reported when floppy_alloc_disk() failed in
      do_floppy_init().
      
      unreferenced object 0xffff888115ed25a0 (size 8):
        comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)
        hex dump (first 8 bytes):
          00 ac 67 5b 81 88 ff ff                          ..g[....
        backtrace:
          [<000000007f457abb>] __kmalloc_node+0x4c/0xc0
          [<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180
          [<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130
          [<0000000066007fd7>] 0xffffffffc06b8b08
          [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0
          [<00000000e26d04ee>] do_init_module+0x1a4/0x680
          [<000000001bb22407>] load_module+0x6249/0x7110
          [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200
          [<000000007bddca46>] do_syscall_64+0x35/0x80
          [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
      unreferenced object 0xffff88810fc30540 (size 32):
        comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)
        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:
          [<000000007f457abb>] __kmalloc_node+0x4c/0xc0
          [<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130
          [<0000000066007fd7>] 0xffffffffc06b8b08
          [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0
          [<00000000e26d04ee>] do_init_module+0x1a4/0x680
          [<000000001bb22407>] load_module+0x6249/0x7110
          [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200
          [<000000007bddca46>] do_syscall_64+0x35/0x80
          [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      If the floppy_alloc_disk() failed, disks of current drive will not be set,
      thus the lastest allocated set->tag cannot be freed in the error handling
      path. A simple call graph shown as below:
      
       floppy_module_init()
         floppy_init()
           do_floppy_init()
             for (drive = 0; drive < N_DRIVE; drive++)
               blk_mq_alloc_tag_set()
                 blk_mq_alloc_tag_set_tags()
                   blk_mq_realloc_tag_set_tags() # set->tag allocated
               floppy_alloc_disk()
                 blk_mq_alloc_disk() # error occurred, disks failed to allocated
      
             ->out_put_disk:
             for (drive = 0; drive < N_DRIVE; drive++)
               if (!disks[drive][0]) # the last disks is not set and loop break
                 break;
               blk_mq_free_tag_set() # the latest allocated set->tag leaked
      
      Fix this problem by free the set->tag of current drive before jump to
      error handling path.
      
      Cc: stable@vger.kernel.org
      Fixes: 302cfee1 ("floppy: use a separate gendisk for each media format")
      Signed-off-by: default avatarYuan Can <yuancan@huawei.com>
      [efremov: added stable list, changed title]
      Signed-off-by: default avatarDenis Efremov <efremov@linux.com>
      f8ace2e3
  2. 03 Dec, 2022 1 commit
  3. 02 Dec, 2022 6 commits
  4. 01 Dec, 2022 13 commits
  5. 30 Nov, 2022 7 commits
  6. 29 Nov, 2022 7 commits
  7. 25 Nov, 2022 1 commit
    • Ye Bin's avatar
      blk-mq: fix possible memleak when register 'hctx' failed · 4b7a21c5
      Ye Bin authored
      There's issue as follows when do fault injection test:
      unreferenced object 0xffff888132a9f400 (size 512):
        comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff  ...........2....
          08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00  ...2............
        backtrace:
          [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0
          [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0
          [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230
          [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910
          [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0
          [<00000000a2a34657>] 0xffffffffa2ad310f
          [<00000000b173f718>] 0xffffffffa2af824a
          [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0
          [<00000000f32fdf93>] do_init_module+0xdf/0x320
          [<00000000cbe8541e>] load_module+0x3006/0x3390
          [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0
          [<00000000a1a29ae8>] do_syscall_64+0x35/0x80
          [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      Fault injection context as follows:
       kobject_add
       blk_mq_register_hctx
       blk_mq_sysfs_register
       blk_register_queue
       device_add_disk
       null_add_dev.part.0 [null_blk]
      
      As 'blk_mq_register_hctx' may already add some objects when failed halfway,
      but there isn't do fallback, caller don't know which objects add failed.
      To solve above issue just do fallback when add objects failed halfway in
      'blk_mq_register_hctx'.
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20221117022940.873959-1-yebin@huaweicloud.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      4b7a21c5
  8. 24 Nov, 2022 3 commits
    • Ye Bin's avatar
      block: fix crash in 'blk_mq_elv_switch_none' · 90b0296e
      Ye Bin authored
      Syzbot found the following issue:
      general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]
      CPU: 0 PID: 5234 Comm: syz-executor931 Not tainted 6.1.0-rc3-next-20221102-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
      RIP: 0010:__elevator_get block/elevator.h:94 [inline]
      RIP: 0010:blk_mq_elv_switch_none block/blk-mq.c:4593 [inline]
      RIP: 0010:__blk_mq_update_nr_hw_queues block/blk-mq.c:4658 [inline]
      RIP: 0010:blk_mq_update_nr_hw_queues+0x304/0xe40 block/blk-mq.c:4709
      RSP: 0018:ffffc90003cdfc08 EFLAGS: 00010206
      RAX: 0000000000000000 RBX: dffffc0000000000 RCX: 0000000000000000
      RDX: 000000000000001d RSI: 0000000000000002 RDI: 00000000000000e8
      RBP: ffff88801dbd0000 R08: ffff888027c89398 R09: ffffffff8de2e517
      R10: fffffbfff1bc5ca2 R11: 0000000000000000 R12: ffffc90003cdfc70
      R13: ffff88801dbd0008 R14: ffff88801dbd03f8 R15: ffff888027c89380
      FS:  0000555557259300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000005d84c8 CR3: 000000007a7cb000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       nbd_start_device+0x153/0xc30 drivers/block/nbd.c:1355
       nbd_start_device_ioctl drivers/block/nbd.c:1405 [inline]
       __nbd_ioctl drivers/block/nbd.c:1481 [inline]
       nbd_ioctl+0x5a1/0xbd0 drivers/block/nbd.c:1521
       blkdev_ioctl+0x36e/0x800 block/ioctl.c:614
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:870 [inline]
       __se_sys_ioctl fs/ioctl.c:856 [inline]
       __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      As after dd6f7f17 commit move '__elevator_get(qe->type)' before set
      'qe->type', so will lead to access wild pointer.
      To solve above issue get 'qe->type' after set 'qe->type'.
      
      Reported-by: syzbot+746a4eece09f86bc39d7@syzkaller.appspotmail.com
      Fixes:dd6f7f17("block: add proper helpers for elevator_type module refcount management")
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Link: https://lore.kernel.org/r/20221107033956.3276891-1-yebin@huaweicloud.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      90b0296e
    • Wang ShaoBo's avatar
      drbd: destroy workqueue when drbd device was freed · 8692814b
      Wang ShaoBo authored
      A submitter workqueue is dynamically allocated by init_submitter()
      called by drbd_create_device(), we should destroy it when this
      device is not needed or destroyed.
      
      Fixes: 113fef9e ("drbd: prepare to queue write requests on a submit worker")
      Signed-off-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Link: https://lore.kernel.org/r/20221124015817.2729789-3-bobo.shaobowang@huawei.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      8692814b
    • Wang ShaoBo's avatar
      drbd: remove call to memset before free device/resource/connection · 6e7b854e
      Wang ShaoBo authored
      This revert c2258ffc ("drbd: poison free'd device, resource and
      connection structs"), add memset is odd here for debugging, there are
      some methods to accurately show what happened, such as kdump.
      Signed-off-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Link: https://lore.kernel.org/r/20221124015817.2729789-2-bobo.shaobowang@huawei.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      6e7b854e