From: Greg Kroah-Hartman Date: Mon, 24 Apr 2017 08:02:13 +0000 (+0100) Subject: 4.10-stable patches X-Git-Tag: v4.4.64~8 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=efc76a53e674f4d2aa55f850a06b94b2b2c486d7;p=thirdparty%2Fkernel%2Fstable-queue.git 4.10-stable patches added patches: acpi-power-avoid-maybe-uninitialized-warning.patch input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch mac80211-fix-mu-mimo-follow-mac-mode.patch mac80211-reject-tods-broadcast-data-frames.patch mmc-dw_mmc-don-t-allow-runtime-pm-for-sdio-cards.patch mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch ubi-upd-always-flush-after-prepared-for-an-update.patch ubifs-fix-o_tmpfile-corner-case-in-ubifs_link.patch ubifs-fix-rename_whiteout-support.patch x86-mce-make-the-mce-notifier-a-blocking-one.patch --- diff --git a/queue-4.10/acpi-power-avoid-maybe-uninitialized-warning.patch b/queue-4.10/acpi-power-avoid-maybe-uninitialized-warning.patch new file mode 100644 index 00000000000..0563f519b63 --- /dev/null +++ b/queue-4.10/acpi-power-avoid-maybe-uninitialized-warning.patch @@ -0,0 +1,45 @@ +From fe8c470ab87d90e4b5115902dd94eced7e3305c3 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Wed, 19 Apr 2017 19:47:04 +0200 +Subject: ACPI / power: Avoid maybe-uninitialized warning + +From: Arnd Bergmann + +commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream. + +gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state() +is enterered at least once, so it assumes that cur_state might not get +initialized: + +drivers/acpi/power.c: In function 'acpi_power_get_inferred_state': +drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized] + +This sets the variable to zero at the start of the loop, to ensure that +there is well-defined behavior even for an empty list. This gets rid of +the warning. + +The warning first showed up when the -Os flag got removed in a bug fix +patch in linux-4.11-rc5. + +I would suggest merging this addon patch on top of that bug fix to avoid +introducing a new warning in the stable kernels. + +Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing) +Signed-off-by: Arnd Bergmann +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/power.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/acpi/power.c ++++ b/drivers/acpi/power.c +@@ -200,6 +200,7 @@ static int acpi_power_get_list_state(str + return -EINVAL; + + /* The state of the list is 'on' IFF all resources are 'on'. */ ++ cur_state = 0; + list_for_each_entry(entry, list, node) { + struct acpi_power_resource *resource = entry->resource; + acpi_handle handle = resource->device.handle; diff --git a/queue-4.10/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch b/queue-4.10/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch new file mode 100644 index 00000000000..9507ad9166c --- /dev/null +++ b/queue-4.10/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch @@ -0,0 +1,49 @@ +From 704de489e0e3640a2ee2d0daf173e9f7375582ba Mon Sep 17 00:00:00 2001 +From: Thorsten Leemhuis +Date: Tue, 18 Apr 2017 11:14:28 -0700 +Subject: Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled + +From: Thorsten Leemhuis + +commit 704de489e0e3640a2ee2d0daf173e9f7375582ba upstream. + +Temporary got a Lifebook E547 into my hands and noticed the touchpad +only works after running: + + echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled + +Add it to the list of machines that need this workaround. + +Signed-off-by: Thorsten Leemhuis +Reviewed-by: Ulrik De Bie +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/elantech.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/input/mouse/elantech.c ++++ b/drivers/input/mouse/elantech.c +@@ -1118,6 +1118,7 @@ static int elantech_get_resolution_v4(st + * Asus UX32VD 0x361f02 00, 15, 0e clickpad + * Avatar AVIU-145A2 0x361f00 ? clickpad + * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons ++ * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons + * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons + * Fujitsu T725 0x470f01 05, 12, 09 2 hw buttons + * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**) +@@ -1524,6 +1525,13 @@ static const struct dmi_system_id elante + }, + }, + { ++ /* Fujitsu LIFEBOOK E547 does not work with crc_enabled == 0 */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E547"), ++ }, ++ }, ++ { + /* Fujitsu LIFEBOOK E554 does not work with crc_enabled == 0 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), diff --git a/queue-4.10/mac80211-fix-mu-mimo-follow-mac-mode.patch b/queue-4.10/mac80211-fix-mu-mimo-follow-mac-mode.patch new file mode 100644 index 00000000000..e1c32c4c484 --- /dev/null +++ b/queue-4.10/mac80211-fix-mu-mimo-follow-mac-mode.patch @@ -0,0 +1,124 @@ +From 9e478066eae41211c92a8f63cc69aafc391bd6ab Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Thu, 13 Apr 2017 14:23:49 +0200 +Subject: mac80211: fix MU-MIMO follow-MAC mode + +From: Johannes Berg + +commit 9e478066eae41211c92a8f63cc69aafc391bd6ab upstream. + +There are two bugs in the follow-MAC code: + * it treats the radiotap header as the 802.11 header + (therefore it can't possibly work) + * it doesn't verify that the skb data it accesses is actually + present in the header, which is mitigated by the first point + +Fix this by moving all of this out into a separate function. +This function copies the data it needs using skb_copy_bits() +to make sure it can be accessed if it's paged, and offsets +that by the possibly present vendor radiotap header. + +This also makes all those conditions more readable. + +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/rx.c | 65 +++++++++++++++++++++++++++++++++++++++--------------- + 1 file changed, 47 insertions(+), 18 deletions(-) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -208,6 +208,51 @@ ieee80211_rx_radiotap_hdrlen(struct ieee + return len; + } + ++static void ieee80211_handle_mu_mimo_mon(struct ieee80211_sub_if_data *sdata, ++ struct sk_buff *skb, ++ int rtap_vendor_space) ++{ ++ struct { ++ struct ieee80211_hdr_3addr hdr; ++ u8 category; ++ u8 action_code; ++ } __packed action; ++ ++ if (!sdata) ++ return; ++ ++ BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1); ++ ++ if (skb->len < rtap_vendor_space + sizeof(action) + ++ VHT_MUMIMO_GROUPS_DATA_LEN) ++ return; ++ ++ if (!is_valid_ether_addr(sdata->u.mntr.mu_follow_addr)) ++ return; ++ ++ skb_copy_bits(skb, rtap_vendor_space, &action, sizeof(action)); ++ ++ if (!ieee80211_is_action(action.hdr.frame_control)) ++ return; ++ ++ if (action.category != WLAN_CATEGORY_VHT) ++ return; ++ ++ if (action.action_code != WLAN_VHT_ACTION_GROUPID_MGMT) ++ return; ++ ++ if (!ether_addr_equal(action.hdr.addr1, sdata->u.mntr.mu_follow_addr)) ++ return; ++ ++ skb = skb_copy(skb, GFP_ATOMIC); ++ if (!skb) ++ return; ++ ++ skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME; ++ skb_queue_tail(&sdata->skb_queue, skb); ++ ieee80211_queue_work(&sdata->local->hw, &sdata->work); ++} ++ + /* + * ieee80211_add_rx_radiotap_header - add radiotap header + * +@@ -515,7 +560,6 @@ ieee80211_rx_monitor(struct ieee80211_lo + struct net_device *prev_dev = NULL; + int present_fcs_len = 0; + unsigned int rtap_vendor_space = 0; +- struct ieee80211_mgmt *mgmt; + struct ieee80211_sub_if_data *monitor_sdata = + rcu_dereference(local->monitor_sdata); + +@@ -553,6 +597,8 @@ ieee80211_rx_monitor(struct ieee80211_lo + return remove_monitor_info(local, origskb, rtap_vendor_space); + } + ++ ieee80211_handle_mu_mimo_mon(monitor_sdata, origskb, rtap_vendor_space); ++ + /* room for the radiotap header based on driver features */ + rt_hdrlen = ieee80211_rx_radiotap_hdrlen(local, status, origskb); + needed_headroom = rt_hdrlen - rtap_vendor_space; +@@ -618,23 +664,6 @@ ieee80211_rx_monitor(struct ieee80211_lo + ieee80211_rx_stats(sdata->dev, skb->len); + } + +- mgmt = (void *)skb->data; +- if (monitor_sdata && +- skb->len >= IEEE80211_MIN_ACTION_SIZE + 1 + VHT_MUMIMO_GROUPS_DATA_LEN && +- ieee80211_is_action(mgmt->frame_control) && +- mgmt->u.action.category == WLAN_CATEGORY_VHT && +- mgmt->u.action.u.vht_group_notif.action_code == WLAN_VHT_ACTION_GROUPID_MGMT && +- is_valid_ether_addr(monitor_sdata->u.mntr.mu_follow_addr) && +- ether_addr_equal(mgmt->da, monitor_sdata->u.mntr.mu_follow_addr)) { +- struct sk_buff *mu_skb = skb_copy(skb, GFP_ATOMIC); +- +- if (mu_skb) { +- mu_skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME; +- skb_queue_tail(&monitor_sdata->skb_queue, mu_skb); +- ieee80211_queue_work(&local->hw, &monitor_sdata->work); +- } +- } +- + if (prev_dev) { + skb->dev = prev_dev; + netif_receive_skb(skb); diff --git a/queue-4.10/mac80211-reject-tods-broadcast-data-frames.patch b/queue-4.10/mac80211-reject-tods-broadcast-data-frames.patch new file mode 100644 index 00000000000..781d198def9 --- /dev/null +++ b/queue-4.10/mac80211-reject-tods-broadcast-data-frames.patch @@ -0,0 +1,63 @@ +From 3018e947d7fd536d57e2b550c33e456d921fff8c Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Thu, 20 Apr 2017 21:32:16 +0200 +Subject: mac80211: reject ToDS broadcast data frames + +From: Johannes Berg + +commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream. + +AP/AP_VLAN modes don't accept any real 802.11 multicast data +frames, but since they do need to accept broadcast management +frames the same is currently permitted for data frames. This +opens a security problem because such frames would be decrypted +with the GTK, and could even contain unicast L3 frames. + +Since the spec says that ToDS frames must always have the BSSID +as the RA (addr1), reject any other data frames. + +The problem was originally reported in "Predicting, Decrypting, +and Abusing WPA2/802.11 Group Keys" at usenix +https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef +and brought to my attention by Jouni. + +Reported-by: Jouni Malinen +Signed-off-by: Johannes Berg +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +-- + +--- + net/mac80211/rx.c | 21 +++++++++++++++++++++ + 1 file changed, 21 insertions(+) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -3614,6 +3614,27 @@ static bool ieee80211_accept_frame(struc + !ether_addr_equal(bssid, hdr->addr1)) + return false; + } ++ ++ /* ++ * 802.11-2016 Table 9-26 says that for data frames, A1 must be ++ * the BSSID - we've checked that already but may have accepted ++ * the wildcard (ff:ff:ff:ff:ff:ff). ++ * ++ * It also says: ++ * The BSSID of the Data frame is determined as follows: ++ * a) If the STA is contained within an AP or is associated ++ * with an AP, the BSSID is the address currently in use ++ * by the STA contained in the AP. ++ * ++ * So we should not accept data frames with an address that's ++ * multicast. ++ * ++ * Accepting it also opens a security problem because stations ++ * could encrypt it with the GTK and inject traffic that way. ++ */ ++ if (ieee80211_is_data(hdr->frame_control) && multicast) ++ return false; ++ + return true; + case NL80211_IFTYPE_WDS: + if (bssid || !ieee80211_is_data(hdr->frame_control)) diff --git a/queue-4.10/mmc-dw_mmc-don-t-allow-runtime-pm-for-sdio-cards.patch b/queue-4.10/mmc-dw_mmc-don-t-allow-runtime-pm-for-sdio-cards.patch new file mode 100644 index 00000000000..6a42b459951 --- /dev/null +++ b/queue-4.10/mmc-dw_mmc-don-t-allow-runtime-pm-for-sdio-cards.patch @@ -0,0 +1,93 @@ +From a6db2c86033bc41329770e90c20d4f1fec3824e4 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Tue, 11 Apr 2017 15:55:43 -0700 +Subject: mmc: dw_mmc: Don't allow Runtime PM for SDIO cards + +From: Douglas Anderson + +commit a6db2c86033bc41329770e90c20d4f1fec3824e4 upstream. + +According to the SDIO standard interrupts are normally signalled in a +very complicated way. They require the card clock to be running and +require the controller to be paying close attention to the signals +coming from the card. This simply can't happen with the clock stopped +or with the controller in a low power mode. + +To that end, we'll disable runtime_pm when we detect that an SDIO card +was inserted. This is much like with what we do with the special +"SDMMC_CLKEN_LOW_PWR" bit that dw_mmc supports. + +NOTE: we specifically do this Runtime PM disabling at card init time +rather than in the enable_sdio_irq() callback. This is _different_ +than how SDHCI does it. Why do we do it differently? + +- Unlike SDHCI, dw_mmc uses the standard sdio_irq code in Linux (AKA + dw_mmc doesn't set MMC_CAP2_SDIO_IRQ_NOTHREAD). +- Because we use the standard sdio_irq code: + - We see a constant stream of enable_sdio_irq(0) and + enable_sdio_irq(1) calls. This is because the standard code + disables interrupts while processing and re-enables them after. + - While interrupts are disabled, there's technically a period where + we could get runtime disabled while processing interrupts. + - If we are runtime disabled while processing interrupts, we'll + reset the controller at resume time (see dw_mci_runtime_resume), + which seems like a terrible idea because we could possibly have + another interrupt pending. + +To fix the above isues we'd want to put something in the standard +sdio_irq code that makes sure to call pm_runtime get/put when +interrupts are being actively being processed. That's possible to do, +but it seems like a more complicated mechanism when we really just +want the runtime pm disabled always for SDIO cards given that all the +other bits needed to get Runtime PM vs. SDIO just aren't there. + +NOTE: at some point in time someone might come up with a fancy way to +do SDIO interrupts and still allow (some) amount of runtime PM. +Technically we could turn off the card clock if we used an alternate +way of signaling SDIO interrupts (and out of band interrupt is one way +to do this). We probably wouldn't actually want to fully runtime +suspend in this case though--at least not with the current +dw_mci_runtime_resume() which basically fully resets the controller at +resume time. + +Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback") +Reported-by: Brian Norris +Signed-off-by: Douglas Anderson +Acked-by: Jaehoon Chung +Reviewed-by: Shawn Lin +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/dw_mmc.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/dw_mmc.c ++++ b/drivers/mmc/host/dw_mmc.c +@@ -22,6 +22,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -1618,10 +1619,16 @@ static void dw_mci_init_card(struct mmc_ + + if (card->type == MMC_TYPE_SDIO || + card->type == MMC_TYPE_SD_COMBO) { +- set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); ++ if (!test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags)) { ++ pm_runtime_get_noresume(mmc->parent); ++ set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); ++ } + clk_en_a = clk_en_a_old & ~clken_low_pwr; + } else { +- clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); ++ if (test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags)) { ++ pm_runtime_put_noidle(mmc->parent); ++ clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); ++ } + clk_en_a = clk_en_a_old | clken_low_pwr; + } + diff --git a/queue-4.10/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch b/queue-4.10/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch new file mode 100644 index 00000000000..25a57f2ea3b --- /dev/null +++ b/queue-4.10/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch @@ -0,0 +1,40 @@ +From 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 Mon Sep 17 00:00:00 2001 +From: Haibo Chen +Date: Wed, 19 Apr 2017 10:53:51 +0800 +Subject: mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card + +From: Haibo Chen + +commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream. + +Currently for DDR50 card, it need tuning in default. We meet tuning fail +issue for DDR50 card and some data CRC error when DDR50 sd card works. + +This is because the default pad I/O drive strength can't make sure DDR50 +card work stable. So increase the pad I/O drive strength for DDR50 card, +and use pins_100mhz. + +This fixes DDR50 card support for IMX since DDR50 tuning was enabled from +commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50") + +Tested-and-reported-by: Tim Harvey +Signed-off-by: Haibo Chen +Acked-by: Dong Aisheng +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-esdhc-imx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mmc/host/sdhci-esdhc-imx.c ++++ b/drivers/mmc/host/sdhci-esdhc-imx.c +@@ -830,6 +830,7 @@ static int esdhc_change_pinstate(struct + + switch (uhs) { + case MMC_TIMING_UHS_SDR50: ++ case MMC_TIMING_UHS_DDR50: + pinctrl = imx_data->pins_100mhz; + break; + case MMC_TIMING_UHS_SDR104: diff --git a/queue-4.10/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch b/queue-4.10/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch new file mode 100644 index 00000000000..cbc6c598d8b --- /dev/null +++ b/queue-4.10/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch @@ -0,0 +1,64 @@ +From 9e1ba4f27f018742a1aa95d11e35106feba08ec1 Mon Sep 17 00:00:00 2001 +From: Ravi Bangoria +Date: Tue, 11 Apr 2017 10:38:13 +0530 +Subject: powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction + +From: Ravi Bangoria + +commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 upstream. + +If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel +OOPS: + + Bad kernel stack pointer cd93c840 at c000000000009868 + Oops: Bad kernel stack pointer, sig: 6 [#1] + ... + GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840 + ... + NIP [c000000000009868] resume_kernel+0x2c/0x58 + LR [c000000000006208] program_check_common+0x108/0x180 + +On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does +not emulate actual store in emulate_step() because it may corrupt the exception +frame. So the kernel does the actual store operation in exception return code +i.e. resume_kernel(). + +resume_kernel() loads the saved stack pointer from memory using lwz, which only +loads the low 32-bits of the address, causing the kernel crash. + +Fix this by loading the 64-bit value instead. + +Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()") +Signed-off-by: Ravi Bangoria +Reviewed-by: Naveen N. Rao +Reviewed-by: Ananth N Mavinakayanahalli +[mpe: Change log massage, add stable tag] +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/entry_64.S | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/powerpc/kernel/entry_64.S ++++ b/arch/powerpc/kernel/entry_64.S +@@ -689,7 +689,7 @@ resume_kernel: + + addi r8,r1,INT_FRAME_SIZE /* Get the kprobed function entry */ + +- lwz r3,GPR1(r1) ++ ld r3,GPR1(r1) + subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception frame */ + mr r4,r1 /* src: current exception frame */ + mr r1,r3 /* Reroute the trampoline frame to r1 */ +@@ -703,8 +703,8 @@ resume_kernel: + addi r6,r6,8 + bdnz 2b + +- /* Do real store operation to complete stwu */ +- lwz r5,GPR1(r1) ++ /* Do real store operation to complete stdu */ ++ ld r5,GPR1(r1) + std r8,0(r5) + + /* Clear _TIF_EMULATE_STACK_STORE flag */ diff --git a/queue-4.10/series b/queue-4.10/series index cb8ff9ae24f..79d70a63ef3 100644 --- a/queue-4.10/series +++ b/queue-4.10/series @@ -9,3 +9,14 @@ cifs-do-not-send-echoes-before-negotiate-is-complete.patch cifs-remove-bad_network_name-flag.patch mmc-dw_mmc-silent-verbose-log-when-calling-from-pm-context.patch s390-mm-fix-cmma-vs-ksm-vs-others.patch +input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch +acpi-power-avoid-maybe-uninitialized-warning.patch +mmc-dw_mmc-don-t-allow-runtime-pm-for-sdio-cards.patch +mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch +ubifs-fix-rename_whiteout-support.patch +ubifs-fix-o_tmpfile-corner-case-in-ubifs_link.patch +mac80211-reject-tods-broadcast-data-frames.patch +mac80211-fix-mu-mimo-follow-mac-mode.patch +x86-mce-make-the-mce-notifier-a-blocking-one.patch +ubi-upd-always-flush-after-prepared-for-an-update.patch +powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch diff --git a/queue-4.10/ubi-upd-always-flush-after-prepared-for-an-update.patch b/queue-4.10/ubi-upd-always-flush-after-prepared-for-an-update.patch new file mode 100644 index 00000000000..a2b306c0fbc --- /dev/null +++ b/queue-4.10/ubi-upd-always-flush-after-prepared-for-an-update.patch @@ -0,0 +1,64 @@ +From 9cd9a21ce070be8a918ffd3381468315a7a76ba6 Mon Sep 17 00:00:00 2001 +From: Sebastian Siewior +Date: Wed, 22 Feb 2017 17:15:21 +0100 +Subject: ubi/upd: Always flush after prepared for an update + +From: Sebastian Siewior + +commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream. + +In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I +managed to trigger and fix a similar bug. Now here is another version of +which I assumed it wouldn't matter back then but it turns out UBI has a +check for it and will error out like this: + +|ubi0 warning: validate_vid_hdr: inconsistent used_ebs +|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592 + +All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a +powercut in the middle of the operation. +ubi_start_update() sets the update-marker and puts all EBs on the erase +list. After that userland can proceed to write new data while the old EB +aren't erased completely. A powercut at this point is usually not that +much of a tragedy. UBI won't give read access to the static volume +because it has the update marker. It will most likely set the corrupted +flag because it misses some EBs. +So we are all good. Unless the size of the image that has been written +differs from the old image in the magnitude of at least one EB. In that +case UBI will find two different values for `used_ebs' and refuse to +attach the image with the error message mentioned above. + +So in order not to get in the situation, the patch will ensure that we +wait until everything is removed before it tries to write any data. +The alternative would be to detect such a case and remove all EBs at the +attached time after we processed the volume-table and see the +update-marker set. The patch looks bigger and I doubt it is worth it +since usually the write() will wait from time to time for a new EB since +usually there not that many spare EB that can be used. + +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/upd.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/mtd/ubi/upd.c ++++ b/drivers/mtd/ubi/upd.c +@@ -148,11 +148,11 @@ int ubi_start_update(struct ubi_device * + return err; + } + +- if (bytes == 0) { +- err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL); +- if (err) +- return err; ++ err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL); ++ if (err) ++ return err; + ++ if (bytes == 0) { + err = clear_update_marker(ubi, vol, 0); + if (err) + return err; diff --git a/queue-4.10/ubifs-fix-o_tmpfile-corner-case-in-ubifs_link.patch b/queue-4.10/ubifs-fix-o_tmpfile-corner-case-in-ubifs_link.patch new file mode 100644 index 00000000000..439e9220427 --- /dev/null +++ b/queue-4.10/ubifs-fix-o_tmpfile-corner-case-in-ubifs_link.patch @@ -0,0 +1,53 @@ +From 32fe905c17f001c0eee13c59afddd0bf2eed509c Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Thu, 30 Mar 2017 10:50:49 +0200 +Subject: ubifs: Fix O_TMPFILE corner case in ubifs_link() + +From: Richard Weinberger + +commit 32fe905c17f001c0eee13c59afddd0bf2eed509c upstream. + +It is perfectly fine to link a tmpfile back using linkat(). +Since tmpfiles are created with a link count of 0 they appear +on the orphan list, upon re-linking the inode has to be removed +from the orphan list again. + +Ralph faced a filesystem corruption in combination with overlayfs +due to this bug. + +Cc: Ralph Sennhauser +Cc: Amir Goldstein +Reported-by: Ralph Sennhauser +Tested-by: Ralph Sennhauser +Reported-by: Amir Goldstein +Fixes: 474b93704f321 ("ubifs: Implement O_TMPFILE") +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ubifs/dir.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/fs/ubifs/dir.c ++++ b/fs/ubifs/dir.c +@@ -748,6 +748,11 @@ static int ubifs_link(struct dentry *old + goto out_fname; + + lock_2_inodes(dir, inode); ++ ++ /* Handle O_TMPFILE corner case, it is allowed to link a O_TMPFILE. */ ++ if (inode->i_nlink == 0) ++ ubifs_delete_orphan(c, inode->i_ino); ++ + inc_nlink(inode); + ihold(inode); + inode->i_ctime = ubifs_current_time(inode); +@@ -768,6 +773,8 @@ out_cancel: + dir->i_size -= sz_change; + dir_ui->ui_size = dir->i_size; + drop_nlink(inode); ++ if (inode->i_nlink == 0) ++ ubifs_add_orphan(c, inode->i_ino); + unlock_2_inodes(dir, inode); + ubifs_release_budget(c, &req); + iput(inode); diff --git a/queue-4.10/ubifs-fix-rename_whiteout-support.patch b/queue-4.10/ubifs-fix-rename_whiteout-support.patch new file mode 100644 index 00000000000..e8eb34df140 --- /dev/null +++ b/queue-4.10/ubifs-fix-rename_whiteout-support.patch @@ -0,0 +1,35 @@ +From c3d9fda688742c06e89aa1f0f8fd943fc11468cb Mon Sep 17 00:00:00 2001 +From: Felix Fietkau +Date: Mon, 6 Mar 2017 10:04:25 +0100 +Subject: ubifs: Fix RENAME_WHITEOUT support + +From: Felix Fietkau + +commit c3d9fda688742c06e89aa1f0f8fd943fc11468cb upstream. + +Remove faulty leftover check in do_rename(), apparently introduced in a +merge that combined whiteout support changes with commit f03b8ad8d386 +("fs: support RENAME_NOREPLACE for local filesystems") + +Fixes: f03b8ad8d386 ("fs: support RENAME_NOREPLACE for local filesystems") +Fixes: 9e0a1fff8db5 ("ubifs: Implement RENAME_WHITEOUT") +Signed-off-by: Felix Fietkau +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ubifs/dir.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/fs/ubifs/dir.c ++++ b/fs/ubifs/dir.c +@@ -1316,9 +1316,6 @@ static int do_rename(struct inode *old_d + unsigned int uninitialized_var(saved_nlink); + struct fscrypt_name old_nm, new_nm; + +- if (flags & ~RENAME_NOREPLACE) +- return -EINVAL; +- + /* + * Budget request settings: deletion direntry, new direntry, removing + * the old inode, and changing old and new parent directory inodes. diff --git a/queue-4.10/x86-mce-make-the-mce-notifier-a-blocking-one.patch b/queue-4.10/x86-mce-make-the-mce-notifier-a-blocking-one.patch new file mode 100644 index 00000000000..d7ad916658c --- /dev/null +++ b/queue-4.10/x86-mce-make-the-mce-notifier-a-blocking-one.patch @@ -0,0 +1,124 @@ +From 0dc9c639e6553e39c13b2c0d54c8a1b098cb95e2 Mon Sep 17 00:00:00 2001 +From: Vishal Verma +Date: Tue, 18 Apr 2017 20:42:35 +0200 +Subject: x86/mce: Make the MCE notifier a blocking one + +From: Vishal Verma + +commit 0dc9c639e6553e39c13b2c0d54c8a1b098cb95e2 upstream. + +The NFIT MCE handler callback (for handling media errors on NVDIMMs) +takes a mutex to add the location of a memory error to a list. But since +the notifier call chain for machine checks (x86_mce_decoder_chain) is +atomic, we get a lockdep splat like: + + BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620 + in_atomic(): 1, irqs_disabled(): 0, pid: 4, name: kworker/0:0 + [..] + Call Trace: + dump_stack + ___might_sleep + __might_sleep + mutex_lock_nested + ? __lock_acquire + nfit_handle_mce + notifier_call_chain + atomic_notifier_call_chain + ? atomic_notifier_call_chain + mce_gen_pool_process + +Convert the notifier to a blocking one which gets to run only in process +context. + +Boris: remove the notifier call in atomic context in print_mce(). For +now, let's print the MCE on the atomic path so that we can make sure +they go out and get logged at least. + +Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error") +Reported-by: Ross Zwisler +Signed-off-by: Vishal Verma +Acked-by: Tony Luck +Cc: Dan Williams +Cc: linux-edac +Cc: x86-ml +Link: http://lkml.kernel.org/r/20170411224457.24777-1-vishal.l.verma@intel.com +Signed-off-by: Borislav Petkov +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +- + arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 +- + arch/x86/kernel/cpu/mcheck/mce.c | 17 +++-------------- + 3 files changed, 5 insertions(+), 16 deletions(-) + +--- a/arch/x86/kernel/cpu/mcheck/mce-genpool.c ++++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c +@@ -85,7 +85,7 @@ void mce_gen_pool_process(void) + head = llist_reverse_order(head); + llist_for_each_entry_safe(node, tmp, head, llnode) { + mce = &node->mce; +- atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, mce); ++ blocking_notifier_call_chain(&x86_mce_decoder_chain, 0, mce); + gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node)); + } + } +--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h ++++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h +@@ -13,7 +13,7 @@ enum severity_level { + MCE_PANIC_SEVERITY, + }; + +-extern struct atomic_notifier_head x86_mce_decoder_chain; ++extern struct blocking_notifier_head x86_mce_decoder_chain; + + #define ATTR_LEN 16 + #define INITIAL_CHECK_INTERVAL 5 * 60 /* 5 minutes */ +--- a/arch/x86/kernel/cpu/mcheck/mce.c ++++ b/arch/x86/kernel/cpu/mcheck/mce.c +@@ -123,7 +123,7 @@ static void (*quirk_no_way_out)(int bank + * CPU/chipset specific EDAC code can register a notifier call here to print + * MCE errors in a human-readable form. + */ +-ATOMIC_NOTIFIER_HEAD(x86_mce_decoder_chain); ++BLOCKING_NOTIFIER_HEAD(x86_mce_decoder_chain); + + /* Do initial initialization of a struct mce */ + void mce_setup(struct mce *m) +@@ -223,7 +223,7 @@ void mce_register_decode_chain(struct no + if (nb != &mce_srao_nb && nb->priority == INT_MAX) + nb->priority -= 1; + +- atomic_notifier_chain_register(&x86_mce_decoder_chain, nb); ++ blocking_notifier_chain_register(&x86_mce_decoder_chain, nb); + } + EXPORT_SYMBOL_GPL(mce_register_decode_chain); + +@@ -231,7 +231,7 @@ void mce_unregister_decode_chain(struct + { + atomic_dec(&num_notifiers); + +- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, nb); ++ blocking_notifier_chain_unregister(&x86_mce_decoder_chain, nb); + } + EXPORT_SYMBOL_GPL(mce_unregister_decode_chain); + +@@ -324,18 +324,7 @@ static void __print_mce(struct mce *m) + + static void print_mce(struct mce *m) + { +- int ret = 0; +- + __print_mce(m); +- +- /* +- * Print out human-readable details about the MCE error, +- * (if the CPU has an implementation for that) +- */ +- ret = atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, m); +- if (ret == NOTIFY_STOP) +- return; +- + pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog --ascii'\n"); + } +