Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 3月, 2023 2 次提交
    • M
      scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress · 744050c7
      由 Mike Christie 提交于 
      mainline inclusion
from mainline-v6.2-rc6
commit 6f1d64b1
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f1d64b13097e85abda0f91b5638000afc5f9a06

----------------------------------------

Bug report and analysis from Ding Hui.

During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:

[  276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[  276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[  276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G            E      6.1.0-rc8+ #3
[  276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[  276.944470] Call Trace:
[  276.944943]  <TASK>
[  276.945397]  dump_stack_lvl+0x34/0x48
[  276.945887]  print_address_description.constprop.0+0x86/0x1e7
[  276.946421]  print_report+0x36/0x4f
[  276.947358]  kasan_report+0xad/0x130
[  276.948234]  kasan_check_range+0x35/0x1c0
[  276.948674]  _raw_spin_lock_bh+0x78/0xe0
[  276.949989]  iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]
[  276.951765]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]
[  276.952185]  dev_attr_show+0x3f/0x80
[  276.953005]  sysfs_kf_seq_show+0x1fb/0x3e0
[  276.953401]  seq_read_iter+0x402/0x1020
[  276.954260]  vfs_read+0x532/0x7b0
[  276.955113]  ksys_read+0xed/0x1c0
[  276.955952]  do_syscall_64+0x38/0x90
[  276.956347]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.956769] RIP: 0033:0x7f5d3a679222
[  276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[  276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222
[  276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003
[  276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000
[  276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000
[  276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58
[  276.960536]  </TASK>
[  276.961357] Allocated by task 2209:
[  276.961756]  kasan_save_stack+0x1e/0x40
[  276.962170]  kasan_set_track+0x21/0x30
[  276.962557]  __kasan_kmalloc+0x7e/0x90
[  276.962923]  __kmalloc+0x5b/0x140
[  276.963308]  iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]
[  276.963712]  iscsi_session_setup+0xda/0xba0 [libiscsi]
[  276.964078]  iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]
[  276.964431]  iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]
[  276.964793]  iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]
[  276.965153]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.965546]  netlink_unicast+0x4d5/0x7b0
[  276.965905]  netlink_sendmsg+0x78d/0xc30
[  276.966236]  sock_sendmsg+0xe5/0x120
[  276.966576]  ____sys_sendmsg+0x5fe/0x860
[  276.966923]  ___sys_sendmsg+0xe0/0x170
[  276.967300]  __sys_sendmsg+0xc8/0x170
[  276.967666]  do_syscall_64+0x38/0x90
[  276.968028]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.968773] Freed by task 2209:
[  276.969111]  kasan_save_stack+0x1e/0x40
[  276.969449]  kasan_set_track+0x21/0x30
[  276.969789]  kasan_save_free_info+0x2a/0x50
[  276.970146]  __kasan_slab_free+0x106/0x190
[  276.970470]  __kmem_cache_free+0x133/0x270
[  276.970816]  device_release+0x98/0x210
[  276.971145]  kobject_cleanup+0x101/0x360
[  276.971462]  iscsi_session_teardown+0x3fb/0x530 [libiscsi]
[  276.971775]  iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]
[  276.972143]  iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]
[  276.972485]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.972808]  netlink_unicast+0x4d5/0x7b0
[  276.973201]  netlink_sendmsg+0x78d/0xc30
[  276.973544]  sock_sendmsg+0xe5/0x120
[  276.973864]  ____sys_sendmsg+0x5fe/0x860
[  276.974248]  ___sys_sendmsg+0xe0/0x170
[  276.974583]  __sys_sendmsg+0xc8/0x170
[  276.974891]  do_syscall_64+0x38/0x90
[  276.975216]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

We can easily reproduce by two tasks:
1. while :; do iscsiadm -m node --login; iscsiadm -m node --logout; done
2. while :; do cat \
/sys/devices/platform/host*/iscsi_host/host*/ipaddress; done

            iscsid              |        cat
