Skip to content

GitLab

Switch branch/tag
  1. 28 Apr, 2023 1 commit
  3. 24 Apr, 2023 1 commit
    • Gleb Chesnokov's avatar
      scstadmin.spec: Fix RPM build errors · bef30fd6
      Gleb Chesnokov authored 
      This patch fixes RPM build errors caused by incorrect file paths:

  RPM build errors:
    File must begin with "/": %{perl_vendorlib}/SCST
    File must begin with "/": %{perl_vendorarch}/auto/SCST_SCST

For some reasons, the perl_vendorlib and perl_vendorarch variables may
not be defined by default on newer RHEL systems.

Therefore, assign the variables explicitly to avoid these errors.
      bef30fd6
  5. 17 Apr, 2023 3 commits
    • Brian Meagher's avatar
      scst_lib,scst_sysfs: Add aen_disabled setting · c326e968
      Brian Meagher authored 
      Add a setting to scst_tgt that can prevent scst_gen_aen_or_ua from
generating an AEN, even if the underlying transport is capable of
transmitting them.  It will instead generate a UA.
      c326e968
    • Gleb Chesnokov's avatar
      scst_lib: Avoid holding scst_mutex during sess_tgt_dev_list access · 33b8323a
      Gleb Chesnokov authored 
      In the previous commit, we introduced the use of RCU protection when
accessing sess_tgt_dev_list in scst_get_max_lun_commands().

As a result, we can now drop the use of scst_mutex when accessing the
list.
      33b8323a
    • Gleb Chesnokov's avatar
      scst: Use RCU read lock when accessing sess_tgt_dev_list · c9198bb0
      Gleb Chesnokov authored 
      We must always protect sess_tgt_dev_list during access and
modification.

There are two mechanisms for that:

- tgt_dev_list_mutex for list modifications.
- RCU for read-only list accesses.

Currently, the codebase doesn't consistently apply protection when
accessing the list. Fix this by adding RCU protection.

See also commit 3e64094b ("scst_sysfs: Do not suspend I/O for LUN
management").
      c9198bb0
  7. 12 Apr, 2023 1 commit
    • Gleb Chesnokov's avatar
      qla2x00t-32gbit: Fix memory leak in qla2x00_probe_one() · 6ff72c81
      Gleb Chesnokov authored 
      
There is a memory leak reported by kmemleak:

  unreferenced object 0xffffc900003f0000 (size 12288):
    comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)
    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:
      [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110
      [<0000000001906886>] __vmalloc_node+0xbd/0x150
      [<000000005bb4dc34>] vmalloc+0x25/0x30
      [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]
      [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]
      [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0

The root cause is traced to an error-handling path in qla2x00_probe_one()
when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is
used to record the port information and it is allocated in
qla2x00_create_host(). However, it is not released in the error handling
path "probe_failed".

Fix this by freeing the memory of "scan.l" when an error occurs in the
adapter initialization process.

Fixes: a4239945b8ad ("scsi: qla2xxx: Add switch command to simplify fabric discovery")
Signed-off-by: default avatarLi Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230325110004.363898-1-lizetao1@huawei.com

Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
[ commit 85ade4010e13 upstream ]
      6ff72c81
  9. 11 Apr, 2023 2 commits
  11. 06 Apr, 2023 3 commits
  13. 05 Apr, 2023 3 commits
  15. 04 Apr, 2023 2 commits
  17. 03 Apr, 2023 1 commit
  19. 31 Mar, 2023 3 commits
    • Gleb Chesnokov's avatar
      scst_vdisk: Introduce the function vdev_set_t10_dev_id() · 4e8ec649
      Gleb Chesnokov authored 
      This patch reduces code duplication.

This patch does not change any functionality.
      4e8ec649
    • Gleb Chesnokov's avatar
      qla2x00t-32gbit: Synchronize the IOCB count to be in order · db581fc0
      Gleb Chesnokov authored 
      
A system hang was observed with the following call trace:

BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1
Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022
RIP: 0010:__wake_up_common+0x55/0x190
Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d
      40 e8 48 8d 43 08 48 89 04 24 48 89 c6\
      49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31
      ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d
RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018
RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8
R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000)
	knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0
Call Trace:
    <TASK>
    __wake_up_common_lock+0x83/0xd0
    qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx]
    __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc]
    nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc]
    nvme_fc_delete_association+0x1bf/0x220 [nvme_fc]
    ? nvme_remove_namespaces+0x9f/0x140 [nvme_core]
    nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core]
    nvme_sysfs_delete+0x5f/0x70 [nvme_core]
    kernfs_fop_write_iter+0x12b/0x1c0
    vfs_write+0x2a3/0x3b0
    ksys_write+0x5f/0xe0
    do_syscall_64+0x5c/0x90
    ? syscall_exit_work+0x103/0x130
    ? syscall_exit_to_user_mode+0x12/0x30
    ? do_syscall_64+0x69/0x90
    ? exit_to_user_mode_loop+0xd0/0x130
    ? exit_to_user_mode_prepare+0xec/0x100
    ? syscall_exit_to_user_mode+0x12/0x30
    ? do_syscall_64+0x69/0x90
    ? syscall_exit_to_user_mode+0x12/0x30
    ? do_syscall_64+0x69/0x90
    entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x7f815cd3eb97

