All of lore.kernel.org
 help / color / mirror / Atom feed
* FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree
@ 2017-09-22  9:43 gregkh
  2017-09-25 13:42 ` Steffen Maier
  0 siblings, 1 reply; 4+ messages in thread
From: gregkh @ 2017-09-22  9:43 UTC (permalink / raw)
  To: maier, bblock, martin.petersen, stable; +Cc: stable


The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 975171b4461be296a35e83ebd748946b81cf0635 Mon Sep 17 00:00:00 2001
From: Steffen Maier <maier@linux.vnet.ibm.com>
Date: Fri, 28 Jul 2017 12:30:53 +0200
Subject: [PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response
 trace records

v4.9 commit aceeffbb59bb ("zfcp: trace full payload of all SAN records
(req,resp,iels)") fixed trace data loss of 2.6.38 commit 2c55b750a884
("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
necessary for problem determination, e.g. to see the
currently active zone set during automatic port scan.

While it already saves space by not dumping any empty residual entries
of the large successful GPN_FT response (4 pages), there are seldom cases
where the GPN_FT response is unsuccessful and likely does not have
FC_NS_FID_LAST set in fp_flags so we did not cap the trace record.
We typically see such case for an initiator WWPN, which is not in any zone.

Cap unsuccessful responses to at least the actual basic CT_IU response
plus whatever fits the SAN trace record built-in "payload" buffer
just in case there's trailing information
of which we would at least see the existence and its beginning.

In order not to erroneously cap successful responses, we need to swap
calling the trace function and setting the CT / ELS status to success (0).

Example trace record pair formatted with zfcpdbf:

Timestamp      : ...
Area           : SAN
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : fssct_1
Request ID     : 0x<request_id>
Destination ID : 0x00fffffc
SAN req short  : 01000000 fc020000 01720ffc 00000000
                 00000008
SAN req length : 20
|
Timestamp      : ...
Area           : SAN
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 2
Tag            : fsscth2
Request ID     : 0x<request_id>
Destination ID : 0x00fffffc
SAN resp short : 01000000 fc020000 80010000 00090700
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
SAN resp length: 16384
San resp info  : 01000000 fc020000 80010000 00090700
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]

The fix saves all but one of the previously associated 64 PAYload trace
record chunks of size 256 bytes each.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index d5bf36ec8a75..31d62ea5fdcd 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -3,7 +3,7 @@
  *
  * Debug traces for zfcp.
  *
- * Copyright IBM Corp. 2002, 2016
+ * Copyright IBM Corp. 2002, 2017
  */
 
 #define KMSG_COMPONENT "zfcp"
@@ -447,6 +447,7 @@ static u16 zfcp_dbf_san_res_cap_len_if_gpn_ft(char *tag,
 	struct fc_ct_hdr *reqh = sg_virt(ct_els->req);
 	struct fc_ns_gid_ft *reqn = (struct fc_ns_gid_ft *)(reqh + 1);
 	struct scatterlist *resp_entry = ct_els->resp;
+	struct fc_ct_hdr *resph;
 	struct fc_gpn_ft_resp *acc;
 	int max_entries, x, last = 0;
 
@@ -473,6 +474,13 @@ static u16 zfcp_dbf_san_res_cap_len_if_gpn_ft(char *tag,
 		return len; /* not GPN_FT response so do not cap */
 
 	acc = sg_virt(resp_entry);
+
+	/* cap all but accept CT responses to at least the CT header */
+	resph = (struct fc_ct_hdr *)acc;
+	if ((ct_els->status) ||
+	    (resph->ct_cmd != cpu_to_be16(FC_FS_ACC)))
+		return max(FC_CT_HDR_LEN, ZFCP_DBF_SAN_MAX_PAYLOAD);
+
 	max_entries = (reqh->ct_mr_size * 4 / sizeof(struct fc_gpn_ft_resp))
 		+ 1 /* zfcp_fc_scan_ports: bytes correct, entries off-by-one
 		     * to account for header as 1st pseudo "entry" */;
diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
index e894ec92076c..c10b4b9f1574 100644
--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -928,8 +928,8 @@ static void zfcp_fsf_send_ct_handler(struct zfcp_fsf_req *req)
 
 	switch (header->fsf_status) {
         case FSF_GOOD:
-		zfcp_dbf_san_res("fsscth2", req);
 		ct->status = 0;
+		zfcp_dbf_san_res("fsscth2", req);
 		break;
         case FSF_SERVICE_CLASS_NOT_SUPPORTED:
 		zfcp_fsf_class_not_supp(req);
@@ -1108,8 +1108,8 @@ static void zfcp_fsf_send_els_handler(struct zfcp_fsf_req *req)
 
 	switch (header->fsf_status) {
 	case FSF_GOOD:
-		zfcp_dbf_san_res("fsselh1", req);
 		send_els->status = 0;
+		zfcp_dbf_san_res("fsselh1", req);
 		break;
 	case FSF_SERVICE_CLASS_NOT_SUPPORTED:
 		zfcp_fsf_class_not_supp(req);

^ permalink raw reply related	[flat|nested] 4+ messages in thread
* Re: FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree
  2017-09-22  9:43 FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree gregkh
@ 2017-09-25 13:42 ` Steffen Maier
  2017-09-25 14:00   ` Steffen Maier
  2017-10-03 11:31   ` Greg KH
  0 siblings, 2 replies; 4+ messages in thread