--------------------------------+---------------------------------------
|- iscsi_sw_tcp_session_destroy |
  |- iscsi_session_teardown     |
    |- device_release           |
      |- iscsi_session_release  ||- dev_attr_show
        |- kfree                |  |- show_host_param_
                                |             ISCSI_HOST_PARAM_IPADDRESS
                                |    |- iscsi_sw_tcp_host_get_param
                                |      |- r/w tcp_sw_host->session (UAF)
  |- iscsi_host_remove          |
  |- iscsi_host_free            |

Fix the above bug by splitting the session removal into 2 parts:

 1. removal from iSCSI class which includes sysfs and removal from host
    tracking.

 2. freeing of session.

During iscsi_tcp host and session removal we can remove the session from
sysfs then remove the host from sysfs. At this point we know userspace is
not accessing the kernel via sysfs so we can free the session and host.

Link: https://lore.kernel.org/r/20230117193937.21244-2-michael.christie@oracle.comSigned-off-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Acked-by: NDing Hui <dinghui@sangfor.com.cn>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
conflicts:
	drivers/scsi/iscsi_tcp.c
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      744050c7
    • M
      scsi: iscsi: Move pool freeing · 7883e908
      由 Mike Christie 提交于 
      mainline inclusion
from mainline-v5.14-rc1
commit a1f3486b
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a1f3486b3b095ed2259d7a1fc021a8b6e72a5365

----------------------------------------

This doesn't fix any bugs, but it makes more sense to free the pool after
we have removed the session. At that time we know nothing is touching any
of the session fields, because all devices have been removed and scans are
stopped.

Link: https://lore.kernel.org/r/20210525181821.7617-19-michael.christie@oracle.comReviewed-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NMike Christie <michael.christie@oracle.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      7883e908
  3. 09 3月, 2023 1 次提交
    • Z
      Revert "scsi: fix iscsi rescan fails to create block" · 61b78156
      由 Zhong Jinghua 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188150, https://gitee.com/openeuler/kernel/issues/I643OL

----------------------------------------

This reverts commit e06779a6.

This commit has a soft lock problem:

watchdog: BUG: soft lockup - CPU#22 stuck for 67s! [iscsid:16369]
 Call Trace:
  scsi_remove_target+0x548/0x7b0
  ? sdev_store_delete+0x90/0x90
  ? __mutex_lock_slowpath+0x10/0x10
  ? device_remove_class_symlinks+0x1b0/0x1b0
  __iscsi_unbind_session+0x16b/0x250 [scsi_transport_iscsi]
  iscsi_remove_session+0x1d3/0x2f0 [scsi_transport_iscsi]
  iscsi_session_remove+0x5c/0x80 [libiscsi]
  iscsi_sw_tcp_session_destroy+0xd3/0x160 [iscsi_tcp]
  iscsi_if_rx+0x2369/0x5060 [scsi_transport_iscsi]

The reason is that if other threads hold the reference count of the
kobject while waiting for the device to be released, it will keep
waiting in a loop.

Fixes: e06779a6 ("scsi: fix iscsi rescan fails to create block")
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      61b78156
  5. 15 2月, 2023 3 次提交
  7. 13 2月, 2023 4 次提交
  9. 07 2月, 2023 1 次提交
    • Z
      scsi: fix iscsi rescan fails to create block · e06779a6
      由 Zhong Jinghua 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188150, https://gitee.com/openeuler/kernel/issues/I643OL
CVE: NA

--------------------------------

When the three iscsi operations delete, logout, and rescan are concurrent
at the same time, there is a probability of failure to add disk through
device_add_disk(). The concurrent process is as follows:

T0: scan host // echo 1 > /sys/devices/platform/host1/scsi_host/host1/scan
T1: delete target // echo 1 > /sys/devices/platform/host1/session1/target1:0:0/1:0:0:1/delete
T2: logout // iscsiadm -m node --login
T3: T2 scsi_queue_work
T4: T0 bus_probe_device