The IOCB counts are out of order and that would block any commands from
going out and subsequently hang the system. Synchronize the IOCB count to
be in correct order.

Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarQuinn Tran <qutran@marvell.com>
Signed-off-by: default avatarNilesh Javali <njavali@marvell.com>
Link: https://lore.kernel.org/r/20230313043711.13500-3-njavali@marvell.com

Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: default avatarJohn Meneghini <jmeneghi@redhat.com>
Tested-by: default avatarLin Li <lilin@redhat.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
[ commit d3affdeb400f upstream ]
      db581fc0
    • Gleb Chesnokov's avatar
      qla2x00t-32gbit: Perform lockless command completion in abort path · c477c7a4
      Gleb Chesnokov authored 
      
While adding and removing the controller, the following call trace was
observed:

WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50
CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1
RIP: 0010:dma_free_attrs+0x33/0x50

Call Trace:
   qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]
   qla2x00_abort_srb+0x8e/0x250 [qla2xxx]
   ? ql_dbg+0x70/0x100 [qla2xxx]
   __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]
   qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]
   qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]
   qla2x00_remove_one+0x364/0x400 [qla2xxx]
   pci_device_remove+0x36/0xa0
   __device_release_driver+0x17a/0x230
   device_release_driver+0x24/0x30
   pci_stop_bus_device+0x68/0x90
   pci_stop_and_remove_bus_device_locked+0x16/0x30
   remove_store+0x75/0x90
   kernfs_fop_write_iter+0x11c/0x1b0
   new_sync_write+0x11f/0x1b0
   vfs_write+0x1eb/0x280
   ksys_write+0x5f/0xe0
   do_syscall_64+0x5c/0x80
   ? do_user_addr_fault+0x1d8/0x680
   ? do_syscall_64+0x69/0x80
   ? exc_page_fault+0x62/0x140
   ? asm_exc_page_fault+0x8/0x30
   entry_SYSCALL_64_after_hwframe+0x44/0xae

The command was completed in the abort path during driver unload with a
lock held, causing the warning in abort path. Hence complete the command
without any lock held.
Reported-by: default avatarLin Li <lilin@redhat.com>
Tested-by: default avatarLin Li <lilin@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarNilesh Javali <njavali@marvell.com>
Link: https://lore.kernel.org/r/20230313043711.13500-2-njavali@marvell.com

Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: default avatarJohn Meneghini <jmeneghi@redhat.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
[ commit 0367076b0817 upstream ]
      c477c7a4
  21. 20 Mar, 2023 1 commit
    • Brian Meagher's avatar
      scst_vdisk, scstadmin: Allow t10_dev_id to be stored before cluster_mode · da4f7c66
      Brian Meagher authored 
      Since cluster_mode relies upon the t10_dev_id to generate a namespace, once
cluster_mode is set the t10_dev_id can no longer be changed.

However, because cluster_mode is listed as one of the various add_dev_params,
this meant that it would be set earlier than t10_dev_id when scstadmin
processes scst.conf

Rectify by adding t10_dev_id to fileio_add_dev_params, etc and modifying the
SCST.pm openDevice so that cluster_mode is set last.
      da4f7c66
  23. 13 Mar, 2023 12 commits
  25. 12 Mar, 2023 7 commits