From: Greg Kroah-Hartman Date: Wed, 11 Aug 2010 00:31:55 +0000 (-0700) Subject: .27 patches X-Git-Tag: v2.6.32.19~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=707e29772c3df327c7acd1512a6fe3c0398e99de;p=thirdparty%2Fkernel%2Fstable-queue.git .27 patches --- diff --git a/queue-2.6.27/md-raid10-fix-deadlock-with-unaligned-read-during-resync.patch b/queue-2.6.27/md-raid10-fix-deadlock-with-unaligned-read-during-resync.patch new file mode 100644 index 00000000000..5a7eed15e54 --- /dev/null +++ b/queue-2.6.27/md-raid10-fix-deadlock-with-unaligned-read-during-resync.patch @@ -0,0 +1,59 @@ +From 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Sat, 7 Aug 2010 21:17:00 +1000 +Subject: md/raid10: fix deadlock with unaligned read during resync + +From: NeilBrown + +commit 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 upstream. + +If the 'bio_split' path in raid10-read is used while +resync/recovery is happening it is possible to deadlock. +Fix this be elevating ->nr_waiting for the duration of both +parts of the split request. + +This fixes a bug that has been present since 2.6.22 +but has only started manifesting recently for unknown reasons. +It is suitable for and -stable since then. + +Reported-by: Justin Bronder +Tested-by: Justin Bronder +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid10.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -818,11 +818,29 @@ static int make_request(struct request_q + */ + bp = bio_split(bio, bio_split_pool, + chunk_sects - (bio->bi_sector & (chunk_sects - 1)) ); ++ ++ /* Each of these 'make_request' calls will call 'wait_barrier'. ++ * If the first succeeds but the second blocks due to the resync ++ * thread raising the barrier, we will deadlock because the ++ * IO to the underlying device will be queued in generic_make_request ++ * and will never complete, so will never reduce nr_pending. ++ * So increment nr_waiting here so no new raise_barriers will ++ * succeed, and so the second wait_barrier cannot block. ++ */ ++ spin_lock_irq(&conf->resync_lock); ++ conf->nr_waiting++; ++ spin_unlock_irq(&conf->resync_lock); ++ + if (make_request(q, &bp->bio1)) + generic_make_request(&bp->bio1); + if (make_request(q, &bp->bio2)) + generic_make_request(&bp->bio2); + ++ spin_lock_irq(&conf->resync_lock); ++ conf->nr_waiting--; ++ wake_up(&conf->wait_barrier); ++ spin_unlock_irq(&conf->resync_lock); ++ + bio_pair_release(bp); + return 0; + bad_map: diff --git a/queue-2.6.27/pci-disable-msi-on-via-k8m800.patch b/queue-2.6.27/pci-disable-msi-on-via-k8m800.patch new file mode 100644 index 00000000000..89ef6ef29c4 --- /dev/null +++ b/queue-2.6.27/pci-disable-msi-on-via-k8m800.patch @@ -0,0 +1,29 @@ +From 549e15611b4ac1de51ef0e0a79c2704f50a638a2 Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Sun, 23 May 2010 10:22:55 +0200 +Subject: PCI: disable MSI on VIA K8M800 + +From: Tejun Heo + +commit 549e15611b4ac1de51ef0e0a79c2704f50a638a2 upstream. + +MSI delivery from on-board ahci controller doesn't work on K8M800. At +this point, it's unclear whether the culprit is with the ahci +controller or the host bridge. Given the track record and considering +the rather minimal impact of MSI, disabling it seems reasonable. + +Signed-off-by: Tejun Heo +Reported-by: Rainer Hurtado Navarro +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2115,6 +2115,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disabl + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3336, quirk_disable_all_msi); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3364, quirk_disable_all_msi); ++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8380_0, quirk_disable_all_msi); + + /* Disable MSI on chipsets that are known to not support it */ + static void __devinit quirk_disable_msi(struct pci_dev *dev) diff --git a/queue-2.6.27/series b/queue-2.6.27/series index 1c5bc93305d..70a4190175f 100644 --- a/queue-2.6.27/series +++ b/queue-2.6.27/series @@ -1 +1,4 @@ nvram-fix-write-beyond-end-condition-prove-to-gcc-copy-is-safe.patch +splice-fix-misuse-of-splice_f_nonblock.patch +pci-disable-msi-on-via-k8m800.patch +md-raid10-fix-deadlock-with-unaligned-read-during-resync.patch diff --git a/queue-2.6.27/splice-fix-misuse-of-splice_f_nonblock.patch b/queue-2.6.27/splice-fix-misuse-of-splice_f_nonblock.patch new file mode 100644 index 00000000000..92ec74ffbd7 --- /dev/null +++ b/queue-2.6.27/splice-fix-misuse-of-splice_f_nonblock.patch @@ -0,0 +1,46 @@ +From 6965031d331a642e31278fa1b5bd47f372ffdd5d Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Tue, 3 Aug 2010 12:48:50 +0200 +Subject: splice: fix misuse of SPLICE_F_NONBLOCK + +From: Miklos Szeredi + +commit 6965031d331a642e31278fa1b5bd47f372ffdd5d upstream. + +SPLICE_F_NONBLOCK is clearly documented to only affect blocking on the +pipe. In __generic_file_splice_read(), however, it causes an EAGAIN +if the page is currently being read. + +This makes it impossible to write an application that only wants +failure if the pipe is full. For example if the same process is +handling both ends of a pipe and isn't otherwise able to determine +whether a splice to the pipe will fill it or not. + +We could make the read non-blocking on O_NONBLOCK or some other splice +flag, but for now this is the simplest fix. + +Signed-off-by: Miklos Szeredi +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- a/fs/splice.c ++++ b/fs/splice.c +@@ -399,17 +399,7 @@ __generic_file_splice_read(struct file *in, loff_t *ppos, + * If the page isn't uptodate, we may need to start io on it + */ + if (!PageUptodate(page)) { +- /* +- * If in nonblock mode then dont block on waiting +- * for an in-flight io page +- */ +- if (flags & SPLICE_F_NONBLOCK) { +- if (!trylock_page(page)) { +- error = -EAGAIN; +- break; +- } +- } else +- lock_page(page); ++ lock_page(page); + + /* + * Page was truncated, or invalidated by the