T0                          T1                     T2                     T3
scsi_scan_target
 mutex_lock(&shost->scan_mutex);
  __scsi_scan_target
   scsi_report_lun_scan
    scsi_add_lun
     scsi_sysfs_add_sdev
      device_add
       kobject_add
       //create session1/target1:0:0/1:0:0:1/
       ...
       bus_probe_device
       // Create block asynchronously
 mutex_unlock(&shost->scan_mutex);
                       sdev_store_delete
                        scsi_remove_device
                         device_remove_file
                          mutex_lock(scan_mutex)
                           __scsi_remove_device
                            res = scsi_device_set_state(sdev, SDEV_CANCEL)
                                             iscsi_if_recv_msg
                                              scsi_queue_work
                                                                 __iscsi_unbind_session
                                                                 session->target_id = ISCSI_MAX_TARGET
                                                                   __scsi_remove_target
                                                                   sdev->sdev_state == SDEV_CANCEL
                                                                   continue;
                                                                   // end, No delete kobject 1:0:0:1
                                             iscsi_if_recv_msg
                                              transport->destroy_session(session)
                                               __iscsi_destroy_session
                                               iscsi_session_teardown
                                                iscsi_remove_session
                                                 __iscsi_unbind_session
                                                  iscsi_session_event
                                                 device_del
                                                 // delete session
T4:
// create the block, its parent is 1:0:0:1
// If kobject 1:0:0:1 does not exist, it won't go down
__device_attach_async_helper
 device_lock
 ...
 __device_attach_driver
  driver_probe_device
   really_probe
    sd_probe
     device_add_disk
      register_disk
       device_add
      // error

The block is created after the seesion is deleted.
When T2 deletes the session, it will mark block'parent 1:0:01 as unusable:
T2
device_del
 kobject_del
  sysfs_remove_dir
   __kernfs_remove
   // Mark the children under the session as unusable
    while ((pos = kernfs_next_descendant_post(pos, kn)))
		if (kernfs_active(pos))
			atomic_add(KN_DEACTIVATED_BIAS, &pos->active);

Then, create the block:
T4
device_add
 kobject_add
  kobject_add_varg
   kobject_add_internal
    create_dir
     sysfs_create_dir_ns
      kernfs_create_dir_ns
       kernfs_add_one
        if ((parent->flags & KERNFS_ACTIVATED) && !kernfs_active(parent))
		goto out_unlock;
		// return error

This error will cause a warning:
kobject_add_internal failed for block (error: -2 parent: 1:0:0:1).
In the lower version (such as 5.10), there is no corresponding error handling, continuing
to go down will trigger a kernel panic, so cc stable.

Therefore, creating the block should not be done after deleting the session.
More practically, we should ensure that the target under the session is deleted first,
and then the session is deleted. In this way, there are two possibilities:

1) if the process(T1) of deleting the target execute first, it will grab the device_lock(),
and the process(T4) of creating the block will wait for the deletion to complete.
Then, block's parent 1:0:0:1 has been deleted, it won't go down.

2) if the process(T4) of creating block execute first, it will grab the device_lock(),
and the process(T1) of deleting the target will wait for the creation block to complete.
Then, the process(T2) of deleting the session should need wait for the deletion to complete.

Fix it by removing the judgment of state equal to SDEV_CANCEL in
__scsi_remove_target() to ensure the order of deletion. Then, it will wait for
T1's mutex_lock(scan_mutex) and device_del() in __scsi_remove_device() will wait for
T4's device_lock(dev).
But we found that such a fix would cause the previous problem:
commit 81b6c999 ("scsi: core: check for device state in __scsi_remove_target()").
So we use scsi_device_try_get() instead of get_devcie() to fix the previous problem.

Fixes: 81b6c999 ("scsi: core: check for device state in __scsi_remove_target()")
Cc: <stable@vger.kernel.org>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      e06779a6
  11. 31 1月, 2023 1 次提交
    • Z
      scsi: ses: fix slab-out-of-bounds in ses_enclosure_data_process · d63b2ed5
      由 Zhang Wensheng 提交于 
      hulk inclusion
category: bugfix
bugzilla: 187025, https://gitee.com/openeuler/kernel/issues/I6B1LN
CVE: NA

