From: Greg Kroah-Hartman Date: Wed, 6 Mar 2013 06:31:32 +0000 (+0800) Subject: 3.4-stable patches X-Git-Tag: v3.8.3~33 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2645a198bc145bc1dbcb7bcec09d6dd6503c3522;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: ath9k-fix-rssi-dummy-marker-value.patch ath9k_hw-improve-reset-reliability-after-errors.patch md-fix-two-bugs-when-attempting-to-resize-raid0-array.patch md-protect-against-crash-upon-fsync-on-ro-array.patch md-raid0-fix-error-return-from-create_stripe_zones.patch --- diff --git a/queue-3.4/ath9k-fix-rssi-dummy-marker-value.patch b/queue-3.4/ath9k-fix-rssi-dummy-marker-value.patch new file mode 100644 index 00000000000..142525114e7 --- /dev/null +++ b/queue-3.4/ath9k-fix-rssi-dummy-marker-value.patch @@ -0,0 +1,34 @@ +From a3d63cadbad97671d740a9698acc2c95d1ca6e79 Mon Sep 17 00:00:00 2001 +From: Felix Fietkau +Date: Fri, 22 Feb 2013 21:09:17 +0100 +Subject: ath9k: fix RSSI dummy marker value + +From: Felix Fietkau + +commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream. + +RSSI is being stored internally as s8 in several places. The indication +of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been +set to 127, but ended up being set to 0x127 because of a code cleanup +mistake. This could lead to invalid signal strength values in a few +places. + +Signed-off-by: Felix Fietkau +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/common.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath/ath9k/common.h ++++ b/drivers/net/wireless/ath/ath9k/common.h +@@ -35,7 +35,7 @@ + #define WME_AC_BK 3 + #define WME_NUM_AC 4 + +-#define ATH_RSSI_DUMMY_MARKER 0x127 ++#define ATH_RSSI_DUMMY_MARKER 127 + #define ATH_RSSI_LPF_LEN 10 + #define RSSI_LPF_THRESHOLD -20 + #define ATH_RSSI_EP_MULTIPLIER (1<<7) diff --git a/queue-3.4/ath9k_hw-improve-reset-reliability-after-errors.patch b/queue-3.4/ath9k_hw-improve-reset-reliability-after-errors.patch new file mode 100644 index 00000000000..4603b7f1c4d --- /dev/null +++ b/queue-3.4/ath9k_hw-improve-reset-reliability-after-errors.patch @@ -0,0 +1,42 @@ +From 3412f2f086ea7531378fabe756bd4a1109994ae6 Mon Sep 17 00:00:00 2001 +From: Felix Fietkau +Date: Mon, 25 Feb 2013 20:51:07 +0100 +Subject: ath9k_hw: improve reset reliability after errors + +From: Felix Fietkau + +commit 3412f2f086ea7531378fabe756bd4a1109994ae6 upstream. + +On many different chips, important aspects of the MAC state are not +fully cleared by a warm reset. This can show up as tx/rx hangs, those +annoying "DMA failed to stop in 10 ms..." messages or other quirks. + +On AR933x, the chip can occasionally get stuck in a way that only a +driver unload/reload or a reboot would bring it back to life. + +With this patch, a full reset is issued when bringing the chip out of +FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down +properly. This makes the DMA related error messages disappear completely +in my tests on AR933x, and the chip does not get stuck anymore. + +Signed-off-by: Felix Fietkau +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/hw.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath/ath9k/hw.c ++++ b/drivers/net/wireless/ath/ath9k/hw.c +@@ -1404,7 +1404,9 @@ static bool ath9k_hw_chip_reset(struct a + reset_type = ATH9K_RESET_POWER_ON; + else + reset_type = ATH9K_RESET_COLD; +- } ++ } else if (ah->chip_fullsleep || REG_READ(ah, AR_Q_TXE) || ++ (REG_READ(ah, AR_CR) & AR_CR_RXE)) ++ reset_type = ATH9K_RESET_COLD; + + if (!ath9k_hw_set_reset_reg(ah, reset_type)) + return false; diff --git a/queue-3.4/md-fix-two-bugs-when-attempting-to-resize-raid0-array.patch b/queue-3.4/md-fix-two-bugs-when-attempting-to-resize-raid0-array.patch new file mode 100644 index 00000000000..f3261d770c8 --- /dev/null +++ b/queue-3.4/md-fix-two-bugs-when-attempting-to-resize-raid0-array.patch @@ -0,0 +1,65 @@ +From a64685399181780998281fe07309a94b25dd24c3 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Thu, 21 Feb 2013 14:33:17 +1100 +Subject: md: fix two bugs when attempting to resize RAID0 array. + +From: NeilBrown + +commit a64685399181780998281fe07309a94b25dd24c3 upstream. + +You cannot resize a RAID0 array (in terms of making the devices +bigger), but the code doesn't entirely stop you. +So: + + disable setting of the available size on each device for + RAID0 and Linear devices. This must not change as doing so + can change the effective layout of data. + + Make sure that the size that raid0_size() reports is accurate, + but rounding devices sizes to chunk sizes. As the device sizes + cannot change now, this isn't so important, but it is best to be + safe. + +Without this change: + mdadm --grow /dev/md0 -z max + mdadm --grow /dev/md0 -Z max + then read to the end of the array + +can cause a BUG in a RAID0 array. + +These bugs have been present ever since it became possible +to resize any device, which is a long time. So the fix is +suitable for any -stable kerenl. + +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 3 +++ + drivers/md/raid0.c | 3 ++- + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -2886,6 +2886,9 @@ rdev_size_store(struct md_rdev *rdev, co + } else if (!sectors) + sectors = (i_size_read(rdev->bdev->bd_inode) >> 9) - + rdev->data_offset; ++ if (!my_mddev->pers->resize) ++ /* Cannot change size for RAID0 or Linear etc */ ++ return -EINVAL; + } + if (sectors < my_mddev->dev_sectors) + return -EINVAL; /* component must fit device */ +--- a/drivers/md/raid0.c ++++ b/drivers/md/raid0.c +@@ -402,7 +402,8 @@ static sector_t raid0_size(struct mddev + "%s does not support generic reshape\n", __func__); + + rdev_for_each(rdev, mddev) +- array_sectors += rdev->sectors; ++ array_sectors += (rdev->sectors & ++ ~(sector_t)(mddev->chunk_sectors-1)); + + return array_sectors; + } diff --git a/queue-3.4/md-protect-against-crash-upon-fsync-on-ro-array.patch b/queue-3.4/md-protect-against-crash-upon-fsync-on-ro-array.patch new file mode 100644 index 00000000000..2ebd7853e4b --- /dev/null +++ b/queue-3.4/md-protect-against-crash-upon-fsync-on-ro-array.patch @@ -0,0 +1,45 @@ +From bbfa57c0f2243a7c31fd248d22e9861a2802cad5 Mon Sep 17 00:00:00 2001 +From: Sebastian Riemer +Date: Thu, 21 Feb 2013 13:28:09 +1100 +Subject: md: protect against crash upon fsync on ro array + +From: Sebastian Riemer + +commit bbfa57c0f2243a7c31fd248d22e9861a2802cad5 upstream. + +If an fsync occurs on a read-only array, we need to send a +completion for the IO and may not increment the active IO count. +Otherwise, we hit a bug trace and can't stop the MD array anymore. + +By advice of Christoph Hellwig we return success upon a flush +request but we return -EROFS for other writes. +We detect flush requests by checking if the bio has zero sectors. + +This patch is suitable to any -stable kernel to which it applies. + +Signed-off-by: Sebastian Riemer +Cc: Christoph Hellwig +Cc: Ben Hutchings +Cc: NeilBrown +Reported-by: Ben Hutchings +Acked-by: Paul Menzel +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -344,6 +344,10 @@ static void md_make_request(struct reque + bio_io_error(bio); + return; + } ++ if (mddev->ro == 1 && unlikely(rw == WRITE)) { ++ bio_endio(bio, bio_sectors(bio) == 0 ? 0 : -EROFS); ++ return; ++ } + smp_rmb(); /* Ensure implications of 'active' are visible */ + rcu_read_lock(); + if (mddev->suspended) { diff --git a/queue-3.4/md-raid0-fix-error-return-from-create_stripe_zones.patch b/queue-3.4/md-raid0-fix-error-return-from-create_stripe_zones.patch new file mode 100644 index 00000000000..21170dd862e --- /dev/null +++ b/queue-3.4/md-raid0-fix-error-return-from-create_stripe_zones.patch @@ -0,0 +1,40 @@ +From 58ebb34c49fcfcaa029e4b1c1453d92583900f9a Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Thu, 21 Feb 2013 15:36:38 +1100 +Subject: md: raid0: fix error return from create_stripe_zones. + +From: NeilBrown + +commit 58ebb34c49fcfcaa029e4b1c1453d92583900f9a upstream. + +Create_stripe_zones returns an error slightly differently to +raid0_run and to raid0_takeover_*. + +The error returned used by the second was wrong and an error would +result in mddev->private being set to NULL and sooner or later a +crash. + +So never return NULL, return ERR_PTR(err), not NULL from +create_stripe_zones. + +This bug has been present since 2.6.35 so the fix is suitable +for any kernel since then. + +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid0.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/md/raid0.c ++++ b/drivers/md/raid0.c +@@ -280,7 +280,7 @@ abort: + kfree(conf->strip_zone); + kfree(conf->devlist); + kfree(conf); +- *private_conf = NULL; ++ *private_conf = ERR_PTR(err); + return err; + } + diff --git a/queue-3.4/series b/queue-3.4/series index 2e795103eb2..2475f95a016 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -11,3 +11,8 @@ sunrpc-don-t-start-the-retransmission-timer-when-out-of-socket-space.patch ata_piix-reenable-ms-virtual-pc-guests.patch hw_random-make-buffer-usable-in-scatterlist.patch mwifiex-correct-sleep-delay-counter.patch +ath9k-fix-rssi-dummy-marker-value.patch +ath9k_hw-improve-reset-reliability-after-errors.patch +md-protect-against-crash-upon-fsync-on-ro-array.patch +md-fix-two-bugs-when-attempting-to-resize-raid0-array.patch +md-raid0-fix-error-return-from-create_stripe_zones.patch