--- /dev/null
+From fe8c470ab87d90e4b5115902dd94eced7e3305c3 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Wed, 19 Apr 2017 19:47:04 +0200
+Subject: ACPI / power: Avoid maybe-uninitialized warning
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <arnd@arndb.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 704de489e0e3640a2ee2d0daf173e9f7375582ba Mon Sep 17 00:00:00 2001
+From: Thorsten Leemhuis <linux@leemhuis.info>
+Date: Tue, 18 Apr 2017 11:14:28 -0700
+Subject: Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled
+
+From: Thorsten Leemhuis <linux@leemhuis.info>
+
+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 <linux@leemhuis.info>
+Reviewed-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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"),
--- /dev/null
+From 9e478066eae41211c92a8f63cc69aafc391bd6ab Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Thu, 13 Apr 2017 14:23:49 +0200
+Subject: mac80211: fix MU-MIMO follow-MAC mode
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+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 <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 3018e947d7fd536d57e2b550c33e456d921fff8c Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Thu, 20 Apr 2017 21:32:16 +0200
+Subject: mac80211: reject ToDS broadcast data frames
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+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 <j@w1.fi>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+--
+
+---
+ 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))
--- /dev/null
+From a6db2c86033bc41329770e90c20d4f1fec3824e4 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Tue, 11 Apr 2017 15:55:43 -0700
+Subject: mmc: dw_mmc: Don't allow Runtime PM for SDIO cards
+
+From: Douglas Anderson <dianders@chromium.org>
+
+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 <briannorris@chromium.org>
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
+Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 <linux/ioport.h>
+ #include <linux/module.h>
+ #include <linux/platform_device.h>
++#include <linux/pm_runtime.h>
+ #include <linux/seq_file.h>
+ #include <linux/slab.h>
+ #include <linux/stat.h>
+@@ -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;
+ }
+
--- /dev/null
+From 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 Mon Sep 17 00:00:00 2001
+From: Haibo Chen <haibo.chen@nxp.com>
+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 <haibo.chen@nxp.com>
+
+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 <tharvey@gateworks.com>
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From 9e1ba4f27f018742a1aa95d11e35106feba08ec1 Mon Sep 17 00:00:00 2001
+From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
+Date: Tue, 11 Apr 2017 10:38:13 +0530
+Subject: powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction
+
+From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
+
+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 <ravi.bangoria@linux.vnet.ibm.com>
+Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
+[mpe: Change log massage, add stable tag]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
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
--- /dev/null
+From 9cd9a21ce070be8a918ffd3381468315a7a76ba6 Mon Sep 17 00:00:00 2001
+From: Sebastian Siewior <bigeasy@linutronix.de>
+Date: Wed, 22 Feb 2017 17:15:21 +0100
+Subject: ubi/upd: Always flush after prepared for an update
+
+From: Sebastian Siewior <bigeasy@linutronix.de>
+
+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 <bigeasy@linutronix.de>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 32fe905c17f001c0eee13c59afddd0bf2eed509c Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Thu, 30 Mar 2017 10:50:49 +0200
+Subject: ubifs: Fix O_TMPFILE corner case in ubifs_link()
+
+From: Richard Weinberger <richard@nod.at>
+
+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 <ralph.sennhauser@gmail.com>
+Cc: Amir Goldstein <amir73il@gmail.com>
+Reported-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
+Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
+Reported-by: Amir Goldstein <amir73il@gmail.com>
+Fixes: 474b93704f321 ("ubifs: Implement O_TMPFILE")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From c3d9fda688742c06e89aa1f0f8fd943fc11468cb Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Mon, 6 Mar 2017 10:04:25 +0100
+Subject: ubifs: Fix RENAME_WHITEOUT support
+
+From: Felix Fietkau <nbd@nbd.name>
+
+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 <nbd@nbd.name>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.
--- /dev/null
+From 0dc9c639e6553e39c13b2c0d54c8a1b098cb95e2 Mon Sep 17 00:00:00 2001
+From: Vishal Verma <vishal.l.verma@intel.com>
+Date: Tue, 18 Apr 2017 20:42:35 +0200
+Subject: x86/mce: Make the MCE notifier a blocking one
+
+From: Vishal Verma <vishal.l.verma@intel.com>
+
+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 <ross.zwisler@linux.intel.com>
+Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
+Acked-by: Tony Luck <tony.luck@intel.com>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: linux-edac <linux-edac@vger.kernel.org>
+Cc: x86-ml <x86@kernel.org>
+Link: http://lkml.kernel.org/r/20170411224457.24777-1-vishal.l.verma@intel.com
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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");
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