--------------------------------

Kasan report a bug like below:
[  494.865170] ==================================================================
[  494.901335] BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x234/0x6f0 [ses]
[  494.901347] Write of size 1 at addr ffff8882f3181a70 by task systemd-udevd/1704
[  494.931929] i801_smbus 0000:00:1f.4: SPD Write Disable is set

[  494.944092] CPU: 12 PID: 1704 Comm: systemd-udevd Tainted: G
[  494.944101] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 7.01 11/13/2019
[  494.964003] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt
[  494.978532] Call Trace:
[  494.978544]  dump_stack+0xbe/0xf9
[  494.978558]  print_address_description.constprop.0+0x19/0x130
[  495.092838]  ? ses_enclosure_data_process+0x234/0x6f0 [ses]
[  495.092846]  __kasan_report.cold+0x68/0x80
[  495.092855]  ? __kasan_kmalloc.constprop.0+0x71/0xd0
[  495.092862]  ? ses_enclosure_data_process+0x234/0x6f0 [ses]
[  495.092868]  kasan_report+0x3a/0x50
[  495.092875]  ses_enclosure_data_process+0x234/0x6f0 [ses]
[  495.092882]  ? mutex_unlock+0x1d/0x40
[  495.092889]  ses_intf_add+0x57f/0x910 [ses]
[  495.092900]  class_interface_register+0x26d/0x290
[  495.092906]  ? class_destroy+0xd0/0xd0
[  495.092912]  ? 0xffffffffc0bf8000
[  495.092919]  ses_init+0x18/0x1000 [ses]
[  495.092927]  do_one_initcall+0xcb/0x370
[  495.092934]  ? initcall_blacklisted+0x1b0/0x1b0
[  495.092942]  ? create_object.isra.0+0x330/0x3a0
[  495.092950]  ? kasan_unpoison_shadow+0x33/0x40
[  495.092957]  ? kasan_unpoison_shadow+0x33/0x40
[  495.092966]  do_init_module+0xe4/0x3a0
[  495.092972]  load_module+0xd0a/0xdd0
[  495.092980]  ? layout_and_allocate+0x300/0x300
[  495.092989]  ? seccomp_run_filters+0x1d6/0x2c0
[  495.092999]  ? kernel_read_file_from_fd+0xb3/0xe0
[  495.093006]  __se_sys_finit_module+0x11b/0x1b0
[  495.093012]  ? __ia32_sys_init_module+0x40/0x40
[  495.093023]  ? __audit_syscall_entry+0x226/0x290
[  495.093032]  do_syscall_64+0x33/0x40
[  495.093041]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  495.093046] RIP: 0033:0x7f39c3376089
[  495.093054] Code: 00 48 81 c4 80 00 00 00 89 f0 c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e7 dd 0b 00 f7 d8 64 89 01 48
[  495.093058] RSP: 002b:00007ffdc6009e18 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  495.093068] RAX: ffffffffffffffda RBX: 000055d4192801c0 RCX: 00007f39c3376089
[  495.093072] RDX: 0000000000000000 RSI: 00007f39c2fae99d RDI: 000000000000000f
[  495.093076] RBP: 00007f39c2fae99d R08: 0000000000000000 R09: 0000000000000001
[  495.093080] R10: 000000000000000f R11: 0000000000000246 R12: 0000000000000000
[  495.093084] R13: 000055d419282e00 R14: 0000000000020000 R15: 000055d41927f1f0

[  495.093091] Allocated by task 1704:
[  495.093098]  kasan_save_stack+0x1b/0x40
[  495.093105]  __kasan_kmalloc.constprop.0+0xc2/0xd0
[  495.093111]  ses_enclosure_data_process+0x65d/0x6f0 [ses]
[  495.093117]  ses_intf_add+0x57f/0x910 [ses]
[  495.093123]  class_interface_register+0x26d/0x290
[  495.093129]  ses_init+0x18/0x1000 [ses]
[  495.093134]  do_one_initcall+0xcb/0x370
[  495.093139]  do_init_module+0xe4/0x3a0
[  495.093144]  load_module+0xd0a/0xdd0
[  495.093150]  __se_sys_finit_module+0x11b/0x1b0
[  495.093155]  do_syscall_64+0x33/0x40
[  495.093162]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[  495.093168] The buggy address belongs to the object at ffff8882f3181a40
                which belongs to the cache kmalloc-64 of size 64
