[PATCH 0/9 V5] iscsi fixes and cleanups

From: Mike Christie <michael.christie@oracle.com>
To: lduncan@suse.com, cleech@redhat.com, martin.petersen@oracle.com,
	linux-scsi@vger.kernel.org,
	james.bottomley@hansenpartnership.com
Cc: lutianxiong@huawei.com, linfeilong@huawei.com,
	liuzhiqiang26@huawei.com, haowenchao@huawei.com
Subject: [PATCH 0/9 V5] iscsi fixes and cleanups
Date: Tue,  2 Feb 2021 19:33:47 -0600	[thread overview]
Message-ID: <20210203013356.11177-1-michael.christie@oracle.com> (raw)

The following patches made over Martin's 5.12 branches contain
fixes for a cmd lifetime bug, software iscsi can_queue setup,
and a couple of the lock cleanup patches Lee has already ackd.

V5:
- Fix up KERN_ERR/INFO use when detecting invalid max_cmds values
from the user.
- Set iscsi_tcp can queue to max value it can support not including
mgmt cmds since the driver itself is not limited and that is a libiscsi
layer limit.
- Added the iscsi session class lock cleanup from the lock cleanup
patchset since it was reviewed already and this is now a patchset
for the next feature window.

V4:
- Add patch:
[PATCH 4/7] libiscsi: fix iscsi host workq destruction
to fix an issue where the user might only call iscsi_host_alloc then
iscsi_host_free and that was leaving the iscsi workqueue running.
- Add check for if a driver were to set can_queue to ISCSI_MGMT_CMDS_MAX
or less.
V3:
- Add some patches for issues found while testing.
	- session queue depth was stuck at 128
	- cmd window could not be detected when session was relogged in.
- Patch "libiscsi: drop taskqueuelock" had a bug where we did not
disable bhs and during xmit thread suspension leaked the current task.
V2:
- Take back_lock when looping over running cmds in iscsi_eh_cmd_timed_out
in case those complete while we are accessing them.