Re: [PATCH v5 10/10] scsi: scsi_debug: Add param to control sdev's allow_restart

On 2023/10/9 7:17, Douglas Gilbert wrote: On 2023-09-22 05:29, Wenchao Hao wrote: Add new module param "allow_restart" to control if setup scsi_device's allow_restart flag. This is used to test scsi command finished with sense_key 0x6, asc 0x4 and ascq 0x2 Signed-off-by: Wenchao Hao Hi,

Re: [PATCH v5 08/10] scsi: scsi_debug: Add new error injection reset lun failed

On 2023/10/7 5:04, Douglas Gilbert wrote: On 2023-09-22 05:29, Wenchao Hao wrote: Add error injection type 3 to make scsi_debug_device_reset() return FAILED. Fail abort command foramt: s/foramt/format/ Examples: error=/sys/kernel/debug/scsi_debug/0:0:0:1/error echo "0 -10 0x12" >

Re: [PATCH v5 01/10] scsi: scsi_debug: create scsi_debug directory in the debugfs filesystem

On 2023/9/28 9:13, Douglas Gilbert wrote: On 2023-09-22 05:28, Wenchao Hao wrote: Create directory scsi_debug in the root of the debugfs filesystem. Prepare to add interface for manage error injection. Acked-by: Douglas Gilbert Signed-off-by: Wenchao Hao ---   drivers/scsi/scsi_debug.c | 6

Re: [PATCH 2/2] scsi: Add comment of target_destroy in scsi_host_template

On 2023/9/22 22:53, Bart Van Assche wrote: On 9/22/23 02:38, Wenchao Hao wrote: Add comment to tell callback function target_destroy of scsi_host_template is called in atomic context. Signed-off-by: Wenchao Hao ---   include/scsi/scsi_host.h | 3 +++   1 file changed, 3 insertions(+) diff

[PATCH 0/2] cleanup patch

This is a cleanup patchset, no logic changed. The first patch just cleanup scsi_dev_queue_ready(); The second patch add comment for target_destroy callback of scsi_host_template to tell it is called in atomic context. Wenchao Hao (2): scsi: core: cleanup scsi_dev_queue_ready() scsi: Add

[PATCH 1/2] scsi: core: cleanup scsi_dev_queue_ready()

This is just a cleanup for scsi_dev_queue_ready() to avoid redundant goto and if statement, it did not change the origin logic. Signed-off-by: Wenchao Hao --- drivers/scsi/scsi_lib.c | 35 ++- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git

[PATCH 2/2] scsi: Add comment of target_destroy in scsi_host_template

Add comment to tell callback function target_destroy of scsi_host_template is called in atomic context. Signed-off-by: Wenchao Hao --- include/scsi/scsi_host.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h index

[PATCH 0/2] Fix two issue between removing device and error handle

I am testing SCSI error handle with my previous scsi_debug error injection patches, and found two issue when removing device and error handler happened together. The first patch fix IO hang because scsi_eh_flush_done_q() would retry command if the device is in SDEV_CANCEL state; The second patch

[PATCH v5 10/10] scsi: scsi_debug: Add param to control sdev's allow_restart

Add new module param "allow_restart" to control if setup scsi_device's allow_restart flag. This is used to test scsi command finished with sense_key 0x6, asc 0x4 and ascq 0x2 Signed-off-by: Wenchao Hao --- drivers/scsi/scsi_debug.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH v5 05/10] scsi: scsi_debug: Return failed value if the error is injected

If a fail queuecommand error is injected, return the failed value defined in the rule from queuecommand. Make queuecommand return format: ++--+---+ | Column | Type | Description |

[PATCH 2/2] scsi: scsi_error: Fix device reset is not triggered

Fix the issue of skipping scsi_try_bus_device_reset() for devices which is in progress of removing in following order: T1: T2:scsi_error_handle __scsi_remove_device scsi_device_set_state(sdev, SDEV_DEL) // would skip

[PATCH 1/2] scsi: core: scsi_device_online() return false if state is SDEV_CANCEL

SDEV_CANCEL is set when removing device and scsi_device_online() should return false if sdev_state is SDEV_CANCEL. IO hang would be caused if return true when state is SDEV_CANCEL with following order: T1: T2:scsi_error_handler __scsi_remove_device()

