[PATCH v2] target/iscsi: Convert timers to use timer_setup()
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly. Includes a fix for correcting an
on-stack timer usage.
Cc: "Nicholas A. Bellinger"
Cc: Bart Van Assche
Cc: Jiang Yi
Cc: Varun Prakash
Cc: linux-scsi@vger.kernel.org
Cc: target-de...@vger.kernel.org
Signed-off-by: Kees Cook
---
This is rebased on top of Bart's timer clean-up patch:
https://www.spinics.net/lists/target-devel/msg15385.html
---
drivers/target/iscsi/iscsi_target.c | 3 +--
drivers/target/iscsi/iscsi_target_erl0.c | 4 ++--
drivers/target/iscsi/iscsi_target_erl0.h | 2 +-
drivers/target/iscsi/iscsi_target_erl1.c | 4 ++--
drivers/target/iscsi/iscsi_target_erl1.h | 2 +-
drivers/target/iscsi/iscsi_target_login.c | 15 +++
drivers/target/iscsi/iscsi_target_login.h | 2 +-
drivers/target/iscsi/iscsi_target_nego.c | 23 +++
drivers/target/iscsi/iscsi_target_util.c | 11 +--
drivers/target/iscsi/iscsi_target_util.h | 4 ++--
10 files changed, 37 insertions(+), 33 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index 7d619160b3d3..9e67c7678c86 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -372,8 +372,7 @@ struct iscsi_np *iscsit_add_np(
init_completion(&np->np_restart_comp);
INIT_LIST_HEAD(&np->np_list);
- setup_timer(&np->np_login_timer, iscsi_handle_login_thread_timeout,
- (unsigned long)np);
+ timer_setup(&np->np_login_timer, iscsi_handle_login_thread_timeout, 0);
ret = iscsi_target_setup_login_socket(np, sockaddr);
if (ret != 0) {
diff --git a/drivers/target/iscsi/iscsi_target_erl0.c
b/drivers/target/iscsi/iscsi_target_erl0.c
index f164098594e9..718fe9a1b709 100644
--- a/drivers/target/iscsi/iscsi_target_erl0.c
+++ b/drivers/target/iscsi/iscsi_target_erl0.c
@@ -749,9 +749,9 @@ int iscsit_check_post_dataout(
}
}
-void iscsit_handle_time2retain_timeout(unsigned long data)
+void iscsit_handle_time2retain_timeout(struct timer_list *t)
{
- struct iscsi_session *sess = (struct iscsi_session *) data;
+ struct iscsi_session *sess = from_timer(sess, t, time2retain_timer);
struct iscsi_portal_group *tpg = sess->tpg;
struct se_portal_group *se_tpg = &tpg->tpg_se_tpg;
diff --git a/drivers/target/iscsi/iscsi_target_erl0.h
b/drivers/target/iscsi/iscsi_target_erl0.h
index 97e4ae728926..dba5e7826574 100644
--- a/drivers/target/iscsi/iscsi_target_erl0.h
+++ b/drivers/target/iscsi/iscsi_target_erl0.h
@@ -11,7 +11,7 @@ extern void iscsit_set_dataout_sequence_values(struct
iscsi_cmd *);
extern int iscsit_check_pre_dataout(struct iscsi_cmd *, unsigned char *);
extern int iscsit_check_post_dataout(struct iscsi_cmd *, unsigned char *, u8);
extern void iscsit_start_time2retain_handler(struct iscsi_session *);
-extern void iscsit_handle_time2retain_timeout(unsigned long data);
+extern void iscsit_handle_time2retain_timeout(struct timer_list *t);
extern int iscsit_stop_time2retain_timer(struct iscsi_session *);
extern void iscsit_connection_reinstatement_rcfr(struct iscsi_conn *);
extern void iscsit_cause_connection_reinstatement(struct iscsi_conn *, int);
diff --git a/drivers/target/iscsi/iscsi_target_erl1.c
b/drivers/target/iscsi/iscsi_target_erl1.c
index 19b28255b687..76184094a0cf 100644
--- a/drivers/target/iscsi/iscsi_target_erl1.c
+++ b/drivers/target/iscsi/iscsi_target_erl1.c
@@ -1148,11 +1148,11 @@ static int iscsit_set_dataout_timeout_values(
/*
* NOTE: Called from interrupt (timer) context.
*/
-void iscsit_handle_dataout_timeout(unsigned long data)
+void iscsit_handle_dataout_timeout(struct timer_list *t)
{
u32 pdu_length = 0, pdu_offset = 0;
u32 r2t_length = 0, r2t_offset = 0;
- struct iscsi_cmd *cmd = (struct iscsi_cmd *) data;
+ struct iscsi_cmd *cmd = from_timer(cmd, t, dataout_timer);
struct iscsi_conn *conn = cmd->conn;
struct iscsi_session *sess = NULL;
struct iscsi_node_attrib *na;
diff --git a/drivers/target/iscsi/iscsi_target_erl1.h
b/drivers/target/iscsi/iscsi_target_erl1.h
index 0ff6e310ca36..6a6e182674de 100644
--- a/drivers/target/iscsi/iscsi_target_erl1.h
+++ b/drivers/target/iscsi/iscsi_target_erl1.h
@@ -29,7 +29,7 @@ extern int iscsit_execute_ooo_cmdsns(struct iscsi_session *);
extern int iscsit_execute_cmd(struct iscsi_cmd *, int);
extern int iscsit_handle_ooo_cmdsn(struct iscsi_session *, struct iscsi_cmd *,
u32);
extern void iscsit_remove_ooo_cmdsn(struct iscsi_session *, struct
iscsi_ooo_cmdsn *);
-extern void iscsit_handle_dataout_timeout(unsigned long data);
+extern void iscsit_handle_dataout_timeout(struct timer_list *t);
extern void iscsit_mod_dataout_timer(struct iscsi_cmd *);
extern void iscsit_start_dataout_timer(struct iscsi_cmd *, struct iscsi_con
Re: [PATCH v2] target/iscsi: Convert timers to use timer_setup()
On Fri, 2017-10-27 at 02:19 -0700, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Includes a fix for correcting an > on-stack timer usage. Hello Kees, These changes look good to me but I would like to test this patch. Is there a tree available somewhere that includes this patch? Thanks, Bart.
Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware
Hi Hannes, Thank you for looking into the issue. If there is anything I can help to test the patch? I appreciate your help. Thank you. On Fri, Oct 6, 2017 at 9:08 AM, Gavin Guo wrote: > On Mon, Oct 2, 2017 at 10:32 PM, Hannes Reinecke wrote: >> On 09/27/2017 09:33 AM, Gavin Guo wrote: >>> There is a problem in the latest upstream kernel with the device: >>> >>> $ grep -i lsi lspci >>> 03:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios >>> Logic SAS1068 PCI-X Fusion-MPT SAS [1000:0054] (rev 01) >>> >>> The device is simulated by the VMware ESXi 5.5 >>> >>> When hotplugging a new disk to the Guest Ubuntu OS, the latest kernel >>> cannot automatically probe the disk. However, on the v3.19.0-80.88 >>> kernel, the disk can be dynamically probed and show the following >>> info message: >>> >>> mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 1, >>> sas_addr 0x5000c29a6bdae0f5 >>> scsi 2:0:1:0: Direct-Access VMware Virtual disk 1.0 PQ: 0 >>> ANSI: 2 >>> sd 2:0:1:0: Attached scsi generic sg2 type 0 >>> sd 2:0:1:0: [sdb] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) >>> sd 2:0:1:0: [sdb] Write Protect is off >>> sd 2:0:1:0: [sdb] Mode Sense: 61 00 00 00 >>> sd 2:0:1:0: [sdb] Cache data unavailable >>> sd 2:0:1:0: [sdb] Assuming drive cache: write through >>> sdb: unknown partition table >>> sd 2:0:1:0: [sdb] Attached SCSI disk >>> >>> After looking up the message: >>> mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 1, >>> sas_addr 0x5000c29a6bdae0f5 >>> >>> I found it comes from the path: >>> mptsas_firmware_event_work -> mptsas_send_sas_event -> >>> mptsas_hotplug_work -> mptsas_add_end_device >>> >>> I'll appreciate if anyone can give the idea: If it's possible that the >>> irq from the simulated LSI SAS controller didn't come in to trigger >>> the event? However, it can work on the v3.19 kernel so if there is >>> any driver implementation issue in the latest kernel. >>> >> This is an issue with the mptsas driver, who originally assumed that no >> system will have direct-attached SAS devices. >> VMWare chose to implement exactly that, so the hotplug detection logic >> is flawed here. >> I'll be sending a patch. >> >> Cheers, >> >> Hannes >> -- >> Dr. Hannes ReineckeTeamlead Storage & Networking >> h...@suse.de +49 911 74053 688 >> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg >> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton >> HRB 21284 (AG Nürnberg) > > Thank you in advance. Please add me to the CC list when you send out > the patch and I can help to verify that.
[GIT PULL] SCSI fixes for 4.14-rc6
Six fixes for mostly minor issues, most of which have small race
windows for occurring.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Bart Van Assche (1):
scsi: Suppress a kernel warning in case the prep function returns
BLKPREP_DEFER
Ben Hutchings (1):
scsi: sg: Re-fix off by one in sg_fill_request_table()
Christos Gkekas (1):
scsi: hpsa: Fix configured_logical_drive_count·check
Himanshu Madhani (1):
scsi: qla2xxx: Initialize Work element before requesting IRQs
Raghava Aditya Renukunta (1):
scsi: aacraid: Fix controller initialization failure
Steffen Maier (1):
scsi: zfcp: fix erp_action use-before-initialize in REC action trace
And the diffstat:
drivers/s390/scsi/zfcp_aux.c| 5 +
drivers/s390/scsi/zfcp_erp.c| 18 +++---
drivers/s390/scsi/zfcp_scsi.c | 5 +
drivers/scsi/aacraid/comminit.c | 8 +---
drivers/scsi/aacraid/linit.c| 7 ++-
drivers/scsi/hpsa.c | 2 +-
drivers/scsi/qla2xxx/qla_os.c | 4 ++--
drivers/scsi/scsi_lib.c | 8 +---
drivers/scsi/sg.c | 2 +-
9 files changed, 37 insertions(+), 22 deletions(-)
With full diff below.
James
---
diff --git a/drivers/s390/scsi/zfcp_aux.c b/drivers/s390/scsi/zfcp_aux.c
index 82ac331d9125..84752152d41f 100644
--- a/drivers/s390/scsi/zfcp_aux.c
+++ b/drivers/s390/scsi/zfcp_aux.c
@@ -357,6 +357,8 @@ struct zfcp_adapter *zfcp_adapter_enqueue(struct ccw_device
*ccw_device)
adapter->next_port_scan = jiffies;
+ adapter->erp_action.adapter = adapter;
+
if (zfcp_qdio_setup(adapter))
goto failed;
@@ -513,6 +515,9 @@ struct zfcp_port *zfcp_port_enqueue(struct zfcp_adapter
*adapter, u64 wwpn,
port->dev.groups = zfcp_port_attr_groups;
port->dev.release = zfcp_port_release;
+ port->erp_action.adapter = adapter;
+ port->erp_action.port = port;
+
if (dev_set_name(&port->dev, "0x%016llx", (unsigned long long)wwpn)) {
kfree(port);
goto err_out;
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index 37408f5f81ce..ec2532ee1822 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -193,9 +193,8 @@ static struct zfcp_erp_action *zfcp_erp_setup_act(int need,
u32 act_status,
atomic_or(ZFCP_STATUS_COMMON_ERP_INUSE,
&zfcp_sdev->status);
erp_action = &zfcp_sdev->erp_action;
- memset(erp_action, 0, sizeof(struct zfcp_erp_action));
- erp_action->port = port;
- erp_action->sdev = sdev;
+ WARN_ON_ONCE(erp_action->port != port);
+ WARN_ON_ONCE(erp_action->sdev != sdev);
if (!(atomic_read(&zfcp_sdev->status) &
ZFCP_STATUS_COMMON_RUNNING))
act_status |= ZFCP_STATUS_ERP_CLOSE_ONLY;
@@ -208,8 +207,8 @@ static struct zfcp_erp_action *zfcp_erp_setup_act(int need,
u32 act_status,
zfcp_erp_action_dismiss_port(port);
atomic_or(ZFCP_STATUS_COMMON_ERP_INUSE, &port->status);
erp_action = &port->erp_action;
- memset(erp_action, 0, sizeof(struct zfcp_erp_action));
- erp_action->port = port;
+ WARN_ON_ONCE(erp_action->port != port);
+ WARN_ON_ONCE(erp_action->sdev != NULL);
if (!(atomic_read(&port->status) & ZFCP_STATUS_COMMON_RUNNING))
act_status |= ZFCP_STATUS_ERP_CLOSE_ONLY;
break;
@@ -219,7 +218,8 @@ static struct zfcp_erp_action *zfcp_erp_setup_act(int need,
u32 act_status,
zfcp_erp_action_dismiss_adapter(adapter);
atomic_or(ZFCP_STATUS_COMMON_ERP_INUSE, &adapter->status);
erp_action = &adapter->erp_action;
- memset(erp_action, 0, sizeof(struct zfcp_erp_action));
+ WARN_ON_ONCE(erp_action->port != NULL);
+ WARN_ON_ONCE(erp_action->sdev != NULL);
if (!(atomic_read(&adapter->status) &
ZFCP_STATUS_COMMON_RUNNING))
act_status |= ZFCP_STATUS_ERP_CLOSE_ONLY;
@@ -229,7 +229,11 @@ static struct zfcp_erp_action *zfcp_erp_setup_act(int
need, u32 act_status,
return NULL;
}
- erp_action->adapter = adapter;
+ WARN_ON_ONCE(erp_action->adapter != adapter);
+ memset(&erp_action->list, 0, sizeof(erp_action->list));
+ memset(&erp_action->timer, 0, sizeof(erp_action->timer));
+ erp_action->step = ZFCP_ERP_STEP_UNINITIALIZED;
+ erp_action->fsf_req_id = 0;
erp_action->action = need;
erp_action->status = act_status;
diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c
index ec3ddd1d31d5..6cf8732627e0 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware
On 10/27/2017 04:02 PM, Gavin Guo wrote: > Hi Hannes, > > Thank you for looking into the issue. If there is anything I can help > to test the patch? I appreciate your help. Thank you. > If you had checked linux-scsi you would have found this patch: '[PATCH] mptsas: Fixup device hotplug for VMWare ESXi', which I guess is already scheduled for inclusion in 4.14. Anything else I could help you with? Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 2/2] scsi: megaraid: Track the page allocations for struct fusion_context
hi Martin , On 2017/10/25 20:36, Martin K. Petersen wrote: > > Yisheng, > >> I have get many kmemleak reports just similar to commit 70c54e210ee9 >> (scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion) >> on v4.14-rc6, however it seems have a different stroy: > > Do you still see leaks reported with the megaraid driver update recently > merged into 4.15/scsi-queue? > No, the related code have been optimized and __get_free_pages is not used to allocate fusion_context anymore. So, please ignore this one, and sorry for disturbing. BTW, what about the Patch 1/2, which is just a minor clean up? Thanks Yisheng Xie
Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware
On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke wrote: > On 10/27/2017 04:02 PM, Gavin Guo wrote: >> Hi Hannes, >> >> Thank you for looking into the issue. If there is anything I can help >> to test the patch? I appreciate your help. Thank you. >> > If you had checked linux-scsi you would have found this patch: > '[PATCH] mptsas: Fixup device hotplug for VMWare ESXi', which I guess is > already scheduled for inclusion in 4.14. > Anything else I could help you with? > > Cheers, > > Hannes > -- > Dr. Hannes ReineckeTeamlead Storage & Networking > h...@suse.de +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) Really appreciate your help. I will proceed the testing and keep you posted.
