On Tue, 2013-06-25 at 20:55 +, Love, Robert W wrote:
The following changes since commit 1e876e3b1a9df25bb04682b0d48aaa7e8ae1fc82:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2013-06-25
09:08:07 -1000)
are available in the git repository
This is a set of seven bug fixes. Several fcoe fixes for locking
problems, initiator issues and a VLAN API change, all of which could
eventually lead to data corruption, one fix for a qla2xxx locking
problem which could lead to multiple completions of the same request
(and subsequent data
Pci core has been saved pm cap register offset by pdev-pm_cap in pci_pm_init()
in init path. So we can use pdev-pm_cap instead of using
pci_find_capability(pdev, PCI_CAP_ID_PM) for better performance and simplified
code.
Acked-by: Lindar Liu lindar_...@usish.com
Tested-by: Lindar Liu
The eh_deadline changes allow for a significant improvement
in multipath failover time. It works very well in our testing.
I do have a few corrections, see below:
On Mon, 2013-06-10 at 13:11 +0200, Hannes Reinecke wrote:
This patchs adds an 'eh_deadline' attribute to the scsi
host which limits
Fix a few issues related to SCSI device removal:
- Fix a race between starved list processing and device removal that
can trigger a kernel oops.
- Avoid that __scsi_remove_device() is called twice for the same SCSI
device, which also can cause a kernel oops.
- Restrict the SCSI device state
From: James Bottomley jbottom...@parallels.com
scsi_run_queue() examines all SCSI devices that are present on
the starved list. Since scsi_run_queue() unlocks the SCSI host
lock a SCSI device can get removed after it has been removed
from the starved list and before its queue is run. Protect
If something goes wrong during LUN scanning, e.g. a transport layer
failure occurs, then __scsi_remove_device() can get invoked by the
LUN scanning code for a SCSI device in state SDEV_CREATED_BLOCK. If
this happens then the SCSI device has not yet been added to sysfs
(is_visible == 0). Make sure
Restrict the SCSI device state changes allowd via sysfs to the
OFFLINERUNNING transitions. Other transitions may confuse
the SCSI mid-layer. As an example, changing the state of a SCSI
device via sysfs into cancel or deleted prevents removal of
a SCSI device by scsi_remove_host().
Signed-off-by:
Since it is not allowed to invoke scsi_remove_host() with interrupts
disabled, avoid saving and restoring the interrupt state inside
scsi_remove_host(). This patch does not change the functionality of
the function scsi_remove_host().
Signed-off-by: Bart Van Assche bvanass...@acm.org
Acked-by:
Make concurrent invocations of scsi_device_set_state() safe.
Signed-off-by: Bart Van Assche bvanass...@acm.org
Acked-by: Hannes Reinecke h...@suse.de
Cc: James Bottomley jbottom...@parallels.com
Cc: Tejun Heo t...@kernel.org
Cc: Mike Christie micha...@cs.wisc.edu
---
drivers/scsi/scsi_error.c |
Disallow the SDEV_TRANSPORT_OFFLINE to SDEV_CANCEL transition such
that no I/O is sent to devices for which the transport is offline.
Notes:
- Functions like sd_shutdown() use scsi_execute_req() and hence
set the REQ_PREEMPT flag. Such requests are passed to the LLD
queuecommand callback in
On Wed 26 Jun 2013 11:14:02 PM PDT, James Bottomley wrote:
On Tue, 2013-06-25 at 20:55 +, Love, Robert W wrote:
The following changes since commit 1e876e3b1a9df25bb04682b0d48aaa7e8ae1fc82:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2013-06-25
On 06/23/2013 02:29 PM, Linus Torvalds wrote:
You could try to do that either *in* the idle thread (which would take
the context switch overhead - maybe negating some of the advantages),
or alternatively hook into the scheduler idle logic before actually
doing the switch.
But anything that
On 06/20/2013 04:17 PM, Matthew Wilcox wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4527,6 +4527,36 @@ long __sched io_schedule_timeout(long timeout)
return ret;
}
+/*
+ * Wait for an I/O to complete against this backing_dev_info. If the
+ * task exhausts its
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Robert Love
15 matches
Mail list logo