[PATCH v5 06/10] scsi: scsi_debug: set command's result and sense data if the error is injected

If a fail commnd error is injected, set the command's status and sense data then finish this scsi command. Set SCSI command's status and sense data format: ++--+---+ | Column | Type | Description

[PATCH v5 09/10] scsi: scsi_debug: Add debugfs interface to fail target reset

The interface is found at /sys/kernel/debug/scsi_debug/target/fail_reset where identifies the target to inject errors on. It's a simple bool type interface which would make this target's reset fail if set to 'Y'. Signed-off-by: Wenchao Hao Reported-by: kernel test robot ---

[PATCH v5 07/10] scsi: scsi_debug: Add new error injection abort failed

Add error injection type 3 to make scsi_debug_abort() return FAILED. Fail abort command foramt: ++--+---+ | Column | Type | Description |

[PATCH v5 08/10] scsi: scsi_debug: Add new error injection reset lun failed

Add error injection type 3 to make scsi_debug_device_reset() return FAILED. Fail abort command foramt: ++--+---+ | Column | Type | Description |

[PATCH v5 01/10] scsi: scsi_debug: create scsi_debug directory in the debugfs filesystem

Create directory scsi_debug in the root of the debugfs filesystem. Prepare to add interface for manage error injection. Acked-by: Douglas Gilbert Signed-off-by: Wenchao Hao --- drivers/scsi/scsi_debug.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/scsi/scsi_debug.c

[PATCH v5 02/10] scsi: scsi_debug: Add interface to manage single device's error inject

This new facility uses the debugfs pseudo file system which is typically mounted under the /sys/kernel/debug directory and requires root permissions to access. The interface file is found at /sys/kernel/debug/scsi_debug//error where identifies the device (logical unit (LU)) to inject errors on.

[PATCH v5 00/10] scsi:scsi_debug: Add error injection for single device

The original error injection mechanism was based on scsi_host which could not inject fault for a single SCSI device. This patchset provides the ability to inject errors for a single SCSI device. Now we supports inject timeout errors, queuecommand errors, and hostbyte, driverbyte, statusbyte, and

[PATCH v5 04/10] scsi: scsi_debug: timeout command if the error is injected

If a timeout error is injected, return 0 from scsi_debug_queuecommand to make the command timeout. Timeout SCSI command format: ++--+---+ | Column | Type | Description |

[PATCH v5 03/10] scsi: scsi_debug: Define grammar to remove added error injection

The grammar to remove error injection is a line with fixed 3 columns separated by spaces. First column is fixed to "-". It tells this is a removal operation. Second column is the error code to match. Third column is the scsi command to match. For example the following command would remove

Re: [PATCH 0/2] scsi:donot skip lun if inquiry returns PQ=1 for all hosts

On 2022/12/16 15:12, Christoph Hellwig wrote: > On Thu, Dec 15, 2022 at 05:09:31PM +0800, Wenchao Hao wrote: >> In my opinion, if the addressed lun still response the >> inquiry and other commands, we should not skip it, >> maybe let the scsi drivers like sd/st/sg to determine >> how to handle

[PATCH 2/2] scsi:iscsi_tcp:Do not skip lun inquiry returns PQ=1

When luns inquiry return PQ=1, do not skip this lun and try to map these luns to an sg device. Signed-off-by: Wenchao Hao --- drivers/scsi/iscsi_tcp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c index 5fb1f364e815..316e2e17c72d 100644

[PATCH 0/2] scsi:donot skip lun if inquiry returns PQ=1 for all hosts

commit 948e922fc4461 ("scsi: core: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT") returns SCSI_SCAN_TARGET_PRESENT if inquiry returns PQ=1. According to the SPC, PQ=1 means the addressed logical unit having the indicated device type is not accessible, it does not mean the addressed

[PATCH 1/2] scsi:core:Add sysfs interface to control if skip lun with PQ=1

commit 948e922fc4461 ("scsi: core: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT") returns SCSI_SCAN_TARGET_PRESENT if inquiry returns PQ=1. According to the SPC, PQ=1 means the addressed logical unit having the indicated device type is not accessible, it does not mean the addressed

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

