From: Greg Kroah-Hartman Date: Sat, 28 Feb 2015 22:05:00 +0000 (-0800) Subject: 3.19-stable patches X-Git-Tag: v3.10.71~50 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=29142eb7f4c25bd0674dd9be0e7d470e545f3154;p=thirdparty%2Fkernel%2Fstable-queue.git 3.19-stable patches added patches: asoc-intel-sst-fix-firmware-name-size-handling.patch asoc-mioa701_wm9713-fix-speaker-event.patch asoc-rt5670-set-use_single_rw-flag-for-regmap.patch asoc-rt5677-fix-spi-dependency.patch bluetooth-ath3k-add-support-of-ar3012-bluetooth-13d3-3423-device.patch bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch bluetooth-btusb-add-broadcom-patchram-support-for-asustek-devices.patch bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch bluetooth-btusb-add-support-for-lite-on-04ca-broadcom-based-bcm43142.patch bluetooth-fix-reporting-invalid-rssi-for-le-devices.patch bluetooth-fix-valid-identity-address-check.patch fsnotify-fix-handling-of-renames-in-audit.patch hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch iwlwifi-mvm-always-use-mac-color-zero.patch iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch ksoftirqd-enable-irqs-and-call-cond_resched-before-poking-rcu.patch pci-fix-infinite-loop-with-rom-image-of-size-0.patch pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch random-fix-fast_mix-function.patch udf-check-length-of-extended-attributes-and-allocation-descriptors.patch xfs-ensure-buffer-types-are-set-correctly.patch xfs-inode-unlink-does-not-set-agi-buffer-type.patch xfs-only-trace-buffer-items-if-they-exist.patch xfs-set-buf-types-when-converting-extent-formats.patch xfs-set-superblock-buffer-type-correctly.patch --- diff --git a/queue-3.19/asoc-intel-sst-fix-firmware-name-size-handling.patch b/queue-3.19/asoc-intel-sst-fix-firmware-name-size-handling.patch new file mode 100644 index 00000000000..4e99dc4bac9 --- /dev/null +++ b/queue-3.19/asoc-intel-sst-fix-firmware-name-size-handling.patch @@ -0,0 +1,59 @@ +From 279e17ae81c17b40ae7a6c9e10f386a7aac7aa55 Mon Sep 17 00:00:00 2001 +From: Christian Engelmayer +Date: Sat, 7 Feb 2015 23:40:52 +0100 +Subject: ASoC: Intel: sst: Fix firmware name size handling + +From: Christian Engelmayer + +commit 279e17ae81c17b40ae7a6c9e10f386a7aac7aa55 upstream. + +Function sst_acpi_probe() uses plain strcpy for setting member firmware_name +of a struct intel_sst_drv from member firmware of a struct sst_machines. +Thereby the destination array has got a length of 20 byte while the source may +hold 32 byte. Since eg. commit 64b9c90b8600 ("ASoC: Intel: Fix BYTCR firmware +name") increased strings from "fw_sst_0f28.bin" to "intel/fw_sst_0f28.bin" +there is an actual possibility that the 20 byte array at the end of struct +intel_sst_drv is overrun. + +Thus increase the size of the destination and use the same define for both +structs. Detected by Coverity CID 1260087. + +Signed-off-by: Christian Engelmayer +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/intel/sst/sst.h | 3 ++- + sound/soc/intel/sst/sst_acpi.c | 2 +- + 2 files changed, 3 insertions(+), 2 deletions(-) + +--- a/sound/soc/intel/sst/sst.h ++++ b/sound/soc/intel/sst/sst.h +@@ -58,6 +58,7 @@ enum sst_algo_ops { + #define SST_BLOCK_TIMEOUT 1000 + + #define FW_SIGNATURE_SIZE 4 ++#define FW_NAME_SIZE 32 + + /* stream states */ + enum sst_stream_states { +@@ -426,7 +427,7 @@ struct intel_sst_drv { + * Holder for firmware name. Due to async call it needs to be + * persistent till worker thread gets called + */ +- char firmware_name[20]; ++ char firmware_name[FW_NAME_SIZE]; + }; + + /* misc definitions */ +--- a/sound/soc/intel/sst/sst_acpi.c ++++ b/sound/soc/intel/sst/sst_acpi.c +@@ -47,7 +47,7 @@ struct sst_machines { + char board[32]; + char machine[32]; + void (*machine_quirk)(void); +- char firmware[32]; ++ char firmware[FW_NAME_SIZE]; + struct sst_platform_info *pdata; + + }; diff --git a/queue-3.19/asoc-mioa701_wm9713-fix-speaker-event.patch b/queue-3.19/asoc-mioa701_wm9713-fix-speaker-event.patch new file mode 100644 index 00000000000..a323197ca36 --- /dev/null +++ b/queue-3.19/asoc-mioa701_wm9713-fix-speaker-event.patch @@ -0,0 +1,38 @@ +From 7331ea474e9e7a348541c207bdb6aa518c6403f4 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Thu, 15 Jan 2015 12:52:01 +0100 +Subject: ASoC: mioa701_wm9713: Fix speaker event + +From: Lars-Peter Clausen + +commit 7331ea474e9e7a348541c207bdb6aa518c6403f4 upstream. + +Commit f6b2a04590bb ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM +setup") converted the driver to register the board level DAPM elements with +the card's DAPM context rather than the CODEC's DAPM context. The change +overlooked that the speaker widget event callback accesses the widget's +codec field which is only valid if the widget has been registered in a CODEC +DAPM context. This patch modifies the callback to take an alternative route +to get the CODEC. + +Fixes: f6b2a04590bb ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM +setup") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/pxa/mioa701_wm9713.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/pxa/mioa701_wm9713.c ++++ b/sound/soc/pxa/mioa701_wm9713.c +@@ -81,7 +81,7 @@ static int rear_amp_power(struct snd_soc + static int rear_amp_event(struct snd_soc_dapm_widget *widget, + struct snd_kcontrol *kctl, int event) + { +- struct snd_soc_codec *codec = widget->codec; ++ struct snd_soc_codec *codec = widget->dapm->card->rtd[0].codec; + + return rear_amp_power(codec, SND_SOC_DAPM_EVENT_ON(event)); + } diff --git a/queue-3.19/asoc-rt5670-set-use_single_rw-flag-for-regmap.patch b/queue-3.19/asoc-rt5670-set-use_single_rw-flag-for-regmap.patch new file mode 100644 index 00000000000..5c066f8d250 --- /dev/null +++ b/queue-3.19/asoc-rt5670-set-use_single_rw-flag-for-regmap.patch @@ -0,0 +1,30 @@ +From 92b133f251b5f914f3ed28bc83e5b7a40d4e22ed Mon Sep 17 00:00:00 2001 +From: Bard Liao +Date: Mon, 9 Feb 2015 14:41:50 +0800 +Subject: ASoC: rt5670: Set use_single_rw flag for regmap + +From: Bard Liao + +commit 92b133f251b5f914f3ed28bc83e5b7a40d4e22ed upstream. + +RT5670 doesn't support auto incrementing writes so driver should +set the use_single_rw flag for regmap. + +Signed-off-by: Bard Liao +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/codecs/rt5670.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/soc/codecs/rt5670.c ++++ b/sound/soc/codecs/rt5670.c +@@ -2522,6 +2522,7 @@ static struct snd_soc_codec_driver soc_c + static const struct regmap_config rt5670_regmap = { + .reg_bits = 8, + .val_bits = 16, ++ .use_single_rw = true, + .max_register = RT5670_VENDOR_ID2 + 1 + (ARRAY_SIZE(rt5670_ranges) * + RT5670_PR_SPACING), + .volatile_reg = rt5670_volatile_register, diff --git a/queue-3.19/asoc-rt5677-fix-spi-dependency.patch b/queue-3.19/asoc-rt5677-fix-spi-dependency.patch new file mode 100644 index 00000000000..2982b558d00 --- /dev/null +++ b/queue-3.19/asoc-rt5677-fix-spi-dependency.patch @@ -0,0 +1,60 @@ +From 4c121129c9dcb43b33d1cd568c8f2636e72597b0 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Wed, 28 Jan 2015 22:31:30 +0100 +Subject: ASoC: rt5677: fix SPI dependency + +From: Arnd Bergmann + +commit 4c121129c9dcb43b33d1cd568c8f2636e72597b0 upstream. + +The rt5677 codec has gained code that requires SPI to work correctly, +but there is no provision in Kconfig to prevent the driver from +being used when SPI is disabled or a loadable module, resulting +in this build error: + +sound/built-in.o: In function `rt5677_spi_write': +:(.text+0xa7ba0): undefined reference to `spi_sync' +sound/built-in.o: In function `rt5677_spi_driver_init': +:(.init.text+0x253c): undefined reference to `spi_register_driver' + +ERROR: "spi_sync" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined! +ERROR: "spi_register_driver" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined! + +This makes the SPI portion of the driver depend on the SPI subsystem, +and disables the function that uses SPI for firmware download if SPI +is disabled. The latter may not be the correct solution, but I could +not come up with a better one. + +Signed-off-by: Arnd Bergmann +Fixes: af48f1d08a54741 ("ASoC: rt5677: Support DSP function for VAD application") +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/codecs/Kconfig | 2 +- + sound/soc/codecs/rt5677.c | 3 +++ + 2 files changed, 4 insertions(+), 1 deletion(-) + +--- a/sound/soc/codecs/Kconfig ++++ b/sound/soc/codecs/Kconfig +@@ -525,7 +525,7 @@ config SND_SOC_RT5677 + + config SND_SOC_RT5677_SPI + tristate +- default SND_SOC_RT5677 ++ default SND_SOC_RT5677 && SPI + + #Freescale sgtl5000 codec + config SND_SOC_SGTL5000 +--- a/sound/soc/codecs/rt5677.c ++++ b/sound/soc/codecs/rt5677.c +@@ -702,6 +702,9 @@ static int rt5677_set_dsp_vad(struct snd + static bool activity; + int ret; + ++ if (!IS_ENABLED(CONFIG_SND_SOC_RT5677_SPI)) ++ return -ENXIO; ++ + if (on && !activity) { + activity = true; + diff --git a/queue-3.19/bluetooth-ath3k-add-support-of-ar3012-bluetooth-13d3-3423-device.patch b/queue-3.19/bluetooth-ath3k-add-support-of-ar3012-bluetooth-13d3-3423-device.patch new file mode 100644 index 00000000000..aaf38cf7088 --- /dev/null +++ b/queue-3.19/bluetooth-ath3k-add-support-of-ar3012-bluetooth-13d3-3423-device.patch @@ -0,0 +1,78 @@ +From 033efa920a7f22a8caf7a38d851a2f451781bbf7 Mon Sep 17 00:00:00 2001 +From: Dmitry Tunin +Date: Sun, 18 Jan 2015 00:16:51 +0300 +Subject: Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device + +From: Dmitry Tunin + +commit 033efa920a7f22a8caf7a38d851a2f451781bbf7 upstream. + +Add support of 13d3:3423 device. + +BugLink: https://bugs.launchpad.net/bugs/1411193 + +T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 +D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 +P: Vendor=13d3 ProdID=3423 Rev= 0.01 +C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA +A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 +I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms +I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms +I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms +I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms +I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms +I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms +I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms + +Signed-off-by: Dmitry Tunin +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bluetooth/ath3k.c | 2 ++ + drivers/bluetooth/btusb.c | 1 + + 2 files changed, 3 insertions(+) + +--- a/drivers/bluetooth/ath3k.c ++++ b/drivers/bluetooth/ath3k.c +@@ -108,6 +108,7 @@ static const struct usb_device_id ath3k_ + { USB_DEVICE(0x13d3, 0x3393) }, + { USB_DEVICE(0x13d3, 0x3402) }, + { USB_DEVICE(0x13d3, 0x3408) }, ++ { USB_DEVICE(0x13d3, 0x3423) }, + { USB_DEVICE(0x13d3, 0x3432) }, + + /* Atheros AR5BBU12 with sflash firmware */ +@@ -162,6 +163,7 @@ static const struct usb_device_id ath3k_ + { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 }, ++ { USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 }, + + /* Atheros AR5BBU22 with sflash firmware */ +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -188,6 +188,7 @@ static const struct usb_device_id blackl + { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 }, ++ { USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 }, + + /* Atheros AR5BBU12 with sflash firmware */ diff --git a/queue-3.19/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch b/queue-3.19/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch new file mode 100644 index 00000000000..6264920e48b --- /dev/null +++ b/queue-3.19/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch @@ -0,0 +1,58 @@ +From c561a5753dd631920c4459a067d22679b3d110d6 Mon Sep 17 00:00:00 2001 +From: Adam Lee +Date: Wed, 28 Jan 2015 15:30:27 -0500 +Subject: Bluetooth: ath3k: workaround the compatibility issue with xHCI controller + +From: Adam Lee + +commit c561a5753dd631920c4459a067d22679b3d110d6 upstream. + +BugLink: https://bugs.launchpad.net/bugs/1400215 + +ath3k devices fail to load firmwares on xHCI buses, but work well on +EHCI, this might be a compatibility issue between xHCI and ath3k chips. +As my testing result, those chips will work on xHCI buses again with +this patch. + +This workaround is from Qualcomm, they also did some workarounds in +Windows driver. + +Signed-off-by: Adam Lee +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bluetooth/ath3k.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/bluetooth/ath3k.c ++++ b/drivers/bluetooth/ath3k.c +@@ -174,6 +174,8 @@ static const struct usb_device_id ath3k_ + #define USB_REQ_DFU_DNLOAD 1 + #define BULK_SIZE 4096 + #define FW_HDR_SIZE 20 ++#define TIMEGAP_USEC_MIN 50 ++#define TIMEGAP_USEC_MAX 100 + + static int ath3k_load_firmware(struct usb_device *udev, + const struct firmware *firmware) +@@ -205,6 +207,9 @@ static int ath3k_load_firmware(struct us + pipe = usb_sndbulkpipe(udev, 0x02); + + while (count) { ++ /* workaround the compatibility issue with xHCI controller*/ ++ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX); ++ + size = min_t(uint, count, BULK_SIZE); + memcpy(send_buf, firmware->data + sent, size); + +@@ -302,6 +307,9 @@ static int ath3k_load_fwfile(struct usb_ + pipe = usb_sndbulkpipe(udev, 0x02); + + while (count) { ++ /* workaround the compatibility issue with xHCI controller*/ ++ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX); ++ + size = min_t(uint, count, BULK_SIZE); + memcpy(send_buf, firmware->data + sent, size); + diff --git a/queue-3.19/bluetooth-btusb-add-broadcom-patchram-support-for-asustek-devices.patch b/queue-3.19/bluetooth-btusb-add-broadcom-patchram-support-for-asustek-devices.patch new file mode 100644 index 00000000000..2184b703550 --- /dev/null +++ b/queue-3.19/bluetooth-btusb-add-broadcom-patchram-support-for-asustek-devices.patch @@ -0,0 +1,69 @@ +From 9a5abdaaf9d2e80e157c7a756f9d9fd933dee48e Mon Sep 17 00:00:00 2001 +From: Rick Dunn +Date: Sat, 17 Jan 2015 05:29:12 +0100 +Subject: Bluetooth: btusb: Add Broadcom patchram support for ASUSTek devices + +From: Rick Dunn + +commit 9a5abdaaf9d2e80e157c7a756f9d9fd933dee48e upstream. + +T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 +D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 +P: Vendor=0b05 ProdID=17cf Rev= 1.12 +S: Manufacturer=Broadcom Corp +S: Product=BCM20702A0 +S: SerialNumber=54271E3298CD +C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA +I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms +I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms +I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms +I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms +I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms +I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms +I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms +I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) +E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms +I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) + +Firmware is extracted from the latest Broadcom BCM4352 Windows driver +by extracting the zip and searching the .hex file names for '17cf'. + +The hex file must then be converted to hcd format using the hex2hcd +utility and then moved to /lib/firmware/brcm/. + +Signed-off-by: Rick Dunn +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bluetooth/btusb.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -118,7 +118,8 @@ static const struct usb_device_id btusb_ + .driver_info = BTUSB_BCM_PATCHRAM }, + + /* ASUSTek Computer - Broadcom based */ +- { USB_VENDOR_AND_INTERFACE_INFO(0x0b05, 0xff, 0x01, 0x01) }, ++ { USB_VENDOR_AND_INTERFACE_INFO(0x0b05, 0xff, 0x01, 0x01), ++ .driver_info = BTUSB_BCM_PATCHRAM }, + + /* Belkin F8065bf - Broadcom based */ + { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) }, diff --git a/queue-3.19/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch b/queue-3.19/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch new file mode 100644 index 00000000000..1e59b5247f6 --- /dev/null +++ b/queue-3.19/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch @@ -0,0 +1,138 @@ +From d049f4e513e861167361b06c7ca85f9e872c8cde Mon Sep 17 00:00:00 2001 +From: Marcel Holtmann +Date: Mon, 26 Jan 2015 20:35:32 -0800 +Subject: Bluetooth: btusb: Add support for Dynex/Insignia USB dongles + +From: Marcel Holtmann + +commit d049f4e513e861167361b06c7ca85f9e872c8cde upstream. + +The Dynex/Insignia USB dongles are Broadcom BCM20702B0 based and require +firmware update before operation. + +T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 +D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 +P: Vendor=19ff ProdID=0239 Rev= 1.12 +S: Manufacturer=Broadcom Corp +S: Product=BCM20702A0 +C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA +I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms +I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms +I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms +I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms +I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms +I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms +I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb +E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms +I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) +E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms +I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) + +Since this is an unsual USB vendor ID (0x19ff), these dongles are added +via USB_DEVICE macro and not USB_VENDOR_AND_INTERFACE_INFO as done for +mainstream Broadcom based dongles. + +The latest known working firmware is BCM20702B0_002.001.014.0527.0557.hex +which needs to be converted using hex2hcd utility and then installed +as /lib/firmware/brcm/BCM20702A0-19ff-0239.hcd to make this device fully +operational. + +Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=2000 lmp_ver=06 lmp_subver=410e +Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=222d lmp_ver=06 lmp_subver=410e + +With this firmware the device reports support for connectionless slave +broadcast (master and slave) feature used by 3D Glasses and TVs. + + < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1 + Page: 2 + > HCI Event: Command Complete (0x0e) plen 14 + Read Local Extended Features (0x04|0x0004) ncmd 1 + Status: Success (0x00) + Page: 2/2 + Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + Connectionless Slave Broadcast - Master + Connectionless Slave Broadcast - Slave + Synchronization Train + Synchronization Scan + +However there are some flaws with this feature. The Set Event Mask Page 2 +command is actually not supported and with that all connectionless slave +broadcast events are always enabled. + + < HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8 + Mask: 0x00000000000f0000 + Synchronization Train Received + Connectionless Slave Broadcast Receive + Connectionless Slave Broadcast Timeout + Truncated Page Complete + > HCI Event: Command Complete (0x0e) plen 4 + Set Event Mask Page 2 (0x03|0x0063) ncmd 1 + Status: Unknown HCI Command (0x01) + +In addition the Synchronization Train Received event is actually broken +on this controller. It mixes up the order of parameters. According to the +Bluetooth Core specification the fields are like this: + + struct hci_ev_sync_train_received { + __u8 status; + bdaddr_t bdaddr; + __le32 offset; + __u8 map[10]; + __u8 lt_addr; + __le32 instant; + __le16 interval; + __u8 service_data; + } __packed; + +This controller however sends the service_data as 5th parameter instead +of having it as last parameter. + + struct hci_ev_sync_train_received { + __u8 status; + bdaddr_t bdaddr; + __le32 offset; + __u8 map[10]; + __u8 service_data; + __u8 lt_addr; + __le32 instant; + __le16 interval; + } __packed; + +So anybody trying to use this hardware for utilizing connectionless slave +broadcast receivers (aka 3D Glasses), be warned about this shortcoming. + +Signed-off-by: Marcel Holtmann +Signed-off-by: Johan Hedberg +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bluetooth/btusb.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -109,6 +109,9 @@ static const struct usb_device_id btusb_ + { USB_DEVICE(0x13d3, 0x3404), + .driver_info = BTUSB_BCM_PATCHRAM }, + ++ /* Broadcom BCM20702B0 (Dynex/Insignia) */ ++ { USB_DEVICE(0x19ff, 0x0239), .driver_info = BTUSB_BCM_PATCHRAM }, ++ + /* Foxconn - Hon Hai */ + { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01), + .driver_info = BTUSB_BCM_PATCHRAM }, diff --git a/queue-3.19/bluetooth-btusb-add-support-for-lite-on-04ca-broadcom-based-bcm43142.patch b/queue-3.19/bluetooth-btusb-add-support-for-lite-on-04ca-broadcom-based-bcm43142.patch new file mode 100644 index 00000000000..6e3eb642319 --- /dev/null +++ b/queue-3.19/bluetooth-btusb-add-support-for-lite-on-04ca-broadcom-based-bcm43142.patch @@ -0,0 +1,76 @@ +From 8f0c304c693c5a9759ed6ae50d07d4590dad5ae7 Mon Sep 17 00:00:00 2001 +From: Matej Dubovy +Date: Mon, 2 Feb 2015 18:50:14 +0100 +Subject: Bluetooth: btusb: Add support for Lite-On (04ca) Broadcom based, BCM43142 + +From: Matej Dubovy + +commit 8f0c304c693c5a9759ed6ae50d07d4590dad5ae7 upstream. + +Please add support for sub BT chip on the combo card +Broadcom 43142A0 (in Lenovo E145), 04ca:2007 + +/sys/kernel/debug/usb/devices + +T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 +D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 +P: Vendor=04ca ProdID=2007 Rev= 1.12 +S: Manufacturer=Broadcom Corp +S: Product=BCM43142A0 +S: SerialNumber=28E347EC73BD +C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA +I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms +I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms +I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms +I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms +I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms +I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms +I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) +E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms +E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms +I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) +E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms +I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) + +Firmware for 04ca:2007 can be extracted from the latest Lenovo E145 +Bluetooth driver for Windows (driver is however described as BCM20702 +but contains also firwmare for BCM43142). +Search for BCM43142A0_001.001.011.0122.0153.hex within hex files, then +it must be converted using hex2hcd utility. Rename file to +BCM43142A0-04ca-2007.hcd, then move to /lib/firmware/brcm/. + +Signed-off-by: Matej Dubovy +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bluetooth/btusb.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -116,6 +116,10 @@ static const struct usb_device_id btusb_ + { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01), + .driver_info = BTUSB_BCM_PATCHRAM }, + ++ /* Lite-On Technology - Broadcom based */ ++ { USB_VENDOR_AND_INTERFACE_INFO(0x04ca, 0xff, 0x01, 0x01), ++ .driver_info = BTUSB_BCM_PATCHRAM }, ++ + /* Broadcom devices with vendor specific id */ + { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01), + .driver_info = BTUSB_BCM_PATCHRAM }, diff --git a/queue-3.19/bluetooth-fix-reporting-invalid-rssi-for-le-devices.patch b/queue-3.19/bluetooth-fix-reporting-invalid-rssi-for-le-devices.patch new file mode 100644 index 00000000000..bb5527f8b79 --- /dev/null +++ b/queue-3.19/bluetooth-fix-reporting-invalid-rssi-for-le-devices.patch @@ -0,0 +1,32 @@ +From 91200e9f3e76af2652952e73ce5d9913f1c987c6 Mon Sep 17 00:00:00 2001 +From: Szymon Janc +Date: Thu, 22 Jan 2015 16:57:05 +0100 +Subject: Bluetooth: Fix reporting invalid RSSI for LE devices + +From: Szymon Janc + +commit 91200e9f3e76af2652952e73ce5d9913f1c987c6 upstream. + +Start Discovery was reporting 0 RSSI for invalid RSSI only for +BR/EDR devices. LE devices were reported with RSSI 127. + +Signed-off-by: Szymon Janc +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + net/bluetooth/mgmt.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/mgmt.c ++++ b/net/bluetooth/mgmt.c +@@ -7066,7 +7066,8 @@ void mgmt_device_found(struct hci_dev *h + * However when using service discovery, the value 127 will be + * returned when the RSSI is not available. + */ +- if (rssi == HCI_RSSI_INVALID && !hdev->discovery.report_invalid_rssi) ++ if (rssi == HCI_RSSI_INVALID && !hdev->discovery.report_invalid_rssi && ++ link_type == ACL_LINK) + rssi = 0; + + bacpy(&ev->addr.bdaddr, bdaddr); diff --git a/queue-3.19/bluetooth-fix-valid-identity-address-check.patch b/queue-3.19/bluetooth-fix-valid-identity-address-check.patch new file mode 100644 index 00000000000..290189b1309 --- /dev/null +++ b/queue-3.19/bluetooth-fix-valid-identity-address-check.patch @@ -0,0 +1,41 @@ +From e12af489b91d47a806f4e96e4edc20df612482e7 Mon Sep 17 00:00:00 2001 +From: Johan Hedberg +Date: Wed, 14 Jan 2015 20:51:37 +0200 +Subject: Bluetooth: Fix valid Identity Address check + +From: Johan Hedberg + +commit e12af489b91d47a806f4e96e4edc20df612482e7 upstream. + +According to the Bluetooth core specification valid identity addresses +are either Public Device Addresses or Static Random Addresses. IRKs +received with any other type of address should be discarded since we +cannot assume to know the permanent identity of the peer device. + +This patch fixes a missing check for the Identity Address when receiving +the Identity Address Information SMP PDU. + +Signed-off-by: Johan Hedberg +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + net/bluetooth/smp.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/smp.c ++++ b/net/bluetooth/smp.c +@@ -2303,8 +2303,12 @@ static int smp_cmd_ident_addr_info(struc + * implementations are not known of and in order to not over + * complicate our implementation, simply pretend that we never + * received an IRK for such a device. ++ * ++ * The Identity Address must also be a Static Random or Public ++ * Address, which hci_is_identity_address() checks for. + */ +- if (!bacmp(&info->bdaddr, BDADDR_ANY)) { ++ if (!bacmp(&info->bdaddr, BDADDR_ANY) || ++ !hci_is_identity_address(&info->bdaddr, info->addr_type)) { + BT_ERR("Ignoring IRK with no identity address"); + goto distribute; + } diff --git a/queue-3.19/fsnotify-fix-handling-of-renames-in-audit.patch b/queue-3.19/fsnotify-fix-handling-of-renames-in-audit.patch new file mode 100644 index 00000000000..229873d0e62 --- /dev/null +++ b/queue-3.19/fsnotify-fix-handling-of-renames-in-audit.patch @@ -0,0 +1,79 @@ +From 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Tue, 10 Feb 2015 14:08:32 -0800 +Subject: fsnotify: fix handling of renames in audit + +From: Jan Kara + +commit 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab upstream. + +Commit e9fd702a58c4 ("audit: convert audit watches to use fsnotify +instead of inotify") broke handling of renames in audit. Audit code +wants to update inode number of an inode corresponding to watched name +in a directory. When something gets renamed into a directory to a +watched name, inotify previously passed moved inode to audit code +however new fsnotify code passes directory inode where the change +happened. That confuses audit and it starts watching parent directory +instead of a file in a directory. + +This can be observed for example by doing: + + cd /tmp + touch foo bar + auditctl -w /tmp/foo + touch foo + mv bar foo + touch foo + +In audit log we see events like: + + type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1 + ... + type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE + type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE + type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE + ... + +and that's it - we see event for the first touch after creating the +audit rule, we see events for rename but we don't see any event for the +last touch. However we start seeing events for unrelated stuff +happening in /tmp. + +Fix the problem by passing moved inode as data in the FS_MOVED_FROM and +FS_MOVED_TO events instead of the directory where the change happens. +This doesn't introduce any new problems because noone besides +audit_watch.c cares about the passed value: + + fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events. + fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all. + fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH. + kernel/audit_tree.c doesn't care about passed 'data' at all. + kernel/audit_watch.c expects moved inode as 'data'. + +Fixes: e9fd702a58c49db ("audit: convert audit watches to use fsnotify instead of inotify") +Signed-off-by: Jan Kara +Cc: Paul Moore +Cc: Eric Paris +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/fsnotify.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/include/linux/fsnotify.h ++++ b/include/linux/fsnotify.h +@@ -101,8 +101,10 @@ static inline void fsnotify_move(struct + new_dir_mask |= FS_ISDIR; + } + +- fsnotify(old_dir, old_dir_mask, old_dir, FSNOTIFY_EVENT_INODE, old_name, fs_cookie); +- fsnotify(new_dir, new_dir_mask, new_dir, FSNOTIFY_EVENT_INODE, new_name, fs_cookie); ++ fsnotify(old_dir, old_dir_mask, source, FSNOTIFY_EVENT_INODE, old_name, ++ fs_cookie); ++ fsnotify(new_dir, new_dir_mask, source, FSNOTIFY_EVENT_INODE, new_name, ++ fs_cookie); + + if (target) + fsnotify_link_count(target); diff --git a/queue-3.19/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch b/queue-3.19/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch new file mode 100644 index 00000000000..91d20866ba4 --- /dev/null +++ b/queue-3.19/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch @@ -0,0 +1,41 @@ +From 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb Mon Sep 17 00:00:00 2001 +From: Seth Forshee +Date: Fri, 20 Feb 2015 11:45:11 -0600 +Subject: HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events + +From: Seth Forshee + +commit 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb upstream. + +d1c7e29e8d27 (HID: i2c-hid: prevent buffer overflow in early IRQ) +changed hid_get_input() to read ihid->bufsize bytes, which can be +more than wMaxInputLength. This is the case with the Dell XPS 13 +9343, and it is causing events to be missed. In some cases the +missed events are releases, which can cause the cursor to jump or +freeze, among other problems. Limit the number of bytes read to +min(wMaxInputLength, ihid->bufsize) to prevent such problems. + +Fixes: d1c7e29e8d27 "HID: i2c-hid: prevent buffer overflow in early IRQ" +Signed-off-by: Seth Forshee +Reviewed-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/i2c-hid/i2c-hid.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/hid/i2c-hid/i2c-hid.c ++++ b/drivers/hid/i2c-hid/i2c-hid.c +@@ -370,7 +370,10 @@ static int i2c_hid_hwreset(struct i2c_cl + static void i2c_hid_get_input(struct i2c_hid *ihid) + { + int ret, ret_size; +- int size = ihid->bufsize; ++ int size = le16_to_cpu(ihid->hdesc.wMaxInputLength); ++ ++ if (size > ihid->bufsize) ++ size = ihid->bufsize; + + ret = i2c_master_recv(ihid->client, ihid->inbuf, size); + if (ret != size) { diff --git a/queue-3.19/iwlwifi-mvm-always-use-mac-color-zero.patch b/queue-3.19/iwlwifi-mvm-always-use-mac-color-zero.patch new file mode 100644 index 00000000000..b3acd5416ef --- /dev/null +++ b/queue-3.19/iwlwifi-mvm-always-use-mac-color-zero.patch @@ -0,0 +1,37 @@ +From 5523d11cc46393a1e61b7ef4a0b2d4e7ed9521e4 Mon Sep 17 00:00:00 2001 +From: Luciano Coelho +Date: Thu, 29 Jan 2015 12:48:20 +0200 +Subject: iwlwifi: mvm: always use mac color zero + +From: Luciano Coelho + +commit 5523d11cc46393a1e61b7ef4a0b2d4e7ed9521e4 upstream. + +We don't really need to use different mac colors when adding mac +contexts, because they're not used anywhere. In fact, the firmware +doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401 +when we reach that. + +Remove the color increment to use always zero and avoid reaching 255. + +Signed-off-by: Luciano Coelho +Reviewed-by: Johannes Berg +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlwifi/mvm/mac80211.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c ++++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c +@@ -707,9 +707,6 @@ static void iwl_mvm_cleanup_iterator(voi + mvmvif->uploaded = false; + mvmvif->ap_sta_id = IWL_MVM_STATION_COUNT; + +- /* does this make sense at all? */ +- mvmvif->color++; +- + spin_lock_bh(&mvm->time_event_lock); + iwl_mvm_te_clear_data(mvm, &mvmvif->time_event_data); + spin_unlock_bh(&mvm->time_event_lock); diff --git a/queue-3.19/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch b/queue-3.19/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch new file mode 100644 index 00000000000..90a3ce1c0fe --- /dev/null +++ b/queue-3.19/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch @@ -0,0 +1,33 @@ +From fd66fc1cafd72ddf27dbec3a5e29e99839d1bc84 Mon Sep 17 00:00:00 2001 +From: Luciano Coelho +Date: Tue, 27 Jan 2015 15:06:57 +0200 +Subject: iwlwifi: mvm: fix failure path when power_update fails in add_interface + +From: Luciano Coelho + +commit fd66fc1cafd72ddf27dbec3a5e29e99839d1bc84 upstream. + +When iwl_mvm_power_update_mac() is called, we have already added the +mac context, so if this call fails we should remove the mac. + +Fixes: commit e5e7aa8e2561 ('iwlwifi: mvm: refactor power code') +Signed-off-by: Luciano Coelho +Reviewed-by: Johannes Berg +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c ++++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c +@@ -1146,7 +1146,7 @@ static int iwl_mvm_mac_add_interface(str + + ret = iwl_mvm_power_update_mac(mvm); + if (ret) +- goto out_release; ++ goto out_remove_mac; + + /* beacon filtering */ + ret = iwl_mvm_disable_beacon_filter(mvm, vif, 0); diff --git a/queue-3.19/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch b/queue-3.19/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch new file mode 100644 index 00000000000..545ff8c0574 --- /dev/null +++ b/queue-3.19/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch @@ -0,0 +1,35 @@ +From 2cee4762c528a9bd2cdff793197bf591a2196c11 Mon Sep 17 00:00:00 2001 +From: Eyal Shapira +Date: Fri, 16 Jan 2015 11:09:30 +0200 +Subject: iwlwifi: mvm: validate tid and sta_id in ba_notif + +From: Eyal Shapira + +commit 2cee4762c528a9bd2cdff793197bf591a2196c11 upstream. + +These are coming from the FW and are used to access arrays. +Bad values can cause an out of bounds access so discard +such ba_notifs and warn. + +Signed-off-by: Eyal Shapira +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlwifi/mvm/tx.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/net/wireless/iwlwifi/mvm/tx.c ++++ b/drivers/net/wireless/iwlwifi/mvm/tx.c +@@ -930,6 +930,11 @@ int iwl_mvm_rx_ba_notif(struct iwl_mvm * + sta_id = ba_notif->sta_id; + tid = ba_notif->tid; + ++ if (WARN_ONCE(sta_id >= IWL_MVM_STATION_COUNT || ++ tid >= IWL_MAX_TID_COUNT, ++ "sta_id %d tid %d", sta_id, tid)) ++ return 0; ++ + rcu_read_lock(); + + sta = rcu_dereference(mvm->fw_id_to_mac_id[sta_id]); diff --git a/queue-3.19/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch b/queue-3.19/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch new file mode 100644 index 00000000000..72595db9b36 --- /dev/null +++ b/queue-3.19/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch @@ -0,0 +1,53 @@ +From cd8f438405032ac8ff88bd8f2eca5e0c0063b14b Mon Sep 17 00:00:00 2001 +From: Emmanuel Grumbach +Date: Thu, 29 Jan 2015 21:34:00 +0200 +Subject: iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN + +From: Emmanuel Grumbach + +commit cd8f438405032ac8ff88bd8f2eca5e0c0063b14b upstream. + +The base address of the scheduler in the device's memory +(SRAM) comes from two different sources. The periphery +register and the alive notification from the firmware. +We have a check in iwl_pcie_tx_start that ensures that +they are the same. +When we resume from WoWLAN, the firmware may have crashed +for whatever reason. In that case, the whole device may be +reset which means that the periphery register will hold a +meaningless value. When we come to compare +trans_pcie->scd_base_addr (which really holds the value we +had when we loaded the WoWLAN firmware upon suspend) and +the current value of the register, we don't see a match +unsurprisingly. +Trick the check to avoid a loud yet harmless WARN. +Note that when the WoWLAN has crashed, we will see that +in iwl_trans_pcie_d3_resume which will let the op_mode +know. Once the op_mode is informed that the WowLAN firmware +has crashed, it can't do much besides resetting the whole +device. + +Reviewed-by: Johannes Berg +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlwifi/pcie/tx.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/iwlwifi/pcie/tx.c ++++ b/drivers/net/wireless/iwlwifi/pcie/tx.c +@@ -722,7 +722,12 @@ void iwl_trans_pcie_tx_reset(struct iwl_ + iwl_write_direct32(trans, FH_KW_MEM_ADDR_REG, + trans_pcie->kw.dma >> 4); + +- iwl_pcie_tx_start(trans, trans_pcie->scd_base_addr); ++ /* ++ * Send 0 as the scd_base_addr since the device may have be reset ++ * while we were in WoWLAN in which case SCD_SRAM_BASE_ADDR will ++ * contain garbage. ++ */ ++ iwl_pcie_tx_start(trans, 0); + } + + /* diff --git a/queue-3.19/ksoftirqd-enable-irqs-and-call-cond_resched-before-poking-rcu.patch b/queue-3.19/ksoftirqd-enable-irqs-and-call-cond_resched-before-poking-rcu.patch new file mode 100644 index 00000000000..aa87bd75891 --- /dev/null +++ b/queue-3.19/ksoftirqd-enable-irqs-and-call-cond_resched-before-poking-rcu.patch @@ -0,0 +1,51 @@ +From 28423ad283d5348793b0c45cc9b1af058e776fd6 Mon Sep 17 00:00:00 2001 +From: Calvin Owens +Date: Tue, 13 Jan 2015 13:16:18 -0800 +Subject: ksoftirqd: Enable IRQs and call cond_resched() before poking RCU + +From: Calvin Owens + +commit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream. + +While debugging an issue with excessive softirq usage, I encountered the +following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread +infrastructure"): + + [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ] + +...but despite this note, the patch still calls RCU with IRQs disabled. + +This seemingly innocuous change caused a significant regression in softirq +CPU usage on the sending side of a large TCP transfer (~1 GB/s): when +introducing 0.01% packet loss, the softirq usage would jump to around 25%, +spiking as high as 50%. Before the change, the usage would never exceed 5%. + +Moving the call to rcu_note_context_switch() after the cond_sched() call, +as it was originally before the hotplug patch, completely eliminated this +problem. + +Signed-off-by: Calvin Owens +Signed-off-by: Paul E. McKenney +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/softirq.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/kernel/softirq.c ++++ b/kernel/softirq.c +@@ -656,9 +656,13 @@ static void run_ksoftirqd(unsigned int c + * in the task stack here. + */ + __do_softirq(); +- rcu_note_context_switch(); + local_irq_enable(); + cond_resched(); ++ ++ preempt_disable(); ++ rcu_note_context_switch(); ++ preempt_enable(); ++ + return; + } + local_irq_enable(); diff --git a/queue-3.19/pci-fix-infinite-loop-with-rom-image-of-size-0.patch b/queue-3.19/pci-fix-infinite-loop-with-rom-image-of-size-0.patch new file mode 100644 index 00000000000..9f19db11f4a --- /dev/null +++ b/queue-3.19/pci-fix-infinite-loop-with-rom-image-of-size-0.patch @@ -0,0 +1,54 @@ +From 16b036af31e1456cb69243a5a0c9ef801ecd1f17 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michel=20D=C3=A4nzer?= +Date: Mon, 19 Jan 2015 17:53:20 +0900 +Subject: PCI: Fix infinite loop with ROM image of size 0 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: =?UTF-8?q?Michel=20D=C3=A4nzer?= + +commit 16b036af31e1456cb69243a5a0c9ef801ecd1f17 upstream. + +If the image size would ever read as 0, pci_get_rom_size() could keep +processing the same image over and over again. Exit the loop if we ever +read a length of zero. + +This fixes a soft lockup on boot when the radeon driver calls +pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card. + +[bhelgaas: changelog, reference] +Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973 +Reported-by: Federico +Signed-off-by: Michel Dänzer +Signed-off-by: Bjorn Helgaas +Reviewed-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/rom.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/pci/rom.c ++++ b/drivers/pci/rom.c +@@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev * + { + void __iomem *image; + int last_image; ++ unsigned length; + + image = rom; + do { +@@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev * + if (readb(pds + 3) != 'R') + break; + last_image = readb(pds + 21) & 0x80; +- /* this length is reliable */ +- image += readw(pds + 16) * 512; +- } while (!last_image); ++ length = readw(pds + 16); ++ image += length * 512; ++ } while (length && !last_image); + + /* never return a size larger than the PCI resource window */ + /* there are known ROMs that get the size wrong */ diff --git a/queue-3.19/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch b/queue-3.19/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch new file mode 100644 index 00000000000..67083184e50 --- /dev/null +++ b/queue-3.19/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch @@ -0,0 +1,47 @@ +From 145b3fe579db66fbe999a2bc3fd5b63dffe9636d Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda Delgado +Date: Tue, 2 Dec 2014 17:35:04 +0100 +Subject: PCI: Generate uppercase hex for modalias var in uevent + +From: Ricardo Ribalda Delgado + +commit 145b3fe579db66fbe999a2bc3fd5b63dffe9636d upstream. + +Some implementations of modprobe fail to load the driver for a PCI device +automatically because the "interface" part of the modalias from the kernel +is lowercase, and the modalias from file2alias is uppercase. + +The "interface" is the low-order byte of the Class Code, defined in PCI +r3.0, Appendix D. Most interface types defined in the spec do not use +alpha characters, so they won't be affected. For example, 00h, 01h, 10h, +20h, etc. are unaffected. + +Print the "interface" byte of the Class Code in uppercase hex, as we +already do for the Vendor ID, Device ID, Class, etc. + +Commit 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface +class") fixed only half of the problem. Some udev implementations rely on +the uevent file and not the modalias file. + +Fixes: d1ded203adf1 ("PCI: add MODALIAS to hotplug event for pci devices") +Fixes: 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface class") +Signed-off-by: Ricardo Ribalda Delgado +Signed-off-by: Bjorn Helgaas +Acked-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/pci-driver.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pci/pci-driver.c ++++ b/drivers/pci/pci-driver.c +@@ -1383,7 +1383,7 @@ static int pci_uevent(struct device *dev + if (add_uevent_var(env, "PCI_SLOT_NAME=%s", pci_name(pdev))) + return -ENOMEM; + +- if (add_uevent_var(env, "MODALIAS=pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x", ++ if (add_uevent_var(env, "MODALIAS=pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X", + pdev->vendor, pdev->device, + pdev->subsystem_vendor, pdev->subsystem_device, + (u8)(pdev->class >> 16), (u8)(pdev->class >> 8), diff --git a/queue-3.19/random-fix-fast_mix-function.patch b/queue-3.19/random-fix-fast_mix-function.patch new file mode 100644 index 00000000000..b99efed5609 --- /dev/null +++ b/queue-3.19/random-fix-fast_mix-function.patch @@ -0,0 +1,60 @@ +From 19acc77a36970958a4a0e4daeb2c8cb2aab0ffd4 Mon Sep 17 00:00:00 2001 +From: George Spelvin +Date: Sat, 7 Feb 2015 00:32:06 -0500 +Subject: random: Fix fast_mix() function + +From: George Spelvin + +commit 19acc77a36970958a4a0e4daeb2c8cb2aab0ffd4 upstream. + +There was a bad typo in commit 43759d4f429c ("random: use an improved +fast_mix() function") and I didn't notice because it "looked right", so +I saw what I expected to see when I reviewed it. + +Only months later did I look and notice it's not the Threefish-inspired +mix function that I had designed and optimized. + +Mea Culpa. Each input bit still has a chance to affect each output bit, +and the fast pool is spilled *long* before it fills, so it's not a total +disaster, but it's definitely not the intended great improvement. + +I'm still working on finding better rotation constants. These are good +enough, but since it's unrolled twice, it's possible to get better +mixing for free by using eight different constants rather than repeating +the same four. + +Signed-off-by: George Spelvin +Cc: Theodore Ts'o +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/random.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/char/random.c ++++ b/drivers/char/random.c +@@ -569,19 +569,19 @@ static void fast_mix(struct fast_pool *f + __u32 c = f->pool[2], d = f->pool[3]; + + a += b; c += d; +- b = rol32(a, 6); d = rol32(c, 27); ++ b = rol32(b, 6); d = rol32(d, 27); + d ^= a; b ^= c; + + a += b; c += d; +- b = rol32(a, 16); d = rol32(c, 14); ++ b = rol32(b, 16); d = rol32(d, 14); + d ^= a; b ^= c; + + a += b; c += d; +- b = rol32(a, 6); d = rol32(c, 27); ++ b = rol32(b, 6); d = rol32(d, 27); + d ^= a; b ^= c; + + a += b; c += d; +- b = rol32(a, 16); d = rol32(c, 14); ++ b = rol32(b, 16); d = rol32(d, 14); + d ^= a; b ^= c; + + f->pool[0] = a; f->pool[1] = b; diff --git a/queue-3.19/udf-check-length-of-extended-attributes-and-allocation-descriptors.patch b/queue-3.19/udf-check-length-of-extended-attributes-and-allocation-descriptors.patch new file mode 100644 index 00000000000..68793074789 --- /dev/null +++ b/queue-3.19/udf-check-length-of-extended-attributes-and-allocation-descriptors.patch @@ -0,0 +1,39 @@ +From 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Wed, 7 Jan 2015 13:49:08 +0100 +Subject: udf: Check length of extended attributes and allocation descriptors + +From: Jan Kara + +commit 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 upstream. + +Check length of extended attributes and allocation descriptors when +loading inodes from disk. Otherwise corrupted filesystems could confuse +the code and make the kernel oops. + +Reported-by: Carl Henrik Lunde +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman + +--- + fs/udf/inode.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/fs/udf/inode.c ++++ b/fs/udf/inode.c +@@ -1489,6 +1489,15 @@ reread: + } + inode->i_generation = iinfo->i_unique; + ++ /* ++ * Sanity check length of allocation descriptors and extended attrs to ++ * avoid integer overflows ++ */ ++ if (iinfo->i_lenEAttr > bs || iinfo->i_lenAlloc > bs) ++ goto out; ++ /* Now do exact checks */ ++ if (udf_file_entry_alloc_offset(inode) + iinfo->i_lenAlloc > bs) ++ goto out; + /* Sanity checks for files in ICB so that we don't get confused later */ + if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) { + /* diff --git a/queue-3.19/xfs-ensure-buffer-types-are-set-correctly.patch b/queue-3.19/xfs-ensure-buffer-types-are-set-correctly.patch new file mode 100644 index 00000000000..0627d90efed --- /dev/null +++ b/queue-3.19/xfs-ensure-buffer-types-are-set-correctly.patch @@ -0,0 +1,44 @@ +From 0d612fb570b71ea2e49554a770cff4c489018b2c Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:29:05 +1100 +Subject: xfs: ensure buffer types are set correctly + +From: Dave Chinner + +commit 0d612fb570b71ea2e49554a770cff4c489018b2c upstream. + +Jan Kara reported that log recovery was finding buffers with invalid +types in them. This should not happen, and indicates a bug in the +logging of buffers. To catch this, add asserts to the buffer +formatting code to ensure that the buffer type is in range when the +transaction is committed. + +We don't set a type on buffers being marked stale - they are not +going to get replayed, the format item exists only for recovery to +be able to prevent replay of the buffer, so the type does not +matter. Hence that needs special casing here. + +Reported-by: Jan Kara +Tested-by: Jan Kara +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_buf_item.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/fs/xfs/xfs_buf_item.c ++++ b/fs/xfs/xfs_buf_item.c +@@ -319,6 +319,10 @@ xfs_buf_item_format( + ASSERT(atomic_read(&bip->bli_refcount) > 0); + ASSERT((bip->bli_flags & XFS_BLI_LOGGED) || + (bip->bli_flags & XFS_BLI_STALE)); ++ ASSERT((bip->bli_flags & XFS_BLI_STALE) || ++ (xfs_blft_from_flags(&bip->__bli_format) > XFS_BLFT_UNKNOWN_BUF ++ && xfs_blft_from_flags(&bip->__bli_format) < XFS_BLFT_MAX_BUF)); ++ + + /* + * If it is an inode buffer, transfer the in-memory state to the diff --git a/queue-3.19/xfs-inode-unlink-does-not-set-agi-buffer-type.patch b/queue-3.19/xfs-inode-unlink-does-not-set-agi-buffer-type.patch new file mode 100644 index 00000000000..9ee6cc8c016 --- /dev/null +++ b/queue-3.19/xfs-inode-unlink-does-not-set-agi-buffer-type.patch @@ -0,0 +1,50 @@ +From f19b872b086711bb4b22c3a0f52f16aa920bcc61 Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:29:40 +1100 +Subject: xfs: inode unlink does not set AGI buffer type + +From: Dave Chinner + +commit f19b872b086711bb4b22c3a0f52f16aa920bcc61 upstream. + +This leads to log recovery throwing errors like: + +XFS (md0): Mounting V5 Filesystem +XFS (md0): Starting recovery (logdev: internal) +XFS (md0): Unknown buffer type 0! +XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1 +ffff8800ffc53800: 58 41 47 49 ..... + +Which is the AGI buffer magic number. + +Ensure that we set the type appropriately in both unlink list +addition and removal. + +Tested-by: Jan Kara +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_inode.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/xfs/xfs_inode.c ++++ b/fs/xfs/xfs_inode.c +@@ -1995,6 +1995,7 @@ xfs_iunlink( + agi->agi_unlinked[bucket_index] = cpu_to_be32(agino); + offset = offsetof(xfs_agi_t, agi_unlinked) + + (sizeof(xfs_agino_t) * bucket_index); ++ xfs_trans_buf_set_type(tp, agibp, XFS_BLFT_AGI_BUF); + xfs_trans_log_buf(tp, agibp, offset, + (offset + sizeof(xfs_agino_t) - 1)); + return 0; +@@ -2086,6 +2087,7 @@ xfs_iunlink_remove( + agi->agi_unlinked[bucket_index] = cpu_to_be32(next_agino); + offset = offsetof(xfs_agi_t, agi_unlinked) + + (sizeof(xfs_agino_t) * bucket_index); ++ xfs_trans_buf_set_type(tp, agibp, XFS_BLFT_AGI_BUF); + xfs_trans_log_buf(tp, agibp, offset, + (offset + sizeof(xfs_agino_t) - 1)); + } else { diff --git a/queue-3.19/xfs-only-trace-buffer-items-if-they-exist.patch b/queue-3.19/xfs-only-trace-buffer-items-if-they-exist.patch new file mode 100644 index 00000000000..878a8c3d911 --- /dev/null +++ b/queue-3.19/xfs-only-trace-buffer-items-if-they-exist.patch @@ -0,0 +1,42 @@ +From e9892d3cc853afdda2cc69e2576d9ddb5fafad71 Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Tue, 10 Feb 2015 09:23:40 +1100 +Subject: xfs: only trace buffer items if they exist + +From: Dave Chinner + +commit e9892d3cc853afdda2cc69e2576d9ddb5fafad71 upstream. + +The commit 2d3d0c5 ("xfs: lobotomise xfs_trans_read_buf_map()") left +a landmine in the tracing code: trace_xfs_trans_buf_read() is now +call on all buffers that are read through this interface rather than +just buffers in transactions. For buffers outside transaction +context, bp->b_fspriv is null, and so the buf log item tracing +functions cannot be called. This causes a NULL pointer dereference +in the trace_xfs_trans_buf_read() function when tracing is turned +on. + +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_trans_buf.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/fs/xfs/xfs_trans_buf.c ++++ b/fs/xfs/xfs_trans_buf.c +@@ -327,9 +327,10 @@ xfs_trans_read_buf_map( + return -EIO; + } + +- if (tp) ++ if (tp) { + _xfs_trans_bjoin(tp, bp, 1); +- trace_xfs_trans_read_buf(bp->b_fspriv); ++ trace_xfs_trans_read_buf(bp->b_fspriv); ++ } + *bpp = bp; + return 0; + diff --git a/queue-3.19/xfs-set-buf-types-when-converting-extent-formats.patch b/queue-3.19/xfs-set-buf-types-when-converting-extent-formats.patch new file mode 100644 index 00000000000..86e894d2f30 --- /dev/null +++ b/queue-3.19/xfs-set-buf-types-when-converting-extent-formats.patch @@ -0,0 +1,54 @@ +From fe22d552b82d7cc7de1851233ae8bef579198637 Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:30:06 +1100 +Subject: xfs: set buf types when converting extent formats + +From: Dave Chinner + +commit fe22d552b82d7cc7de1851233ae8bef579198637 upstream. + +Conversion from local to extent format does not set the buffer type +correctly on the new extent buffer when a symlink data is moved out +of line. + +Fix the symlink code and leave a comment in the generic bmap code +reminding us that the format-specific data copy needs to set the +destination buffer type appropriately. + +Tested-by: Jan Kara +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/libxfs/xfs_bmap.c | 6 +++++- + fs/xfs/libxfs/xfs_symlink_remote.c | 2 ++ + 2 files changed, 7 insertions(+), 1 deletion(-) + +--- a/fs/xfs/libxfs/xfs_bmap.c ++++ b/fs/xfs/libxfs/xfs_bmap.c +@@ -973,7 +973,11 @@ xfs_bmap_local_to_extents( + *firstblock = args.fsbno; + bp = xfs_btree_get_bufl(args.mp, tp, args.fsbno, 0); + +- /* initialise the block and copy the data */ ++ /* ++ * Initialise the block and copy the data ++ * ++ * Note: init_fn must set the buffer log item type correctly! ++ */ + init_fn(tp, bp, ip, ifp); + + /* account for the change in fork size and log everything */ +--- a/fs/xfs/libxfs/xfs_symlink_remote.c ++++ b/fs/xfs/libxfs/xfs_symlink_remote.c +@@ -178,6 +178,8 @@ xfs_symlink_local_to_remote( + struct xfs_mount *mp = ip->i_mount; + char *buf; + ++ xfs_trans_buf_set_type(tp, bp, XFS_BLFT_SYMLINK_BUF); ++ + if (!xfs_sb_version_hascrc(&mp->m_sb)) { + bp->b_ops = NULL; + memcpy(bp->b_addr, ifp->if_u1.if_data, ifp->if_bytes); diff --git a/queue-3.19/xfs-set-superblock-buffer-type-correctly.patch b/queue-3.19/xfs-set-superblock-buffer-type-correctly.patch new file mode 100644 index 00000000000..110f8628261 --- /dev/null +++ b/queue-3.19/xfs-set-superblock-buffer-type-correctly.patch @@ -0,0 +1,42 @@ +From 3443a3bca54588f43286b725d8648d33a38c86f1 Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:30:23 +1100 +Subject: xfs: set superblock buffer type correctly + +From: Dave Chinner + +commit 3443a3bca54588f43286b725d8648d33a38c86f1 upstream. + +When the superblock is modified in a transaction, the commonly +modified fields are not actually copied to the superblock buffer to +avoid the buffer lock becoming a serialisation point. However, there +are some other operations that modify the superblock fields within +the transaction that don't directly log to the superblock but rely +on the changes to be applied during the transaction commit (to +minimise the buffer lock hold time). + +When we do this, we fail to mark the buffer log item as being a +superblock buffer and that can lead to the buffer not being marked +with the corect type in the log and hence causing recovery issues. +Fix it by setting the type correctly, similar to xfs_mod_sb()... + +Tested-by: Jan Kara +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_trans.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/xfs/xfs_trans.c ++++ b/fs/xfs/xfs_trans.c +@@ -472,6 +472,7 @@ xfs_trans_apply_sb_deltas( + whole = 1; + } + ++ xfs_trans_buf_set_type(tp, bp, XFS_BLFT_SB_BUF); + if (whole) + /* + * Log the whole thing, the fields are noncontiguous.