public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] zfcp: Stop system after memory corruption
@ 2007-05-07 14:35 Swen Schillig
  2007-05-07 15:56 ` Julian Calaby
  0 siblings, 1 reply; 4+ messages in thread
From: Swen Schillig @ 2007-05-07 14:35 UTC (permalink / raw)
  To: linux-scsi, linux-s390; +Cc: James Bottomley

From: Christof Schmitt <christof.schmitt@de.ibm.com>

For each request that is sent to the FCP adapter, zfcp allocates
memory. Status information and data that is being read from the
device is written to this memory by the hardware. After that,
the hardware signals this via the response queue and zfcp
continues processing.

Now, if zfcp detects that there is a signal for an incoming
response from the hardware, but there is no outstanding request
for that request id, then some memory that can be in use anywhere
in the system has just been overwritten. This should never happen,
but if it does, stop the system with a panic.


Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
---

 drivers/s390/scsi/zfcp_qdio.c |   32 +++++---------------------------
 1 files changed, 5 insertions(+), 27 deletions(-)

diff -urpN linux-2.6/drivers/s390/scsi/zfcp_qdio.c linux-2.6-patched/drivers/s390/scsi/zfcp_qdio.c
--- linux-2.6/drivers/s390/scsi/zfcp_qdio.c	2007-05-07 12:47:16.000000000 +0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_qdio.c	2007-05-07 12:47:26.000000000 +0200
@@ -285,8 +285,8 @@ zfcp_qdio_request_handler(struct ccw_dev
 /**
  * zfcp_qdio_reqid_check - checks for valid reqids or unsolicited status
  */
-static int zfcp_qdio_reqid_check(struct zfcp_adapter *adapter, 
-				 unsigned long req_id)
+static void zfcp_qdio_reqid_check(struct zfcp_adapter *adapter, 
+				  unsigned long req_id)
 {
 	struct zfcp_fsf_req *fsf_req;
 	unsigned long flags;
@@ -298,9 +298,7 @@ static int zfcp_qdio_reqid_check(struct 

 	if (!fsf_req) {
 		spin_unlock_irqrestore(&adapter->req_list_lock, flags);
-		ZFCP_LOG_NORMAL("error: unknown request id (%ld).\n", req_id);
-		zfcp_erp_adapter_reopen(adapter, 0);
-		return -EINVAL;
+		panic("error: unknown request id (%ld).\n", req_id);
 	}

 	zfcp_reqlist_remove(adapter, req_id);
@@ -309,8 +307,6 @@ static int zfcp_qdio_reqid_check(struct 

 	/* finish the FSF request */
 	zfcp_fsf_req_complete(fsf_req);
-
-	return 0;
 }

 /*
@@ -374,27 +370,9 @@ zfcp_qdio_response_handler(struct ccw_de

 			/* look for QDIO request identifiers in SB */
 			buffere = &buffer->element[buffere_index];
-			retval = zfcp_qdio_reqid_check(adapter,
-					(unsigned long) buffere->addr);
+			zfcp_qdio_reqid_check(adapter,
+					      (unsigned long) buffere->addr);

-			if (retval) {
-				ZFCP_LOG_NORMAL("bug: unexpected inbound "
-						"packet on adapter %s "
-						"(reqid=0x%lx, "
-						"first_element=%d, "
-						"elements_processed=%d)\n",
-						zfcp_get_busid_by_adapter(adapter),
-						(unsigned long) buffere->addr,
-						first_element,
-						elements_processed);
-				ZFCP_LOG_NORMAL("hex dump of inbound buffer "
-						"at address %p "
-						"(buffer_index=%d, "
-						"buffere_index=%d)\n", buffer,
-						buffer_index, buffere_index);
-				ZFCP_HEX_DUMP(ZFCP_LOG_LEVEL_NORMAL,
-					      (char *) buffer, SBAL_SIZE);
-			}
 			/*
 			 * A single used SBALE per inbound SBALE has been
 			 * implemented by QDIO so far. Hope they will


-------------------------------------------------------

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] zfcp: Stop system after memory corruption
  2007-05-07 14:35 [PATCH] zfcp: Stop system after memory corruption Swen Schillig
@ 2007-05-07 15:56 ` Julian Calaby
  2007-05-08 12:58   ` Christof Schmitt
  0 siblings, 1 reply; 4+ messages in thread
From: Julian Calaby @ 2007-05-07 15:56 UTC (permalink / raw)
  To: Swen Schillig; +Cc: linux-scsi, linux-s390

On 5/8/07, Swen Schillig <swen.schillig@freenet.de> wrote:
> From: Christof Schmitt <christof.schmitt@de.ibm.com>
[snip]
> -                               ZFCP_LOG_NORMAL("bug: unexpected inbound "
> -                                               "packet on adapter %s "
> -                                               "(reqid=0x%lx, "
> -                                               "first_element=%d, "
> -                                               "elements_processed=%d)\n",
> -                                               zfcp_get_busid_by_adapter(adapter),
> -                                               (unsigned long) buffere->addr,
> -                                               first_element,
> -                                               elements_processed);
> -                               ZFCP_LOG_NORMAL("hex dump of inbound buffer "
> -                                               "at address %p "
> -                                               "(buffer_index=%d, "
> -                                               "buffere_index=%d)\n", buffer,
> -                                               buffer_index, buffere_index);
> -                               ZFCP_HEX_DUMP(ZFCP_LOG_LEVEL_NORMAL,
> -                                             (char *) buffer, SBAL_SIZE);

As a minor quibble, may I suggest that these lines belong just above
the panic introduced above? I assume that they'd be useful for
debugging should this situation occur.

If I'm completely mis-understanding the situation, please disregard this email.

Thanks,

-- 

Julian Calaby

Email: julian.calaby@gmail.com

(please note that I'm only subscribed to linux-scsi if replying)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] zfcp: Stop system after memory corruption
  2007-05-07 15:56 ` Julian Calaby