On Wednesday, December 7, 2022 at 1:01:23 AM UTC+8 Wenchao Hao wrote: > On Tue, Dec 6, 2022 at 1:13 AM Lee Duncan wrote: > > > > On 12/4/22 05:02, Wenchao Hao wrote: > > > On Thu, Dec 1, 2022 at 3:53 AM Lee Duncan wrote: > > >> > > ... > > >> > > >> Let me start by saying I agree with

Re: [PATCH v7] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

On 2022/11/26 9:07, Wenchao Hao wrote: > I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION > for multiple times which should be fixed. > > This patch introduce target_state in iscsi_cls_session to make > sure session would send only one ISCSI_KEVENT_UNBIND_SESSION. > > But this

[PATCH v7] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION for multiple times which should be fixed. This patch introduce target_state in iscsi_cls_session to make sure session would send only one ISCSI_KEVENT_UNBIND_SESSION. But this would break issue fixed in commit 13e60d3ba287

Re: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

On Thursday, November 24, 2022 at 6:06:09 PM UTC+8 Uli wrote: > >>> "'Lee Duncan' via open-iscsi" schrieb am > 23.11.2022 um 17:47 in Nachricht > <0f7258d5-ff8e-fa4e...@suse.com>: > > On 11/22/22 20:41, Wenchao Hao wrote: > > ... > > Again, I don't believe that's correct. I will test it. >

Re: [PATCH v6] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

On 2022/11/23 2:15, Mike Christie wrote: > On 11/22/22 11:29 AM, Wenchao Hao wrote: >> On Wed, Nov 23, 2022 at 1:04 AM Mike Christie >> wrote: >>> >>> On 11/21/22 8:17 AM, Wenchao Hao wrote: And the function looks like following after change: static void

[PATCH v3 2/2] scsi: donot increase scsi_device's iorequest_cnt if dispatch failed

If scsi_dispatch_cmd() failed, the scsi command did not send to disks, so it would never done from LLDs. scsi scsi_queue_rq() would return BLK_STS_RESOURCE if scsi_dispatch_cmd() failed, the related request would be requeued, and the timeout of this request would not fired any more, so no one

[PATCH v3 1/2] scsi: increase scsi device's iodone_cnt in scsi_timeout()

If an scsi command time out and going to be aborted, we should increase the iodone_cnt of the related scsi device, or the iodone_cnt would be less than iorequest_cnt Increase iodone_cnt in scsi_timeout() would not cause double accounting issue, briefly analysed as following: - we add the

[PATCH v3 0/2] Fix scsi device's iodone_cnt mismatch with iorequest_cnt

Following scenario would make scsi_device's iodone_cnt mismatch with iorequest_cnt even if there is no request on this device any more. 1. request timeout happened. If we do not retry the timeouted command, this command would be finished in scsi_finish_command() which would not increase

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

On 2022/11/23 4:00, Lee Duncan wrote: > On 11/22/22 13:30, Wenchao Hao wrote: >> There are 3 iscsi session's startup mode which are onboot, manual and >> automatic. We can boot from iSCSI disks with help of dracut's service >> in initrd, which would set node's startup mode to onboot, then create

[PATCH] scsi:iscsi: Record session's startup mode in kernel

There are 3 iscsi session's startup mode which are onboot, manual and automatic. We can boot from iSCSI disks with help of dracut's service in initrd, which would set node's startup mode to onboot, then create iSCSI sessions. While the configure of onboot mode is recorded in file of initrd stage

[PATCH] scsi:iscsi: rename iscsi_set_param to iscsi_if_set_param

There are two iscsi_set_param() functions individually defined in libiscsi.c and scsi_transport_iscsi.c which is confused. So rename the one in scsi_transport_iscsi.c to iscsi_if_set_param(). Signed-off-by: Wenchao Hao --- drivers/scsi/scsi_transport_iscsi.c | 4 ++-- 1 file changed, 2

Re: [PATCH v6] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