[  495.093173] The buggy address is located 48 bytes inside of
                64-byte region [ffff8882f3181a40, ffff8882f3181a80)
[  495.093175] The buggy address belongs to the page:
[  495.093181] page:ffffea000bcc6000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2f3180
[  495.093186] head:ffffea000bcc6000 order:2 compound_mapcount:0 compound_pincount:0
[  495.093194] flags: 0x17ffe0000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff)
[  495.093204] raw: 017ffe0000010200 ffffea0016e5fb08 ffffea0016921508 ffff888100050e00
[  495.093211] raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
[  495.093213] page dumped because: kasan: bad access detected

[  495.093216] Memory state around the buggy address:
[  495.093222]  ffff8882f3181900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  495.093227]  ffff8882f3181980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  495.093231] >ffff8882f3181a00: fc fc fc fc fc fc fc fc 00 00 00 00 01 fc fc fc
[  495.093234]                                                              ^
[  495.093239]  ffff8882f3181a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  495.093244]  ffff8882f3181b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  495.093246] ==================================================================

After analysis on vmcore, it was found that the line "desc_ptr[len] =
'\0';" has slab-out-of-bounds problem in ses_enclosure_data_process.
In ses_enclosure_data_process, "desc_ptr" point to "buf", so it have
to be limited in the memory of "buf", however. although there is
"desc_ptr >= buf + page7_len" judgment, it does not work because
"desc_ptr + 4 + len" may bigger than "buf + page7_len", which will
lead to slab-out-of-bounds problem.
Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com>
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      d63b2ed5
  13. 23 12月, 2022 2 次提交
  15. 13 12月, 2022 1 次提交
  17. 12 12月, 2022 1 次提交
    • Y
      blk-mq: fix kabi broken due to request_wrapper · a4814b31
      由 Yu Kuai 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65K8D
CVE: NA

--------------------------------

Before commit f60df4a0 ("blk-mq: fix kabi broken in struct
request"), drivers will got cmd address right after request, however,
after this commit, drivers will got cmd address after request_wrapper
instead, which is bigger than request and will cause compatibility
issues.

Fix the problem by placing request_wrapper behind cmd, so that the
cmd address for drivers will stay the same.

Before commit:		|request|cmd|
After commit:		|request|request_wrapper|cmd|
With this patch:	|request|cmd|request_wrapper|

Performance test: arm64 Kunpeng-920 96 core

1) null_blk setup:
modprobe null_blk nr_devices=0 &&
    udevadm settle &&
    cd /sys/kernel/config/nullb &&
    mkdir nullb0 &&
    cd nullb0 &&
    echo 0 > completion_nsec &&
    echo 512 > blocksize &&
    echo 0 > home_node &&
    echo 0 > irqmode &&
    echo 1024 > size &&
    echo 0 > memory_backed &&
    echo 2 > queue_mode &&
	echo 4096 > hw_queue_depth &&
	echo 96 > submit_queues &&
    echo 1 > power

2) fio test script:
[global]
ioengine=libaio
direct=1
numjobs=96
iodepth=32
bs=4k
rw=randwrite
allow_mounted_write=0
time_based
runtime=60
group_reporting=1
ioscheduler=none
cpus_allowed_policy=split
cpus_allowed=0-95

[test]
filename=/dev/nullb0

3) iops test result:

without this patch:	23.9M
with this patch:	24.1M

Fixes: f60df4a0 ("blk-mq: fix kabi broken in struct request")
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      a4814b31
  19. 02 12月, 2022 2 次提交
  21. 25 11月, 2022 1 次提交
  23. 21 11月, 2022 1 次提交
  25. 18 11月, 2022 10 次提交
  27. 15 11月, 2022 10 次提交