@ 2007-05-08 12:58   ` Christof Schmitt
  2007-05-08 13:24     ` Julian Calaby
  0 siblings, 1 reply; 4+ messages in thread
From: Christof Schmitt @ 2007-05-08 12:58 UTC (permalink / raw)
  To: Julian Calaby; +Cc: Swen Schillig, linux-scsi, linux-s390

On Tue, May 08, 2007 at 01:56:07AM +1000, Julian Calaby wrote:
> >From: Christof Schmitt <christof.schmitt@de.ibm.com>
> [snip]
> >-                               ZFCP_LOG_NORMAL("bug: unexpected inbound "
> >-                                               "packet on adapter %s "
> >-                                               "(reqid=0x%lx, "
> >-                                               "first_element=%d, "
> >-                                               "elements_processed=%d)\n",
[...]
> As a minor quibble, may I suggest that these lines belong just above
> the panic introduced above? I assume that they'd be useful for
> debugging should this situation occur.

If this problem occurs, the administrator of the Linux system will be
advised to dump the Linux system and to also capture the logs from the
FCP adapter. The memory dump already contains the information about the 
unexpected packet and also information about the last requests
sent to the FCP adapter. So, the messages do not provide additional
debug data, and i removed them to simplify the code.

Christof Schmitt

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] zfcp: Stop system after memory corruption
  2007-05-08 12:58   ` Christof Schmitt
@ 2007-05-08 13:24     ` Julian Calaby
  0 siblings, 0 replies; 4+ messages in thread
From: Julian Calaby @ 2007-05-08 13:24 UTC (permalink / raw)
  To: Christof Schmitt; +Cc: Swen Schillig, linux-scsi, linux-s390

On 5/8/07, Christof Schmitt <christof.schmitt@de.ibm.com> wrote:
> On Tue, May 08, 2007 at 01:56:07AM +1000, Julian Calaby wrote:
> > >From: Christof Schmitt <christof.schmitt@de.ibm.com>
> > [snip]
> > >-                               ZFCP_LOG_NORMAL("bug: unexpected inbound "
> > >-                                               "packet on adapter %s "
> > >-                                               "(reqid=0x%lx, "
> > >-                                               "first_element=%d, "
> > >-                                               "elements_processed=%d)\n",
> [...]
> > As a minor quibble, may I suggest that these lines belong just above
> > the panic introduced above? I assume that they'd be useful for
> > debugging should this situation occur.
>
> If this problem occurs, the administrator of the Linux system will be
> advised to dump the Linux system and to also capture the logs from the
> FCP adapter. The memory dump already contains the information about the
> unexpected packet and also information about the last requests
> sent to the FCP adapter. So, the messages do not provide additional
> debug data, and i removed them to simplify the code.

Ah!

Thanks,

-- 

Julian Calaby

Email: julian.calaby@gmail.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-05-08 13:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-07 14:35 [PATCH] zfcp: Stop system after memory corruption Swen Schillig
2007-05-07 15:56 ` Julian Calaby
2007-05-08 12:58   ` Christof Schmitt
2007-05-08 13:24     ` Julian Calaby

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox