License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 21:07:57 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
2008-06-10 23:20:56 +07:00
|
|
|
* zfcp device driver
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
2008-06-10 23:20:56 +07:00
|
|
|
* Registration and callback for the s390 common I/O layer.
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
2012-07-20 16:15:04 +07:00
|
|
|
* Copyright IBM Corp. 2002, 2010
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
|
|
|
|
2008-12-25 19:39:53 +07:00
|
|
|
#define KMSG_COMPONENT "zfcp"
|
|
|
|
#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
|
|
|
|
|
2011-07-30 14:25:15 +07:00
|
|
|
#include <linux/module.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include "zfcp_ext.h"
|
2010-02-17 17:18:50 +07:00
|
|
|
#include "zfcp_reqlist.h"
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-05-15 18:18:21 +07:00
|
|
|
#define ZFCP_MODEL_PRIV 0x4
|
|
|
|
|
2009-11-24 22:54:00 +07:00
|
|
|
static DEFINE_SPINLOCK(zfcp_ccw_adapter_ref_lock);
|
|
|
|
|
|
|
|
struct zfcp_adapter *zfcp_ccw_adapter_by_cdev(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
struct zfcp_adapter *adapter;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
adapter = dev_get_drvdata(&cdev->dev);
|
|
|
|
if (adapter)
|
|
|
|
kref_get(&adapter->ref);
|
|
|
|
spin_unlock_irqrestore(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
return adapter;
|
|
|
|
}
|
|
|
|
|
|
|
|
void zfcp_ccw_adapter_put(struct zfcp_adapter *adapter)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
kref_put(&adapter->ref, zfcp_adapter_release);
|
|
|
|
spin_unlock_irqrestore(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
}
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
/**
|
|
|
|
* zfcp_ccw_activate - activate adapter and wait for it to finish
|
|
|
|
* @cdev: pointer to belonging ccw device
|
|
|
|
* @clear: Status flags to clear.
|
|
|
|
* @tag: s390dbf trace record tag
|
|
|
|
*/
|
|
|
|
static int zfcp_ccw_activate(struct ccw_device *cdev, int clear, char *tag)
|
2009-06-16 15:30:34 +07:00
|
|
|
{
|
2009-11-24 22:54:00 +07:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2009-06-16 15:30:34 +07:00
|
|
|
|
2009-08-18 20:43:27 +07:00
|
|
|
if (!adapter)
|
|
|
|
return 0;
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
zfcp_erp_clear_adapter_status(adapter, clear);
|
2010-09-08 19:40:01 +07:00
|
|
|
zfcp_erp_set_adapter_status(adapter, ZFCP_STATUS_COMMON_RUNNING);
|
2009-06-16 15:30:34 +07:00
|
|
|
zfcp_erp_adapter_reopen(adapter, ZFCP_STATUS_COMMON_ERP_FAILED,
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
tag);
|
zfcp: auto port scan resiliency
This patch improves the Fibre Channel port scan behaviour of the zfcp lldd.
Without it the zfcp device driver may churn up the storage area network by
excessive scanning and scan bursts, particularly in big virtual server
environments, potentially resulting in interference of virtual servers and
reduced availability of storage connectivity.
The two main issues as to the zfcp device drivers automatic port scan in
virtual server environments are frequency and simultaneity.
On the one hand, there is no point in allowing lots of ports scans
in a row. It makes sense, though, to make sure that a scan is conducted
eventually if there has been any indication for potential SAN changes.
On the other hand, lots of virtual servers receiving the same indication
for a SAN change had better not attempt to conduct a scan instantly,
that is, at the same time.
Hence this patch has a two-fold approach for better port scanning:
the introduction of a rate limit to amend frequency issues, and the
introduction of a short random backoff to amend simultaneity issues.
Both approaches boil down to deferred port scans, with delays
comprising parts for both approaches.
The new port scan behaviour is summarised best by:
NEW: NEW:
no_auto_port_rescan random rate flush
backoff limit =wait
adapter resume/thaw yes yes no yes*
adapter online (user) no yes no yes*
port rescan (user) no no no yes
adapter recovery (user) yes yes yes no
adapter recovery (other) yes yes yes no
incoming ELS yes yes yes no
incoming ELS lost yes yes yes no
Implementation is straight-forward by converting an existing worker to
a delayed worker. But care is needed whenever that worker is going to be
flushed (in order to make sure work has been completed), since a flush
operation cancels the timer set up for deferred execution (see * above).
There is a small race window whenever a port scan work starts
running up to the point in time of storing the time stamp for that port
scan. The impact is negligible. Closing that gap isn't trivial, though, and
would the destroy the beauty of a simple work-to-delayed-work conversion.
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-11-13 20:59:48 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to scan ports here, with some random backoff and without
|
|
|
|
* rate limit. Recovery has already scheduled a port scan for us,
|
|
|
|
* but with both random delay and rate limit. Nevertheless we get
|
|
|
|
* what we want here by flushing the scheduled work after sleeping
|
|
|
|
* an equivalent random time.
|
|
|
|
* Let the port scan random delay elapse first. If recovery finishes
|
|
|
|
* up to that point in time, that would be perfect for both recovery
|
|
|
|
* and port scan. If not, i.e. recovery takes ages, there was no
|
|
|
|
* point in waiting a random delay on top of the time consumed by
|
|
|
|
* recovery.
|
|
|
|
*/
|
|
|
|
msleep(zfcp_fc_port_scan_backoff());
|
2009-06-16 15:30:34 +07:00
|
|
|
zfcp_erp_wait(adapter);
|
zfcp: auto port scan resiliency
This patch improves the Fibre Channel port scan behaviour of the zfcp lldd.
Without it the zfcp device driver may churn up the storage area network by
excessive scanning and scan bursts, particularly in big virtual server
environments, potentially resulting in interference of virtual servers and
reduced availability of storage connectivity.
The two main issues as to the zfcp device drivers automatic port scan in
virtual server environments are frequency and simultaneity.
On the one hand, there is no point in allowing lots of ports scans
in a row. It makes sense, though, to make sure that a scan is conducted
eventually if there has been any indication for potential SAN changes.
On the other hand, lots of virtual servers receiving the same indication
for a SAN change had better not attempt to conduct a scan instantly,
that is, at the same time.
Hence this patch has a two-fold approach for better port scanning:
the introduction of a rate limit to amend frequency issues, and the
introduction of a short random backoff to amend simultaneity issues.
Both approaches boil down to deferred port scans, with delays
comprising parts for both approaches.
The new port scan behaviour is summarised best by:
NEW: NEW:
no_auto_port_rescan random rate flush
backoff limit =wait
adapter resume/thaw yes yes no yes*
adapter online (user) no yes no yes*
port rescan (user) no no no yes
adapter recovery (user) yes yes yes no
adapter recovery (other) yes yes yes no
incoming ELS yes yes yes no
incoming ELS lost yes yes yes no
Implementation is straight-forward by converting an existing worker to
a delayed worker. But care is needed whenever that worker is going to be
flushed (in order to make sure work has been completed), since a flush
operation cancels the timer set up for deferred execution (see * above).
There is a small race window whenever a port scan work starts
running up to the point in time of storing the time stamp for that port
scan. The impact is negligible. Closing that gap isn't trivial, though, and
would the destroy the beauty of a simple work-to-delayed-work conversion.
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-11-13 20:59:48 +07:00
|
|
|
flush_delayed_work(&adapter->scan_work);
|
2009-06-16 15:30:34 +07:00
|
|
|
|
2009-11-24 22:54:00 +07:00
|
|
|
zfcp_ccw_adapter_put(adapter);
|
|
|
|
|
2009-06-16 15:30:34 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-05-15 18:18:21 +07:00
|
|
|
static struct ccw_device_id zfcp_ccw_device_id[] = {
|
|
|
|
{ CCW_DEVICE_DEVTYPE(0x1731, 0x3, 0x1732, 0x3) },
|
|
|
|
{ CCW_DEVICE_DEVTYPE(0x1731, 0x3, 0x1732, ZFCP_MODEL_PRIV) },
|
|
|
|
{},
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(ccw, zfcp_ccw_device_id);
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/**
|
|
|
|
* zfcp_ccw_probe - probe function of zfcp driver
|
2009-11-24 22:54:00 +07:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
2009-08-18 20:43:27 +07:00
|
|
|
* This function gets called by the common i/o layer for each FCP
|
|
|
|
* device found on the current system. This is only a stub to make cio
|
|
|
|
* work: To only allocate adapter resources for devices actually used,
|
|
|
|
* the allocation is deferred to the first call to ccw_set_online.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2009-11-24 22:54:00 +07:00
|
|
|
static int zfcp_ccw_probe(struct ccw_device *cdev)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2009-08-18 20:43:27 +07:00
|
|
|
return 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* zfcp_ccw_remove - remove function of zfcp driver
|
2009-11-24 22:54:00 +07:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer and removes an adapter
|
|
|
|
* from the system. Task of this function is to get rid of all units and
|
|
|
|
* ports that belong to this adapter. And in addition all resources of this
|
|
|
|
* adapter will be freed too.
|
|
|
|
*/
|
2009-11-24 22:54:00 +07:00
|
|
|
static void zfcp_ccw_remove(struct ccw_device *cdev)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct zfcp_adapter *adapter;
|
|
|
|
struct zfcp_port *port, *p;
|
|
|
|
struct zfcp_unit *unit, *u;
|
2008-10-01 17:42:20 +07:00
|
|
|
LIST_HEAD(unit_remove_lh);
|
|
|
|
LIST_HEAD(port_remove_lh);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-11-24 22:54:00 +07:00
|
|
|
ccw_device_set_offline(cdev);
|
2009-09-24 15:23:24 +07:00
|
|
|
|
2009-11-24 22:54:00 +07:00
|
|
|
adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2009-11-24 22:53:58 +07:00
|
|
|
if (!adapter)
|
|
|
|
return;
|
|
|
|
|
|
|
|
write_lock_irq(&adapter->port_list_lock);
|
|
|
|
list_for_each_entry_safe(port, p, &adapter->port_list, list) {
|
|
|
|
write_lock(&port->unit_list_lock);
|
2009-11-24 22:54:05 +07:00
|
|
|
list_for_each_entry_safe(unit, u, &port->unit_list, list)
|
2009-11-24 22:53:58 +07:00
|
|
|
list_move(&unit->list, &unit_remove_lh);
|
|
|
|
write_unlock(&port->unit_list_lock);
|
|
|
|
list_move(&port->list, &port_remove_lh);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2009-11-24 22:53:58 +07:00
|
|
|
write_unlock_irq(&adapter->port_list_lock);
|
2009-11-24 22:54:00 +07:00
|
|
|
zfcp_ccw_adapter_put(adapter); /* put from zfcp_ccw_adapter_by_cdev */
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-11-24 22:53:59 +07:00
|
|
|
list_for_each_entry_safe(unit, u, &unit_remove_lh, list)
|
2013-04-26 21:13:49 +07:00
|
|
|
device_unregister(&unit->dev);
|
2009-11-24 22:53:59 +07:00
|
|
|
|
|
|
|
list_for_each_entry_safe(port, p, &port_remove_lh, list)
|
2013-04-26 21:13:48 +07:00
|
|
|
device_unregister(&port->dev);
|
2009-11-24 22:53:59 +07:00
|
|
|
|
2009-11-24 22:54:00 +07:00
|
|
|
zfcp_adapter_unregister(adapter);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* zfcp_ccw_set_online - set_online function of zfcp driver
|
2009-11-24 22:54:00 +07:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
2009-08-18 20:43:27 +07:00
|
|
|
* This function gets called by the common i/o layer and sets an
|
|
|
|
* adapter into state online. The first call will allocate all
|
|
|
|
* adapter resources that will be retained until the device is removed
|
|
|
|
* via zfcp_ccw_remove.
|
|
|
|
*
|
|
|
|
* Setting an fcp device online means that it will be registered with
|
|
|
|
* the SCSI stack, that the QDIO queues will be set up and that the
|
|
|
|
* adapter will be opened.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2009-11-24 22:54:00 +07:00
|
|
|
static int zfcp_ccw_set_online(struct ccw_device *cdev)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2009-11-24 22:54:00 +07:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-08-18 20:43:27 +07:00
|
|
|
if (!adapter) {
|
2009-11-24 22:54:00 +07:00
|
|
|
adapter = zfcp_adapter_enqueue(cdev);
|
|
|
|
|
|
|
|
if (IS_ERR(adapter)) {
|
|
|
|
dev_err(&cdev->dev,
|
2009-08-18 20:43:27 +07:00
|
|
|
"Setting up data structures for the "
|
|
|
|
"FCP adapter failed\n");
|
2009-11-24 22:54:00 +07:00
|
|
|
return PTR_ERR(adapter);
|
2009-08-18 20:43:27 +07:00
|
|
|
}
|
2009-11-24 22:54:00 +07:00
|
|
|
kref_get(&adapter->ref);
|
2009-08-18 20:43:27 +07:00
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2006-08-02 16:05:16 +07:00
|
|
|
/* initialize request counter */
|
2010-02-17 17:18:50 +07:00
|
|
|
BUG_ON(!zfcp_reqlist_isempty(adapter->req_list));
|
2006-08-02 16:05:16 +07:00
|
|
|
adapter->req_no = 0;
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
zfcp_ccw_activate(cdev, 0, "ccsonl1");
|
zfcp: auto port scan resiliency
This patch improves the Fibre Channel port scan behaviour of the zfcp lldd.
Without it the zfcp device driver may churn up the storage area network by
excessive scanning and scan bursts, particularly in big virtual server
environments, potentially resulting in interference of virtual servers and
reduced availability of storage connectivity.
The two main issues as to the zfcp device drivers automatic port scan in
virtual server environments are frequency and simultaneity.
On the one hand, there is no point in allowing lots of ports scans
in a row. It makes sense, though, to make sure that a scan is conducted
eventually if there has been any indication for potential SAN changes.
On the other hand, lots of virtual servers receiving the same indication
for a SAN change had better not attempt to conduct a scan instantly,
that is, at the same time.
Hence this patch has a two-fold approach for better port scanning:
the introduction of a rate limit to amend frequency issues, and the
introduction of a short random backoff to amend simultaneity issues.
Both approaches boil down to deferred port scans, with delays
comprising parts for both approaches.
The new port scan behaviour is summarised best by:
NEW: NEW:
no_auto_port_rescan random rate flush
backoff limit =wait
adapter resume/thaw yes yes no yes*
adapter online (user) no yes no yes*
port rescan (user) no no no yes
adapter recovery (user) yes yes yes no
adapter recovery (other) yes yes yes no
incoming ELS yes yes yes no
incoming ELS lost yes yes yes no
Implementation is straight-forward by converting an existing worker to
a delayed worker. But care is needed whenever that worker is going to be
flushed (in order to make sure work has been completed), since a flush
operation cancels the timer set up for deferred execution (see * above).
There is a small race window whenever a port scan work starts
running up to the point in time of storing the time stamp for that port
scan. The impact is negligible. Closing that gap isn't trivial, though, and
would the destroy the beauty of a simple work-to-delayed-work conversion.
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-11-13 20:59:48 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to scan ports here, always, with some random delay and
|
|
|
|
* without rate limit - basically what zfcp_ccw_activate() has
|
|
|
|
* achieved for us. Not quite! That port scan depended on
|
|
|
|
* !no_auto_port_rescan. So let's cover the no_auto_port_rescan
|
|
|
|
* case here to make sure a port scan is done unconditionally.
|
|
|
|
* Since zfcp_ccw_activate() has waited the desired random time,
|
|
|
|
* we can immediately schedule and flush a port scan for the
|
|
|
|
* remaining cases.
|
|
|
|
*/
|
2012-09-04 20:23:35 +07:00
|
|
|
zfcp_fc_inverse_conditional_port_scan(adapter);
|
zfcp: auto port scan resiliency
This patch improves the Fibre Channel port scan behaviour of the zfcp lldd.
Without it the zfcp device driver may churn up the storage area network by
excessive scanning and scan bursts, particularly in big virtual server
environments, potentially resulting in interference of virtual servers and
reduced availability of storage connectivity.
The two main issues as to the zfcp device drivers automatic port scan in
virtual server environments are frequency and simultaneity.
On the one hand, there is no point in allowing lots of ports scans
in a row. It makes sense, though, to make sure that a scan is conducted
eventually if there has been any indication for potential SAN changes.
On the other hand, lots of virtual servers receiving the same indication
for a SAN change had better not attempt to conduct a scan instantly,
that is, at the same time.
Hence this patch has a two-fold approach for better port scanning:
the introduction of a rate limit to amend frequency issues, and the
introduction of a short random backoff to amend simultaneity issues.
Both approaches boil down to deferred port scans, with delays
comprising parts for both approaches.
The new port scan behaviour is summarised best by:
NEW: NEW:
no_auto_port_rescan random rate flush
backoff limit =wait
adapter resume/thaw yes yes no yes*
adapter online (user) no yes no yes*
port rescan (user) no no no yes
adapter recovery (user) yes yes yes no
adapter recovery (other) yes yes yes no
incoming ELS yes yes yes no
incoming ELS lost yes yes yes no
Implementation is straight-forward by converting an existing worker to
a delayed worker. But care is needed whenever that worker is going to be
flushed (in order to make sure work has been completed), since a flush
operation cancels the timer set up for deferred execution (see * above).
There is a small race window whenever a port scan work starts
running up to the point in time of storing the time stamp for that port
scan. The impact is negligible. Closing that gap isn't trivial, though, and
would the destroy the beauty of a simple work-to-delayed-work conversion.
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-11-13 20:59:48 +07:00
|
|
|
flush_delayed_work(&adapter->scan_work);
|
2009-11-24 22:54:00 +07:00
|
|
|
zfcp_ccw_adapter_put(adapter);
|
|
|
|
return 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
* zfcp_ccw_offline_sync - shut down adapter and wait for it to finish
|
2009-11-24 22:54:00 +07:00
|
|
|
* @cdev: pointer to belonging ccw device
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
* @set: Status flags to set.
|
|
|
|
* @tag: s390dbf trace record tag
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer and sets an adapter
|
2007-05-09 16:01:24 +07:00
|
|
|
* into state offline.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
static int zfcp_ccw_offline_sync(struct ccw_device *cdev, int set, char *tag)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2009-11-24 22:54:00 +07:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
|
|
|
|
|
|
|
if (!adapter)
|
|
|
|
return 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
zfcp_erp_set_adapter_status(adapter, set);
|
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, tag);
|
2005-04-17 05:20:36 +07:00
|
|
|
zfcp_erp_wait(adapter);
|
2009-11-24 22:54:00 +07:00
|
|
|
|
|
|
|
zfcp_ccw_adapter_put(adapter);
|
2005-04-17 05:20:36 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
/**
|
|
|
|
* zfcp_ccw_set_offline - set_offline function of zfcp driver
|
|
|
|
* @cdev: pointer to belonging ccw device
|
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer and sets an adapter
|
|
|
|
* into state offline.
|
|
|
|
*/
|
|
|
|
static int zfcp_ccw_set_offline(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
return zfcp_ccw_offline_sync(cdev, 0, "ccsoff1");
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/**
|
2008-06-10 23:20:56 +07:00
|
|
|
* zfcp_ccw_notify - ccw notify function
|
2009-11-24 22:54:00 +07:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 05:20:36 +07:00
|
|
|
* @event: indicates if adapter was detached or attached
|
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer if an adapter has gone
|
|
|
|
* or reappeared.
|
|
|
|
*/
|
2009-11-24 22:54:00 +07:00
|
|
|
static int zfcp_ccw_notify(struct ccw_device *cdev, int event)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2009-11-24 22:54:00 +07:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
|
|
|
|
|
|
|
if (!adapter)
|
|
|
|
return 1;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
switch (event) {
|
|
|
|
case CIO_GONE:
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
if (atomic_read(&adapter->status) &
|
|
|
|
ZFCP_STATUS_ADAPTER_SUSPENDED) { /* notification ignore */
|
|
|
|
zfcp_dbf_hba_basic("ccnigo1", adapter);
|
|
|
|
break;
|
|
|
|
}
|
2009-11-24 22:54:00 +07:00
|
|
|
dev_warn(&cdev->dev, "The FCP device has been detached\n");
|
2010-12-02 21:16:16 +07:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccnoti1");
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
|
|
|
case CIO_NO_PATH:
|
2009-11-24 22:54:00 +07:00
|
|
|
dev_warn(&cdev->dev,
|
2008-10-01 17:42:15 +07:00
|
|
|
"The CHPID for the FCP device is offline\n");
|
2010-12-02 21:16:16 +07:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccnoti2");
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
|
|
|
case CIO_OPER:
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
if (atomic_read(&adapter->status) &
|
|
|
|
ZFCP_STATUS_ADAPTER_SUSPENDED) { /* notification ignore */
|
|
|
|
zfcp_dbf_hba_basic("ccniop1", adapter);
|
|
|
|
break;
|
|
|
|
}
|
2009-11-24 22:54:00 +07:00
|
|
|
dev_info(&cdev->dev, "The FCP device is operational again\n");
|
2010-09-08 19:40:01 +07:00
|
|
|
zfcp_erp_set_adapter_status(adapter,
|
|
|
|
ZFCP_STATUS_COMMON_RUNNING);
|
2008-04-18 17:51:55 +07:00
|
|
|
zfcp_erp_adapter_reopen(adapter, ZFCP_STATUS_COMMON_ERP_FAILED,
|
2010-12-02 21:16:16 +07:00
|
|
|
"ccnoti4");
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
2009-04-01 00:16:05 +07:00
|
|
|
case CIO_BOXED:
|
2009-11-24 22:54:00 +07:00
|
|
|
dev_warn(&cdev->dev, "The FCP device did not respond within "
|
|
|
|
"the specified time\n");
|
2010-12-02 21:16:16 +07:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccnoti5");
|
2009-04-01 00:16:05 +07:00
|
|
|
break;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2009-11-24 22:54:00 +07:00
|
|
|
|
|
|
|
zfcp_ccw_adapter_put(adapter);
|
2005-04-17 05:20:36 +07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-06-10 23:20:56 +07:00
|
|
|
* zfcp_ccw_shutdown - handle shutdown from cio
|
|
|
|
* @cdev: device for adapter to shutdown.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2008-06-10 23:20:56 +07:00
|
|
|
static void zfcp_ccw_shutdown(struct ccw_device *cdev)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2009-11-24 22:54:00 +07:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-09-24 15:23:23 +07:00
|
|
|
if (!adapter)
|
2009-11-24 22:54:00 +07:00
|
|
|
return;
|
2009-09-24 15:23:23 +07:00
|
|
|
|
2010-12-02 21:16:16 +07:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccshut1");
|
2005-04-17 05:20:36 +07:00
|
|
|
zfcp_erp_wait(adapter);
|
2009-08-18 20:43:27 +07:00
|
|
|
zfcp_erp_thread_kill(adapter);
|
2009-11-24 22:54:00 +07:00
|
|
|
|
|
|
|
zfcp_ccw_adapter_put(adapter);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
static int zfcp_ccw_suspend(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
zfcp_ccw_offline_sync(cdev, ZFCP_STATUS_ADAPTER_SUSPENDED, "ccsusp1");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int zfcp_ccw_thaw(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
/* trace records for thaw and final shutdown during suspend
|
|
|
|
can only be found in system dump until the end of suspend
|
|
|
|
but not after resume because it's based on the memory image
|
|
|
|
right after the very first suspend (freeze) callback */
|
|
|
|
zfcp_ccw_activate(cdev, 0, "ccthaw1");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int zfcp_ccw_resume(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
zfcp_ccw_activate(cdev, ZFCP_STATUS_ADAPTER_SUSPENDED, "ccresu1");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-24 15:23:22 +07:00
|
|
|
struct ccw_driver zfcp_ccw_driver = {
|
2011-03-23 16:16:02 +07:00
|
|
|
.driver = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.name = "zfcp",
|
|
|
|
},
|
2008-06-10 23:20:56 +07:00
|
|
|
.ids = zfcp_ccw_device_id,
|
|
|
|
.probe = zfcp_ccw_probe,
|
|
|
|
.remove = zfcp_ccw_remove,
|
|
|
|
.set_online = zfcp_ccw_set_online,
|
|
|
|
.set_offline = zfcp_ccw_set_offline,
|
|
|
|
.notify = zfcp_ccw_notify,
|
|
|
|
.shutdown = zfcp_ccw_shutdown,
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 20:23:32 +07:00
|
|
|
.freeze = zfcp_ccw_suspend,
|
|
|
|
.thaw = zfcp_ccw_thaw,
|
|
|
|
.restore = zfcp_ccw_resume,
|
2008-06-10 23:20:56 +07:00
|
|
|
};
|