On 2022/11/9 11:47, Mike Christie wrote: > On 11/7/22 7:44 PM, Wenchao Hao wrote: >> I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION >> for multiple times which should be fixed. >> >> +static char *iscsi_session_target_state_names[] = { >> +"UNBOUND", >> +"ALLOCATED",

Re: Could not logout of all requested sessions reported error (9 - internal error)

Would the discussion in this issue is helpful for you? On Thursday, November 3, 2022 at 9:56:43 PM UTC+8 Andinet Gebre wrote: > > > I am able to discover and login into the Target from the iscsi client and > CHAP is also configured to

[PATCH v6] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION for multiple times which should be fixed. This patch introduce target_state in iscsi_cls_session to make sure session would send only one ISCSI_KEVENT_UNBIND_SESSION. But this would break issue fixed in commit 13e60d3ba287

[PATCH v3] scsi: iscsi: Fix multiple iscsi session unbind event sent to userspace

I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION for multiple times which should be fixed. This patch introduce target_state in iscsi_cls_session to make sure session would send only one ISCSI_KEVENT_UNBIND_SESSION. But this would break issue fixed in commit 13e60d3ba287

Re: [PATCH v2] scsi: iscsi: Fix multiple iscsi session unbind event sent to userspace

On 2022/4/21 0:28, Mike Christie wrote: > On 4/17/22 7:06 PM, Wenchao Hao wrote: >> I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION >> for multiple times which should be fixed. >> >> This patch introduce target_unbound in iscsi_cls_session to make >> sure session would send

[PATCH v2] scsi: iscsi: Fix multiple iscsi session unbind event sent to userspace

I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION for multiple times which should be fixed. This patch introduce target_unbound in iscsi_cls_session to make sure session would send only one ISCSI_KEVENT_UNBIND_SESSION. But this would break issue fixed in commit 13e60d3ba287

Re: [PATCH 2/2] iscsi: set session to FREE state after unbind session in remove session

On 2022/4/14 23:30, Mike Christie wrote: > On 4/13/22 8:49 PM, Wenchao Hao wrote: >> __iscsi_unbind_session() set session state to ISCSI_SESSION_UNBOUND, which >> would overwrite the ISCSI_SESSION_FREE state. >> >> Signed-off-by: Wenchao Hao >> --- >> drivers/scsi/scsi_transport_iscsi.c | 26

Re: [PATCH 1/2] scsi: iscsi: introduce session UNBOUND state to avoid multiple unbind event

On 2022/4/14 23:22, Mike Christie wrote: > On 4/13/22 8:49 PM, Wenchao Hao wrote: >> Fix the issue of kernel send multiple ISCSI_KEVENT_UNBIND_SESSION event. >> If session is in UNBOUND state, do not perform unbind operations anymore, >> else unbind session and set session to UNBOUND state. >> >

[PATCH 2/2] iscsi: set session to FREE state after unbind session in remove session

__iscsi_unbind_session() set session state to ISCSI_SESSION_UNBOUND, which would overwrite the ISCSI_SESSION_FREE state. Signed-off-by: Wenchao Hao --- drivers/scsi/scsi_transport_iscsi.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git

[PATCH 1/2] scsi: iscsi: introduce session UNBOUND state to avoid multiple unbind event

Fix the issue of kernel send multiple ISCSI_KEVENT_UNBIND_SESSION event. If session is in UNBOUND state, do not perform unbind operations anymore, else unbind session and set session to UNBOUND state. Reference:https://github.com/open-iscsi/open-iscsi/issues/338 Signed-off-by: Wenchao Hao ---

[PATCH 0/2] Fix multiple iscsi session unbind event sent to userspace

kernel would send ISCSI_KEVENT_UNBIND_SESSION twice to userspace, for open-iscsi, this would trigger iscsi_stop twice. We should fix this issue. Here introduced a new session state ISCSI_SESSION_UNBOUND to address it. Once session state is ISCSI_KEVENT_UNBIND_SESSION, it means

[PATCH] scsi:libiscsi: remove unnecessary memset in iscsi_conn_setup

iscsi_cls_conn is alloced by kzalloc(), the whole iscsi_cls_conn is zero filled already including the dd_data. So it is unnecessary to call memset again. Signed-off-by: Wenchao Hao Reviewed-by: Wu Bo Reviewed-by: Lee Duncan --- drivers/scsi/libiscsi.c | 1 - 1 file changed, 1 deletion(-)

Re: [PATCH] scsi:libiscsi: remove unnecessary memset in iscsi_conn_setup

cc open-iscsi@googlegroups.com linux-s...@vger.kernel.org On 2022/3/17 6:09, Wenchao Hao wrote: iscsi_cls_conn is alloced by kzalloc(), the whole iscsi_cls_conn is zero filled already including the dd_data. So it is unnecessary to call memset again. Signed-off-by: Wenchao Hao Reviewed-by: Wu

Re: [PATCH v3 0/3] scsi:iscsi: handle iscsi_cls_conn device with sysfs correctly

On 2022/3/10 9:57, Wenchao Hao wrote: We found a NULL pointer dereference in iscsi_sw_tcp_conn_get_param(), the root reason is we did sysfs addition wrong. The origin implement do device setup in iscsi_create_conn() which bind the alloc/init and add in one function; do device teardown in

[PATCH v3 2/3] scsi:libiscsi: Add iscsi_cls_conn to sysfs after been initialized

iscsi_create_conn() would expose iscsi_cls_conn to sysfs, while the initialization of iscsi_conn's dd_data is not ready now. When userspace try to access an attribute such as connect's address, it might cause a NULL pointer dereference. So we should add iscsi_cls_conn to sysfs until it has been

[PATCH v3 0/3] scsi:iscsi: handle iscsi_cls_conn device with sysfs correctly

We found a NULL pointer dereference in iscsi_sw_tcp_conn_get_param(), the root reason is we did sysfs addition wrong. The origin implement do device setup in iscsi_create_conn() which bind the alloc/init and add in one function; do device teardown in iscsi_destroy_conn() which bind remove and

[PATCH v3 3/3] scsi:libiscsi: teradown iscsi_cls_conn gracefully

commit 1b8d0300a3e9 ("scsi: libiscsi: Fix UAF in iscsi_conn_get_param()/iscsi_conn_teardown()") fixed an UAF in iscsi_conn_get_param() and introduced 2 tmp_xxx varibles, the implement looks ugly. We can fix this UAF with the help of device_del() gracefully. Call iscsi_remove_conn() at the

[PATCH v3 1/3] scsi: iscsi: Add helper functions to manage iscsi_cls_conn

iscsi_alloc_conn(): alloc and initialize iscsi_cls_conn iscsi_add_conn(): expose iscsi_cls_conn to userspace's via sysfs. iscsi_remove_conn(): remove iscsi_cls_conn from sysfs Signed-off-by: Wenchao Hao Signed-off-by: Wu Bo --- drivers/scsi/scsi_transport_iscsi.c | 97

Re: [PATCH v2 1/3] scsi: iscsi: Add helper functions to manage iscsi_cls_conn

On 2022/3/9 1:19, Mike Christie wrote: On 3/8/22 9:09 PM, Wenchao Hao wrote: iscsi_alloc_conn(): alloc and initialize iscsi_cls_conn iscsi_add_conn(): expose iscsi_cls_conn to userspace's via sysfs. iscsi_remove_conn(): remove iscsi_cls_conn from sysfs iscsi_free_conn(): free iscsi_cls_conn

[PATCH v2 2/3] scsi:libiscsi: Add iscsi_cls_conn to sysfs after been initialized

iscsi_create_conn() would expose iscsi_cls_conn to sysfs, while the initialization of iscsi_conn's dd_data is not ready now. When userspace try to access an attribute such as connect's address, it might cause a NULL pointer dereference. So we should add iscsi_cls_conn to sysfs until it has been

[PATCH v2 3/3] scsi:libiscsi: teardown iscsi_cls_conn gracefully

commit 1b8d0300a3e9 ("scsi: libiscsi: Fix UAF in iscsi_conn_get_param()/iscsi_conn_teardown()") fixed an UAF in iscsi_conn_get_param() and introduced 2 tmp_xxx varibles, the implement looks ugly. We can fix this UAF with the help of device_del() gracefully. Call iscsi_remove_conn() at the

[PATCH v2 0/3] scsi:iscsi: handle iscsi_cls_conn device with sysfs

We found a NULL pointer dereference in iscsi_sw_tcp_conn_get_param(), the root reason is we did sysfs addition wrong. iscsi_create_conn() expose iscsi_cls_conn to sysfs while the related resources are not initialized. So we should delay the calling of device_add() until these resources has been

[PATCH v2 1/3] scsi: iscsi: Add helper functions to manage iscsi_cls_conn

iscsi_alloc_conn(): alloc and initialize iscsi_cls_conn iscsi_add_conn(): expose iscsi_cls_conn to userspace's via sysfs. iscsi_remove_conn(): remove iscsi_cls_conn from sysfs iscsi_free_conn(): free iscsi_cls_conn Signed-off-by: Wenchao Hao Signed-off-by: Wu Bo ---

Re: [PATCH 1/2] iscsi_tcp: Fix NULL pointer dereference in iscsi_sw_tcp_conn_get_param()

On 2022/3/3 23:03, Mike Christie wrote: On 3/3/22 8:56 PM, Wenchao Hao wrote: kernel might crash in iscsi_sw_tcp_conn_get_param() because it dereference an invalid address. The initialization of iscsi_conn's dd_data is after device_register() of struct iscsi_cls_conn, so iscsi_conn's dd_data

[PATCH 1/2] scsi: iscsi: Add helper functions to alloc and add iscsi_cls_conn

iscsi_alloc_conn() would alloc and initialize iscsi_cls_conn but do not expose it to userspace. iscsi_add_conn() would expose it to userspace. LLDs should split the alloc and register to 2 steps. And simplify iscsi_create_conn() with these helper functions. Signed-off-by: Wenchao Hao

[PATCH 2/2] scsi:libiscsi: Add iscsi_cls_conn to sysfs after been initialized

iscsi_create_conn() would expose iscsi_cls_conn to sysfs, while the initialization of iscsi_conn's dd_data is not ready now. When userspace try to access an attribute such as connect's address, it might cause a NULL pointer dereference. So we should add iscsi_cls_conn to sysfs until it has been

[PATCH 0/2]scsi:libiscsi: Add iscsi_cls_conn device to sysfs correctly

We found a NULL pointer dereference in iscsi_sw_tcp_conn_get_param(), the root reason is we did sysfs addition wrong. iscsi_create_conn() expose iscsi_cls_conn to sysfs while the related resources are not initialized. So we should delay the calling of device_add() until these resources has been

Re: [PATCH 1/2] iscsi_tcp: Fix NULL pointer dereference in iscsi_sw_tcp_conn_get_param()

On 2022/3/3 23:03, Mike Christie wrote: On 3/3/22 8:56 PM, Wenchao Hao wrote: kernel might crash in iscsi_sw_tcp_conn_get_param() because it dereference an invalid address. The initialization of iscsi_conn's dd_data is after device_register() of struct iscsi_cls_conn, so iscsi_conn's dd_data

Re: [PATCH 2/2] iscsi_tcp: Check if tcp_conn is valid in

On 2022/3/3 22:59, Mike Christie wrote: On 3/3/22 8:56 PM, Wenchao Hao wrote: iscsi_create_conn() would add newly alloced iscsi_cls_conn to connlist, it means when userspace sends ISCSI_UEVENT_SET_PARAM, iscsi_conn_lookup() would found this iscsi_cls_conn and call the set_param callback which

[PATCH 2/2] iscsi_tcp: Check if tcp_conn is valid in

iscsi_create_conn() would add newly alloced iscsi_cls_conn to connlist, it means when userspace sends ISCSI_UEVENT_SET_PARAM, iscsi_conn_lookup() would found this iscsi_cls_conn and call the set_param callback which is iscsi_sw_tcp_conn_set_param(). While the iscsi_conn's dd_data might not been

[PATCH 1/2] iscsi_tcp: Fix NULL pointer dereference in iscsi_sw_tcp_conn_get_param()

kernel might crash in iscsi_sw_tcp_conn_get_param() because it dereference an invalid address. The initialization of iscsi_conn's dd_data is after device_register() of struct iscsi_cls_conn, so iscsi_conn's dd_data might not initialized when iscsi_sw_tcp_conn_get_param() is called. Following