From: Steffen Maier @ 2017-09-25 13:42 UTC (permalink / raw)
  To: gregkh, bblock, martin.petersen, stable

Hi Greg,

the following upstream zfcp patches since v3.18 were tagged for stable:

> $ git log --grep=stable --pretty=fixes v3.18.. -- drivers/s390/scsi/
> 5d4a3d0a2ff2 ("scsi: zfcp: trace high part of "new" 64 bit SCSI LUN")
> fdb7cee3b9e3 ("scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response")
> 12c3e5754c80 ("scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records")
> 1a5d999ebfc7 ("scsi: zfcp: fix missing trace records for early returns in TMF eh handlers")

This depends on the next one which is why it caused the build error.

> 9fe5d2b2fd30 ("scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA")

This in turn depends on below aceeffbb59bb ("zfcp: trace full payload of 
all SAN records (req,resp,iels)") which is why it failed.

> 975171b4461b ("scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records")
> a099b7b1fc1f ("scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path")
> 71b8e45da51a ("scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled")

Above are the ones you included for longterm 3.18.72.

Below are the ones I cannot seem to find in branch linux-3.18.y of 
linux-stable.git up to the current HEAD with tag v3.18.71:
* linux-3.18.y 60a8261b1257 [origin/linux-3.18.y] Linux 3.18.71.

> 2dfa6688aafd ("scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send")
> 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
> 56d23ed7adf3 ("scsi: zfcp: do not trace pure benign residual HBA responses at default level")
> dac37e15b7d5 ("scsi: zfcp: fix use-after-"free" in FC ingress path after TMF")
> e7cb08e894a0 ("scsi: zfcp: spin_lock_irqsave() is not nestable")
> aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")

This is a dependency for some of the above patches included for 3.18.72.

> 94db3725f049 ("zfcp: fix payload trace length for SAN request&response")
> 771bf03537dd ("zfcp: fix D_ID field with actual value on tracing SAN responses")
> 7c964ffe586b ("zfcp: restore tracing of handle for port and LUN with HBA records")
> d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
> 0102a30a6ff6 ("zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace")
> 35f040df97fa ("zfcp: retain trace level for SCSI and HBA FSF response records")
> 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport gone")
> 70369f8e15b2 ("zfcp: fix ELS/GS request&response length for hardware data router")
> bd77befa5bcf ("zfcp: fix fc_host port_type with NPIV")

How should we proceed?
Either also pull in the old patches (belatedly?) into 3.18.72,
or maybe even drop all zfcp patches from 3.18.72 so zfcp effectively 
remains on 3.18.0 level which would also be OK with me.

Even if the partial zfcp stable patches including your latest 3.18.y 
longterm commit ("fix up s390 build error for 3.18") would make up a 
working zfcp, the stable subset does not seem optimal.


On 09/22/2017 11:43 AM, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 3.18-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
>  From 975171b4461be296a35e83ebd748946b81cf0635 Mon Sep 17 00:00:00 2001
> From: Steffen Maier <maier@linux.vnet.ibm.com>
> Date: Fri, 28 Jul 2017 12:30:53 +0200
> Subject: [PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response
>   trace records
> 
> v4.9 commit aceeffbb59bb ("zfcp: trace full payload of all SAN records
> (req,resp,iels)") fixed trace data loss of 2.6.38 commit 2c55b750a884
> ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
> necessary for problem determination, e.g. to see the
> currently active zone set during automatic port scan.
> 
> While it already saves space by not dumping any empty residual entries
> of the large successful GPN_FT response (4 pages), there are seldom cases
> where the GPN_FT response is unsuccessful and likely does not have
> FC_NS_FID_LAST set in fp_flags so we did not cap the trace record.
> We typically see such case for an initiator WWPN, which is not in any zone.
> 
> Cap unsuccessful responses to at least the actual basic CT_IU response
> plus whatever fits the SAN trace record built-in "payload" buffer
> just in case there's trailing information
> of which we would at least see the existence and its beginning.
> 
> In order not to erroneously cap successful responses, we need to swap
> calling the trace function and setting the CT / ELS status to success (0).
> 
> Example trace record pair formatted with zfcpdbf:
> 
> Timestamp      : ...
> Area           : SAN
> Subarea        : 00
> Level          : 1
> Exception      : -
> CPU ID         : ..
> Caller         : 0x...
> Record ID      : 1
> Tag            : fssct_1
> Request ID     : 0x<request_id>
> Destination ID : 0x00fffffc
> SAN req short  : 01000000 fc020000 01720ffc 00000000
>                   00000008
> SAN req length : 20
> |
> Timestamp      : ...
> Area           : SAN
> Subarea        : 00
> Level          : 1
> Exception      : -
> CPU ID         : ..
> Caller         : 0x...
> Record ID      : 2
> Tag            : fsscth2
> Request ID     : 0x<request_id>
> Destination ID : 0x00fffffc
> SAN resp short : 01000000 fc020000 80010000 00090700
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
> SAN resp length: 16384
> San resp info  : 01000000 fc020000 80010000 00090700
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
>                   00000000 00000000 00000000 00000000 [trailing info]
> 
> The fix saves all but one of the previously associated 64 PAYload trace
> record chunks of size 256 bytes each.
> 
> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
> Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
> Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
> Cc: <stable@vger.kernel.org> #2.6.38+
> Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
> Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
> 
> diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> index d5bf36ec8a75..31d62ea5fdcd 100644
> --- a/drivers/s390/scsi/zfcp_dbf.c
> +++ b/drivers/s390/scsi/zfcp_dbf.c
> @@ -3,7 +3,7 @@
>    *
>    * Debug traces for zfcp.
>    *
> - * Copyright IBM Corp. 2002, 2016
> + * Copyright IBM Corp. 2002, 2017
>    */
> 
>   #define KMSG_COMPONENT "zfcp"
> @@ -447,6 +447,7 @@ static u16 zfcp_dbf_san_res_cap_len_if_gpn_ft(char *tag,
>   	struct fc_ct_hdr *reqh = sg_virt(ct_els->req);
>   	struct fc_ns_gid_ft *reqn = (struct fc_ns_gid_ft *)(reqh + 1);
>   	struct scatterlist *resp_entry = ct_els->resp;
> +	struct fc_ct_hdr *resph;
>   	struct fc_gpn_ft_resp *acc;
>   	int max_entries, x, last = 0;
> 
> @@ -473,6 +474,13 @@ static u16 zfcp_dbf_san_res_cap_len_if_gpn_ft(char *tag,
>   		return len; /* not GPN_FT response so do not cap */
> 
>   	acc = sg_virt(resp_entry);
> +
> +	/* cap all but accept CT responses to at least the CT header */
> +	resph = (struct fc_ct_hdr *)acc;
> +	if ((ct_els->status) ||
> +	    (resph->ct_cmd != cpu_to_be16(FC_FS_ACC)))
> +		return max(FC_CT_HDR_LEN, ZFCP_DBF_SAN_MAX_PAYLOAD);
> +
>   	max_entries = (reqh->ct_mr_size * 4 / sizeof(struct fc_gpn_ft_resp))
>   		+ 1 /* zfcp_fc_scan_ports: bytes correct, entries off-by-one
>   		     * to account for header as 1st pseudo "entry" */;
> diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
> index e894ec92076c..c10b4b9f1574 100644
> --- a/drivers/s390/scsi/zfcp_fsf.c
> +++ b/drivers/s390/scsi/zfcp_fsf.c
> @@ -928,8 +928,8 @@ static void zfcp_fsf_send_ct_handler(struct zfcp_fsf_req *req)
> 
>   	switch (header->fsf_status) {
>           case FSF_GOOD:
> -		zfcp_dbf_san_res("fsscth2", req);
>   		ct->status = 0;
> +		zfcp_dbf_san_res("fsscth2", req);
>   		break;
>           case FSF_SERVICE_CLASS_NOT_SUPPORTED:
>   		zfcp_fsf_class_not_supp(req);
> @@ -1108,8 +1108,8 @@ static void zfcp_fsf_send_els_handler(struct zfcp_fsf_req *req)
> 
>   	switch (header->fsf_status) {
>   	case FSF_GOOD:
> -		zfcp_dbf_san_res("fsselh1", req);
>   		send_els->status = 0;
> +		zfcp_dbf_san_res("fsselh1", req);
>   		break;
>   	case FSF_SERVICE_CLASS_NOT_SUPPORTED:
>   		zfcp_fsf_class_not_supp(req);
> 

-- 
Mit freundlichen Gr��en / Kind regards
Steffen Maier

Linux on z Systems Development

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree
  2017-09-25 13:42 ` Steffen Maier
@ 2017-09-25 14:00   ` Steffen Maier
  2017-10-03 11:31   ` Greg KH
  1 sibling, 0 replies; 4+ messages in thread
From: Steffen Maier @ 2017-09-25 14:00 UTC (permalink / raw)
  To: gregkh, bblock, martin.petersen, stable

On 09/25/2017 03:42 PM, Steffen Maier wrote:
> Hi Greg,
> 
> the following upstream zfcp patches since v3.18 were tagged for stable:
> 
>> $ git log --grep=stable --pretty=fixes v3.18.. -- drivers/s390/scsi/
>> 5d4a3d0a2ff2 ("scsi: zfcp: trace high part of "new" 64 bit SCSI LUN")
>> fdb7cee3b9e3 ("scsi: zfcp: trace HBA FSF response by default on 
>> dismiss or timedout late response")
>> 12c3e5754c80 ("scsi: zfcp: fix payload with full FCP_RSP IU in SCSI 
>> trace records")
>> 1a5d999ebfc7 ("scsi: zfcp: fix missing trace records for early returns 
>> in TMF eh handlers")
> 
> This depends on the next one which is why it caused the build error.
> 
>> 9fe5d2b2fd30 ("scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to 
>> correlate with HBA")
> 
> This in turn depends on below aceeffbb59bb ("zfcp: trace full payload of 
> all SAN records (req,resp,iels)") which is why it failed.

Sorry, correction to myself, above did not apply because of:

zfcp_dbf.h hunk 1: the copyright update of below 4eeaa4f3f1d6 ("zfcp: 
close window with unblocked rport during rport gone") which is not in 3.18.y

zfcp_dbf.h hunk 3: the context suffix changed with below dac37e15b7d5 
("scsi: zfcp: fix use-after-"free" in FC ingress path after TMF") which 
is not in 3.18.y

zfcp_scsi.c hunk 1: the copyright update of below dac37e15b7d5 ("scsi: 
zfcp: fix use-after-"free" in FC ingress path after TMF") which is not 
in 3.18.y

zfcp_scsi.c hunk 3: the context changed with below dac37e15b7d5 ("scsi: 
zfcp: fix use-after-"free" in FC ingress path after TMF") which is not 
in 3.18.y

>> 975171b4461b ("scsi: zfcp: fix capping of unsuccessful GPN_FT SAN 
>> response trace records")

This one depends on below aceeffbb59bb ("zfcp: trace full payload of
all SAN records (req,resp,iels)") [and maybe others below for other 
failed hunks] which is why it failed to apply.

>> a099b7b1fc1f ("scsi: zfcp: add handling for FCP_RESID_OVER to the fcp 
>> ingress path")
>> 71b8e45da51a ("scsi: zfcp: fix queuecommand for scsi_eh commands when 
>> DIX enabled")
> 
> Above are the ones you included for longterm 3.18.72.
> 
> Below are the ones I cannot seem to find in branch linux-3.18.y of 
> linux-stable.git up to the current HEAD with tag v3.18.71:
> * linux-3.18.y 60a8261b1257 [origin/linux-3.18.y] Linux 3.18.71.
> 
>> 2dfa6688aafd ("scsi: zfcp: fix use-after-free by not tracing WKA port 
>> open/close on failed send")
>> 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
>> 56d23ed7adf3 ("scsi: zfcp: do not trace pure benign residual HBA 
>> responses at default level")
>> dac37e15b7d5 ("scsi: zfcp: fix use-after-"free" in FC ingress path 
>> after TMF")
>> e7cb08e894a0 ("scsi: zfcp: spin_lock_irqsave() is not nestable")
>> aceeffbb59bb ("zfcp: trace full payload of all SAN records 
>> (req,resp,iels)")
> 
> This is a dependency for some of the above patches included for 3.18.72.
> 
>> 94db3725f049 ("zfcp: fix payload trace length for SAN request&response")
>> 771bf03537dd ("zfcp: fix D_ID field with actual value on tracing SAN 
>> responses")
>> 7c964ffe586b ("zfcp: restore tracing of handle for port and LUN with 
>> HBA records")
>> d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
>> 0102a30a6ff6 ("zfcp: restore: Dont use 0 to indicate invalid LUN in 
>> rec trace")
>> 35f040df97fa ("zfcp: retain trace level for SCSI and HBA FSF response 
>> records")
>> 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport 
>> gone")
>> 70369f8e15b2 ("zfcp: fix ELS/GS request&response length for hardware 
>> data router")
>> bd77befa5bcf ("zfcp: fix fc_host port_type with NPIV")
> 
> How should we proceed?
> Either also pull in the old patches (belatedly?) into 3.18.72,
> or maybe even drop all zfcp patches from 3.18.72 so zfcp effectively 
> remains on 3.18.0 level which would also be OK with me.
> 
> Even if the partial zfcp stable patches including your latest 3.18.y 
> longterm commit ("fix up s390 build error for 3.18") would make up a 
> working zfcp, the stable subset does not seem optimal.
> 
> 
> On 09/22/2017 11:43 AM, gregkh@linuxfoundation.org wrote:
>>
>> The patch below does not apply to the 3.18-stable tree.
>> If someone wants it applied there, or to any other stable or longterm
>> tree, then please email the backport, including the original git commit
>> id to <stable@vger.kernel.org>.
>>
>> thanks,
>>
>> greg k-h
>>
>> ------------------ original commit in Linus's tree ------------------
>>
>> �From 975171b4461be296a35e83ebd748946b81cf0635 Mon Sep 17 00:00:00 2001
>> From: Steffen Maier <maier@linux.vnet.ibm.com>
>> Date: Fri, 28 Jul 2017 12:30:53 +0200
>> Subject: [PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN 
>> response
>> � trace records

-- 
Mit freundlichen Gr��en / Kind regards
Steffen Maier

Linux on z Systems Development

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree
  2017-09-25 13:42 ` Steffen Maier
  2017-09-25 14:00   ` Steffen Maier
@ 2017-10-03 11:31   ` Greg KH
  1 sibling, 0 replies; 4+ messages in thread
From: Greg KH @ 2017-10-03 11:31 UTC (permalink / raw)
  To: Steffen Maier; +Cc: bblock, martin.petersen, stable

On Mon, Sep 25, 2017 at 03:42:23PM +0200, Steffen Maier wrote:
> Hi Greg,
> 
> the following upstream zfcp patches since v3.18 were tagged for stable:
> 
> > $ git log --grep=stable --pretty=fixes v3.18.. -- drivers/s390/scsi/
> > 5d4a3d0a2ff2 ("scsi: zfcp: trace high part of "new" 64 bit SCSI LUN")
> > fdb7cee3b9e3 ("scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response")
> > 12c3e5754c80 ("scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records")
> > 1a5d999ebfc7 ("scsi: zfcp: fix missing trace records for early returns in TMF eh handlers")
> 
> This depends on the next one which is why it caused the build error.
> 
> > 9fe5d2b2fd30 ("scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA")
> 
> This in turn depends on below aceeffbb59bb ("zfcp: trace full payload of all
> SAN records (req,resp,iels)") which is why it failed.
> 
> > 975171b4461b ("scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records")
> > a099b7b1fc1f ("scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path")
> > 71b8e45da51a ("scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled")
> 
> Above are the ones you included for longterm 3.18.72.
> 
> Below are the ones I cannot seem to find in branch linux-3.18.y of
> linux-stable.git up to the current HEAD with tag v3.18.71:
> * linux-3.18.y 60a8261b1257 [origin/linux-3.18.y] Linux 3.18.71.
> 
> > 2dfa6688aafd ("scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send")
> > 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
> > 56d23ed7adf3 ("scsi: zfcp: do not trace pure benign residual HBA responses at default level")
> > dac37e15b7d5 ("scsi: zfcp: fix use-after-"free" in FC ingress path after TMF")
> > e7cb08e894a0 ("scsi: zfcp: spin_lock_irqsave() is not nestable")
> > aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
> 
> This is a dependency for some of the above patches included for 3.18.72.
> 
> > 94db3725f049 ("zfcp: fix payload trace length for SAN request&response")
> > 771bf03537dd ("zfcp: fix D_ID field with actual value on tracing SAN responses")
> > 7c964ffe586b ("zfcp: restore tracing of handle for port and LUN with HBA records")
> > d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
> > 0102a30a6ff6 ("zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace")
> > 35f040df97fa ("zfcp: retain trace level for SCSI and HBA FSF response records")
> > 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport gone")
> > 70369f8e15b2 ("zfcp: fix ELS/GS request&response length for hardware data router")
> > bd77befa5bcf ("zfcp: fix fc_host port_type with NPIV")
> 
> How should we proceed?
> Either also pull in the old patches (belatedly?) into 3.18.72,
> or maybe even drop all zfcp patches from 3.18.72 so zfcp effectively remains
> on 3.18.0 level which would also be OK with me.
> 
> Even if the partial zfcp stable patches including your latest 3.18.y
> longterm commit ("fix up s390 build error for 3.18") would make up a working
> zfcp, the stable subset does not seem optimal.

Can you send me a patch series of the fixed up patches that need to get
into 3.18-stable, if you think people are actually running this hardware
on that kernel?

I know I'm not :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-10-03 11:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-22  9:43 FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree gregkh
2017-09-25 13:42 ` Steffen Maier
2017-09-25 14:00   ` Steffen Maier
2017-10-03 11:31   ` Greg KH

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.