[patch 0/6] zfcp: updates, fixing a variety of oddities
-- patch 1/6: Remove unnecessary eh_bus_reset_handler callsback The callback function used by zfcp always returns success, which is an indication for the SCSI midlayer to stop error handling. Remove the bus_reset callback, since the same function will be called via the host_reset callback. patch 2/6: Use also port and adapter to identify unit in messages Add the appropriate messages. patch 3/6: Specify waiting times in ERP in seconds It is not necessary to use jiffies or milliseconds to specify waiting times that last a couple of seconds. patch 4/6: Remove SCSI devices when removing adapter The common I/O layer can call remove a handler to inform zfcp that a device disappeared. The handler zfcp_ccw_remove then removes all unit, port and the adapter data structures. Removing the units requires that the SCSI devices are removed first. patch 5/6: Fix deadlock when adding invalid LUN When adding an invalid LUN, there is a deadlock between the add via scsi_scan_target and the slave_destroy handler: The handler waits for the scan to complete, but for an invalid unit, scsi_scan_target directly calls the slave_destroy handler. Fix the deadlock by removing the wait in the slave_destroy handler, it was not necessary anyway. patch 6/6: Reduce flood on HBA trace Remove tracing for request with a "qualifier" field set in the response. Â The protocol status qualifier now contains measurement data for "good" commands, so this check would trace every response by default. The fix is to simply remove the "qual" tracing: The responses with an interesting status are also traced as "ferr" or "perr" and all responses can be traced as "norm" with a higher trace level. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/6] zfcp: Remove unnecessary eh_bus_reset_handler callback
From: Christof Schmitt <[EMAIL PROTECTED]>
The callback function used by zfcp always returns success,
which is an indication for the SCSI midlayer to stop error
handling. Remove the bus_reset callback, since the same
function will be called via the host_reset callback.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_scsi.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: scsi-misc/drivers/s390/scsi/zfcp_scsi.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_scsi.c
+++ scsi-misc/drivers/s390/scsi/zfcp_scsi.c
@@ -51,7 +51,6 @@ struct zfcp_data zfcp_data = {
.queuecommand = zfcp_scsi_queuecommand,
.eh_abort_handler = zfcp_scsi_eh_abort_handler,
.eh_device_reset_handler = zfcp_scsi_eh_device_reset_handler,
- .eh_bus_reset_handler = zfcp_scsi_eh_host_reset_handler,
.eh_host_reset_handler = zfcp_scsi_eh_host_reset_handler,
.can_queue = 4096,
.this_id= -1,
@@ -542,7 +541,7 @@ zfcp_task_management_function(struct zfc
}
/**
- * zfcp_scsi_eh_host_reset_handler - handler for host and bus reset
+ * zfcp_scsi_eh_host_reset_handler - handler for host reset
*/
static int zfcp_scsi_eh_host_reset_handler(struct scsi_cmnd *scpnt)
{
@@ -552,7 +551,7 @@ static int zfcp_scsi_eh_host_reset_handl
unit = (struct zfcp_unit*) scpnt->device->hostdata;
adapter = unit->port->adapter;
- ZFCP_LOG_NORMAL("host/bus reset because of problems with "
+ ZFCP_LOG_NORMAL("host reset because of problems with "
"unit 0x%016Lx\n", unit->fcp_lun);
zfcp_erp_adapter_reopen(adapter, 0);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/6] zfcp: Use also port and adapter to identify unit in messages.
From: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_scsi.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_scsi.c
linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c
--- linux-2.6/drivers/s390/scsi/zfcp_scsi.c 2007-11-02 08:38:25.0
+0100
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c 2007-11-02
08:38:25.0 +0100
@@ -458,7 +458,9 @@ zfcp_scsi_eh_device_reset_handler(struct
retval = SUCCESS;
goto out;
}
- ZFCP_LOG_NORMAL("resetting unit 0x%016Lx\n", unit->fcp_lun);
+ ZFCP_LOG_NORMAL("resetting unit 0x%016Lx on port 0x%016Lx, adapter
%s\n",
+ unit->fcp_lun, unit->port->wwpn,
+ zfcp_get_busid_by_adapter(unit->port->adapter));
/*
* If we do not know whether the unit supports 'logical unit reset'
@@ -552,7 +554,9 @@ static int zfcp_scsi_eh_host_reset_handl
adapter = unit->port->adapter;
ZFCP_LOG_NORMAL("host reset because of problems with "
- "unit 0x%016Lx\n", unit->fcp_lun);
+ "unit 0x%016Lx on port 0x%016Lx, adapter %s\n",
+ unit->fcp_lun, unit->port->wwpn,
+ zfcp_get_busid_by_adapter(unit->port->adapter));
zfcp_erp_adapter_reopen(adapter, 0);
zfcp_erp_wait(adapter);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 4/6] zfcp: Remove SCSI devices when removing complete adapter
From: Christof Schmitt <[EMAIL PROTECTED]>
The common I/O layer can call remove a handler to inform zfcp
that a device disappeared. The handler zfcp_ccw_remove then
removes all unit, port and the adapter data structures. Removing
the units requires that the SCSI devices are removed first.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_ccw.c |3 +++
1 file changed, 3 insertions(+)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_ccw.c
linux-2.6-patched/drivers/s390/scsi/zfcp_ccw.c
--- linux-2.6/drivers/s390/scsi/zfcp_ccw.c 2007-11-02 08:37:56.0
+0100
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_ccw.c 2007-11-02
08:38:26.0 +0100
@@ -120,6 +120,9 @@ zfcp_ccw_remove(struct ccw_device *ccw_d
list_for_each_entry_safe(port, p, &adapter->port_remove_lh, list) {
list_for_each_entry_safe(unit, u, &port->unit_remove_lh, list) {
+ if (atomic_test_mask(ZFCP_STATUS_UNIT_REGISTERED,
+ &unit->status))
+ scsi_remove_device(unit->device);
zfcp_unit_dequeue(unit);
}
zfcp_port_dequeue(port);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 5/6] zfcp: Fix deadlock when adding invalid LUN
From: Christof Schmitt <[EMAIL PROTECTED]>
When adding an invalid LUN, there is a deadlock between the add
via scsi_scan_target and the slave_destroy handler: The handler
waits for the scan to complete, but for an invalid unit,
scsi_scan_target directly calls the slave_destroy handler.
Fix the deadlock by removing the wait in the slave_destroy
handler, it was not necessary anyway.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |2 --
drivers/s390/scsi/zfcp_def.h |4
drivers/s390/scsi/zfcp_erp.c |1 -
drivers/s390/scsi/zfcp_scsi.c |3 ---
4 files changed, 10 deletions(-)
Index: scsi-misc/drivers/s390/scsi/zfcp_aux.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_aux.c
+++ scsi-misc/drivers/s390/scsi/zfcp_aux.c
@@ -844,8 +844,6 @@ zfcp_unit_enqueue(struct zfcp_port *port
unit->sysfs_device.release = zfcp_sysfs_unit_release;
dev_set_drvdata(&unit->sysfs_device, unit);
- init_waitqueue_head(&unit->scsi_scan_wq);
-
/* mark unit unusable as long as sysfs registration is not complete */
atomic_set_mask(ZFCP_STATUS_COMMON_REMOVE, &unit->status);
Index: scsi-misc/drivers/s390/scsi/zfcp_def.h
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_def.h
+++ scsi-misc/drivers/s390/scsi/zfcp_def.h
@@ -982,10 +982,6 @@ struct zfcp_unit {
struct scsi_device *device;/* scsi device struct pointer */
struct zfcp_erp_action erp_action; /* pending error recovery */
atomic_t erp_counter;
- wait_queue_head_t scsi_scan_wq; /* can be used to wait until
- all scsi_scan_target
- requests have been
- completed. */
};
/* FSF request */
Index: scsi-misc/drivers/s390/scsi/zfcp_erp.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_erp.c
+++ scsi-misc/drivers/s390/scsi/zfcp_erp.c
@@ -1609,7 +1609,6 @@ static void zfcp_erp_scsi_scan(struct wo
scsi_scan_target(&rport->dev, 0, rport->scsi_target_id,
unit->scsi_lun, 0);
atomic_clear_mask(ZFCP_STATUS_UNIT_SCSI_WORK_PENDING, &unit->status);
- wake_up(&unit->scsi_scan_wq);
zfcp_unit_put(unit);
kfree(p);
}
Index: scsi-misc/drivers/s390/scsi/zfcp_scsi.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_scsi.c
+++ scsi-misc/drivers/s390/scsi/zfcp_scsi.c
@@ -180,9 +180,6 @@ static void zfcp_scsi_slave_destroy(stru
if (unit) {
zfcp_erp_wait(unit->port->adapter);
- wait_event(unit->scsi_scan_wq,
- atomic_test_mask(ZFCP_STATUS_UNIT_SCSI_WORK_PENDING,
- &unit->status) == 0);
atomic_clear_mask(ZFCP_STATUS_UNIT_REGISTERED, &unit->status);
sdpnt->hostdata = NULL;
unit->device = NULL;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 6/6] zfcp: Reduce flood on hba trace
From: Christof Schmitt <[EMAIL PROTECTED]>
Remove tracing for request with a "qualifier" field set in the
response. The protocol status qualifier now contains measurement
data for "good" commands, so this check would trace every response
by default.
The fix is to simply remove the "qual" tracing: The responses with an
interesting status are also traced as "ferr" or "perr" and all
responses can be traced as "norm" with a higher trace level.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_dbf.c |6 --
1 file changed, 6 deletions(-)
Index: scsi-misc/drivers/s390/scsi/zfcp_dbf.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_dbf.c
+++ scsi-misc/drivers/s390/scsi/zfcp_dbf.c
@@ -161,12 +161,6 @@ void zfcp_hba_dbf_event_fsf_response(str
(fsf_req->fsf_command == FSF_QTCB_OPEN_LUN)) {
strncpy(rec->tag2, "open", ZFCP_DBF_TAG_SIZE);
level = 4;
- } else if ((prot_status_qual->doubleword[0] != 0) ||
- (prot_status_qual->doubleword[1] != 0) ||
- (fsf_status_qual->doubleword[0] != 0) ||
- (fsf_status_qual->doubleword[1] != 0)) {
- strncpy(rec->tag2, "qual", ZFCP_DBF_TAG_SIZE);
- level = 3;
} else {
strncpy(rec->tag2, "norm", ZFCP_DBF_TAG_SIZE);
level = 6;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/6] zfcp: Specify waiting times in ERP in seconds
From: Christof Schmitt <[EMAIL PROTECTED]>
It is not necessary to use jiffies or milliseconds to specify
waiting times that last a couple of seconds.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_def.h |4 ++--
drivers/s390/scsi/zfcp_erp.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
Index: scsi-misc/drivers/s390/scsi/zfcp_def.h
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_def.h
+++ scsi-misc/drivers/s390/scsi/zfcp_def.h
@@ -117,7 +117,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_SBAL_TIMEOUT (5*HZ)
-#define ZFCP_TYPE2_RECOVERY_TIME(8*HZ)
+#define ZFCP_TYPE2_RECOVERY_TIME8 /* seconds */
/* queue polling (values in microseconds) */
#define ZFCP_MAX_INPUT_THRESHOLD 5000/* FIXME: tune */
@@ -138,7 +138,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_STATUS_READS_RECOMFSF_STATUS_READS_RECOM
/* Do 1st retry in 1 second, then double the timeout for each following retry
*/
-#define ZFCP_EXCHANGE_CONFIG_DATA_FIRST_SLEEP 100
+#define ZFCP_EXCHANGE_CONFIG_DATA_FIRST_SLEEP 1
#define ZFCP_EXCHANGE_CONFIG_DATA_RETRIES 7
/* timeout value for "default timer" for fsf requests */
Index: scsi-misc/drivers/s390/scsi/zfcp_erp.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_erp.c
+++ scsi-misc/drivers/s390/scsi/zfcp_erp.c
@@ -131,7 +131,7 @@ static void zfcp_close_qdio(struct zfcp_
debug_text_event(adapter->erp_dbf, 3, "qdio_down2a");
while (qdio_shutdown(adapter->ccw_device,
QDIO_FLAG_CLEANUP_USING_CLEAR) == -EINPROGRESS)
- msleep(1000);
+ ssleep(1);
debug_text_event(adapter->erp_dbf, 3, "qdio_down2b");
/* cleanup used outbound sbals */
@@ -1900,7 +1900,7 @@ zfcp_erp_adapter_strategy(struct zfcp_er
ZFCP_LOG_INFO("Waiting to allow the adapter %s "
"to recover itself\n",
zfcp_get_busid_by_adapter(adapter));
- msleep(jiffies_to_msecs(ZFCP_TYPE2_RECOVERY_TIME));
+ ssleep(ZFCP_TYPE2_RECOVERY_TIME);
}
return retval;
@@ -2080,7 +2080,7 @@ zfcp_erp_adapter_strategy_open_qdio(stru
debug_text_event(adapter->erp_dbf, 3, "qdio_down1a");
while (qdio_shutdown(adapter->ccw_device,
QDIO_FLAG_CLEANUP_USING_CLEAR) == -EINPROGRESS)
- msleep(1000);
+ ssleep(1);
debug_text_event(adapter->erp_dbf, 3, "qdio_down1b");
failed_qdio_establish:
@@ -2165,7 +2165,7 @@ zfcp_erp_adapter_strategy_open_fsf_xconf
ZFCP_LOG_DEBUG("host connection still initialising... "
"waiting and retrying...\n");
/* sleep a little bit before retry */
- msleep(jiffies_to_msecs(sleep));
+ ssleep(sleep);
sleep *= 2;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: add some internal zfcp adapter statistics
From: Swen Schillig <[EMAIL PROTECTED]>
add some statistics provided by the zFCP adapter to the sysfs
The new zFCP adapter statistics provide a variety of information
about the virtual adapter (subchannel). In order to collect this information
the zFCP driver is extended on one side to query the adapter and
on the other side summarize certain values which can then be fetched on demand.
This information is made available via files(attributes) in the sysfs
filesystem.
The information provided by the new zFCP adapter statistics can be fetched
by reading from the following files in the sysfs filesystem
/sys/class/scsi_host/host/seconds_active
/sys/class/scsi_host/host/requests
/sys/class/scsi_host/host/megabytes
/sys/class/scsi_host/host/utilization
These are the statistics on a virtual adapter (subchannel) level.
In addition latency information is provided on a SCSI device level (LUN) which
can be found at the following location
/sys/class/scsi_device//device/cmd_latency
/sys/class/scsi_device//device/read_latency
/sys/class/scsi_device//device/write_latency
The information provided is raw and not modified or interpreted by any means.
No interpretation or modification of the values is done by the zFCP driver.
The individual values are summed up during normal operation of the virtual
adapter.
An overrun of the variables is neither detected nor treated. The conclusion is
that
the file has to be read twice to make a meaningful statement, because only the
differences of the values
between the two reads can be used.
The statistics make use of the SCSI mid-layer interface to provide its data to
the user.
In detail two hooks from the scsi_host_template are used to integrate
the zFCP statistics.
struct scsi_host_template {
...
.shost_attrs = zfcp_a_stats_attrs,
.sdev_attrs = zfcp_sysfs_sdev_attrs,
...
};
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_def.h | 13 +++
drivers/s390/scsi/zfcp_fsf.c | 36 ++
drivers/s390/scsi/zfcp_fsf.h | 29 +++-
drivers/s390/scsi/zfcp_scsi.c | 148 ++
4 files changed, 223 insertions(+), 3 deletions(-)
Index: scsi-misc/drivers/s390/scsi/zfcp_def.h
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_def.h
+++ scsi-misc/drivers/s390/scsi/zfcp_def.h
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel features */
u32 connection_features; /* host connection
features */
u32hardware_version; /* of FCP channel */
+ u16 timer_ticks; /* time int for a tick */
struct Scsi_Host*scsi_host;/* Pointer to mid-layer */
struct list_headport_list_head;/* remote port list */
struct list_headport_remove_lh;/* head of ports to be
@@ -986,6 +998,7 @@ struct zfcp_unit {
all scsi_scan_target
requests have been
completed. */
+ struct zfcp_latencies latencies;
};
/* FSF request */
Index: scsi-misc/drivers/s390/scsi/zfcp_fsf.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_fsf.c
+++ scsi-misc/drivers/s390/scsi/zfcp_fsf.c
@@ -2079,6 +2079,7 @@ zfcp_fsf_exchange_config_evaluate(struct
fc_host_supported_classes(shost) =
FC_COS_CLASS2 | FC_COS_CLASS3;
adapter->hydra_version = bottom->adapter_type;
+ adapter->timer_ticks = bottom->timer_interval;
if (fc_host_permanent_port_name(shost) == -1)
fc_host_permanent_port_name(shost) =
fc_host_port_name(shost);
@@ -3823,6 +3824,33 @@ zfcp_fsf_send_fcp_command_task_managemen
return fsf_req;
}
+static void zfcp_fsf_req_latency(struct zfcp_fsf_req *fsf_req)
+{
+ struct fsf_qual_latency_info *lat_inf;
+ struct zfcp_unit *unit;
+
+ lat_inf = &fsf_req->qtcb->prefix.prot_status_qual.latency_info;
+ unit = fsf_req->unit;
+
+ switch (fsf_req->qtcb->bottom.io.data_direction) {
+ case FSF_DATADIR_READ:
+ uni
Re: [PATCH] zfcp: add some internal zfcp adapter statistics
On Saturday 03 November 2007 10:40, Heiko Carstens wrote:
> > > + if (!(adapter->adapter_features & FSF_FEATURE_MEASUREMENT_DATA)) {
> > > + ZFCP_LOG_NORMAL("error: Enhanced measurement feature not "
> > > + "supported");
> > > + return -EOPNOTSUPP;
> > > + }
>
> Btw. any user can flood the console with these messages if the adapter
> doesn't support the feature. That can be considered a denial of service
> attack. Please just return -EOPNOTSUPP and don't print anything on the
> console.
>
I can see your point but I think you're a bit too extreme in your assessment on
a simple console
message (with almost no processing behind it). If someone really wants to
"flood" the console with messages they
go other and possibly easier ways to achieve the same thing, how about "logger"
!
But since it seems to bother you a lot, I will remove the message.
Cheers Swen
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: add some internal zfcp adapter statistics
On Saturday 03 November 2007 10:17, Heiko Carstens wrote:
> > +static void zfcp_fsf_req_latency(struct zfcp_fsf_req *fsf_req)
> > +{
> > + struct fsf_qual_latency_info *lat_inf;
> > + struct zfcp_unit *unit;
> > +
> > + lat_inf = &fsf_req->qtcb->prefix.prot_status_qual.latency_info;
> > + unit = fsf_req->unit;
> > +
> > + switch (fsf_req->qtcb->bottom.io.data_direction) {
> > + case FSF_DATADIR_READ:
> > + unit->latencies.read.channel += lat_inf->channel_lat;
> > + unit->latencies.read.fabric += lat_inf->fabric_lat;
> > + unit->latencies.read.counter++;
> > + break;
> > + case FSF_DATADIR_WRITE:
> > + unit->latencies.write.channel += lat_inf->channel_lat;
> > + unit->latencies.write.fabric += lat_inf->fabric_lat;
> > + unit->latencies.write.counter++;
> > + break;
> > + case FSF_DATADIR_CMND:
> > + unit->latencies.cmd.channel += lat_inf->channel_lat;
> > + unit->latencies.cmd.fabric += lat_inf->fabric_lat;
> > + unit->latencies.cmd.counter++;
> > + break;
> > + }
> > +}
>
> These statistics are concurrently updated from several cpus without
> any locking. That looks like a bug.
>
> > +zfcp_sysfs_unit_##_name##_latency_show(struct device *dev, \
> > + struct device_attribute *attr, \
> > + char *buf) { \
> > + struct scsi_device *sdev = to_scsi_device(dev); \
> > + struct zfcp_unit *unit = sdev->hostdata;\
> > + struct zfcp_latencies *lat = &unit->latencies; \
> > + struct zfcp_adapter *adapter = unit->port->adapter; \
> > + \
> > + return sprintf(buf, "%u %u %u\n", \
> > + lat->_name.fabric * adapter->timer_ticks / 1000, \
> > + lat->_name.channel * adapter->timer_ticks / 1000,\
> > + lat->_name.counter); \
>
> In addition they can be read concurrently from userspace without any
> locking... Since you put several values together in the output I assume
> this is supposed to be some sort of snapshot, which it currently isn't.
>
> > +static int
> > +zfcp_sysfs_adapter_ex_config(struct class_device *cdev,
> > +struct fsf_qtcb_bottom_config **qtcb_config)
> > +{
> > + struct Scsi_Host *scsi_host = class_to_shost(cdev);
> > + struct zfcp_adapter *adapter = (struct zfcp_adapter *)
> > + scsi_host->hostdata[0];
> > +
> > + if (!(adapter->adapter_features & FSF_FEATURE_MEASUREMENT_DATA)) {
> > + ZFCP_LOG_NORMAL("error: Enhanced measurement feature not "
> > + "supported");
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + *qtcb_config = kzalloc(sizeof(struct fsf_qtcb_bottom_config),
> > + GFP_KERNEL);
> > + if (!*qtcb_config)
> > + return -ENOMEM;
> > +
> > + return zfcp_fsf_exchange_config_data_sync(adapter, *qtcb_config);
> > +}
> > +
> > +static ssize_t
> > +zfcp_sysfs_adapter_request_show(struct class_device *cdev, char *buf)
> > +{
> > + struct fsf_qtcb_bottom_config *qtcb_config;
> > + int retval;
> > +
> > + retval = zfcp_sysfs_adapter_ex_config(cdev, &qtcb_config);
> > +
> > + if (!retval)
> > + retval = sprintf(buf, "%lu %lu %lu\n",
> > +qtcb_config->stat_info.input_req,
> > +qtcb_config->stat_info.output_req,
> > +qtcb_config->stat_info.control_req);
> > +
> > + kfree(qtcb_config);
> > + return retval;
> > +}
>
> You're going to call kfree with some random value if the adapter doesn't
> support the measurement data feature.
>
Ok, valid points.
I changed the patch to meet the above described issues.
Before I will post the modified version I want to do some testing (and an
internal review).
The updated version will follow soon (hopefully this week), thanks for
reviewing.
Cheers Swen
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH UPDATE] zfcp: add some internal zfcp adapter statistics
Updated the statistics patch to cover the issues pointed out by Heiko.
James, could you please apply.
Thanks
Swen
---
From: Swen Schillig <[EMAIL PROTECTED]>
add some statistics provided by the zFCP adapter to the sysfs
The new zFCP adapter statistics provide a variety of information
about the virtual adapter (subchannel). In order to collect this information
the zFCP driver is extended on one side to query the adapter and
on the other side summarize certain values which can then be fetched on demand.
This information is made available via files(attributes) in the sysfs
filesystem.
The information provided by the new zFCP adapter statistics can be fetched
by reading from the following files in the sysfs filesystem
/sys/class/scsi_host/host/seconds_active
/sys/class/scsi_host/host/requests
/sys/class/scsi_host/host/megabytes
/sys/class/scsi_host/host/utilization
These are the statistics on a virtual adapter (subchannel) level.
In addition latency information is provided on a SCSI device level (LUN) which
can be found at the following location
/sys/class/scsi_device//device/cmd_latency
/sys/class/scsi_device//device/read_latency
/sys/class/scsi_device//device/write_latency
The information provided is raw and not modified or interpreted by any means.
No interpretation or modification of the values is done by the zFCP driver.
The individual values are summed up during normal operation of the virtual
adapter.
An overrun of the variables is neither detected nor treated. The conclusion is
that
the file has to be read twice to make a meaningful statement, because only the
differences of the values
between the two reads can be used.
The statistics make use of the SCSI mid-layer interface to provide its data to
the user.
In detail two hooks from the scsi_host_template are used to integrate
the zFCP statistics.
struct scsi_host_template {
...
.shost_attrs = zfcp_a_stats_attrs,
.sdev_attrs = zfcp_sysfs_sdev_attrs,
...
};
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Michael Loehr <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |2
drivers/s390/scsi/zfcp_def.h | 14 +++
drivers/s390/scsi/zfcp_fsf.c | 39 ++
drivers/s390/scsi/zfcp_fsf.h | 29 +++-
drivers/s390/scsi/zfcp_scsi.c | 149 ++
5 files changed, 230 insertions(+), 3 deletions(-)
Index: scsi-misc/drivers/s390/scsi/zfcp_def.h
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_def.h
+++ scsi-misc/drivers/s390/scsi/zfcp_def.h
@@ -869,6 +869,18 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+ spinlock_t lock;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -884,6 +896,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel features */
u32 connection_features; /* host connection
features */
u32hardware_version; /* of FCP channel */
+ u16 timer_ticks; /* time int for a tick */
struct Scsi_Host*scsi_host;/* Pointer to mid-layer */
struct list_headport_list_head;/* remote port list */
struct list_headport_remove_lh;/* head of ports to be
@@ -983,6 +996,7 @@ struct zfcp_unit {
struct scsi_device *device;/* scsi device struct pointer */
struct zfcp_erp_action erp_action; /* pending error recovery */
atomic_t erp_counter;
+ struct zfcp_latencies latencies;
};
/* FSF request */
Index: scsi-misc/drivers/s390/scsi/zfcp_fsf.c
===
--- scsi-misc.orig/drivers/s390/scsi/zfcp_fsf.c
+++ scsi-misc/drivers/s390/scsi/zfcp_fsf.c
@@ -2079,6 +2079,7 @@ zfcp_fsf_exchange_config_evaluate(struct
fc_host_supported_classes(shost) =
FC_COS_CLASS2 | FC_COS_CLASS3;
adapter->hydra_version = bottom->adapter_type;
+ adapter->timer_ticks = bottom->timer_interval;
if (fc_host_permanent_port_name(shost) == -1)
fc_host_permanent_port_name(shost) =
fc_host_port_name(shost);
@@ -3823,6 +3824,36 @@ zfcp_fsf_send_fcp_command_task_managemen
return fsf_req;
}
+static void zfcp_fsf_req_latency(struct zfcp_fsf_req *fsf_req)
+{
+ struct fsf_qual_latency_info *lat_inf;
+ struct zfcp_unit *unit;
+ un
Re: [PATCH UPDATE] zfcp: add some internal zfcp adapter statistics
James
can you give me the status of the below patch ?
Is there anything missing from my side or is the patch still in review by you ?
Cheers Swen
On Friday 09 November 2007 14:07, Swen Schillig wrote:
> Updated the statistics patch to cover the issues pointed out by Heiko.
>
> James, could you please apply.
>
> Thanks
> Swen
>
> ---
> From: Swen Schillig <[EMAIL PROTECTED]>
>
> add some statistics provided by the zFCP adapter to the sysfs
>
> The new zFCP adapter statistics provide a variety of information
> about the virtual adapter (subchannel). In order to collect this information
> the zFCP driver is extended on one side to query the adapter and
> on the other side summarize certain values which can then be fetched on
> demand.
> This information is made available via files(attributes) in the sysfs
> filesystem.
>
> The information provided by the new zFCP adapter statistics can be fetched
> by reading from the following files in the sysfs filesystem
>
> /sys/class/scsi_host/host/seconds_active
> /sys/class/scsi_host/host/requests
> /sys/class/scsi_host/host/megabytes
> /sys/class/scsi_host/host/utilization
>
> These are the statistics on a virtual adapter (subchannel) level.
> In addition latency information is provided on a SCSI device level (LUN) which
> can be found at the following location
>
> /sys/class/scsi_device//device/cmd_latency
> /sys/class/scsi_device//device/read_latency
> /sys/class/scsi_device//device/write_latency
>
>
> The information provided is raw and not modified or interpreted by any means.
> No interpretation or modification of the values is done by the zFCP driver.
> The individual values are summed up during normal operation of the virtual
> adapter.
> An overrun of the variables is neither detected nor treated. The conclusion
> is that
> the file has to be read twice to make a meaningful statement, because only
> the differences of the values
> between the two reads can be used.
>
> The statistics make use of the SCSI mid-layer interface to provide its data
> to the user.
> In detail two hooks from the scsi_host_template are used to integrate
> the zFCP statistics.
>
> struct scsi_host_template {
> ...
> .shost_attrs = zfcp_a_stats_attrs,
> .sdev_attrs = zfcp_sysfs_sdev_attrs,
> ...
> };
>
>
> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
> Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
> Signed-off-by: Michael Loehr <[EMAIL PROTECTED]>
>
> ---
> drivers/s390/scsi/zfcp_aux.c |2
> drivers/s390/scsi/zfcp_def.h | 14 +++
> drivers/s390/scsi/zfcp_fsf.c | 39 ++
> drivers/s390/scsi/zfcp_fsf.h | 29 +++-
> drivers/s390/scsi/zfcp_scsi.c | 149
> ++
> 5 files changed, 230 insertions(+), 3 deletions(-)
>
> Index: scsi-misc/drivers/s390/scsi/zfcp_def.h
> ===
> --- scsi-misc.orig/drivers/s390/scsi/zfcp_def.h
> +++ scsi-misc/drivers/s390/scsi/zfcp_def.h
> @@ -869,6 +869,18 @@ struct zfcp_erp_action {
> struct timer_list timer;
> };
>
> +struct latency_cont {
> + u32 channel;
> + u32 fabric;
> + u32 counter;
> +};
> +
> +struct zfcp_latencies {
> + struct latency_cont read;
> + struct latency_cont write;
> + struct latency_cont cmd;
> + spinlock_t lock;
> +};
>
> struct zfcp_adapter {
> struct list_headlist; /* list of adapters */
> @@ -884,6 +896,7 @@ struct zfcp_adapter {
> u32 adapter_features; /* FCP channel features */
> u32 connection_features; /* host connection
> features */
> u32 hardware_version; /* of FCP channel */
> + u16 timer_ticks; /* time int for a tick */
> struct Scsi_Host*scsi_host;/* Pointer to mid-layer */
> struct list_headport_list_head;/* remote port list */
> struct list_headport_remove_lh;/* head of ports to be
> @@ -983,6 +996,7 @@ struct zfcp_unit {
> struct scsi_device *device;/* scsi device struct pointer
> */
> struct zfcp_erp_action erp_action; /* pending error recovery */
> atomic_t erp_counter;
> + struct zfcp_latencies latencies;
> };
>
> /* FSF request */
> Index: scsi-misc/drivers/s390/scsi/zfcp_fsf.c
> ===
> --- scsi-misc.orig/drivers/s390/scsi/zfcp_fsf.c
> +++ scsi-misc/drivers/s
[PATCH] zfcp: fix use after free bug
From: Heiko Carstens <[EMAIL PROTECTED]>
zfcp_erp_strategy_check_fsfreq() checks if it is safe to access the
fsf_req associated with the erp_action that gets passed. To test if
it is safe it accesses the fsf_req in order to get its index into
the hash list. This is broken since the fsf_req might be freed already
and the read index has no meaning. It could lead to memory corruption.
Fix this by introducing a new zfcp_reqlist_find_safe() method which
just checks if addresses are equal. This is slower, but only gets
called in case of error recovery.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_def.h | 14 ++
drivers/s390/scsi/zfcp_erp.c |3 ++-
2 files changed, 16 insertions(+), 1 deletion(-)
Index: SHIP_OCT2005/drivers/s390/scsi/zfcp_def.h
===
--- SHIP_OCT2005.orig/drivers/s390/scsi/zfcp_def.h
+++ SHIP_OCT2005/drivers/s390/scsi/zfcp_def.h
@@ -1210,6 +1210,20 @@ zfcp_reqlist_find(struct zfcp_adapter *a
return NULL;
}
+static inline struct zfcp_fsf_req *
+zfcp_reqlist_find_safe(struct zfcp_adapter *adapter, struct zfcp_fsf_req *req)
+{
+ struct zfcp_fsf_req *request;
+ unsigned int idx;
+
+ for (idx = 0; idx < REQUEST_LIST_SIZE; idx++) {
+ list_for_each_entry(request, &adapter->req_list[idx], list)
+ if (request == req)
+ return request;
+ }
+ return NULL;
+}
+
/*
* functions needed for reference/usage counting
*/
Index: SHIP_OCT2005/drivers/s390/scsi/zfcp_erp.c
===
--- SHIP_OCT2005.orig/drivers/s390/scsi/zfcp_erp.c
+++ SHIP_OCT2005/drivers/s390/scsi/zfcp_erp.c
@@ -837,7 +837,8 @@ zfcp_erp_strategy_check_fsfreq(struct zf
if (erp_action->fsf_req) {
/* take lock to ensure that request is not deleted meanwhile */
spin_lock(&adapter->req_list_lock);
- if (zfcp_reqlist_find(adapter, erp_action->fsf_req->req_id)) {
+ if (zfcp_reqlist_find_safe(adapter, erp_action->fsf_req) &&
+ erp_action->fsf_req->erp_action == erp_action) {
/* fsf_req still exists */
debug_text_event(adapter->erp_dbf, 3, "a_ca_req");
debug_event(adapter->erp_dbf, 3, &erp_action->fsf_req,
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: add some internal zfcp adapter statistics
On Sunday 25 November 2007 12:16, James Bottomley wrote: > > On Wed, 2007-10-31 at 11:33 +0100, Swen Schillig wrote: > > From: Swen Schillig <[EMAIL PROTECTED]> > > > > add some statistics provided by the zFCP adapter to the sysfs > > > > The new zFCP adapter statistics provide a variety of information > > about the virtual adapter (subchannel). In order to collect this information > > the zFCP driver is extended on one side to query the adapter and > > on the other side summarize certain values which can then be fetched on > > demand. > > This information is made available via files(attributes) in the sysfs > > filesystem. > > > > The information provided by the new zFCP adapter statistics can be fetched > > by reading from the following files in the sysfs filesystem > > > > /sys/class/scsi_host/host/seconds_active > > /sys/class/scsi_host/host/requests > > /sys/class/scsi_host/host/megabytes > > /sys/class/scsi_host/host/utilization > > This lot all look like they belong in the FC transport class statistics > (some even already exist there). They might look alike but they are not the same. The values provided through the FC transport class always refer to the physical port whereas the new values here refer to a virtual adapter or subchannel. The attributes provided here are all new and not covered or displayed anywhere else ! > > > These are the statistics on a virtual adapter (subchannel) level. > > In addition latency information is provided on a SCSI device level (LUN) > > which > > can be found at the following location > > > > /sys/class/scsi_device//device/cmd_latency > > /sys/class/scsi_device//device/read_latency > > /sys/class/scsi_device//device/write_latency > > These look to duplicate to some degree the figures > in /sys/block//stat. Isn't the block device the best place to > gather these, if they're useful? Since user latencies should probably > include elevator times. Actually no, the latencies covered here are channel- and fabric-latencies grouped by scsi-devices and not device-, scsi- or block-latencies. In contrast to the stats provided by the block-layer structure, tape devices will be covered here as well . > > James > > > Cheers Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: add some internal zfcp adapter statistics
On Monday 26 November 2007 11:23, Swen Schillig wrote: > On Sunday 25 November 2007 12:16, James Bottomley wrote: > > > > On Wed, 2007-10-31 at 11:33 +0100, Swen Schillig wrote: > > > From: Swen Schillig <[EMAIL PROTECTED]> > > > > > > add some statistics provided by the zFCP adapter to the sysfs > > > > > > The new zFCP adapter statistics provide a variety of information > > > about the virtual adapter (subchannel). In order to collect this > > > information > > > the zFCP driver is extended on one side to query the adapter and > > > on the other side summarize certain values which can then be fetched on > > > demand. > > > This information is made available via files(attributes) in the sysfs > > > filesystem. > > > > > > The information provided by the new zFCP adapter statistics can be fetched > > > by reading from the following files in the sysfs filesystem > > > > > > /sys/class/scsi_host/host/seconds_active > > > /sys/class/scsi_host/host/requests > > > /sys/class/scsi_host/host/megabytes > > > /sys/class/scsi_host/host/utilization > > > > This lot all look like they belong in the FC transport class statistics > > (some even already exist there). > > They might look alike but they are not the same. The values provided through > the FC transport > class always refer to the physical port whereas the new values here refer to > a virtual adapter or subchannel. > The attributes provided here are all new and not covered or displayed > anywhere else ! > > > > > > These are the statistics on a virtual adapter (subchannel) level. > > > In addition latency information is provided on a SCSI device level (LUN) > > > which > > > can be found at the following location > > > > > > /sys/class/scsi_device//device/cmd_latency > > > /sys/class/scsi_device//device/read_latency > > > /sys/class/scsi_device//device/write_latency > > > > These look to duplicate to some degree the figures > > in /sys/block//stat. Isn't the block device the best place to > > gather these, if they're useful? Since user latencies should probably > > include elevator times. > > Actually no, the latencies covered here are channel- and fabric-latencies > grouped by scsi-devices > and not device-, scsi- or block-latencies. In contrast to the stats provided > by the block-layer structure, > tape devices will be covered here as well . > > > > > James > > > > > > > > Cheers Swen > James were my answers, comments sufficient enough to apply my patch or is there still something missing required ? Thanks Cheers Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MAINTAINERS: zfcp
James we are planning a major rewrite of the zfcp driver, meaning that a lot of patches will hit the mailing-list in the near future. Since I can't support this additional work-load along with my other responsibilities we are shifting the maintainership to Christof Schmitt as the maintainer and Martin Peschke as the co-maintainer. Please support the two in providing us a new and more stable zfcp environment. Thanks Swen --- MAINTAINERS |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Index: scsi-misc/MAINTAINERS === --- scsi-misc.orig/MAINTAINERS +++ scsi-misc/MAINTAINERS @@ -3246,8 +3246,10 @@ W: http://www.ibm.com/developerworks/lin S: Supported S390 ZFCP DRIVER -P: Swen Schillig -M: [EMAIL PROTECTED] +P: Christof Schmitt +M: [EMAIL PROTECTED] +P: Martin Peschke +M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.ibm.com/developerworks/linux/linux390/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] zfcp: NULL vs 0 usage
Subject: [PATCH] zfcp: NULL vs 0 usage
From: Heiko Carstens <[EMAIL PROTECTED]>
Get rid of two 'warning: Using plain integer as NULL pointer'.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |9 +++--
drivers/s390/scsi/zfcp_fsf.c |2 +-
2 files changed, 4 insertions(+), 7 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_aux.c
linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-07-18 10:27:48.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c 2007-07-18
10:28:25.0 +0200
@@ -1526,15 +1526,12 @@ zfcp_gid_pn_buffers_alloc(struct zfcp_gi
* zfcp_gid_pn_buffers_free - free buffers for GID_PN nameserver request
* @gid_pn: pointer to struct zfcp_gid_pn_data which has to be freed
*/
-static void
-zfcp_gid_pn_buffers_free(struct zfcp_gid_pn_data *gid_pn)
+static void zfcp_gid_pn_buffers_free(struct zfcp_gid_pn_data *gid_pn)
{
-if ((gid_pn->ct.pool != 0))
+ if (gid_pn->ct.pool)
mempool_free(gid_pn, gid_pn->ct.pool);
else
-kfree(gid_pn);
-
- return;
+ kfree(gid_pn);
}
/**
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_fsf.c
linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c
--- linux-2.6/drivers/s390/scsi/zfcp_fsf.c 2007-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c 2007-07-18
10:28:25.0 +0200
@@ -1930,7 +1930,7 @@ static int zfcp_fsf_send_els_handler(str
skip_fsfstatus:
send_els->status = retval;
- if (send_els->handler != 0)
+ if (send_els->handler)
send_els->handler(send_els->handler_data);
return retval;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] zfcp: Replace kmalloc/memset with kzalloc
Subject: [PATCH] zfcp: Replace kmalloc/memset with kzalloc
From: Swen Schillig <[EMAIL PROTECTED]>
Memory allocated with kmalloc is always initialzed to 0 with memset.
Replace the two calls with kzalloc, that already does both steps.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_erp.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_erp.c
linux-2.6-patched/drivers/s390/scsi/zfcp_erp.c
--- linux-2.6/drivers/s390/scsi/zfcp_erp.c 2007-07-18 10:27:48.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_erp.c 2007-07-18
10:28:23.0 +0200
@@ -1626,7 +1626,7 @@ zfcp_erp_schedule_work(struct zfcp_unit
{
struct zfcp_erp_add_work *p;
- p = kmalloc(sizeof(*p), GFP_KERNEL);
+ p = kzalloc(sizeof(*p), GFP_KERNEL);
if (!p) {
ZFCP_LOG_NORMAL("error: Out of resources. Could not register "
"the FCP-LUN 0x%Lx connected to "
@@ -1639,7 +1639,6 @@ zfcp_erp_schedule_work(struct zfcp_unit
}
zfcp_unit_get(unit);
- memset(p, 0, sizeof(*p));
atomic_set_mask(ZFCP_STATUS_UNIT_SCSI_WORK_PENDING, &unit->status);
INIT_WORK(&p->work, zfcp_erp_scsi_scan);
p->unit = unit;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] zfcp: code cleanup
Subject: [PATCH] zfcp: code cleanup
From: Swen Schillig <[EMAIL PROTECTED]>
improve code for buffer enqueue. easy readability and maintainability.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_def.h |1
drivers/s390/scsi/zfcp_qdio.c | 113 +++---
2 files changed, 33 insertions(+), 81 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_def.h
linux-2.6-patched/drivers/s390/scsi/zfcp_def.h
--- linux-2.6/drivers/s390/scsi/zfcp_def.h 2007-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_def.h 2007-07-18
10:28:26.0 +0200
@@ -126,6 +126,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_MIN_OUTPUT_THRESHOLD 1 /* ignored by QDIO layer */
#define QDIO_SCSI_QFMT 1 /* 1 for FSF */
+#define QBUFF_PER_PAGE (PAGE_SIZE / sizeof(struct qdio_buffer))
/* FSF SPECIFIC DEFINES */
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-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_qdio.c 2007-07-18
10:28:26.0 +0200
@@ -47,103 +47,56 @@ static int zfcp_qdio_handler_error_check
#define ZFCP_LOG_AREA ZFCP_LOG_AREA_QDIO
/*
- * Allocates BUFFER memory to each of the pointers of the qdio_buffer_t
- * array in the adapter struct.
- * Cur_buf is the pointer array and count can be any number of required
- * buffers, the page-fitting arithmetic is done entirely within this funciton.
+ * Frees BUFFER memory for each of the pointers of the struct qdio_buffer array
+ * in the adapter struct sbuf is the pointer array.
*
- * returns:number of buffers allocated
* locks: must only be called with zfcp_data.config_sema taken
*/
-static int
-zfcp_qdio_buffers_enqueue(struct qdio_buffer **cur_buf, int count)
+static void
+zfcp_qdio_buffers_dequeue(struct qdio_buffer **sbuf)
{
- int buf_pos;
- int qdio_buffers_per_page;
- int page_pos = 0;
- struct qdio_buffer *first_in_page = NULL;
-
- qdio_buffers_per_page = PAGE_SIZE / sizeof (struct qdio_buffer);
- ZFCP_LOG_TRACE("buffers_per_page=%d\n", qdio_buffers_per_page);
-
- for (buf_pos = 0; buf_pos < count; buf_pos++) {
- if (page_pos == 0) {
- cur_buf[buf_pos] = (struct qdio_buffer *)
- get_zeroed_page(GFP_KERNEL);
- if (cur_buf[buf_pos] == NULL) {
- ZFCP_LOG_INFO("error: allocation of "
- "QDIO buffer failed \n");
- goto out;
- }
- first_in_page = cur_buf[buf_pos];
- } else {
- cur_buf[buf_pos] = first_in_page + page_pos;
+ int pos;
- }
- /* was initialised to zero */
- page_pos++;
- page_pos %= qdio_buffers_per_page;
- }
- out:
- return buf_pos;
+ for (pos = 0; pos < QDIO_MAX_BUFFERS_PER_Q; pos += QBUFF_PER_PAGE)
+ free_page((unsigned long) sbuf[pos]);
}
/*
- * Frees BUFFER memory for each of the pointers of the struct qdio_buffer array
- * in the adapter struct cur_buf is the pointer array and count can be any
- * number of buffers in the array that should be freed starting from buffer 0
+ * Allocates BUFFER memory to each of the pointers of the qdio_buffer_t
+ * array in the adapter struct.
+ * Cur_buf is the pointer array
*
+ * returns:zero on success else -ENOMEM
* locks: must only be called with zfcp_data.config_sema taken
*/
-static void
-zfcp_qdio_buffers_dequeue(struct qdio_buffer **cur_buf, int count)
+static int
+zfcp_qdio_buffers_enqueue(struct qdio_buffer **sbuf)
{
- int buf_pos;
- int qdio_buffers_per_page;
-
- qdio_buffers_per_page = PAGE_SIZE / sizeof (struct qdio_buffer);
- ZFCP_LOG_TRACE("buffers_per_page=%d\n", qdio_buffers_per_page);
+ int pos;
- for (buf_pos = 0; buf_pos < count; buf_pos += qdio_buffers_per_page)
- free_page((unsigned long) cur_buf[buf_pos]);
- return;
+ for (pos = 0; pos < QDIO_MAX_BUFFERS_PER_Q; pos += QBUFF_PER_PAGE) {
+ sbuf[pos] = (struct qdio_buffer *) get_zeroed_page(GFP_KERNEL);
+ if (!sbuf[pos]) {
+ zfcp_qdio_buffers_dequeue(sbuf);
+ return -ENOMEM;
+ }
+ }
+ for (pos = 0; pos < QDIO_MAX_BUFFERS_PER_Q; pos++)
+ if (pos % QBUFF_PER_PAGE)
+ sbuf[pos] = sbuf[pos - 1] + 1;
+ return 0;
}
/* locks: must only be called with zfcp_data.confi
Re: [PATCH] zfcp: convert to use the data buffer accessors
Replying to the mailing-list as well.
ACK
On Sunday 29 July 2007 09:46, FUJITA Tomonori wrote:
> The patch is only compile tested.
>
> ---
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [PATCH] zfcp: convert to use the data buffer accessors
>
> - remove the unnecessary map_single path.
>
> - convert to use the new accessors for the sg lists and the
> parameters.
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
> drivers/s390/scsi/zfcp_fsf.c |5 +++--
> drivers/s390/scsi/zfcp_qdio.c | 41
> ++---
> 2 files changed, 9 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
> index b240800..9929997 100644
> --- a/drivers/s390/scsi/zfcp_fsf.c
> +++ b/drivers/s390/scsi/zfcp_fsf.c
> @@ -4154,8 +4154,9 @@ zfcp_fsf_send_fcp_command_task_handler(struct
> zfcp_fsf_req *fsf_req)
> fcp_rsp_iu->fcp_resid,
> (int) zfcp_get_fcp_dl(fcp_cmnd_iu));
>
> - scpnt->resid = fcp_rsp_iu->fcp_resid;
> - if (scpnt->request_bufflen - scpnt->resid < scpnt->underflow)
> + scsi_set_resid(scpnt, fcp_rsp_iu->fcp_resid);
> + if (scsi_bufflen(scpnt) - scsi_get_resid(scpnt) <
> + scpnt->underflow)
> set_host_byte(&scpnt->result, DID_ERROR);
> }
>
> diff --git a/drivers/s390/scsi/zfcp_qdio.c b/drivers/s390/scsi/zfcp_qdio.c
> index c408bad..81daa82 100644
> --- a/drivers/s390/scsi/zfcp_qdio.c
> +++ b/drivers/s390/scsi/zfcp_qdio.c
> @@ -36,8 +36,6 @@ static void zfcp_qdio_sbale_fill
> (struct zfcp_fsf_req *, unsigned long, void *, int);
> static int zfcp_qdio_sbals_from_segment
> (struct zfcp_fsf_req *, unsigned long, void *, unsigned long);
> -static int zfcp_qdio_sbals_from_buffer
> - (struct zfcp_fsf_req *, unsigned long, void *, unsigned long, int);
>
> static qdio_handler_t zfcp_qdio_request_handler;
> static qdio_handler_t zfcp_qdio_response_handler;
> @@ -632,28 +630,6 @@ out:
>
>
> /**
> - * zfcp_qdio_sbals_from_buffer - fill SBALs from buffer
> - * @fsf_req: request to be processed
> - * @sbtype: SBALE flags
> - * @buffer: data buffer
> - * @length: length of buffer
> - * @max_sbals: upper bound for number of SBALs to be used
> - */
> -static int
> -zfcp_qdio_sbals_from_buffer(struct zfcp_fsf_req *fsf_req, unsigned long
> sbtype,
> - void *buffer, unsigned long length, int max_sbals)
> -{
> - struct scatterlist sg_segment;
> -
> - zfcp_address_to_sg(buffer, &sg_segment);
> - sg_segment.length = length;
> -
> - return zfcp_qdio_sbals_from_sg(fsf_req, sbtype, &sg_segment, 1,
> - max_sbals);
> -}
> -
> -
> -/**
> * zfcp_qdio_sbals_from_scsicmnd - fill SBALs from scsi command
> * @fsf_req: request to be processed
> * @sbtype: SBALE flags
> @@ -664,18 +640,13 @@ int
> zfcp_qdio_sbals_from_scsicmnd(struct zfcp_fsf_req *fsf_req,
> unsigned long sbtype, struct scsi_cmnd *scsi_cmnd)
> {
> - if (scsi_cmnd->use_sg) {
> + if (scsi_sg_count(scsi_cmnd))
> return zfcp_qdio_sbals_from_sg(fsf_req, sbtype,
> - (struct scatterlist *)
> - scsi_cmnd->request_buffer,
> - scsi_cmnd->use_sg,
> - ZFCP_MAX_SBALS_PER_REQ);
> - } else {
> -return zfcp_qdio_sbals_from_buffer(fsf_req, sbtype,
> - scsi_cmnd->request_buffer,
> -
> scsi_cmnd->request_bufflen,
> - ZFCP_MAX_SBALS_PER_REQ);
> - }
> +scsi_sglist(scsi_cmnd),
> +scsi_sg_count(scsi_cmnd),
> +ZFCP_MAX_SBALS_PER_REQ);
> + else
> + return 0;
> }
>
> /**
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] zfcp: fix memory leak
From: Heiko Carstens <[EMAIL PROTECTED]>
fix memory leak.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_scsi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_scsi.c
linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c
--- linux-2.6/drivers/s390/scsi/zfcp_scsi.c 2007-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c 2007-08-08
10:14:01.0 +0200
@@ -764,7 +764,9 @@ zfcp_reset_fc_host_stats(struct Scsi_Hos
return;
ret = zfcp_fsf_exchange_port_data(NULL, adapter, data);
- if (ret == 0) {
+ if (ret) {
+ kfree(data);
+ } else {
adapter->stats_reset = jiffies/HZ;
old_data = adapter->stats_reset_data;
adapter->stats_reset_data = data; /* finally freed in
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] zfcp: allocate gid_pn_data objects from gid_pn_cache
From: Heiko Carstens <[EMAIL PROTECTED]>
allocate gid_pn_data objects from gid_pn_cache.
Allocate gid_pn_data objects from the corresponding cache which ensures
proper alignment.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_aux.c
linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-08-08 10:13:39.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c 2007-08-08
10:14:02.0 +0200
@@ -1503,7 +1503,7 @@ zfcp_gid_pn_buffers_alloc(struct zfcp_gi
data->ct.pool = pool;
}
} else {
- data = kmalloc(sizeof(struct zfcp_gid_pn_data), GFP_ATOMIC);
+ data = kmem_cache_alloc(zfcp_data.gid_pn_cache, GFP_ATOMIC);
}
if (NULL == data)
@@ -1531,7 +1531,7 @@ static void zfcp_gid_pn_buffers_free(str
if (gid_pn->ct.pool)
mempool_free(gid_pn, gid_pn->ct.pool);
else
- kfree(gid_pn);
+ kmem_cache_free(zfcp_data.gid_pn_cache, gid_pn);
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] zfcp: Avoid race condition on "link up" event
From: Christoph Schmitt <[EMAIL PROTECTED]>
Symptom: zfcp receives a response to a "status read" request
that is no longer valid in zfcp. This leads to a
kernel panic, since some memory has been overwritten
by the response reporting.
Problem: On receiving an "unsolicited status", zfcp issues a
new "status read" request. On receiving the
"unsolicited status" "link up", zfcp triggers an adapter
reopen. The new "status read" request and the reopen
can lead to a race where zfcp issues the request before
the reopen, but the hardware handles the reopen first.
Solution:Not issue the "status read" request to avoid the race
condition. The adapter reopen will enqueue 16 new
"status read" requests anyway.
Signed-off-by: Christoph Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_fsf.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_fsf.c
linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c
--- linux-2.6/drivers/s390/scsi/zfcp_fsf.c 2007-08-08 10:13:39.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c 2007-08-08
10:14:03.0 +0200
@@ -33,7 +33,7 @@ static int zfcp_fsf_send_fcp_command_tas
static int zfcp_fsf_send_fcp_command_task_management_handler(
struct zfcp_fsf_req *);
static int zfcp_fsf_abort_fcp_command_handler(struct zfcp_fsf_req *);
-static int zfcp_fsf_status_read_handler(struct zfcp_fsf_req *);
+static void zfcp_fsf_status_read_handler(struct zfcp_fsf_req *);
static int zfcp_fsf_send_ct_handler(struct zfcp_fsf_req *);
static int zfcp_fsf_send_els_handler(struct zfcp_fsf_req *);
static int zfcp_fsf_control_file_handler(struct zfcp_fsf_req *);
@@ -856,10 +856,10 @@ zfcp_fsf_status_read_port_closed(struct
*
* returns:
*/
-static int
+static void
zfcp_fsf_status_read_handler(struct zfcp_fsf_req *fsf_req)
{
- int retval = 0;
+ int retval;
struct zfcp_adapter *adapter = fsf_req->adapter;
struct fsf_status_read_buffer *status_buffer =
(struct fsf_status_read_buffer *) fsf_req->data;
@@ -869,7 +869,7 @@ zfcp_fsf_status_read_handler(struct zfcp
zfcp_hba_dbf_event_fsf_unsol("dism", adapter, status_buffer);
mempool_free(status_buffer, adapter->pool.data_status_read);
zfcp_fsf_req_free(fsf_req);
- goto out;
+ return;
}
zfcp_hba_dbf_event_fsf_unsol("read", adapter, status_buffer);
@@ -1061,6 +1061,15 @@ zfcp_fsf_status_read_handler(struct zfcp
* FIXME:
* allocation failure possible? (Is this code needed?)
*/
+ /*
+* If we triggered an adapter reopen, then the reopen will also
+* enqueue new status read requests. Not issuing a status read
+* here avoids a race between the request send and the adapter
+* reopen.
+*/
+ if (status_buffer->status_type == FSF_STATUS_READ_LINK_UP)
+ return;
+
retval = zfcp_fsf_status_read(adapter, 0);
if (retval < 0) {
ZFCP_LOG_INFO("Failed to create unsolicited status read "
@@ -1076,8 +1085,6 @@ zfcp_fsf_status_read_handler(struct zfcp
zfcp_erp_adapter_reopen(adapter, 0);
}
}
- out:
- return retval;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] zfcp: fix the data buffer accessor patch
From: Heiko Carstens <[EMAIL PROTECTED]>
Fix the data buffer accessor patch.
For request without a data buffer nothing was written into
a SBALE.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_qdio.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
Index: linux_jb/drivers/s390/scsi/zfcp_qdio.c
===
--- linux_jb.orig/drivers/s390/scsi/zfcp_qdio.c
+++ linux_jb/drivers/s390/scsi/zfcp_qdio.c
@@ -640,13 +640,9 @@ int
zfcp_qdio_sbals_from_scsicmnd(struct zfcp_fsf_req *fsf_req,
unsigned long sbtype, struct scsi_cmnd *scsi_cmnd)
{
- if (scsi_sg_count(scsi_cmnd))
- return zfcp_qdio_sbals_from_sg(fsf_req, sbtype,
- scsi_sglist(scsi_cmnd),
- scsi_sg_count(scsi_cmnd),
- ZFCP_MAX_SBALS_PER_REQ);
- else
- return 0;
+ return zfcp_qdio_sbals_from_sg(fsf_req, sbtype, scsi_sglist(scsi_cmnd),
+ scsi_sg_count(scsi_cmnd),
+ ZFCP_MAX_SBALS_PER_REQ);
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] zfcp: Avoid race condition on "link up" event
On Wednesday 08 August 2007 10:47, Swen Schillig wrote:
> From: Christoph Schmitt <[EMAIL PROTECTED]>
>
> Symptom: zfcp receives a response to a "status read" request
>that is no longer valid in zfcp. This leads to a
>kernel panic, since some memory has been overwritten
>by the response reporting.
> Problem: On receiving an "unsolicited status", zfcp issues a
>new "status read" request. On receiving the
>"unsolicited status" "link up", zfcp triggers an adapter
>reopen. The new "status read" request and the reopen
>can lead to a race where zfcp issues the request before
>the reopen, but the hardware handles the reopen first.
> Solution:Not issue the "status read" request to avoid the race
>condition. The adapter reopen will enqueue 16 new
>"status read" requests anyway.
>
> Signed-off-by: Christoph Schmitt <[EMAIL PROTECTED]>
> Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
> ---
>
> drivers/s390/scsi/zfcp_fsf.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff -urpN linux-2.6/drivers/s390/scsi/zfcp_fsf.c
> linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c
> --- linux-2.6/drivers/s390/scsi/zfcp_fsf.c2007-08-08 10:13:39.0
> +0200
> +++ linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c2007-08-08
> 10:14:03.0 +0200
> @@ -33,7 +33,7 @@ static int zfcp_fsf_send_fcp_command_tas
> static int zfcp_fsf_send_fcp_command_task_management_handler(
> struct zfcp_fsf_req *);
> static int zfcp_fsf_abort_fcp_command_handler(struct zfcp_fsf_req *);
> -static int zfcp_fsf_status_read_handler(struct zfcp_fsf_req *);
> +static void zfcp_fsf_status_read_handler(struct zfcp_fsf_req *);
> static int zfcp_fsf_send_ct_handler(struct zfcp_fsf_req *);
> static int zfcp_fsf_send_els_handler(struct zfcp_fsf_req *);
> static int zfcp_fsf_control_file_handler(struct zfcp_fsf_req *);
> @@ -856,10 +856,10 @@ zfcp_fsf_status_read_port_closed(struct
> *
> * returns:
> */
> -static int
> +static void
> zfcp_fsf_status_read_handler(struct zfcp_fsf_req *fsf_req)
> {
> - int retval = 0;
> + int retval;
> struct zfcp_adapter *adapter = fsf_req->adapter;
> struct fsf_status_read_buffer *status_buffer =
> (struct fsf_status_read_buffer *) fsf_req->data;
> @@ -869,7 +869,7 @@ zfcp_fsf_status_read_handler(struct zfcp
> zfcp_hba_dbf_event_fsf_unsol("dism", adapter, status_buffer);
> mempool_free(status_buffer, adapter->pool.data_status_read);
> zfcp_fsf_req_free(fsf_req);
> - goto out;
> + return;
> }
>
> zfcp_hba_dbf_event_fsf_unsol("read", adapter, status_buffer);
> @@ -1061,6 +1061,15 @@ zfcp_fsf_status_read_handler(struct zfcp
>* FIXME:
>* allocation failure possible? (Is this code needed?)
>*/
> + /*
> + * If we triggered an adapter reopen, then the reopen will also
> + * enqueue new status read requests. Not issuing a status read
> + * here avoids a race between the request send and the adapter
> + * reopen.
> + */
> + if (status_buffer->status_type == FSF_STATUS_READ_LINK_UP)
> + return;
> +
> retval = zfcp_fsf_status_read(adapter, 0);
> if (retval < 0) {
> ZFCP_LOG_INFO("Failed to create unsolicited status read "
> @@ -1076,8 +1085,6 @@ zfcp_fsf_status_read_handler(struct zfcp
> zfcp_erp_adapter_reopen(adapter, 0);
> }
> }
> - out:
> - return retval;
> }
>
> /*
>
James
please dump this patch.
The description is a bit misleading and the issue is solved within our
microcode.
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/10] zfcp: fix memory leak.
Subject: [PATCH] zfcp: fix memory leak.
From: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Singed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_scsi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_scsi.c
linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c
--- linux-2.6/drivers/s390/scsi/zfcp_scsi.c 2007-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c 2007-08-27
13:22:18.0 +0200
@@ -764,7 +764,9 @@ zfcp_reset_fc_host_stats(struct Scsi_Hos
return;
ret = zfcp_fsf_exchange_port_data(NULL, adapter, data);
- if (ret == 0) {
+ if (ret) {
+ kfree(data);
+ } else {
adapter->stats_reset = jiffies/HZ;
old_data = adapter->stats_reset_data;
adapter->stats_reset_data = data; /* finally freed in
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/10] zfcp: allocate gid_pn_data objects from gid_pn_cache.
From: Heiko Carstens <[EMAIL PROTECTED]>
Allocate gid_pn_data objects from the corresponding cache which ensures
proper alignment.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_aux.c
linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-08-27 13:21:50.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c 2007-08-27
13:22:18.0 +0200
@@ -1503,7 +1503,7 @@ zfcp_gid_pn_buffers_alloc(struct zfcp_gi
data->ct.pool = pool;
}
} else {
- data = kmalloc(sizeof(struct zfcp_gid_pn_data), GFP_ATOMIC);
+ data = kmem_cache_alloc(zfcp_data.gid_pn_cache, GFP_ATOMIC);
}
if (NULL == data)
@@ -1531,7 +1531,7 @@ static void zfcp_gid_pn_buffers_free(str
if (gid_pn->ct.pool)
mempool_free(gid_pn, gid_pn->ct.pool);
else
- kfree(gid_pn);
+ kmem_cache_free(zfcp_data.gid_pn_cache, gid_pn);
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/10] zfcp: avoid if (whatever) ; constructs.
From: Heiko Carstens <[EMAIL PROTECTED]> Avoid "if (whatever) ;" constructs since they seem to confuse people, even if there is a comment. Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> --- drivers/s390/scsi/zfcp_erp.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -urpN linux-2.6/drivers/s390/scsi/zfcp_erp.c linux-2.6-patched/drivers/s390/scsi/zfcp_erp.c --- linux-2.6/drivers/s390/scsi/zfcp_erp.c 2007-08-27 13:22:01.0 +0200 +++ linux-2.6-patched/drivers/s390/scsi/zfcp_erp.c 2007-08-27 13:22:20.0 +0200 @@ -1687,8 +1687,8 @@ zfcp_erp_strategy_followup_actions(int a break; case ZFCP_ERP_ACTION_REOPEN_UNIT: - if (status == ZFCP_ERP_SUCCEEDED) ; /* no further action */ - else + /* Nothing to do if status == ZFCP_ERP_SUCCEEDED */ + if (status != ZFCP_ERP_SUCCEEDED) zfcp_erp_port_reopen_internal(unit->port, 0); break; } - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 5/10] zfcp: Remove unnecessary assignment
From: Christof Schmitt <[EMAIL PROTECTED]> zfcp_adapter_enqueue initialized adapter->ccw_device twice with the same value. Remove the second assignment, since it is not necessary. Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> --- drivers/s390/scsi/zfcp_aux.c |1 - 1 file changed, 1 deletion(-) diff -urpN linux-2.6/drivers/s390/scsi/zfcp_aux.c linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c --- linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-08-27 13:22:19.0 +0200 +++ linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c 2007-08-27 13:22:20.0 +0200 @@ -1058,7 +1058,6 @@ zfcp_adapter_enqueue(struct ccw_device * /* mark adapter unusable as long as sysfs registration is not complete */ atomic_set_mask(ZFCP_STATUS_COMMON_REMOVE, &adapter->status); - adapter->ccw_device = ccw_device; dev_set_drvdata(&ccw_device->dev, adapter); if (zfcp_sysfs_adapter_create_files(&ccw_device->dev)) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/10] zfcp: correct indentation for nested if-else
From: Christof Schmitt <[EMAIL PROTECTED]>
correct indentation for nested if-else
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_fsf.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_fsf.c
linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c
--- linux-2.6/drivers/s390/scsi/zfcp_fsf.c 2007-08-27 13:21:50.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_fsf.c 2007-08-27
13:22:19.0 +0200
@@ -3586,17 +3586,17 @@ zfcp_fsf_send_fcp_command_task(struct zf
ZFCP_LOG_DEBUG(
"Data did not fit into available buffer(s), "
"waiting for more...\n");
- retval = -EIO;
- } else {
- ZFCP_LOG_NORMAL("error: No truncation implemented but "
- "required. Shutting down unit "
- "(adapter %s, port 0x%016Lx, "
- "unit 0x%016Lx)\n",
- zfcp_get_busid_by_unit(unit),
- unit->port->wwpn,
- unit->fcp_lun);
- zfcp_erp_unit_shutdown(unit, 0);
- retval = -EINVAL;
+ retval = -EIO;
+ } else {
+ ZFCP_LOG_NORMAL("error: No truncation implemented but "
+ "required. Shutting down unit "
+ "(adapter %s, port 0x%016Lx, "
+ "unit 0x%016Lx)\n",
+ zfcp_get_busid_by_unit(unit),
+ unit->port->wwpn,
+ unit->fcp_lun);
+ zfcp_erp_unit_shutdown(unit, 0);
+ retval = -EINVAL;
}
goto no_fit;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/10] Introduce disable_target_scan flag in FC transport class
From: Christof Schmitt <[EMAIL PROTECTED]>
This change has already been discussed on linux-scsi:
http://marc.info/?t=11877109643
http://marc.info/?t=11876091315
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_transport_fc.c |4 +++-
include/scsi/scsi_transport_fc.h |2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff -urpN linux-2.6/drivers/scsi/scsi_transport_fc.c
linux-2.6-patched/drivers/scsi/scsi_transport_fc.c
--- linux-2.6/drivers/scsi/scsi_transport_fc.c 2007-08-27 13:21:50.0
+0200
+++ linux-2.6-patched/drivers/scsi/scsi_transport_fc.c 2007-08-27
13:22:22.0 +0200
@@ -2988,10 +2988,12 @@ fc_scsi_scan_rport(struct work_struct *w
struct fc_rport *rport =
container_of(work, struct fc_rport, scan_work);
struct Scsi_Host *shost = rport_to_shost(rport);
+ struct fc_internal *i = to_fc_internal(shost->transportt);
unsigned long flags;
if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
- (rport->roles & FC_PORT_ROLE_FCP_TARGET)) {
+ (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
+ !(i->f->disable_target_scan)) {
scsi_scan_target(&rport->dev, rport->channel,
rport->scsi_target_id, SCAN_WILD_CARD, 1);
}
diff -urpN linux-2.6/include/scsi/scsi_transport_fc.h
linux-2.6-patched/include/scsi/scsi_transport_fc.h
--- linux-2.6/include/scsi/scsi_transport_fc.h 2007-08-27 13:21:52.0
+0200
+++ linux-2.6-patched/include/scsi/scsi_transport_fc.h 2007-08-27
13:22:22.0 +0200
@@ -632,6 +632,8 @@ struct fc_function_template {
unsigned long show_host_fabric_name:1;
unsigned long show_host_symbolic_name:1;
unsigned long show_host_system_hostname:1;
+
+ unsigned long disable_target_scan:1;
};
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/10] zfcp: Remove braces for only one statement
From: Christof Schmitt <[EMAIL PROTECTED]>
Remove braces for only one statement
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_scsi.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_scsi.c
linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c
--- linux-2.6/drivers/s390/scsi/zfcp_scsi.c 2007-08-27 13:22:18.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c 2007-08-27
13:22:21.0 +0200
@@ -189,10 +189,9 @@ static void zfcp_scsi_slave_destroy(stru
unit->device = NULL;
zfcp_erp_unit_failed(unit);
zfcp_unit_put(unit);
- } else {
+ } else
ZFCP_LOG_NORMAL("bug: no unit associated with SCSI device at "
"address %p\n", sdpnt);
- }
}
/*
@@ -361,12 +360,11 @@ zfcp_unit_lookup(struct zfcp_adapter *ad
list_for_each_entry(port, &adapter->port_list_head, list) {
if (!port->rport || (id != port->rport->scsi_target_id))
continue;
- list_for_each_entry(unit, &port->unit_list_head, list) {
+ list_for_each_entry(unit, &port->unit_list_head, list)
if (lun == unit->scsi_lun) {
retval = unit;
goto out;
}
- }
}
out:
return retval;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/10] zfcp: cleanup, separation of ERP, non ERP-version for exchange_ functions
From: Swen Schillig <[EMAIL PROTECTED]>
cleanup, using ERP request mempool for all ERP versions of
the exchange functions (exchange_config (ECD), exchange_port (EPD) )
providing individual versions of the ECD, EPD functions for ERP
and other purposes (_sync).
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_erp.c |2
drivers/s390/scsi/zfcp_ext.h |8 -
drivers/s390/scsi/zfcp_fsf.c | 231 ++
drivers/s390/scsi/zfcp_scsi.c |5
4 files changed, 175 insertions(+), 71 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_ext.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_ext.h
+++ HEAD/drivers/s390/scsi/zfcp_ext.h
@@ -82,9 +82,11 @@ extern int zfcp_fsf_open_unit(struct zf
extern int zfcp_fsf_close_unit(struct zfcp_erp_action *);
extern int zfcp_fsf_exchange_config_data(struct zfcp_erp_action *);
-extern int zfcp_fsf_exchange_port_data(struct zfcp_erp_action *,
- struct zfcp_adapter *,
- struct fsf_qtcb_bottom_port *);
+extern int zfcp_fsf_exchange_config_data_sync(struct zfcp_adapter *,
+ struct fsf_qtcb_bottom_config *);
+extern int zfcp_fsf_exchange_port_data(struct zfcp_erp_action *);
+extern int zfcp_fsf_exchange_port_data_sync(struct zfcp_adapter *,
+ struct fsf_qtcb_bottom_port *);
extern int zfcp_fsf_control_file(struct zfcp_adapter *, struct zfcp_fsf_req
**,
u32, u32, struct zfcp_sg_list *);
extern void zfcp_fsf_start_timer(struct zfcp_fsf_req *, unsigned long);
Index: HEAD/drivers/s390/scsi/zfcp_fsf.c
===
--- HEAD.orig/drivers/s390/scsi/zfcp_fsf.c
+++ HEAD/drivers/s390/scsi/zfcp_fsf.c
@@ -1941,25 +1941,28 @@ zfcp_fsf_exchange_config_data(struct zfc
{
volatile struct qdio_buffer_element *sbale;
struct zfcp_fsf_req *fsf_req;
+ struct zfcp_adapter *adapter = erp_action->adapter;
unsigned long lock_flags;
- int retval = 0;
+ int retval;
/* setup new FSF request */
- retval = zfcp_fsf_req_create(erp_action->adapter,
+ retval = zfcp_fsf_req_create(adapter,
FSF_QTCB_EXCHANGE_CONFIG_DATA,
ZFCP_REQ_AUTO_CLEANUP,
-erp_action->adapter->pool.fsf_req_erp,
+adapter->pool.fsf_req_erp,
&lock_flags, &fsf_req);
- if (retval < 0) {
+ if (retval) {
ZFCP_LOG_INFO("error: Could not create exchange configuration "
"data request for adapter %s.\n",
- zfcp_get_busid_by_adapter(erp_action->adapter));
- goto out;
+ zfcp_get_busid_by_adapter(adapter));
+ write_unlock_irqrestore(&adapter->request_queue.queue_lock,
+ lock_flags);
+ return retval;
}
sbale = zfcp_qdio_sbale_req(fsf_req, fsf_req->sbal_curr, 0);
-sbale[0].flags |= SBAL_FLAGS0_TYPE_READ;
-sbale[1].flags |= SBAL_FLAGS_LAST_ENTRY;
+ sbale[0].flags |= SBAL_FLAGS0_TYPE_READ;
+ sbale[1].flags |= SBAL_FLAGS_LAST_ENTRY;
fsf_req->qtcb->bottom.config.feature_selection =
FSF_FEATURE_CFDC |
@@ -1971,23 +1974,71 @@ zfcp_fsf_exchange_config_data(struct zfc
zfcp_erp_start_timer(fsf_req);
retval = zfcp_fsf_req_send(fsf_req);
+ write_unlock_irqrestore(&adapter->request_queue.queue_lock,
+ lock_flags);
if (retval) {
- ZFCP_LOG_INFO
- ("error: Could not send exchange configuration data "
-"command on the adapter %s\n",
-zfcp_get_busid_by_adapter(erp_action->adapter));
+ ZFCP_LOG_INFO("error: Could not send exchange configuration "
+ "data command on the adapter %s\n",
+ zfcp_get_busid_by_adapter(adapter));
zfcp_fsf_req_free(fsf_req);
erp_action->fsf_req = NULL;
- goto out;
}
+ else
+ ZFCP_LOG_DEBUG("exchange configuration data request initiated "
+ "(adapter %s)\n",
+ zfcp_get_busid_by_adapter(adapter));
- ZFCP_LOG_DEBUG("exchange configuration data request initiated "
- "(adapter %s)\n",
-
[PATCH 10/10] zfcp: Enable debug feature before setting adapter online
From: Christof Schmitt <[EMAIL PROTECTED]>
Already register the debug feature before the zfcp adapter is
set online. This allows to use the debug feature to investigate
the online/offline sequence.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |8
drivers/s390/scsi/zfcp_ccw.c |8 +---
2 files changed, 9 insertions(+), 7 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_aux.c
linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-08-27 13:22:21.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_aux.c 2007-08-27
13:22:24.0 +0200
@@ -1038,6 +1038,10 @@ zfcp_adapter_enqueue(struct ccw_device *
spin_lock_init(&adapter->san_dbf_lock);
spin_lock_init(&adapter->scsi_dbf_lock);
+ retval = zfcp_adapter_debug_register(adapter);
+ if (retval)
+ goto debug_register_failed;
+
/* initialize error recovery stuff */
rwlock_init(&adapter->erp_lock);
@@ -1084,6 +1088,8 @@ zfcp_adapter_enqueue(struct ccw_device *
generic_services_failed:
zfcp_sysfs_adapter_remove_files(&adapter->ccw_device->dev);
sysfs_failed:
+ zfcp_adapter_debug_unregister(adapter);
+ debug_register_failed:
dev_set_drvdata(&ccw_device->dev, NULL);
zfcp_reqlist_free(adapter);
failed_low_mem_buffers:
@@ -1129,6 +1135,8 @@ zfcp_adapter_dequeue(struct zfcp_adapter
goto out;
}
+ zfcp_adapter_debug_unregister(adapter);
+
/* remove specified adapter data structure from list */
write_lock_irq(&zfcp_data.config_lock);
list_del(&adapter->list);
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_ccw.c
linux-2.6-patched/drivers/s390/scsi/zfcp_ccw.c
--- linux-2.6/drivers/s390/scsi/zfcp_ccw.c 2007-07-09 01:32:17.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_ccw.c 2007-08-27
13:22:24.0 +0200
@@ -150,15 +150,12 @@ zfcp_ccw_set_online(struct ccw_device *c
down(&zfcp_data.config_sema);
adapter = dev_get_drvdata(&ccw_device->dev);
- retval = zfcp_adapter_debug_register(adapter);
- if (retval)
- goto out;
retval = zfcp_erp_thread_setup(adapter);
if (retval) {
ZFCP_LOG_INFO("error: start of error recovery thread for "
"adapter %s failed\n",
zfcp_get_busid_by_adapter(adapter));
- goto out_erp_thread;
+ goto out;
}
retval = zfcp_adapter_scsi_register(adapter);
@@ -177,8 +174,6 @@ zfcp_ccw_set_online(struct ccw_device *c
out_scsi_register:
zfcp_erp_thread_kill(adapter);
- out_erp_thread:
- zfcp_adapter_debug_unregister(adapter);
out:
up(&zfcp_data.config_sema);
return retval;
@@ -201,7 +196,6 @@ zfcp_ccw_set_offline(struct ccw_device *
zfcp_erp_adapter_shutdown(adapter, 0);
zfcp_erp_wait(adapter);
zfcp_erp_thread_kill(adapter);
- zfcp_adapter_debug_unregister(adapter);
up(&zfcp_data.config_sema);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/10] zfcp: Disable LUN scanning from the FC transport class
From: Christof Schmitt <[EMAIL PROTECTED]> zfcp manages the valid SCSI units currently on its own. So we don't want the FC transport class to issue scans for units. Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> --- drivers/s390/scsi/zfcp_scsi.c |1 + 1 file changed, 1 insertion(+) diff -urpN linux-2.6/drivers/s390/scsi/zfcp_scsi.c linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c --- linux-2.6/drivers/s390/scsi/zfcp_scsi.c 2007-08-27 13:22:22.0 +0200 +++ linux-2.6-patched/drivers/s390/scsi/zfcp_scsi.c 2007-08-27 13:22:23.0 +0200 @@ -800,6 +800,7 @@ struct fc_function_template zfcp_transpo .show_host_port_type = 1, .show_host_speed = 1, .show_host_port_id = 1, + .disable_target_scan = 1, }; /** - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] zfcp: add statistics and other zfcp related information to sysfs
The zfcp adapter provides a variety of information which was never
published to the external world. This patch adds a few of those "statistics"
to the sysfs tree structure.
These are reflected in the following attributes
/sys/bus/ccw/drivers/zfcp/0.0.1707
/* information for the virtual adapter */
statistic_services/
requests
megabytes
utilization
seconds_active
/* LUN specific info for channel- and fabric-latency */
0x500507630300c562/0x401040a6/
read_latency
write_latency
cmd_latency
Please comment if this would be an acceptable way to publish
the additional information.
Cheers Swen.
---
drivers/s390/scsi/Makefile|2
drivers/s390/scsi/zfcp_aux.c | 30
drivers/s390/scsi/zfcp_def.h | 58 +
drivers/s390/scsi/zfcp_ext.h | 32 ++---
drivers/s390/scsi/zfcp_fsf.c |1
drivers/s390/scsi/zfcp_fsf.h | 29
drivers/s390/scsi/zfcp_qdio.c | 34 +
drivers/s390/scsi/zfcp_sysfs_statistics.c | 191 ++
drivers/s390/scsi/zfcp_sysfs_unit.c | 63 +
9 files changed, 394 insertions(+), 46 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -1,23 +1,23 @@
-/*
+/*
* This file is part of the zfcp device driver for
* FCP adapters for IBM System z9 and zSeries.
*
* (C) Copyright IBM Corp. 2002, 2006
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
#ifndef ZFCP_DEF_H
#define ZFCP_DEF_H
@@ -90,7 +90,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_DEVICE_TYPE0x1732
#define ZFCP_DEVICE_MODEL 0x03
#define ZFCP_DEVICE_MODEL_PRIV 0x04
-
+
/* allow as many chained SBALs as are supported by hardware */
#define ZFCP_MAX_SBALS_PER_REQ FSF_MAX_SBALS_PER_REQ
#define ZFCP_MAX_SBALS_PER_CT_REQ FSF_MAX_SBALS_PER_REQ
@@ -508,7 +508,7 @@ struct zfcp_rc_entry {
/*
* this allows removal of logging code by the preprocessor
- * (the most detailed log level still to be compiled in is specified,
+ * (the most detailed log level still to be compiled in is specified,
* higher log levels are removed)
*/
#define ZFCP_LOG_LEVEL_LIMIT ZFCP_LOG_LEVEL_TRACE
@@ -546,7 +546,7 @@ do { \
if (ZFCP_LOG_CHECK(level)) \
_ZFCP_LOG(fmt, ##args); \
} while (0)
-
+
#if ZFCP_LOG_LEVEL_LIMIT < ZFCP_LOG_LEVEL_NORMAL
# define ZFCP_LOG_NORMAL(fmt, args...) do { } while (0)
#else
@@ -583,8 +583,8 @@ do { \
/*** ADAPTER/PORT/UNIT AND FSF_REQ STATUS FLAGS **/
-/*
- * Note, the leftmost status byte is common among adapter, port
+/*
+ * Note, the leftmost status byte is common among adapter, port
* and unit
*/
#define ZFCP_COMMON_FLAGS 0xfff0
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel features *
Re: [RFC] zfcp: add statistics and other zfcp related information to sysfs
On Monday 03 September 2007 14:40, Matthew Wilcox wrote: > On Mon, Sep 03, 2007 at 02:16:21PM +0200, Swen Schillig wrote: > > /sys/bus/ccw/drivers/zfcp/0.0.1707 > > /* information for the virtual adapter */ > > statistic_services/ > > requests > > megabytes > > utilization > > seconds_active > > /* LUN specific info for channel- and fabric-latency */ > > 0x500507630300c562/0x401040a6/ > > read_latency > > write_latency > > cmd_latency > > > > Please comment if this would be an acceptable way to publish > > the additional information. > > This seems like it might be information that other adapters could, > in theory, also provide. Maybe the first set of stats should > be added to /sys/class/scsi_host/hostN/ and the second set to > /sys/class/scsi_device/H:C:T:L/ ? The names of the individual files > make sense to me. > Matthew, thanks for your feedback. In the past we were trying a centralized and common approach a couple of times, with no success. Since we really need to have our data available soon, I'd prefer to start off with the "proprietary" location and make this data available to our customers. Anybody else some comments ? Otherwise I'll post the patch. Cheers Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: add statistics and other zfcp relatedinformation to sysfs
From: Swen Schillig <[EMAIL PROTECTED]>
add statistics and other zfcp related information to sysfs
The zfcp adapter provides a variety of information which was never
published to the external world. This patch adds a few of those "statistics"
to the sysfs tree structure.
These are reflected in the following attributes
/sys/bus/ccw/drivers/zfcp/0.0.1707
/* information for the virtual adapter */
statistic_services/
requests
megabytes
utilization
seconds_active
/* LUN specific info for channel- and fabric-latency */
0x500507630300c562/0x401040a6/
read_latency
write_latency
cmd_latency
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/Makefile|2
drivers/s390/scsi/zfcp_aux.c | 30
drivers/s390/scsi/zfcp_def.h | 58 +
drivers/s390/scsi/zfcp_ext.h | 32 ++---
drivers/s390/scsi/zfcp_fsf.c |1
drivers/s390/scsi/zfcp_fsf.h | 29
drivers/s390/scsi/zfcp_qdio.c | 34 +
drivers/s390/scsi/zfcp_sysfs_statistics.c | 191 ++
drivers/s390/scsi/zfcp_sysfs_unit.c | 63 +
9 files changed, 394 insertions(+), 46 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -1,23 +1,23 @@
-/*
+/*
* This file is part of the zfcp device driver for
* FCP adapters for IBM System z9 and zSeries.
*
* (C) Copyright IBM Corp. 2002, 2006
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
#ifndef ZFCP_DEF_H
#define ZFCP_DEF_H
@@ -90,7 +90,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_DEVICE_TYPE0x1732
#define ZFCP_DEVICE_MODEL 0x03
#define ZFCP_DEVICE_MODEL_PRIV 0x04
-
+
/* allow as many chained SBALs as are supported by hardware */
#define ZFCP_MAX_SBALS_PER_REQ FSF_MAX_SBALS_PER_REQ
#define ZFCP_MAX_SBALS_PER_CT_REQ FSF_MAX_SBALS_PER_REQ
@@ -508,7 +508,7 @@ struct zfcp_rc_entry {
/*
* this allows removal of logging code by the preprocessor
- * (the most detailed log level still to be compiled in is specified,
+ * (the most detailed log level still to be compiled in is specified,
* higher log levels are removed)
*/
#define ZFCP_LOG_LEVEL_LIMIT ZFCP_LOG_LEVEL_TRACE
@@ -546,7 +546,7 @@ do { \
if (ZFCP_LOG_CHECK(level)) \
_ZFCP_LOG(fmt, ##args); \
} while (0)
-
+
#if ZFCP_LOG_LEVEL_LIMIT < ZFCP_LOG_LEVEL_NORMAL
# define ZFCP_LOG_NORMAL(fmt, args...) do { } while (0)
#else
@@ -583,8 +583,8 @@ do { \
/*** ADAPTER/PORT/UNIT AND FSF_REQ STATUS FLAGS **/
-/*
- * Note, the leftmost status byte is common among adapter, port
+/*
+ * Note, the leftmost status byte is common among adapter, port
* and unit
*/
#define ZFCP_COMMON_FLAGS 0xfff0
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32
[PATCH 2/2] zfcp: zfcp: add statistics and other zfcp relatedinformation to sysfs
From: Swen Schillig <[EMAIL PROTECTED]>
add statistics and other zfcp related information to sysfs
The zfcp adapter provides a variety of information which was never
published to the external world. This patch adds a few of those "statistics"
to the sysfs tree structure.
These are reflected in the following attributes
/sys/bus/ccw/drivers/zfcp/0.0.1707
/* information for the virtual adapter */
statistic_services/
requests
megabytes
utilization
seconds_active
/* LUN specific info for channel- and fabric-latency */
0x500507630300c562/0x401040a6/
read_latency
write_latency
cmd_latency
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/Makefile|2
drivers/s390/scsi/zfcp_aux.c | 30 -
drivers/s390/scsi/zfcp_def.h | 14 ++
drivers/s390/scsi/zfcp_ext.h |2
drivers/s390/scsi/zfcp_fsf.c |1
drivers/s390/scsi/zfcp_fsf.h | 28 -
drivers/s390/scsi/zfcp_qdio.c | 39 +++
drivers/s390/scsi/zfcp_sysfs_statistics.c | 162 ++
drivers/s390/scsi/zfcp_sysfs_unit.c | 63 +++
9 files changed, 333 insertions(+), 8 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel features */
u32 connection_features; /* host connection
features */
u32hardware_version; /* of FCP channel */
+ u16 timer_ticks; /* time int for a tick */
struct Scsi_Host*scsi_host;/* Pointer to mid-layer */
struct list_headport_list_head;/* remote port list */
struct list_headport_remove_lh;/* head of ports to be
@@ -930,6 +942,7 @@ struct zfcp_adapter {
struct zfcp_scsi_dbf_record scsi_dbf_buf;
struct zfcp_adapter_mempool pool; /* Adapter memory pools */
struct qdio_initialize qdio_init_data;/* for qdio_establish */
+ struct device stat_services;
struct device generic_services; /* directory for WKA ports */
struct fc_host_statistics *fc_stats;
struct fsf_qtcb_bottom_port *stats_reset_data;
@@ -986,6 +999,7 @@ struct zfcp_unit {
all scsi_scan_target
requests have been
completed. */
+ struct zfcp_latencies latencies;
};
/* FSF request */
Index: HEAD/drivers/s390/scsi/zfcp_fsf.c
===
--- HEAD.orig/drivers/s390/scsi/zfcp_fsf.c
+++ HEAD/drivers/s390/scsi/zfcp_fsf.c
@@ -2079,6 +2079,7 @@ zfcp_fsf_exchange_config_evaluate(struct
fc_host_supported_classes(shost) =
FC_COS_CLASS2 | FC_COS_CLASS3;
adapter->hydra_version = bottom->adapter_type;
+ adapter->timer_ticks = bottom->timer_interval;
if (fc_host_permanent_port_name(shost) == -1)
fc_host_permanent_port_name(shost) =
fc_host_port_name(shost);
Index: HEAD/drivers/s390/scsi/zfcp_fsf.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_fsf.h
+++ HEAD/drivers/s390/scsi/zfcp_fsf.h
@@ -322,11 +322,18 @@ struct fsf_link_down_info {
u8 vendor_specific_code;
} __attribute__ ((packed));
+struct fsf_qual_latency_info {
+ u32 channel_lat;
+ u32 fabric_lat;
+ u8 res1[8];
+} __attribute__ ((packed));
+
union fsf_prot_status_qual {
u64 doubleword[FSF_PROT_STATUS_QUAL_SIZE / sizeof(u64)];
struct fsf_qual_version_error version_error;
struct fsf_qual_sequence_error sequence_error;
struct fsf_link_down_info link_down_info;
+ struct fsf_qual_latency_info latency_info;
} __attribute__ ((packed));
struct fsf_qtcb_prefix {
@@ -340,6 +347,15 @@ struct fsf_qtcb_prefix {
u8 res1[20];
} __attribute__ ((packed));
+struct fsf_statistics_info {
+ u64 input_req;
+
[PATCH 1/2] zfcp: whitespace cleanup
From: Swen Schillig <[EMAIL PROTECTED]>
Cleanup the whitepace from the entire zfcp driver to prevent
to have those changes in future feature or function patches.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c|4 -
drivers/s390/scsi/zfcp_def.h| 46 ++--
drivers/s390/scsi/zfcp_erp.c| 134 ++--
drivers/s390/scsi/zfcp_ext.h| 30
drivers/s390/scsi/zfcp_fsf.c| 40 +-
drivers/s390/scsi/zfcp_fsf.h| 30
drivers/s390/scsi/zfcp_qdio.c |7 -
drivers/s390/scsi/zfcp_scsi.c | 36 -
drivers/s390/scsi/zfcp_sysfs_unit.c |4 -
9 files changed, 165 insertions(+), 166 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_aux.c
===
--- HEAD.orig/drivers/s390/scsi/zfcp_aux.c
+++ HEAD/drivers/s390/scsi/zfcp_aux.c
@@ -891,7 +891,7 @@ zfcp_unit_dequeue(struct zfcp_unit *unit
/*
* Allocates a combined QTCB/fsf_req buffer for erp actions and fcp/SCSI
* commands.
- * It also genrates fcp-nameserver request/response buffer and unsolicited
+ * It also genrates fcp-nameserver request/response buffer and unsolicited
* status read fsf_req buffers.
*
* locks: must only be called with zfcp_data.config_sema taken
@@ -982,7 +982,7 @@ zfcp_adapter_enqueue(struct ccw_device *
struct zfcp_adapter *adapter;
/*
-* Note: It is safe to release the list_lock, as any list changes
+* Note: It is safe to release the list_lock, as any list changes
* are protected by the config_sema, which must be held to get here
*/
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -1,23 +1,23 @@
-/*
+/*
* This file is part of the zfcp device driver for
* FCP adapters for IBM System z9 and zSeries.
*
* (C) Copyright IBM Corp. 2002, 2006
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
#ifndef ZFCP_DEF_H
#define ZFCP_DEF_H
@@ -90,7 +90,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_DEVICE_TYPE0x1732
#define ZFCP_DEVICE_MODEL 0x03
#define ZFCP_DEVICE_MODEL_PRIV 0x04
-
+
/* allow as many chained SBALs as are supported by hardware */
#define ZFCP_MAX_SBALS_PER_REQ FSF_MAX_SBALS_PER_REQ
#define ZFCP_MAX_SBALS_PER_CT_REQ FSF_MAX_SBALS_PER_REQ
@@ -508,7 +508,7 @@ struct zfcp_rc_entry {
/*
* this allows removal of logging code by the preprocessor
- * (the most detailed log level still to be compiled in is specified,
+ * (the most detailed log level still to be compiled in is specified,
* higher log levels are removed)
*/
#define ZFCP_LOG_LEVEL_LIMIT ZFCP_LOG_LEVEL_TRACE
@@ -546,7 +546,7 @@ do { \
if (ZFCP_LOG_CHECK(level)) \
_ZFCP_LOG(fmt, ##args); \
} while (0)
-
+
#if ZFCP_LOG_LEVEL_LIMIT < ZFCP_LOG_LEVEL_NORMAL
# define ZFCP_LOG_NORMAL(fmt, args...) do { } while (0)
#else
@@ -583,8 +583,8 @@ do { \
/*** ADAPTER/PORT/UNIT AND FSF_REQ STATUS FLAGS **/
-/*
- * Note, the leftmost status byte is common among adapter, port
+/*
+ * Note, the leftmost status byte is common among adapter, port
* and unit
*/
#define ZFCP_COMMON_FLAGS 0xfff0
@@ -1007,8 +1007,8 @@ struct zfcp_fsf_req {
u32fsf_command;/* FSF Command copy */
struct fsf_qtcb*qtcb;
[PATCH 0/2] zfcp: cleanup and add statistics
James please drop my first attempt for the zfcp add statistics patch and instead use the 2 which are following. Patch 1: whitespace cleanup. Patch 2: the modified zfcp add statistics patch This patchset was created due to the comments from Heiko Carstens pointing out a few things which could be improved. Sorry, for the inconvenience. Cheers Swen. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: Invalid locking order
From: Swen Schillig <[EMAIL PROTECTED]>
Invalid locking order. Kernel hangs after trying to take two locks
which are dependend on each other. Introducing temporary variable
to free requests. Free lock after requests are copied.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_ext.h |2 +-
drivers/s390/scsi/zfcp_fsf.c | 23 ++-
2 files changed, 11 insertions(+), 14 deletions(-)
Index: linux-2.6/drivers/s390/scsi/zfcp_ext.h
===
--- linux-2.6.orig/drivers/s390/scsi/zfcp_ext.h
+++ linux-2.6/drivers/s390/scsi/zfcp_ext.h
@@ -89,7 +89,7 @@ extern int zfcp_fsf_control_file(struct
u32, u32, struct zfcp_sg_list *);
extern void zfcp_fsf_start_timer(struct zfcp_fsf_req *, unsigned long);
extern void zfcp_erp_start_timer(struct zfcp_fsf_req *);
-extern int zfcp_fsf_req_dismiss_all(struct zfcp_adapter *);
+extern void zfcp_fsf_req_dismiss_all(struct zfcp_adapter *);
extern int zfcp_fsf_status_read(struct zfcp_adapter *, int);
extern int zfcp_fsf_req_create(struct zfcp_adapter *, u32, int, mempool_t *,
unsigned long *, struct zfcp_fsf_req **);
Index: linux-2.6/drivers/s390/scsi/zfcp_fsf.c
===
--- linux-2.6.orig/drivers/s390/scsi/zfcp_fsf.c
+++ linux-2.6/drivers/s390/scsi/zfcp_fsf.c
@@ -176,28 +176,25 @@ static void zfcp_fsf_req_dismiss(struct
/**
* zfcp_fsf_req_dismiss_all - dismiss all remaining fsf requests
*/
-int zfcp_fsf_req_dismiss_all(struct zfcp_adapter *adapter)
+void zfcp_fsf_req_dismiss_all(struct zfcp_adapter *adapter)
{
struct zfcp_fsf_req *request, *tmp;
unsigned long flags;
+ LIST_HEAD(remove_queue);
unsigned int i, counter;
spin_lock_irqsave(&adapter->req_list_lock, flags);
atomic_set(&adapter->reqs_active, 0);
- for (i=0; ireq_list[i]))
- continue;
-
- counter = 0;
- list_for_each_entry_safe(request, tmp,
-&adapter->req_list[i], list) {
- zfcp_fsf_req_dismiss(adapter, request, counter);
- counter++;
- }
- }
+ for (i=0; ireq_list[i], &remove_queue);
+
spin_unlock_irqrestore(&adapter->req_list_lock, flags);
- return 0;
+ counter = 0;
+ list_for_each_entry_safe(request, tmp, &remove_queue, list) {
+ zfcp_fsf_req_dismiss(adapter, request, counter);
+ counter++;
+ }
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: Invalid locking order
Hi Andreas No, not those. We got a possible recursive locking on the adapter->request_queue.queue_lock Cheers Swen On Wednesday 07 February 2007 17:06, Andreas Herrmann wrote: > On Wed, Feb 07, 2007 at 01:17:57PM +0100, Swen Schillig wrote: > > From: Swen Schillig <[EMAIL PROTECTED]> > > > > Invalid locking order. Kernel hangs after trying to take two locks > > which are dependend on each other. Introducing temporary variable > > to free requests. Free lock after requests are copied. > > > > I am just curious. You didn't mention which locks are causing the dead > lock. > > I've glanced through the code and it seems that locking order > of abort_lock and req_list_lock for adapters is inconsistent. > Is that the bug you try to fix? > > > Regards, > > Andreas > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: use of uninitialized variable
commit 988d955c3314336d716a9208f3d565b06f262e07
Author: Swen Schillig <[EMAIL PROTECTED]>
Date: Fri Feb 9 09:40:11 2007 +0100
Use of uninitialized variable.
ERP action might not be finished accordingly.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index c88babc..cbe47a2 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -841,29 +841,27 @@ zfcp_erp_action_exists(struct zfcp_erp_action *erp_action)
*
* returns:0
*/
-static int
+static void
zfcp_erp_strategy_check_fsfreq(struct zfcp_erp_action *erp_action)
{
- int retval = 0;
- struct zfcp_fsf_req *fsf_req = NULL;
struct zfcp_adapter *adapter = erp_action->adapter;
if (erp_action->fsf_req) {
/* take lock to ensure that request is not deleted meanwhile */
spin_lock(&adapter->req_list_lock);
- if ((!zfcp_reqlist_ismember(adapter,
- erp_action->fsf_req->req_id)) &&
- (fsf_req->erp_action == erp_action)) {
+ if (zfcp_reqlist_ismember(adapter,
+ erp_action->fsf_req->req_id)) {
/* fsf_req still exists */
debug_text_event(adapter->erp_dbf, 3, "a_ca_req");
- debug_event(adapter->erp_dbf, 3, &fsf_req,
+ debug_event(adapter->erp_dbf, 3, &erp_action->fsf_req,
sizeof (unsigned long));
/* dismiss fsf_req of timed out/dismissed erp_action */
if (erp_action->status & (ZFCP_STATUS_ERP_DISMISSED |
ZFCP_STATUS_ERP_TIMEDOUT)) {
debug_text_event(adapter->erp_dbf, 3,
"a_ca_disreq");
- fsf_req->status |= ZFCP_STATUS_FSFREQ_DISMISSED;
+ erp_action->fsf_req->status |=
+ ZFCP_STATUS_FSFREQ_DISMISSED;
}
if (erp_action->status & ZFCP_STATUS_ERP_TIMEDOUT) {
ZFCP_LOG_NORMAL("error: erp step timed out "
@@ -876,11 +874,11 @@ zfcp_erp_strategy_check_fsfreq(struct zfcp_erp_action
*erp_action)
* then keep it running asynchronously and don't mess
* with the association of erp_action and fsf_req.
*/
- if (fsf_req->status & (ZFCP_STATUS_FSFREQ_COMPLETED |
+ if (erp_action->fsf_req->status &
+ (ZFCP_STATUS_FSFREQ_COMPLETED |
ZFCP_STATUS_FSFREQ_DISMISSED)) {
/* forget about association between fsf_req
and erp_action */
- fsf_req->erp_action = NULL;
erp_action->fsf_req = NULL;
}
} else {
@@ -894,8 +892,6 @@ zfcp_erp_strategy_check_fsfreq(struct zfcp_erp_action
*erp_action)
spin_unlock(&adapter->req_list_lock);
} else
debug_text_event(adapter->erp_dbf, 3, "a_ca_noreq");
-
- return retval;
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: removed wrong comment
commit 07a105136f07f0cf1b476383e43033b8a65e13ff Author: Swen Schillig <[EMAIL PROTECTED]> Date: Fri Feb 9 09:58:09 2007 +0100 removed wrong comment Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> --- diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c index cbe47a2..0cc8603 100644 --- a/drivers/s390/scsi/zfcp_erp.c +++ b/drivers/s390/scsi/zfcp_erp.c @@ -838,8 +838,6 @@ zfcp_erp_action_exists(struct zfcp_erp_action *erp_action) * and does appropriate preparations (dismiss fsf request, ...) * * locks: called under erp_lock (disabled interrupts) - * - * returns:0 */ static void zfcp_erp_strategy_check_fsfreq(struct zfcp_erp_action *erp_action) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: Stop system after memory corruption
From: Christof Schmitt <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
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.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_qdio.c 2007-05-07
12:47:26.0 +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
---
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] zfcp: print S_ID and D_ID with 3 bytes
From: Christof Schmitt <[EMAIL PROTECTED]>
S_ID and D_ID are defined in the FCP spec as 3 byte fields.
Change the output in zfcp print statements accordingly to print
them with only 3 bytes.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |6 +++---
drivers/s390/scsi/zfcp_erp.c | 20 ++--
drivers/s390/scsi/zfcp_fsf.c | 30 +++---
3 files changed, 28 insertions(+), 28 deletions(-)
--- linux-2.6.orig/drivers/s390/scsi/zfcp_aux.c 2007-04-26 14:53:13.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-05-07 13:29:48.0
+0200
@@ -1497,7 +1497,7 @@
if (!port || (port->wwpn != (*(wwn_t *) &els_plogi->serv_param.wwpn))) {
ZFCP_LOG_DEBUG("ignored incoming PLOGI for nonexisting port "
- "with d_id 0x%08x on adapter %s\n",
+ "with d_id 0x%06x on adapter %s\n",
status_buffer->d_id,
zfcp_get_busid_by_adapter(adapter));
} else {
@@ -1522,7 +1522,7 @@
if (!port || (port->wwpn != els_logo->nport_wwpn)) {
ZFCP_LOG_DEBUG("ignored incoming LOGO for nonexisting port "
- "with d_id 0x%08x on adapter %s\n",
+ "with d_id 0x%06x on adapter %s\n",
status_buffer->d_id,
zfcp_get_busid_by_adapter(adapter));
} else {
@@ -1704,7 +1704,7 @@
/* looks like a valid d_id */
port->d_id = ct_iu_resp->d_id & ZFCP_DID_MASK;
atomic_set_mask(ZFCP_STATUS_PORT_DID_DID, &port->status);
- ZFCP_LOG_DEBUG("adapter %s: wwpn=0x%016Lx ---> d_id=0x%08x\n",
+ ZFCP_LOG_DEBUG("adapter %s: wwpn=0x%016Lx ---> d_id=0x%06x\n",
zfcp_get_busid_by_port(port), port->wwpn, port->d_id);
goto out;
--- linux-2.6.orig/drivers/s390/scsi/zfcp_erp.c 2007-05-07 12:37:01.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_erp.c 2007-05-07 13:29:48.0
+0200
@@ -342,9 +342,9 @@
adisc->wwpn = fc_host_port_name(adapter->scsi_host);
adisc->wwnn = fc_host_node_name(adapter->scsi_host);
adisc->nport_id = fc_host_port_id(adapter->scsi_host);
- ZFCP_LOG_INFO("ADISC request from s_id 0x%08x to d_id 0x%08x "
+ ZFCP_LOG_INFO("ADISC request from s_id 0x%06x to d_id 0x%06x "
"(wwpn=0x%016Lx, wwnn=0x%016Lx, "
- "hard_nport_id=0x%08x, nport_id=0x%08x)\n",
+ "hard_nport_id=0x%06x, nport_id=0x%06x)\n",
adisc->nport_id, send_els->d_id, (wwn_t) adisc->wwpn,
(wwn_t) adisc->wwnn, adisc->hard_nport_id,
adisc->nport_id);
@@ -352,7 +352,7 @@
retval = zfcp_fsf_send_els(send_els);
if (retval != 0) {
ZFCP_LOG_NORMAL("error: initiation of Send ELS failed for port "
- "0x%08x on adapter %s\n", send_els->d_id,
+ "0x%06x on adapter %s\n", send_els->d_id,
zfcp_get_busid_by_adapter(adapter));
goto freemem;
}
@@ -398,7 +398,7 @@
if (send_els->status != 0) {
ZFCP_LOG_NORMAL("ELS request rejected/timed out, "
"force physical port reopen "
- "(adapter %s, port d_id=0x%08x)\n",
+ "(adapter %s, port d_id=0x%06x)\n",
zfcp_get_busid_by_adapter(adapter), d_id);
debug_text_event(adapter->erp_dbf, 3, "forcreop");
if (zfcp_erp_port_forced_reopen(port, 0))
@@ -411,9 +411,9 @@
adisc = zfcp_sg_to_address(send_els->resp);
- ZFCP_LOG_INFO("ADISC response from d_id 0x%08x to s_id "
- "0x%08x (wwpn=0x%016Lx, wwnn=0x%016Lx, "
- "hard_nport_id=0x%08x, nport_id=0x%08x)\n",
+ ZFCP_LOG_INFO("ADISC response from d_id 0x%06x to s_id "
+ "0x%06x (wwpn=0x%016Lx, wwnn=0x%016Lx, "
+ "hard_nport_id=0x%06x, nport_id=0x%06x)\n",
d_id, fc_host_port_id(adapter->scsi_host),
(wwn_t) adisc->wwpn, (wwn_t) adisc->wwnn,
adisc->hard_nport_id, adisc->nport_id);
@@ -1377,7 +1377,7 @@
if (atomic_test_mask(ZFCP_STATUS_PORT_WKA, &port->
[PATCH 1/5] zfcp: Locking for req_no and req_seq_no
From: Christof Schmitt <[EMAIL PROTECTED]>
There is a possible race condition while generating the unique
request ids and sequence numbers. Both might be read at the
same time and have the same value. Fix this by serializing the
access through the queue lock of the adapter: First call
zfcp_fsf_req_sbal_get that acquires the lock, then read and
increment the unique ids.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_fsf.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
--- linux-2.6.orig/drivers/s390/scsi/zfcp_fsf.c 2007-05-07 13:56:57.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_fsf.c 2007-05-07 13:57:34.0
+0200
@@ -4645,23 +4645,22 @@
fsf_req->adapter = adapter;
fsf_req->fsf_command = fsf_cmd;
INIT_LIST_HEAD(&fsf_req->list);
-
- /* this is serialized (we are holding req_queue-lock of adapter */
- if (adapter->req_no == 0)
- adapter->req_no++;
- fsf_req->req_id = adapter->req_no++;
-
init_timer(&fsf_req->timer);
- zfcp_fsf_req_qtcb_init(fsf_req);
/* initialize waitqueue which may be used to wait on
this request completion */
init_waitqueue_head(&fsf_req->completion_wq);
ret = zfcp_fsf_req_sbal_get(adapter, req_flags, lock_flags);
-if(ret < 0) {
+if (ret < 0)
goto failed_sbals;
- }
+
+ /* this is serialized (we are holding req_queue-lock of adapter) */
+ if (adapter->req_no == 0)
+ adapter->req_no++;
+ fsf_req->req_id = adapter->req_no++;
+
+ zfcp_fsf_req_qtcb_init(fsf_req);
/*
* We hold queue_lock here. Check if QDIOUP is set and let request fail
---
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] zfcp: Fix deadlock between zfcp ERP and SCSI
From: Christof Schmitt <[EMAIL PROTECTED]>
The SCSI stack requires low level drivers to register and
unregister devices. For zfcp this leads to the situation where
zfcp calls the SCSI stack, the SCSI tries to scan the new device
and the scan SCSI command fails. This would require the zfcp erp,
but the erp thread is already blocked in the register call.
The fix is to make sure that the calls from the ERP thread to
the SCSI stack do not block the ERP thread. In detail:
1) Use a workqueue to avoid blocking of the scsi_scan_target calls.
2) When removing a unit make sure that no scsi_scan_target call is
pending.
3) Replace scsi_flush_work with scsi_target_unblock. This avoids
blocking and has the same result.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |2 +
drivers/s390/scsi/zfcp_def.h |5 +++
drivers/s390/scsi/zfcp_erp.c | 64 +++---
drivers/s390/scsi/zfcp_scsi.c |5 +++
4 files changed, 72 insertions(+), 4 deletions(-)
--- linux-2.6.orig/drivers/s390/scsi/zfcp_aux.c 2007-05-07 13:56:57.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-05-07 15:50:19.0
+0200
@@ -913,6 +913,8 @@
unit->sysfs_device.release = zfcp_sysfs_unit_release;
dev_set_drvdata(&unit->sysfs_device, unit);
+ init_waitqueue_head(&unit->scsi_scan_wq);
+
/* mark unit unusable as long as sysfs registration is not complete */
atomic_set_mask(ZFCP_STATUS_COMMON_REMOVE, &unit->status);
--- linux-2.6.orig/drivers/s390/scsi/zfcp_def.h 2007-04-26 14:53:13.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_def.h 2007-05-07 15:54:46.0
+0200
@@ -637,6 +637,7 @@
#define ZFCP_STATUS_UNIT_SHARED0x0004
#define ZFCP_STATUS_UNIT_READONLY 0x0008
#define ZFCP_STATUS_UNIT_REGISTERED0x0010
+#define ZFCP_STATUS_UNIT_SCSI_WORK_PENDING 0x0020
/* FSF request status (this does not have a common part) */
#define ZFCP_STATUS_FSFREQ_NOT_INIT0x
@@ -980,6 +981,10 @@
struct scsi_device *device;/* scsi device struct pointer */
struct zfcp_erp_action erp_action; /* pending error recovery */
atomic_t erp_counter;
+ wait_queue_head_t scsi_scan_wq; /* can be used to wait until
+ all scsi_scan_target
+ requests have been
+ completed. */
};
/* FSF request */
--- linux-2.6.orig/drivers/s390/scsi/zfcp_erp.c 2007-05-07 13:56:57.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_erp.c 2007-05-07 15:50:19.0
+0200
@@ -1591,6 +1591,62 @@
return result;
}
+struct zfcp_erp_add_work {
+ struct zfcp_unit *unit;
+ struct work_struct work;
+};
+
+/**
+ * zfcp_erp_scsi_scan
+ * @data: pointer to a struct zfcp_erp_add_work
+ *
+ * Registers a logical unit with the SCSI stack.
+ */
+static void zfcp_erp_scsi_scan(struct work_struct *work)
+{
+ struct zfcp_erp_add_work *p =
+ container_of(work, struct zfcp_erp_add_work, work);
+ struct zfcp_unit *unit = p->unit;
+ struct fc_rport *rport = unit->port->rport;
+ scsi_scan_target(&rport->dev, 0, rport->scsi_target_id,
+unit->scsi_lun, 0);
+ atomic_clear_mask(ZFCP_STATUS_UNIT_SCSI_WORK_PENDING, &unit->status);
+ wake_up(&unit->scsi_scan_wq);
+ zfcp_unit_put(unit);
+ kfree(p);
+}
+
+/**
+ * zfcp_erp_schedule_work
+ * @unit: pointer to unit which should be registered with SCSI stack
+ *
+ * Schedules work which registers a unit with the SCSI stack
+ */
+static void
+zfcp_erp_schedule_work(struct zfcp_unit *unit)
+{
+ struct zfcp_erp_add_work *p;
+
+ p = kmalloc(sizeof(*p), GFP_KERNEL);
+ if (!p) {
+ ZFCP_LOG_NORMAL("error: Out of resources. Could not register "
+ "the FCP-LUN 0x%Lx connected to "
+ "the port with WWPN 0x%Lx connected to "
+ "the adapter %s with the SCSI stack.\n",
+ unit->fcp_lun,
+ unit->port->wwpn,
+ zfcp_get_busid_by_unit(unit));
+ return;
+ }
+
+ zfcp_unit_get(unit);
+ memset(p, 0, sizeof(*p));
+ atomic_set_mask(ZFCP_STATUS_UNIT_SCSI_WORK_PENDING, &unit->status);
+ INIT_WORK(&p->work, zfcp_erp_scsi_scan);
+ p->unit = unit;
+ schedule_work(&p->work);
+}
+
/*
* function:
*
@@ -3092,9 +3148,9 @@
&& port->rport) {
[PATCH 3/5] zfcp: rework request ID management.
From: Heiko Carstens <[EMAIL PROTECTED]>
Simplify request ID management and make sure that frequently used
functions are inlined. Also fix a memory leak in zfcp_adapter_enqueue()
which only gets hit in error handling.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c | 82 --
drivers/s390/scsi/zfcp_def.h | 36 ++
drivers/s390/scsi/zfcp_erp.c |3 -
drivers/s390/scsi/zfcp_ext.h |4 --
drivers/s390/scsi/zfcp_fsf.c |2 -
drivers/s390/scsi/zfcp_qdio.c | 17 +---
drivers/s390/scsi/zfcp_scsi.c |4 +-
7 files changed, 59 insertions(+), 89 deletions(-)
--- linux-2.6.orig/drivers/s390/scsi/zfcp_aux.c 2007-05-07 15:50:19.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_aux.c 2007-05-07 16:26:34.0
+0200
@@ -118,97 +118,32 @@
#define ZFCP_LOG_AREA ZFCP_LOG_AREA_FSF
-static int zfcp_reqlist_init(struct zfcp_adapter *adapter)
+static int zfcp_reqlist_alloc(struct zfcp_adapter *adapter)
{
- int i;
+ int idx;
adapter->req_list = kcalloc(REQUEST_LIST_SIZE, sizeof(struct list_head),
GFP_KERNEL);
-
if (!adapter->req_list)
return -ENOMEM;
- for (i=0; ireq_list[i]);
-
+ for (idx = 0; idx < REQUEST_LIST_SIZE; idx++)
+ INIT_LIST_HEAD(&adapter->req_list[idx]);
return 0;
}
static void zfcp_reqlist_free(struct zfcp_adapter *adapter)
{
- struct zfcp_fsf_req *request, *tmp;
- unsigned int i;
-
- for (i=0; ireq_list[i]))
- continue;
-
- list_for_each_entry_safe(request, tmp,
-&adapter->req_list[i], list)
- list_del(&request->list);
- }
-
kfree(adapter->req_list);
}
-void zfcp_reqlist_add(struct zfcp_adapter *adapter,
- struct zfcp_fsf_req *fsf_req)
-{
- unsigned int i;
-
- i = fsf_req->req_id % REQUEST_LIST_SIZE;
- list_add_tail(&fsf_req->list, &adapter->req_list[i]);
-}
-
-void zfcp_reqlist_remove(struct zfcp_adapter *adapter, unsigned long req_id)
-{
- struct zfcp_fsf_req *request, *tmp;
- unsigned int i, counter;
- u64 dbg_tmp[2];
-
- i = req_id % REQUEST_LIST_SIZE;
- BUG_ON(list_empty(&adapter->req_list[i]));
-
- counter = 0;
- list_for_each_entry_safe(request, tmp, &adapter->req_list[i], list) {
- if (request->req_id == req_id) {
- dbg_tmp[0] = (u64) atomic_read(&adapter->reqs_active);
- dbg_tmp[1] = (u64) counter;
- debug_event(adapter->erp_dbf, 4, (void *) dbg_tmp, 16);
- list_del(&request->list);
- break;
- }
- counter++;
- }
-}
-
-struct zfcp_fsf_req *zfcp_reqlist_ismember(struct zfcp_adapter *adapter,
- unsigned long req_id)
-{
- struct zfcp_fsf_req *request, *tmp;
- unsigned int i;
-
- /* 0 is reserved as an invalid req_id */
- if (req_id == 0)
- return NULL;
-
- i = req_id % REQUEST_LIST_SIZE;
-
- list_for_each_entry_safe(request, tmp, &adapter->req_list[i], list)
- if (request->req_id == req_id)
- return request;
-
- return NULL;
-}
-
int zfcp_reqlist_isempty(struct zfcp_adapter *adapter)
{
- unsigned int i;
+ unsigned int idx;
- for (i=0; ireq_list[i]))
+ for (idx = 0; idx < REQUEST_LIST_SIZE; idx++)
+ if (!list_empty(&adapter->req_list[idx]))
return 0;
-
return 1;
}
@@ -1106,7 +1041,7 @@
/* initialize list of fsf requests */
spin_lock_init(&adapter->req_list_lock);
- retval = zfcp_reqlist_init(adapter);
+ retval = zfcp_reqlist_alloc(adapter);
if (retval) {
ZFCP_LOG_INFO("request list initialization failed\n");
goto failed_low_mem_buffers;
@@ -1167,6 +1102,7 @@
zfcp_sysfs_adapter_remove_files(&adapter->ccw_device->dev);
sysfs_failed:
dev_set_drvdata(&ccw_device->dev, NULL);
+ zfcp_reqlist_free(adapter);
failed_low_mem_buffers:
zfcp_free_low_mem_buffers(adapter);
if (qdio_free(ccw_device) != 0)
--- linux-2.6.orig/drivers/s390/scsi/zfcp_def.h 2007-05-07 15:54:46.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_def.h 2007-05-07 16:26:34.0
+0200
@@ -1090,6 +1090,42 @@
#define zfcp_get_busid_by_unit(unit) (zfcp_get_busid_by_port(unit->port))
/*
+ * Helper functions for request ID management.
+ */
+static inline i
[PATCH 4/5] zfcp: clear adapter failed flag if an fsf request times out.
From: Heiko Carstens <[EMAIL PROTECTED]>
Must clear adapter failed flag if an fsf request times out. This is
necessary because on link down situations the failed flags gets set
but the QDIO queues are still up. Since an adapter reopen will be
skipped if the failed flag is set an adapter_reopen that is issued
on fsf request timeout has no effect if the local link is down.
Might lead to locked up system if the SCSI stack is waiting for abort
completion.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_erp.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/drivers/s390/scsi/zfcp_erp.c 2007-05-07 16:26:34.0
+0200
+++ linux-2.6/drivers/s390/scsi/zfcp_erp.c 2007-05-07 16:33:54.0
+0200
@@ -179,7 +179,7 @@
static void zfcp_fsf_request_timeout_handler(unsigned long data)
{
struct zfcp_adapter *adapter = (struct zfcp_adapter *) data;
- zfcp_erp_adapter_reopen(adapter, 0);
+ zfcp_erp_adapter_reopen(adapter, ZFCP_STATUS_COMMON_ERP_FAILED);
}
void zfcp_fsf_start_timer(struct zfcp_fsf_req *fsf_req, unsigned long timeout)
---
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] zfcp: clear boxed flag on unit reopen.
From: Heiko Carstens <[EMAIL PROTECTED]> The boxed flag for units was never cleared. This doesn't hurt, but on ACL updates the error recovery could reopen more units than needed. Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> --- drivers/s390/scsi/zfcp_fsf.c |1 + 1 files changed, 1 insertion(+) --- linux-2.6.orig/drivers/s390/scsi/zfcp_fsf.c 2007-05-07 16:26:34.0 +0200 +++ linux-2.6/drivers/s390/scsi/zfcp_fsf.c 2007-05-07 16:34:16.0 +0200 @@ -3043,6 +3043,7 @@ queue_designator = &header->fsf_status_qual.fsf_queue_designator; atomic_clear_mask(ZFCP_STATUS_COMMON_ACCESS_DENIED | + ZFCP_STATUS_COMMON_ACCESS_BOXED | ZFCP_STATUS_UNIT_SHARED | ZFCP_STATUS_UNIT_READONLY, &unit->status); --- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] zfcp: avoid clutter in erp_dbf
>From Martin Peschke <[EMAIL PROTECTED]>
avoid clutter in erp_dbf
cleanup zfcp_fsf_req_dismiss functions:
- avoid clutter in erp_dbf (reqs_active is always 0)
- fold called three-line function into calling function
- add meaningful comment
- coding style
Signed-off-by: Martin Peschke <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_fsf.c | 40 +---
1 file changed, 13 insertions(+), 27 deletions(-)
--- linux_jb_patched.orig/drivers/s390/scsi/zfcp_fsf.c 2007-05-08
14:47:17.0 +0200
+++ linux_jb_patched/drivers/s390/scsi/zfcp_fsf.c 2007-05-08
14:48:08.0 +0200
@@ -156,44 +156,30 @@ zfcp_fsf_req_free(struct zfcp_fsf_req *f
kfree(fsf_req);
}
-/**
- * zfcp_fsf_req_dismiss - dismiss a single fsf request
- */
-static void zfcp_fsf_req_dismiss(struct zfcp_adapter *adapter,
-struct zfcp_fsf_req *fsf_req,
-unsigned int counter)
-{
- u64 dbg_tmp[2];
-
- dbg_tmp[0] = (u64) atomic_read(&adapter->reqs_active);
- dbg_tmp[1] = (u64) counter;
- debug_event(adapter->erp_dbf, 4, (void *) dbg_tmp, 16);
- list_del(&fsf_req->list);
- fsf_req->status |= ZFCP_STATUS_FSFREQ_DISMISSED;
- zfcp_fsf_req_complete(fsf_req);
-}
-
-/**
- * zfcp_fsf_req_dismiss_all - dismiss all remaining fsf requests
+/*
+ * Never ever call this without shutting down the adapter first.
+ * Otherwise the adapter would continue using and corrupting s390 storage.
+ * Included BUG_ON() call to ensure this is done.
+ * ERP is supposed to be the only user of this function.
*/
void zfcp_fsf_req_dismiss_all(struct zfcp_adapter *adapter)
{
- struct zfcp_fsf_req *request, *tmp;
+ struct zfcp_fsf_req *fsf_req, *tmp;
unsigned long flags;
LIST_HEAD(remove_queue);
- unsigned int i, counter;
+ unsigned int i;
+ BUG_ON(atomic_test_mask(ZFCP_STATUS_ADAPTER_QDIOUP, &adapter->status));
spin_lock_irqsave(&adapter->req_list_lock, flags);
atomic_set(&adapter->reqs_active, 0);
- for (i=0; ireq_list[i], &remove_queue);
-
spin_unlock_irqrestore(&adapter->req_list_lock, flags);
- counter = 0;
- list_for_each_entry_safe(request, tmp, &remove_queue, list) {
- zfcp_fsf_req_dismiss(adapter, request, counter);
- counter++;
+ list_for_each_entry_safe(fsf_req, tmp, &remove_queue, list) {
+ list_del(&fsf_req->list);
+ fsf_req->status |= ZFCP_STATUS_FSFREQ_DISMISSED;
+ zfcp_fsf_req_complete(fsf_req);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] zfcp: IO stall after deleting and path checker changes after reenabling zfcp devices
From: Michael Loehr <[EMAIL PROTECTED]> IO stall after deleting and path checker changes after reenabling zfcp device Setting one zfcp device offline using chccwdev in a multipath environment and waiting will lead to IO stall on all paths. After setting the zfcp device back online using chccwdev, the devices with io stall will have a different path checker. Devices corresponding to the deleted units are never freed. This has the effect that 'slave_destroy' is never called and zfcp still thinks that this unit is registered (ZFCP_STATUS_UNIT_REGISTERED is still set). Hence the erp routine is not called correctly and the unit is not enabled properly. Do not delete rport and the sdev. Just set the host to block on 'offline'. Setting host online again will then remove the blocked status and everything is fine again. Signed-off-by: Michael Loehr <[EMAIL PROTECTED]> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> h --- drivers/s390/scsi/zfcp_aux.c |1 + drivers/s390/scsi/zfcp_ccw.c |5 + drivers/s390/scsi/zfcp_scsi.c |3 +++ 3 files changed, 5 insertions(+), 4 deletions(-) Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c @@ -1129,6 +1129,7 @@ zfcp_adapter_dequeue(struct zfcp_adapter int retval = 0; unsigned long flags; + zfcp_adapter_scsi_unregister(adapter); device_unregister(&adapter->generic_services); zfcp_sysfs_adapter_remove_files(&adapter->ccw_device->dev); dev_set_drvdata(&adapter->ccw_device->dev, NULL); Index: linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_ccw.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c @@ -189,9 +189,7 @@ zfcp_ccw_set_online(struct ccw_device *c * @ccw_device: pointer to belonging ccw device * * This function gets called by the common i/o layer and sets an adapter - * into state offline. Setting an fcp device offline means that it will be - * unregistered from the SCSI stack and that the adapter will be shut down - * asynchronously. + * into state offline. */ static int zfcp_ccw_set_offline(struct ccw_device *ccw_device) @@ -202,7 +200,6 @@ zfcp_ccw_set_offline(struct ccw_device * adapter = dev_get_drvdata(&ccw_device->dev); zfcp_erp_adapter_shutdown(adapter, 0); zfcp_erp_wait(adapter); - zfcp_adapter_scsi_unregister(adapter); zfcp_erp_thread_kill(adapter); zfcp_adapter_debug_unregister(adapter); up(&zfcp_data.config_sema); Index: linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_scsi.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c @@ -569,6 +569,9 @@ zfcp_adapter_scsi_register(struct zfcp_a int retval = 0; static unsigned int unique_id = 0; + if (adapter->scsi_host) + goto out; + /* register adapter as SCSI host with mid layer of SCSI stack */ adapter->scsi_host = scsi_host_alloc(&zfcp_data.scsi_host_template, sizeof (struct zfcp_adapter *)); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] zfcp: IO stall after path checker changes
From: Michael Loehr <[EMAIL PROTECTED]> Devices corresponding to a deleted unit are never freed. This has the effect that slave_destroy is never called and zfcp 'thinks' that this unit is still registered. This patch changes the zfcp behaviour the way that the rport and sdev are not deleted anymore. The host is set to block on 'offline'. Host online is only removing the blocked status and everything works as expected again. Signed-off-by: Michael Loehr <[EMAIL PROTECTED]> Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> --- drivers/s390/scsi/zfcp_aux.c |1 + drivers/s390/scsi/zfcp_ccw.c |5 + drivers/s390/scsi/zfcp_scsi.c |3 +++ 3 files changed, 5 insertions(+), 4 deletions(-) Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c @@ -1127,6 +1127,7 @@ zfcp_adapter_dequeue(struct zfcp_adapter int retval = 0; unsigned long flags; + zfcp_adapter_scsi_unregister(adapter); device_unregister(&adapter->generic_services); zfcp_sysfs_adapter_remove_files(&adapter->ccw_device->dev); dev_set_drvdata(&adapter->ccw_device->dev, NULL); Index: linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_ccw.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c @@ -189,9 +189,7 @@ zfcp_ccw_set_online(struct ccw_device *c * @ccw_device: pointer to belonging ccw device * * This function gets called by the common i/o layer and sets an adapter - * into state offline. Setting an fcp device offline means that it will be - * unregistered from the SCSI stack and that the adapter will be shut down - * asynchronously. + * into state offline. */ static int zfcp_ccw_set_offline(struct ccw_device *ccw_device) @@ -202,7 +200,6 @@ zfcp_ccw_set_offline(struct ccw_device * adapter = dev_get_drvdata(&ccw_device->dev); zfcp_erp_adapter_shutdown(adapter, 0); zfcp_erp_wait(adapter); - zfcp_adapter_scsi_unregister(adapter); zfcp_erp_thread_kill(adapter); zfcp_adapter_debug_unregister(adapter); up(&zfcp_data.config_sema); Index: linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_scsi.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c @@ -569,6 +569,9 @@ zfcp_adapter_scsi_register(struct zfcp_a int retval = 0; static unsigned int unique_id = 0; + if (adapter->scsi_host) + goto out; + /* register adapter as SCSI host with mid layer of SCSI stack */ adapter->scsi_host = scsi_host_alloc(&zfcp_data.scsi_host_template, sizeof (struct zfcp_adapter *)); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] zfcp: clear adapter status flags during adapter shutdown
From: Volker Sameske <[EMAIL PROTECTED]>
zfcp: clear adapter status flags during adapter shutdown
In some cases we did not reset some adapter status flags properly.
This patch clears these flags during FCP adapter shutdown.
Signed-off-by: Volker Sameske <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_erp.c |7 +++
1 file changed, 7 insertions(+)
Index: linux_jb_patched/drivers/s390/scsi/zfcp_erp.c
===
--- linux_jb_patched.orig/drivers/s390/scsi/zfcp_erp.c
+++ linux_jb_patched/drivers/s390/scsi/zfcp_erp.c
@@ -1986,6 +1986,10 @@ zfcp_erp_adapter_strategy_generic(struct
failed_openfcp:
zfcp_close_fsf(erp_action->adapter);
failed_qdio:
+ atomic_clear_mask(ZFCP_STATUS_ADAPTER_XCONFIG_OK |
+ ZFCP_STATUS_ADAPTER_LINK_UNPLUGGED |
+ ZFCP_STATUS_ADAPTER_XPORT_OK,
+ &erp_action->adapter->status);
out:
return retval;
}
@@ -2167,6 +2171,9 @@ zfcp_erp_adapter_strategy_open_fsf_xconf
sleep *= 2;
}
+ atomic_clear_mask(ZFCP_STATUS_ADAPTER_HOST_CON_INIT,
+ &adapter->status);
+
if (!atomic_test_mask(ZFCP_STATUS_ADAPTER_XCONFIG_OK,
&adapter->status)) {
ZFCP_LOG_INFO("error: exchange of configuration data for "
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] zfcp: Don't report device as LUN 0 to SCSI stack
From: Christof Schmitt <[EMAIL PROTECTED]>
zfcp reported units to the SCSI stack starting
with number 0. LUN 0 reported to the SCSI stack is usually
not the FCP LUN 0. When scanning for devices,
the SCSI stack tried to issue a REPORT LUN command to LUN 0.
The current design for zfcp does not want the SCSI stack to scan
for devices, since they are configured explicitly via sysfs.
This patch changes the numbering to always start with LUN 1 and therefore
prevent the SCSI stack sending REPORT LUN command.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c
===
--- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c
+++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c
@@ -864,7 +864,8 @@ zfcp_unit_enqueue(struct zfcp_port *port
zfcp_unit_get(unit);
- scsi_lun = 0;
+ /* Don't report LUN 0 to prevent the REPORT LUNS command from SCSI. */
+ scsi_lun = 1;
found = 0;
write_lock_irq(&zfcp_data.config_lock);
list_for_each_entry(tmp_unit, &port->unit_list_head, list) {
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] zfcp: IO stall after path checker changes
James I just saw that I posted this patch on 9th already, but todays git pull from your tree didn't show the inclusion of this one (and another patch posted the same day). Event though it's reported in your summary from the 26 ! If I'm to quick then I'm sorry for sending it twice, if there's any other reason for this patch to not be included please let me know. Thanks Swen On Tuesday 29 May 2007 15:29, Swen Schillig wrote: > From: Michael Loehr <[EMAIL PROTECTED]> > > Devices corresponding to a deleted unit are never freed. > This has the effect that slave_destroy is never called and zfcp > 'thinks' that this unit is still registered. > This patch changes the zfcp behaviour the way that the > rport and sdev are not deleted anymore. The host is set to > block on 'offline'. Host online is only removing the blocked status > and everything works as expected again. > > Signed-off-by: Michael Loehr <[EMAIL PROTECTED]> > Signed-off-by: Swen Schillig <[EMAIL PROTECTED]> > > --- > > drivers/s390/scsi/zfcp_aux.c |1 + > drivers/s390/scsi/zfcp_ccw.c |5 + > drivers/s390/scsi/zfcp_scsi.c |3 +++ > 3 files changed, 5 insertions(+), 4 deletions(-) > > Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c > === > --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c > +++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c > @@ -1127,6 +1127,7 @@ zfcp_adapter_dequeue(struct zfcp_adapter > int retval = 0; > unsigned long flags; > > + zfcp_adapter_scsi_unregister(adapter); > device_unregister(&adapter->generic_services); > zfcp_sysfs_adapter_remove_files(&adapter->ccw_device->dev); > dev_set_drvdata(&adapter->ccw_device->dev, NULL); > Index: linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c > === > --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_ccw.c > +++ linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c > @@ -189,9 +189,7 @@ zfcp_ccw_set_online(struct ccw_device *c > * @ccw_device: pointer to belonging ccw device > * > * This function gets called by the common i/o layer and sets an adapter > - * into state offline. Setting an fcp device offline means that it will be > - * unregistered from the SCSI stack and that the adapter will be shut down > - * asynchronously. > + * into state offline. > */ > static int > zfcp_ccw_set_offline(struct ccw_device *ccw_device) > @@ -202,7 +200,6 @@ zfcp_ccw_set_offline(struct ccw_device * > adapter = dev_get_drvdata(&ccw_device->dev); > zfcp_erp_adapter_shutdown(adapter, 0); > zfcp_erp_wait(adapter); > - zfcp_adapter_scsi_unregister(adapter); > zfcp_erp_thread_kill(adapter); > zfcp_adapter_debug_unregister(adapter); > up(&zfcp_data.config_sema); > Index: linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c > === > --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_scsi.c > +++ linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c > @@ -569,6 +569,9 @@ zfcp_adapter_scsi_register(struct zfcp_a > int retval = 0; > static unsigned int unique_id = 0; > > + if (adapter->scsi_host) > + goto out; > + > /* register adapter as SCSI host with mid layer of SCSI stack */ > adapter->scsi_host = scsi_host_alloc(&zfcp_data.scsi_host_template, >sizeof (struct zfcp_adapter *)); > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] zfcp: IO stall after path checker changes
On Tuesday 29 May 2007 17:54, James Bottomley wrote: > On Tue, 2007-05-29 at 10:51 -0500, James Bottomley wrote: > > On Tue, 2007-05-29 at 15:55 +0200, Swen Schillig wrote: > > > I just saw that I posted this patch on 9th already, > > > but todays git pull from your tree didn't show the inclusion of this one > > > (and another patch posted the same day). > > > Event though it's reported in your summary from the 26 ! > > > If I'm to quick then I'm sorry for sending it twice, if there's any other > > > reason for this patch to not be included please let me know. > > > > Sorry ... must have missed it. I'll add it to rc-fixes (unfortunately I > > need linus to pull before I can push into this tree, so there'll be a > > slight delay). > > Actually, forget that; this is it, isn't it? > > http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=9f28745a6b554fdd6b0dbc9856077701a55f9569 > > In which case it's awaiting a pull into Linus' tree head. > > James > > Yeah, that's it. Thanks. Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: Replace kmalloc/memset with kzalloc
From: Swen Schillig <[EMAIL PROTECTED]>
Memory allocated with kmalloc is always initialzed to 0 with memset.
Replace the two calls with kzalloc, that already does both steps.
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_erp.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff -urpN linux-2.6/drivers/s390/scsi/zfcp_erp.c
linux-2.6-patched/drivers/s390/scsi/zfcp_erp.c
--- linux-2.6/drivers/s390/scsi/zfcp_erp.c 2007-06-14 10:32:45.0
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_erp.c 2007-06-14
10:33:29.0 +0200
@@ -1626,7 +1626,7 @@ zfcp_erp_schedule_work(struct zfcp_unit
{
struct zfcp_erp_add_work *p;
- p = kmalloc(sizeof(*p), GFP_KERNEL);
+ p = kzalloc(sizeof(*p), GFP_KERNEL);
if (!p) {
ZFCP_LOG_NORMAL("error: Out of resources. Could not register "
"the FCP-LUN 0x%Lx connected to "
@@ -1639,7 +1639,6 @@ zfcp_erp_schedule_work(struct zfcp_unit
}
zfcp_unit_get(unit);
- memset(p, 0, sizeof(*p));
atomic_set_mask(ZFCP_STATUS_UNIT_SCSI_WORK_PENDING, &unit->status);
INIT_WORK(&p->work, zfcp_erp_scsi_scan);
p->unit = unit;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
missing patches
James on the 29th of may I posted 3 patches for the zfcp driver named [PATCH 2/3] zfcp: clear adapter status flags during adapter shutdown [PATCH 3/3] zfcp: Don't report device as LUN 0 to SCSI stack unfortunately I can't find them in the tree so far, is there any reason for that ? Thanks Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] zfcp: Don't report device as LUN 0 to SCSI stack
On Monday 18 June 2007 10:47, Hannes Reinecke wrote: > James Bottomley wrote: > > On Tue, 2007-05-29 at 15:29 +0200, Swen Schillig wrote: > >> From: Christof Schmitt <[EMAIL PROTECTED]> > >> > >> zfcp reported units to the SCSI stack starting > >> with number 0. LUN 0 reported to the SCSI stack is usually > >> not the FCP LUN 0. When scanning for devices, > >> the SCSI stack tried to issue a REPORT LUN command to LUN 0. > >> The current design for zfcp does not want the SCSI stack to scan > >> for devices, since they are configured explicitly via sysfs. > >> This patch changes the numbering to always start with LUN 1 and therefore > >> prevent the SCSI stack sending REPORT LUN command. > > > > As a general principle, this does sound to be wrong (at least shifting > > the LUNs). Wouldn't something like the existing blacklist preventing > > the REPORT LUN command from being sent be more appropriate? > > > IMO the zfcp driver should export the FCP LUNs and not building their > own internal SCSI LUN to FCP LUN mapping table. > That would avoid this issue, too. And would make the zfcp driver more in > line with everyone else ... > > Cheers, > > Hannes Agree, we will provide a new patch covering this issue. So dump this one, but please don't forget to apply the other patches we sent. Cheers Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: Report FCP LUN to SCSI midlayer
From: Christof Schmitt <[EMAIL PROTECTED]>
When reporting SCSI devices to the SCSI midlayer, use the FCP LUN as
LUN reported to the SCSI layer. With this approach, zfcp does not have
to create unique LUNS, and this code can be removed.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/scsi/zfcp_aux.c | 22 --
drivers/scsi/scsi_scan.c |3 ++-
include/scsi/scsi_device.h |1 +
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_aux.c b/drivers/s390/scsi/zfcp_aux.c
index 821cde6..c631cf7 100644
--- a/drivers/s390/scsi/zfcp_aux.c
+++ b/drivers/s390/scsi/zfcp_aux.c
@@ -815,9 +815,7 @@ zfcp_get_adapter_by_busid(char *bus_id)
struct zfcp_unit *
zfcp_unit_enqueue(struct zfcp_port *port, fcp_lun_t fcp_lun)
{
- struct zfcp_unit *unit, *tmp_unit;
- unsigned int scsi_lun;
- int found;
+ struct zfcp_unit *unit;
/*
* check that there is no unit with this FCP_LUN already in list
@@ -863,22 +861,10 @@ zfcp_unit_enqueue(struct zfcp_port *port, fcp_lun_t
fcp_lun)
}
zfcp_unit_get(unit);
-
- scsi_lun = 0;
- found = 0;
+ unit->scsi_lun = scsilun_to_int((struct scsi_lun *)&unit->fcp_lun);
+
write_lock_irq(&zfcp_data.config_lock);
- list_for_each_entry(tmp_unit, &port->unit_list_head, list) {
- if (tmp_unit->scsi_lun != scsi_lun) {
- found = 1;
- break;
- }
- scsi_lun++;
- }
- unit->scsi_lun = scsi_lun;
- if (found)
- list_add_tail(&unit->list, &tmp_unit->list);
- else
- list_add_tail(&unit->list, &port->unit_list_head);
+ list_add_tail(&unit->list, &port->unit_list_head);
atomic_clear_mask(ZFCP_STATUS_COMMON_REMOVE, &unit->status);
atomic_set_mask(ZFCP_STATUS_COMMON_RUNNING, &unit->status);
write_unlock_irq(&zfcp_data.config_lock);
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 662577f..cf95ad9 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1213,7 +1213,7 @@ static void scsi_sequential_lun_scan(struct scsi_target
*starget,
* Given a struct scsi_lun of: 0a 04 0b 03 00 00 00 00, this function
returns
* the integer: 0x0b030a04
**/
-static int scsilun_to_int(struct scsi_lun *scsilun)
+int scsilun_to_int(struct scsi_lun *scsilun)
{
int i;
unsigned int lun;
@@ -1224,6 +1224,7 @@ static int scsilun_to_int(struct scsi_lun *scsilun)
scsilun->scsi_lun[i + 1]) << (i * 8));
return lun;
}
+EXPORT_SYMBOL(scsilun_to_int);
/**
* int_to_scsilun: reverts an int into a scsi_lun
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 2f3c5b8..6fe1cf6 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -287,6 +287,7 @@ extern void scsi_target_block(struct device *);
extern void scsi_target_unblock(struct device *);
extern void scsi_remove_target(struct device *);
extern void int_to_scsilun(unsigned int, struct scsi_lun *);
+extern int scsilun_to_int(struct scsi_lun *);
extern const char *scsi_device_state_name(enum scsi_device_state);
extern int scsi_is_sdev_device(const struct device *);
extern int scsi_is_target_device(const struct device *);
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: Report FCP LUN to SCSI midlayer
On Friday 22 June 2007 16:11, James Bottomley wrote: > On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote: > > James Bottomley <[EMAIL PROTECTED]> wrote: > > > A proposal to display the correct form of the LUN would be useful if you > > > wish to make it? ... The problem is really that SAM specifies a > > > possible 4 level structure with 4 possible address methods per level. > > > > > > The well known LUNs should be simple; there are only three: Report Lun, > > > Access Controls and Target Log Pages. The rest we really need input on. > > > For instance, I could see the vendors wishing us to combine a > > > multi-level flat addressing space into a single logical unit number, > > > whereas I could see them wanting us to supply some sort of hierarchy for > > > the peripheral and logical unit methods of addressing. > > > > > > Since you're already using 2 level flat addressing, how do you want to > > > see that represented? > > > > James, why would we would not want to display the lun per SAM4 4.6.2 as > > suggested by Stefan in a previous comment. > > Because in a two LUN system, what was LUN 1 would then become LUN > 0x1 which looks a bit unpalatable. > > James > > > - Despite the issue whether we should display and/or use (sysfs !?) full blown 64bit values, so with leading zeros, you still have the option to display, for the single level addressing, the LUN as a 2 byte value as described in SAM4 4.6.2. So for your example this would be 0x0001 or 0x1, which is exactly what you'd like to see, right ? Only for 2+ level environment the 64bit representation comes into the play. And, because you were asking how we'd like that to be represented, I personally prefer a full blown 64bit hex value with leading zeros. It makes the comparison to internal structures/models easier and gets us a bit closer to the documented (SAM4) standard. ...and I think we all can deal with a few extra digits being displayed. Cheers Swen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: Report FCP LUN to SCSI midlayer
On Monday 25 June 2007 16:03, Hannes Reinecke wrote:
> Swen Schillig wrote:
> > On Friday 22 June 2007 16:11, James Bottomley wrote:
> >> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> >>> James Bottomley <[EMAIL PROTECTED]> wrote:
> >>>> A proposal to display the correct form of the LUN would be useful if you
> >>>> wish to make it? ... The problem is really that SAM specifies a
> >>>> possible 4 level structure with 4 possible address methods per level.
> >>>>
> >>>> The well known LUNs should be simple; there are only three: Report Lun,
> >>>> Access Controls and Target Log Pages. The rest we really need input on.
> >>>> For instance, I could see the vendors wishing us to combine a
> >>>> multi-level flat addressing space into a single logical unit number,
> >>>> whereas I could see them wanting us to supply some sort of hierarchy for
> >>>> the peripheral and logical unit methods of addressing.
> >>>>
> >>>> Since you're already using 2 level flat addressing, how do you want to
> >>>> see that represented?
> >>> James, why would we would not want to display the lun per SAM4 4.6.2 as
> >>> suggested by Stefan in a previous comment.
> >> Because in a two LUN system, what was LUN 1 would then become LUN
> >> 0x1 which looks a bit unpalatable.
> >>
> >> James
> >>
> >>
> >> -
> >
> > Despite the issue whether we should display and/or use (sysfs !?)
> > full blown 64bit values, so with leading zeros, you still have the option
> > to display,
> > for the single level addressing, the LUN as a 2 byte value as described in
> > SAM4 4.6.2.
> > So for your example this would be 0x0001 or 0x1, which is exactly what
> > you'd like to see, right ?
> > Only for 2+ level environment the 64bit representation comes into the play.
> >
> > And, because you were asking how we'd like that to be represented, I
> > personally prefer
> > a full blown 64bit hex value with leading zeros.
> > It makes the comparison to internal structures/models easier and gets us a
> > bit closer
> > to the documented (SAM4) standard.
> > ...and I think we all can deal with a few extra digits being displayed.
> >
> Well ...
> why don't we stick with the original implementation like zfcp had it?
> We can simpley expand the midlayer to add an attribute 'lun'
> to each scsi_device. This would be the LUN as returned by eg
> REPORT LUNS.
> No translation, nothing. Would be easy to implement and would allow
> any administrator to map the h:c:i:l value to the 'real' lun.
>
> Cheers,
>
> Hannes
What do you mean with "like we had it" ?
I thought you were quite happy with the new version making
the old manual counting thing ("zfcp-ism") obsolete.
What's the benefit of adding another (LUN) attribute to the midlayer, I don't
get
what this is supposed to solve.
The initial question was, should we not display the long-ish LUN value in
hex format making it easier for admins (and us) to actually use it
as it is.
I think Luben and Stefan suggested a good way to do that, ok apart from the
be64 bits :-)
So, just use the struct scsi_lun in its full extend, for the sysfs without a
leading "0x",
and forgetting about the scsilun_to_int conversion which isn't good for
anything.
This way we would be conform to SAM4 as well even though I'm getting the
impression
that this isn't the major goal of this discussion.
Anyway, before anyone else is suggesting some other magic attribute extension
to the LUN value,
why not leave it as it is and just have it serving this one purpose of being a
unique number ?
(yeah, yeah I know there's already some meaning behind the 4 levels)
Just my 2 cents !
Cheers Swen
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
