--- /dev/null
+From f771d5bb71d4df9573d12386400540516672208b Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Tue, 18 Oct 2016 10:59:09 +0800
+Subject: ALSA: hda - Adding a new group of pin cfg into ALC295 pin quirk table
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit f771d5bb71d4df9573d12386400540516672208b upstream.
+
+We have a new Dell laptop model which uses ALC295, the pin definition
+is different from the existing ones in the pin quirk table, to fix the
+headset mic detection and mic mute led's problem, we need to add the
+new pin defintion into the pin quirk table.
+
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5809,8 +5809,6 @@ static const struct hda_model_fixup alc2
+ #define ALC295_STANDARD_PINS \
+ {0x12, 0xb7a60130}, \
+ {0x14, 0x90170110}, \
+- {0x17, 0x21014020}, \
+- {0x18, 0x21a19030}, \
+ {0x21, 0x04211020}
+
+ #define ALC298_STANDARD_PINS \
+@@ -6037,7 +6035,13 @@ static const struct snd_hda_pin_quirk al
+ ALC292_STANDARD_PINS,
+ {0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+- ALC295_STANDARD_PINS),
++ ALC295_STANDARD_PINS,
++ {0x17, 0x21014020},
++ {0x18, 0x21a19030}),
++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
++ ALC295_STANDARD_PINS,
++ {0x17, 0x21014040},
++ {0x18, 0x21a19050}),
+ SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
+ ALC298_STANDARD_PINS,
+ {0x17, 0x90170110}),
--- /dev/null
+From 3ab7511eafdd5c4f40d2832f09554478dfbea170 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Mon, 17 Oct 2016 17:23:59 +0100
+Subject: ALSA: hda - allow 40 bit DMA mask for NVidia devices
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit 3ab7511eafdd5c4f40d2832f09554478dfbea170 upstream.
+
+Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits
+for Nvidia audio controllers") simply disabled any DMA exceeding 32
+bits for NVidia devices, even though they are capable of performing
+DMA up to 40 bits. On some architectures (such as arm64), system memory
+is not guaranteed to be 32-bit addressable by PCI devices, and so this
+change prevents NVidia devices from working on platforms such as AMD
+Seattle.
+
+Since the original commit already mentioned that up to 40 bits of DMA
+is supported, and given that the code has been updated in the meantime
+to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf
+and explicitly set the DMA mask to 40 bits for NVidia devices.
+
+Fixes: 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...')
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_intel.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -340,8 +340,7 @@ enum {
+
+ /* quirks for Nvidia */
+ #define AZX_DCAPS_PRESET_NVIDIA \
+- (AZX_DCAPS_NO_MSI | /*AZX_DCAPS_ALIGN_BUFSIZE |*/ \
+- AZX_DCAPS_NO_64BIT | AZX_DCAPS_CORBRP_SELF_CLEAR |\
++ (AZX_DCAPS_NO_MSI | AZX_DCAPS_CORBRP_SELF_CLEAR |\
+ AZX_DCAPS_SNOOP_TYPE(NVIDIA))
+
+ #define AZX_DCAPS_PRESET_CTHDA \
+@@ -1699,6 +1698,10 @@ static int azx_first_init(struct azx *ch
+ }
+ }
+
++ /* NVidia hardware normally only supports up to 40 bits of DMA */
++ if (chip->pci->vendor == PCI_VENDOR_ID_NVIDIA)
++ dma_bits = 40;
++
+ /* disable 64bit DMA address on some devices */
+ if (chip->driver_caps & AZX_DCAPS_NO_64BIT) {
+ dev_dbg(card->dev, "Disabling 64bit DMA\n");
--- /dev/null
+From 6aecd8715802d23dc6a0859b50c62d2b0a99de3a Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Thu, 20 Oct 2016 14:03:33 +0800
+Subject: ALSA: hda - Fix headset mic detection problem for two Dell laptops
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit 6aecd8715802d23dc6a0859b50c62d2b0a99de3a upstream.
+
+They uses the codec ALC255, and have the different pin cfg definition
+from the ones in the existing pin quirk table. Now adding them into
+the table to fix the problem.
+
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5855,11 +5855,19 @@ static const struct snd_hda_pin_quirk al
+ {0x1b, 0x02011020},
+ {0x21, 0x0221101f}),
+ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
++ {0x14, 0x90170110},
++ {0x1b, 0x01011020},
++ {0x21, 0x0221101f}),
++ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+ {0x14, 0x90170130},
+ {0x1b, 0x01014020},
+ {0x21, 0x0221103f}),
+ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+ {0x14, 0x90170130},
++ {0x1b, 0x01011020},
++ {0x21, 0x0221103f}),
++ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
++ {0x14, 0x90170130},
+ {0x1b, 0x02011020},
+ {0x21, 0x0221103f}),
+ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
--- /dev/null
+From 1a3f099101b85cc93d864eb030d97e7725c72ea7 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 20 Oct 2016 12:14:51 +0200
+Subject: ALSA: hda - Fix surround output pins for ASRock B150M mobo
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 1a3f099101b85cc93d864eb030d97e7725c72ea7 upstream.
+
+ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide
+proper pins for the surround outputs, hence we need to specify the
+pincfgs manually with a couple of other corrections.
+
+Reported-and-tested-by: Benjamin Valentin <benpicco@googlemail.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -6615,6 +6615,7 @@ enum {
+ ALC891_FIXUP_HEADSET_MODE,
+ ALC891_FIXUP_DELL_MIC_NO_PRESENCE,
+ ALC662_FIXUP_ACER_VERITON,
++ ALC892_FIXUP_ASROCK_MOBO,
+ };
+
+ static const struct hda_fixup alc662_fixups[] = {
+@@ -6891,6 +6892,16 @@ static const struct hda_fixup alc662_fix
+ { }
+ }
+ },
++ [ALC892_FIXUP_ASROCK_MOBO] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = (const struct hda_pintbl[]) {
++ { 0x15, 0x40f000f0 }, /* disabled */
++ { 0x16, 0x40f000f0 }, /* disabled */
++ { 0x18, 0x01014011 }, /* LO */
++ { 0x1a, 0x01014012 }, /* LO */
++ { }
++ }
++ },
+ };
+
+ static const struct snd_pci_quirk alc662_fixup_tbl[] = {
+@@ -6928,6 +6939,7 @@ static const struct snd_pci_quirk alc662
+ SND_PCI_QUIRK(0x144d, 0xc051, "Samsung R720", ALC662_FIXUP_IDEAPAD),
+ SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo Ideapad Y550P", ALC662_FIXUP_IDEAPAD),
+ SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Ideapad Y550", ALC662_FIXUP_IDEAPAD),
++ SND_PCI_QUIRK(0x1849, 0x5892, "ASRock B150M", ALC892_FIXUP_ASROCK_MOBO),
+ SND_PCI_QUIRK(0x19da, 0xa130, "Zotac Z68", ALC662_FIXUP_ZOTAC_Z68),
+ SND_PCI_QUIRK(0x1b0a, 0x01b8, "ACER Veriton", ALC662_FIXUP_ACER_VERITON),
+ SND_PCI_QUIRK(0x1b35, 0x2206, "CZC P10T", ALC662_FIXUP_CZC_P10T),
--- /dev/null
+From 9b50898ad96c793a8f7cde9d8f281596d752a7dd Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 25 Oct 2016 15:56:35 +0200
+Subject: ALSA: seq: Fix time account regression
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 9b50898ad96c793a8f7cde9d8f281596d752a7dd upstream.
+
+The recent rewrite of the sequencer time accounting using timespec64
+in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
+internally] introduced a bad regression. Namely, the time reported
+back doesn't increase but goes back and forth.
+
+The culprit was obvious: the delta is stored to the result (cur_time =
+delta), instead of adding the delta (cur_time += delta)!
+
+Let's fix it.
+
+Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
+Reported-by: Yves Guillemot <yc.guillemot@wanadoo.fr>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/seq/seq_timer.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/core/seq/seq_timer.c
++++ b/sound/core/seq/seq_timer.c
+@@ -448,8 +448,8 @@ snd_seq_real_time_t snd_seq_timer_get_cu
+
+ ktime_get_ts64(&tm);
+ tm = timespec64_sub(tm, tmr->last_update);
+- cur_time.tv_nsec = tm.tv_nsec;
+- cur_time.tv_sec = tm.tv_sec;
++ cur_time.tv_nsec += tm.tv_nsec;
++ cur_time.tv_sec += tm.tv_sec;
+ snd_seq_sanity_real_time(&cur_time);
+ }
+ spin_unlock_irqrestore(&tmr->lock, flags);
--- /dev/null
+From bdc3478f90cd4d2928197f36629d5cf93b64dbe9 Mon Sep 17 00:00:00 2001
+From: Marcel Hasler <mahasler@gmail.com>
+Date: Thu, 27 Oct 2016 00:42:27 +0200
+Subject: ALSA: usb-audio: Add quirk for Syntek STK1160
+
+From: Marcel Hasler <mahasler@gmail.com>
+
+commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.
+
+The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
+the issue reported on the mailing list
+(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
+bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
+
+Signed-off-by: Marcel Hasler <mahasler@gmail.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/quirks-table.h | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/sound/usb/quirks-table.h
++++ b/sound/usb/quirks-table.h
+@@ -2907,6 +2907,23 @@ AU0828_DEVICE(0x2040, 0x7260, "Hauppauge
+ AU0828_DEVICE(0x2040, 0x7213, "Hauppauge", "HVR-950Q"),
+ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"),
+
++/* Syntek STK1160 */
++{
++ .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
++ USB_DEVICE_ID_MATCH_INT_CLASS |
++ USB_DEVICE_ID_MATCH_INT_SUBCLASS,
++ .idVendor = 0x05e1,
++ .idProduct = 0x0408,
++ .bInterfaceClass = USB_CLASS_AUDIO,
++ .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
++ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
++ .vendor_name = "Syntek",
++ .product_name = "STK1160",
++ .ifnum = QUIRK_ANY_INTERFACE,
++ .type = QUIRK_AUDIO_ALIGN_TRANSFER
++ }
++},
++
+ /* Digidesign Mbox */
+ {
+ /* Thanks to Clemens Ladisch <clemens@ladisch.de> */
--- /dev/null
+From 0a3ffab93fe52530602fe47cd74802cffdb19c05 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
+Date: Mon, 24 Oct 2016 15:20:29 +0200
+Subject: ANDROID: binder: Add strong ref checks
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Arve Hjønnevåg <arve@android.com>
+
+commit 0a3ffab93fe52530602fe47cd74802cffdb19c05 upstream.
+
+Prevent using a binder_ref with only weak references where a strong
+reference is required.
+
+Signed-off-by: Arve Hjønnevåg <arve@android.com>
+Signed-off-by: Martijn Coenen <maco@android.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/android/binder.c | 30 +++++++++++++++++++++---------
+ 1 file changed, 21 insertions(+), 9 deletions(-)
+
+--- a/drivers/android/binder.c
++++ b/drivers/android/binder.c
+@@ -1003,7 +1003,7 @@ static int binder_dec_node(struct binder
+
+
+ static struct binder_ref *binder_get_ref(struct binder_proc *proc,
+- uint32_t desc)
++ u32 desc, bool need_strong_ref)
+ {
+ struct rb_node *n = proc->refs_by_desc.rb_node;
+ struct binder_ref *ref;
+@@ -1011,12 +1011,16 @@ static struct binder_ref *binder_get_ref
+ while (n) {
+ ref = rb_entry(n, struct binder_ref, rb_node_desc);
+
+- if (desc < ref->desc)
++ if (desc < ref->desc) {
+ n = n->rb_left;
+- else if (desc > ref->desc)
++ } else if (desc > ref->desc) {
+ n = n->rb_right;
+- else
++ } else if (need_strong_ref && !ref->strong) {
++ binder_user_error("tried to use weak ref as strong ref\n");
++ return NULL;
++ } else {
+ return ref;
++ }
+ }
+ return NULL;
+ }
+@@ -1286,7 +1290,10 @@ static void binder_transaction_buffer_re
+ } break;
+ case BINDER_TYPE_HANDLE:
+ case BINDER_TYPE_WEAK_HANDLE: {
+- struct binder_ref *ref = binder_get_ref(proc, fp->handle);
++ struct binder_ref *ref;
++
++ ref = binder_get_ref(proc, fp->handle,
++ fp->type == BINDER_TYPE_HANDLE);
+
+ if (ref == NULL) {
+ pr_err("transaction release %d bad handle %d\n",
+@@ -1381,7 +1388,7 @@ static void binder_transaction(struct bi
+ if (tr->target.handle) {
+ struct binder_ref *ref;
+
+- ref = binder_get_ref(proc, tr->target.handle);
++ ref = binder_get_ref(proc, tr->target.handle, true);
+ if (ref == NULL) {
+ binder_user_error("%d:%d got transaction to invalid handle\n",
+ proc->pid, thread->pid);
+@@ -1590,7 +1597,10 @@ static void binder_transaction(struct bi
+ } break;
+ case BINDER_TYPE_HANDLE:
+ case BINDER_TYPE_WEAK_HANDLE: {
+- struct binder_ref *ref = binder_get_ref(proc, fp->handle);
++ struct binder_ref *ref;
++
++ ref = binder_get_ref(proc, fp->handle,
++ fp->type == BINDER_TYPE_HANDLE);
+
+ if (ref == NULL) {
+ binder_user_error("%d:%d got transaction with invalid handle, %d\n",
+@@ -1801,7 +1811,9 @@ static int binder_thread_write(struct bi
+ ref->desc);
+ }
+ } else
+- ref = binder_get_ref(proc, target);
++ ref = binder_get_ref(proc, target,
++ cmd == BC_ACQUIRE ||
++ cmd == BC_RELEASE);
+ if (ref == NULL) {
+ binder_user_error("%d:%d refcount change on invalid ref %d\n",
+ proc->pid, thread->pid, target);
+@@ -1997,7 +2009,7 @@ static int binder_thread_write(struct bi
+ if (get_user(cookie, (binder_uintptr_t __user *)ptr))
+ return -EFAULT;
+ ptr += sizeof(binder_uintptr_t);
+- ref = binder_get_ref(proc, target);
++ ref = binder_get_ref(proc, target, false);
+ if (ref == NULL) {
+ binder_user_error("%d:%d %s invalid ref %d\n",
+ proc->pid, thread->pid,
--- /dev/null
+From 4afb604e2d14d429ac9e1fd84b952602853b2df5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
+Date: Mon, 24 Oct 2016 15:20:30 +0200
+Subject: ANDROID: binder: Clear binder and cookie when setting handle in flat binder struct
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Arve Hjønnevåg <arve@android.com>
+
+commit 4afb604e2d14d429ac9e1fd84b952602853b2df5 upstream.
+
+Prevents leaking pointers between processes
+
+Signed-off-by: Arve Hjønnevåg <arve@android.com>
+Signed-off-by: Martijn Coenen <maco@android.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/android/binder.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/android/binder.c
++++ b/drivers/android/binder.c
+@@ -1585,7 +1585,9 @@ static void binder_transaction(struct bi
+ fp->type = BINDER_TYPE_HANDLE;
+ else
+ fp->type = BINDER_TYPE_WEAK_HANDLE;
++ fp->binder = 0;
+ fp->handle = ref->desc;
++ fp->cookie = 0;
+ binder_inc_ref(ref, fp->type == BINDER_TYPE_HANDLE,
+ &thread->todo);
+
+@@ -1635,7 +1637,9 @@ static void binder_transaction(struct bi
+ return_error = BR_FAILED_REPLY;
+ goto err_binder_get_ref_for_node_failed;
+ }
++ fp->binder = 0;
+ fp->handle = new_ref->desc;
++ fp->cookie = 0;
+ binder_inc_ref(new_ref, fp->type == BINDER_TYPE_HANDLE, NULL);
+ trace_binder_transaction_ref_to_ref(t, ref,
+ new_ref);
+@@ -1689,6 +1693,7 @@ static void binder_transaction(struct bi
+ binder_debug(BINDER_DEBUG_TRANSACTION,
+ " fd %d -> %d\n", fp->handle, target_fd);
+ /* TODO: fput? */
++ fp->binder = 0;
+ fp->handle = target_fd;
+ } break;
+
--- /dev/null
+From 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b Mon Sep 17 00:00:00 2001
+From: Chris Mason <clm@fb.com>
+Date: Thu, 27 Oct 2016 10:42:20 -0700
+Subject: btrfs: fix races on root_log_ctx lists
+
+From: Chris Mason <clm@fb.com>
+
+commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b upstream.
+
+btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the
+list because it knows all of the waiters are patiently waiting for the
+commit to finish.
+
+But, there's a small race where btrfs_sync_log can remove itself from
+the list if it finds a log commit is already done. Also, it uses
+list_del_init() to remove itself from the list, but there's no way to
+know if btrfs_remove_all_log_ctxs has already run, so we don't know for
+sure if it is safe to call list_del_init().
+
+This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and
+just calls it with the proper locking.
+
+This is part two of the corruption fixed by cbd60aa7cd1. I should have
+done this in the first place, but convinced myself the optimizations were
+safe. A 12 hour run of dbench 2048 will eventually trigger a list debug
+WARN_ON for the list_del_init() in btrfs_sync_log().
+
+Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4
+Reported-by: Dave Jones <davej@codemonkey.org.uk>
+Signed-off-by: Chris Mason <clm@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/tree-log.c | 20 ++++++--------------
+ 1 file changed, 6 insertions(+), 14 deletions(-)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -2713,14 +2713,12 @@ static inline void btrfs_remove_all_log_
+ int index, int error)
+ {
+ struct btrfs_log_ctx *ctx;
++ struct btrfs_log_ctx *safe;
+
+- if (!error) {
+- INIT_LIST_HEAD(&root->log_ctxs[index]);
+- return;
+- }
+-
+- list_for_each_entry(ctx, &root->log_ctxs[index], list)
++ list_for_each_entry_safe(ctx, safe, &root->log_ctxs[index], list) {
++ list_del_init(&ctx->list);
+ ctx->log_ret = error;
++ }
+
+ INIT_LIST_HEAD(&root->log_ctxs[index]);
+ }
+@@ -2961,13 +2959,9 @@ int btrfs_sync_log(struct btrfs_trans_ha
+ mutex_unlock(&root->log_mutex);
+
+ out_wake_log_root:
+- /*
+- * We needn't get log_mutex here because we are sure all
+- * the other tasks are blocked.
+- */
++ mutex_lock(&log_root_tree->log_mutex);
+ btrfs_remove_all_log_ctxs(log_root_tree, index2, ret);
+
+- mutex_lock(&log_root_tree->log_mutex);
+ log_root_tree->log_transid_committed++;
+ atomic_set(&log_root_tree->log_commit[index2], 0);
+ mutex_unlock(&log_root_tree->log_mutex);
+@@ -2978,10 +2972,8 @@ out_wake_log_root:
+ if (waitqueue_active(&log_root_tree->log_commit_wait[index2]))
+ wake_up(&log_root_tree->log_commit_wait[index2]);
+ out:
+- /* See above. */
+- btrfs_remove_all_log_ctxs(root, index1, ret);
+-
+ mutex_lock(&root->log_mutex);
++ btrfs_remove_all_log_ctxs(root, index1, ret);
+ root->log_transid_committed++;
+ atomic_set(&root->log_commit[index1], 0);
+ mutex_unlock(&root->log_mutex);
--- /dev/null
+From a05b82d5149dfeef05254a11c3636a89a854520a Mon Sep 17 00:00:00 2001
+From: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
+Date: Fri, 21 Oct 2016 14:53:53 +0530
+Subject: cxl: Fix leaking pid refs in some error paths
+
+From: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
+
+commit a05b82d5149dfeef05254a11c3636a89a854520a upstream.
+
+In some error paths in functions cxl_start_context and
+afu_ioctl_start_work pid references to the current & group-leader tasks
+can leak after they are taken. This patch fixes these error paths to
+release these pid references before exiting the error path.
+
+Fixes: 7b8ad495d592 ("cxl: Fix DSI misses when the context owning task exits")
+Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
+Reported-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
+Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
+Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/cxl/api.c | 2 ++
+ drivers/misc/cxl/file.c | 22 +++++++++++++---------
+ 2 files changed, 15 insertions(+), 9 deletions(-)
+
+--- a/drivers/misc/cxl/api.c
++++ b/drivers/misc/cxl/api.c
+@@ -247,7 +247,9 @@ int cxl_start_context(struct cxl_context
+ cxl_ctx_get();
+
+ if ((rc = cxl_ops->attach_process(ctx, kernel, wed, 0))) {
++ put_pid(ctx->glpid);
+ put_pid(ctx->pid);
++ ctx->glpid = ctx->pid = NULL;
+ cxl_adapter_context_put(ctx->afu->adapter);
+ cxl_ctx_put();
+ goto out;
+--- a/drivers/misc/cxl/file.c
++++ b/drivers/misc/cxl/file.c
+@@ -194,6 +194,16 @@ static long afu_ioctl_start_work(struct
+ ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF);
+
+ /*
++ * Increment the mapped context count for adapter. This also checks
++ * if adapter_context_lock is taken.
++ */
++ rc = cxl_adapter_context_get(ctx->afu->adapter);
++ if (rc) {
++ afu_release_irqs(ctx, ctx);
++ goto out;
++ }
++
++ /*
+ * We grab the PID here and not in the file open to allow for the case
+ * where a process (master, some daemon, etc) has opened the chardev on
+ * behalf of another process, so the AFU's mm gets bound to the process
+@@ -205,15 +215,6 @@ static long afu_ioctl_start_work(struct
+ ctx->pid = get_task_pid(current, PIDTYPE_PID);
+ ctx->glpid = get_task_pid(current->group_leader, PIDTYPE_PID);
+
+- /*
+- * Increment the mapped context count for adapter. This also checks
+- * if adapter_context_lock is taken.
+- */
+- rc = cxl_adapter_context_get(ctx->afu->adapter);
+- if (rc) {
+- afu_release_irqs(ctx, ctx);
+- goto out;
+- }
+
+ trace_cxl_attach(ctx, work.work_element_descriptor, work.num_interrupts, amr);
+
+@@ -221,6 +222,9 @@ static long afu_ioctl_start_work(struct
+ amr))) {
+ afu_release_irqs(ctx, ctx);
+ cxl_adapter_context_put(ctx->afu->adapter);
++ put_pid(ctx->glpid);
++ put_pid(ctx->pid);
++ ctx->glpid = ctx->pid = NULL;
+ goto out;
+ }
+
--- /dev/null
+From 52e73eb2872c9af6f382b2b22954ca8214397a4e Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Thu, 27 Oct 2016 17:04:05 -0700
+Subject: device-dax: fix percpu_ref_exit ordering
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 52e73eb2872c9af6f382b2b22954ca8214397a4e upstream.
+
+We need to wait until the percpu_ref is released before exit. Otherwise,
+we sometimes lose the race and trigger this new warning that was added
+in v4.9 (commit a67823c1ed10 "percpu-refcount: init ->confirm_switch
+member properly"):
+
+ WARNING: CPU: 0 PID: 3629 at lib/percpu-refcount.c:107 percpu_ref_exit+0x51/0x60
+ [..]
+ Call Trace:
+ [<ffffffff814bf093>] dump_stack+0x85/0xc2
+ [<ffffffff810b15db>] __warn+0xcb/0xf0
+ [<ffffffff810b170d>] warn_slowpath_null+0x1d/0x20
+ [<ffffffff814d70c1>] percpu_ref_exit+0x51/0x60
+ [<ffffffffa005706a>] dax_pmem_percpu_exit+0x1a/0x50 [dax_pmem]
+ [<ffffffff81615f1f>] devm_action_release+0xf/0x20
+
+Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dax/pmem.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/dax/pmem.c
++++ b/drivers/dax/pmem.c
+@@ -44,7 +44,6 @@ static void dax_pmem_percpu_exit(void *d
+
+ dev_dbg(dax_pmem->dev, "%s\n", __func__);
+ percpu_ref_exit(ref);
+- wait_for_completion(&dax_pmem->cmp);
+ }
+
+ static void dax_pmem_percpu_kill(void *data)
+@@ -54,6 +53,7 @@ static void dax_pmem_percpu_kill(void *d
+
+ dev_dbg(dax_pmem->dev, "%s\n", __func__);
+ percpu_ref_kill(ref);
++ wait_for_completion(&dax_pmem->cmp);
+ }
+
+ static int dax_pmem_probe(struct device *dev)
--- /dev/null
+From 67bf5156edc4f58241fd7c119ae145c552adddd6 Mon Sep 17 00:00:00 2001
+From: David Arcari <darcari@redhat.com>
+Date: Wed, 12 Oct 2016 18:40:30 +0200
+Subject: gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()
+
+From: David Arcari <darcari@redhat.com>
+
+commit 67bf5156edc4f58241fd7c119ae145c552adddd6 upstream.
+
+acpi_dev_gpio_irq_get() currently ignores the error returned
+by acpi_get_gpiod_by_index() and overwrites it with -ENOENT.
+
+Problem is this error can be -EPROBE_DEFER, which just blows
+up some drivers when the module ordering is not correct.
+
+Signed-off-by: David Arcari <darcari@redhat.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib-acpi.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib-acpi.c
++++ b/drivers/gpio/gpiolib-acpi.c
+@@ -602,14 +602,17 @@ int acpi_dev_gpio_irq_get(struct acpi_de
+ {
+ int idx, i;
+ unsigned int irq_flags;
++ int ret = -ENOENT;
+
+ for (i = 0, idx = 0; idx <= index; i++) {
+ struct acpi_gpio_info info;
+ struct gpio_desc *desc;
+
+ desc = acpi_get_gpiod_by_index(adev, NULL, i, &info);
+- if (IS_ERR(desc))
++ if (IS_ERR(desc)) {
++ ret = PTR_ERR(desc);
+ break;
++ }
+ if (info.gpioint && idx++ == index) {
+ int irq = gpiod_to_irq(desc);
+
+@@ -628,7 +631,7 @@ int acpi_dev_gpio_irq_get(struct acpi_de
+ }
+
+ }
+- return -ENOENT;
++ return ret;
+ }
+ EXPORT_SYMBOL_GPL(acpi_dev_gpio_irq_get);
+
--- /dev/null
+From 0f4bbb233743bdfd51d47688b0bc2561f310488b Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:00 +0200
+Subject: gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 0f4bbb233743bdfd51d47688b0bc2561f310488b upstream.
+
+The GPIO_GET_CHIPINFO_IOCTL handler allocates a gpiochip_info struct on the
+stack and then passes it to copy_to_user(). But depending on the length of
+the GPIO chip name and label the struct is only partially initialized.
+
+This exposes the previous, potentially sensitive, stack content to the
+issuing userspace application. To avoid this make sure that the struct is
+fully initialized.
+
+Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -821,6 +821,8 @@ static long gpio_ioctl(struct file *filp
+ if (cmd == GPIO_GET_CHIPINFO_IOCTL) {
+ struct gpiochip_info chipinfo;
+
++ memset(&chipinfo, 0, sizeof(chipinfo));
++
+ strncpy(chipinfo.name, dev_name(&gdev->dev),
+ sizeof(chipinfo.name));
+ chipinfo.name[sizeof(chipinfo.name)-1] = '\0';
--- /dev/null
+From 1f1cc4566bd9dd8d3cf19965a4b6392143618536 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:53:59 +0200
+Subject: gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 1f1cc4566bd9dd8d3cf19965a4b6392143618536 upstream.
+
+The current line offset validation is off by one. Depending on the data
+stored behind the descs array this can either cause undefined behavior or
+disclose arbitrary, potentially sensitive, memory to the issuing userspace
+application.
+
+Make sure that offset is within the bounds of the desc array.
+
+Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -837,7 +837,7 @@ static long gpio_ioctl(struct file *filp
+
+ if (copy_from_user(&lineinfo, ip, sizeof(lineinfo)))
+ return -EFAULT;
+- if (lineinfo.line_offset > gdev->ngpio)
++ if (lineinfo.line_offset >= gdev->ngpio)
+ return -EINVAL;
+
+ desc = &gdev->descs[lineinfo.line_offset];
--- /dev/null
+From 953b956a2e6d35298e684f251bad98ea6c96f982 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Mon, 24 Oct 2016 13:59:15 +0200
+Subject: gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 953b956a2e6d35298e684f251bad98ea6c96f982 upstream.
+
+When allocating a new line handle or event a file is allocated that it is
+associated to. The file is attached to a file descriptor of the current
+process and the file descriptor is returned to userspace using
+copy_to_user(). If this copy operation fails the line handle or event
+allocation is aborted, all acquired resources are freed and an error is
+returned.
+
+But the file struct is not freed and left attached to the userspace
+application and even though the file descriptor number was not copied it is
+trivial to guess. If a userspace application performs a IOCTL on such a
+left over file descriptor it will trigger a use-after-free and if the file
+descriptor is closed (latest when the application exits) a double-free is
+triggered.
+
+anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
+file descriptor for the current process and install the file struct in the
+file descriptor. As soon as the file struct is installed in the file
+descriptor it is accessible by userspace (even if the IOCTL itself hasn't
+completed yet), this means uninstalling the fd on the error path is not an
+option, since userspace might already got a reference to the file.
+
+Instead anon_inode_getfd() needs to be broken into its individual steps.
+The allocation of the file struct and file descriptor is done first, then
+the copy_to_user() is executed and only if it succeeds the file is
+installed.
+
+Since the file struct is reference counted it can not be just freed, but
+its reference needs to be dropped, which will also call the release()
+callback, which will free the state attached to the file. So in this case
+the normal error cleanup path should not be taken.
+
+Fixes: d932cd49182f ("gpio: free handles in fringe cases")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 57 ++++++++++++++++++++++++++++++++++++++-----------
+ 1 file changed, 45 insertions(+), 12 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -21,6 +21,7 @@
+ #include <linux/uaccess.h>
+ #include <linux/compat.h>
+ #include <linux/anon_inodes.h>
++#include <linux/file.h>
+ #include <linux/kfifo.h>
+ #include <linux/poll.h>
+ #include <linux/timekeeping.h>
+@@ -421,6 +422,7 @@ static int linehandle_create(struct gpio
+ {
+ struct gpiohandle_request handlereq;
+ struct linehandle_state *lh;
++ struct file *file;
+ int fd, i, ret;
+
+ if (copy_from_user(&handlereq, ip, sizeof(handlereq)))
+@@ -497,26 +499,41 @@ static int linehandle_create(struct gpio
+ i--;
+ lh->numdescs = handlereq.lines;
+
+- fd = anon_inode_getfd("gpio-linehandle",
+- &linehandle_fileops,
+- lh,
+- O_RDONLY | O_CLOEXEC);
++ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
+ if (fd < 0) {
+ ret = fd;
+ goto out_free_descs;
+ }
+
++ file = anon_inode_getfile("gpio-linehandle",
++ &linehandle_fileops,
++ lh,
++ O_RDONLY | O_CLOEXEC);
++ if (IS_ERR(file)) {
++ ret = PTR_ERR(file);
++ goto out_put_unused_fd;
++ }
++
+ handlereq.fd = fd;
+ if (copy_to_user(ip, &handlereq, sizeof(handlereq))) {
+- ret = -EFAULT;
+- goto out_free_descs;
++ /*
++ * fput() will trigger the release() callback, so do not go onto
++ * the regular error cleanup path here.
++ */
++ fput(file);
++ put_unused_fd(fd);
++ return -EFAULT;
+ }
+
++ fd_install(fd, file);
++
+ dev_dbg(&gdev->dev, "registered chardev handle for %d lines\n",
+ lh->numdescs);
+
+ return 0;
+
++out_put_unused_fd:
++ put_unused_fd(fd);
+ out_free_descs:
+ for (; i >= 0; i--)
+ gpiod_free(lh->descs[i]);
+@@ -719,6 +736,7 @@ static int lineevent_create(struct gpio_
+ struct gpioevent_request eventreq;
+ struct lineevent_state *le;
+ struct gpio_desc *desc;
++ struct file *file;
+ u32 offset;
+ u32 lflags;
+ u32 eflags;
+@@ -813,23 +831,38 @@ static int lineevent_create(struct gpio_
+ if (ret)
+ goto out_free_desc;
+
+- fd = anon_inode_getfd("gpio-event",
+- &lineevent_fileops,
+- le,
+- O_RDONLY | O_CLOEXEC);
++ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
+ if (fd < 0) {
+ ret = fd;
+ goto out_free_irq;
+ }
+
++ file = anon_inode_getfile("gpio-event",
++ &lineevent_fileops,
++ le,
++ O_RDONLY | O_CLOEXEC);
++ if (IS_ERR(file)) {
++ ret = PTR_ERR(file);
++ goto out_put_unused_fd;
++ }
++
+ eventreq.fd = fd;
+ if (copy_to_user(ip, &eventreq, sizeof(eventreq))) {
+- ret = -EFAULT;
+- goto out_free_irq;
++ /*
++ * fput() will trigger the release() callback, so do not go onto
++ * the regular error cleanup path here.
++ */
++ fput(file);
++ put_unused_fd(fd);
++ return -EFAULT;
+ }
+
++ fd_install(fd, file);
++
+ return 0;
+
++out_put_unused_fd:
++ put_unused_fd(fd);
+ out_free_irq:
+ free_irq(le->irq, le);
+ out_free_desc:
--- /dev/null
+From ac7dbb991ee5afc0beacce3a252dcaaa249a7786 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:06 +0200
+Subject: gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit ac7dbb991ee5afc0beacce3a252dcaaa249a7786 upstream.
+
+The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined
+linehandle and lineevent flags. From a backwards and forwards compatibility
+viewpoint it is highly desirable to reject unknown flags though.
+
+On one hand an application that is using newer flags and is running on
+an older kernel has no way to detect if the new flags were handled
+correctly if they are silently discarded.
+
+On the other hand an application that (accidentally) passes undefined flags
+will run fine on an older kernel, but may break on a newer kernel when
+these flags get defined.
+
+Ensure that requests that have undefined flags set are rejected with an
+error, rather than silently discarding the undefined flags.
+
+Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -554,6 +554,10 @@ struct lineevent_state {
+ struct mutex read_lock;
+ };
+
++#define GPIOEVENT_REQUEST_VALID_FLAGS \
++ (GPIOEVENT_REQUEST_RISING_EDGE | \
++ GPIOEVENT_REQUEST_FALLING_EDGE)
++
+ static unsigned int lineevent_poll(struct file *filep,
+ struct poll_table_struct *wait)
+ {
+@@ -748,6 +752,13 @@ static int lineevent_create(struct gpio_
+ ret = -EINVAL;
+ goto out_free_label;
+ }
++
++ /* Return an error if a unknown flag is set */
++ if ((lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) ||
++ (eflags & ~GPIOEVENT_REQUEST_VALID_FLAGS)) {
++ ret = -EINVAL;
++ goto out_free_label;
++ }
+
+ /* This is just wrong: we don't look for events on output lines */
+ if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {
--- /dev/null
+From b8b0e3d303654b3bb7b31b0266c513fd6f4132ce Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:03 +0200
+Subject: gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit b8b0e3d303654b3bb7b31b0266c513fd6f4132ce upstream.
+
+The line offset that is used as an index into the descs array is provided
+by userspace and might go beyond the bounds of the array. If that happens
+undefined behavior will occur.
+
+Make sure that the offset is within the bounds of the desc array and reject
+any requests that specify a value outside of it.
+
+Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -731,6 +731,11 @@ static int lineevent_create(struct gpio_
+ lflags = eventreq.handleflags;
+ eflags = eventreq.eventflags;
+
++ if (offset >= gdev->ngpio) {
++ ret = -EINVAL;
++ goto out_free_label;
++ }
++
+ /* This is just wrong: we don't look for events on output lines */
+ if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {
+ ret = -EINVAL;
--- /dev/null
+From e3e847c7f15a27c80f526b2a7a8d4dd7ce0960a0 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:05 +0200
+Subject: gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit e3e847c7f15a27c80f526b2a7a8d4dd7ce0960a0 upstream.
+
+The GPIO_GET_LINEHANDLE_IOCTL currently ignores unknown or undefined
+linehandle flags. From a backwards and forwards compatibility viewpoint it
+is highly desirable to reject unknown flags though.
+
+On one hand an application that is using newer flags and is running on
+an older kernel has no way to detect if the new flags were handled
+correctly if they are silently discarded.
+
+On the other hand an application that (accidentally) passes undefined flags
+will run fine on an older kernel, but may break on a newer kernel when
+these flags get defined.
+
+Ensure that requests that have undefined flags set are rejected with an
+error, rather than silently discarding the undefined flags.
+
+Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -331,6 +331,13 @@ struct linehandle_state {
+ u32 numdescs;
+ };
+
++#define GPIOHANDLE_REQUEST_VALID_FLAGS \
++ (GPIOHANDLE_REQUEST_INPUT | \
++ GPIOHANDLE_REQUEST_OUTPUT | \
++ GPIOHANDLE_REQUEST_ACTIVE_LOW | \
++ GPIOHANDLE_REQUEST_OPEN_DRAIN | \
++ GPIOHANDLE_REQUEST_OPEN_SOURCE)
++
+ static long linehandle_ioctl(struct file *filep, unsigned int cmd,
+ unsigned long arg)
+ {
+@@ -448,6 +455,12 @@ static int linehandle_create(struct gpio
+ ret = -EINVAL;
+ goto out_free_descs;
+ }
++
++ /* Return an error if a unknown flag is set */
++ if (lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) {
++ ret = -EINVAL;
++ goto out_free_descs;
++ }
+
+ desc = &gdev->descs[offset];
+ ret = gpiod_request(desc, lh->label);
--- /dev/null
+From e405f9fcb63602d35f7a419ededa3f952a395a72 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:01 +0200
+Subject: gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream.
+
+The line offset that is used as an index into the descs array is provided
+by userspace and might go beyond the bounds of the array. If that happens
+undefined behavior will occur.
+
+Make sure that the offset is within the bounds of the desc array and reject
+any requests that specify a value outside of it.
+
+Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -442,6 +442,11 @@ static int linehandle_create(struct gpio
+ u32 lflags = handlereq.flags;
+ struct gpio_desc *desc;
+
++ if (offset >= gdev->ngpio) {
++ ret = -EINVAL;
++ goto out_free_descs;
++ }
++
+ desc = &gdev->descs[offset];
+ ret = gpiod_request(desc, lh->label);
+ if (ret)
--- /dev/null
+From d82aa4a8f2e8df9673ddb099262355da4c9b99b1 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:04 +0200
+Subject: gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix another information leak
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit d82aa4a8f2e8df9673ddb099262355da4c9b99b1 upstream.
+
+The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data
+struct on the stack and then passes it to copy_to_user(). But only the
+first element of the values array in the struct is set, which leaves the
+struct partially initialized.
+
+This exposes the previous, potentially sensitive, stack content to the
+issuing userspace application. To avoid this make sure that the struct is
+fully initialized.
+
+Cc: stable@vger.kernel.org
+Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -645,6 +645,8 @@ static long lineevent_ioctl(struct file
+ if (cmd == GPIOHANDLE_GET_LINE_VALUES_IOCTL) {
+ int val;
+
++ memset(&ghd, 0, sizeof(ghd));
++
+ val = gpiod_get_value_cansleep(le->desc);
+ if (val < 0)
+ return val;
--- /dev/null
+From 3eded5d83bf4e36ad78775c7ceb44a45480b0abd Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Tue, 18 Oct 2016 16:54:02 +0200
+Subject: gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 3eded5d83bf4e36ad78775c7ceb44a45480b0abd upstream.
+
+The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data
+struct on the stack and then passes it to copy_to_user(). But depending on
+the number of requested line handles the struct is only partially
+initialized.
+
+This exposes the previous, potentially sensitive, stack content to the
+issuing userspace application. To avoid this make sure that the struct is
+fully initialized.
+
+Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -342,6 +342,8 @@ static long linehandle_ioctl(struct file
+ if (cmd == GPIOHANDLE_GET_LINE_VALUES_IOCTL) {
+ int val;
+
++ memset(&ghd, 0, sizeof(ghd));
++
+ /* TODO: check if descriptors are really input */
+ for (i = 0; i < lh->numdescs; i++) {
+ val = gpiod_get_value_cansleep(lh->descs[i]);
--- /dev/null
+From 03dab869b7b239c4e013ec82aea22e181e441cfc Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 26 Oct 2016 15:01:54 +0100
+Subject: KEYS: Fix short sprintf buffer in /proc/keys show function
+
+From: David Howells <dhowells@redhat.com>
+
+commit 03dab869b7b239c4e013ec82aea22e181e441cfc upstream.
+
+This fixes CVE-2016-7042.
+
+Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector
+is turned on, this can cause a panic due to stack corruption.
+
+The problem is that xbuf[] is not big enough to hold a 64-bit timeout
+rendered as weeks:
+
+ (gdb) p 0xffffffffffffffffULL/(60*60*24*7)
+ $2 = 30500568904943
+
+That's 14 chars plus NUL, not 11 chars plus NUL.
+
+Expand the buffer to 16 chars.
+
+I think the unpatched code apparently works if the stack-protector is not
+enabled because on a 32-bit machine the buffer won't be overflowed and on a
+64-bit machine there's a 64-bit aligned pointer at one side and an int that
+isn't checked again on the other side.
+
+The panic incurred looks something like:
+
+Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
+CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
+Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
+ 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
+ ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
+ ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
+Call Trace:
+ [<ffffffff813d941f>] dump_stack+0x63/0x84
+ [<ffffffff811b2cb6>] panic+0xde/0x22a
+ [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
+ [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
+ [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
+ [<ffffffff81350410>] ? key_validate+0x50/0x50
+ [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
+ [<ffffffff8126b31c>] seq_read+0x2cc/0x390
+ [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
+ [<ffffffff81244fc7>] __vfs_read+0x37/0x150
+ [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
+ [<ffffffff81246156>] vfs_read+0x96/0x130
+ [<ffffffff81247635>] SyS_read+0x55/0xc0
+ [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
+
+Reported-by: Ondrej Kozina <okozina@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Tested-by: Ondrej Kozina <okozina@redhat.com>
+Signed-off-by: James Morris <james.l.morris@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/proc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/security/keys/proc.c
++++ b/security/keys/proc.c
+@@ -181,7 +181,7 @@ static int proc_keys_show(struct seq_fil
+ struct timespec now;
+ unsigned long timo;
+ key_ref_t key_ref, skey_ref;
+- char xbuf[12];
++ char xbuf[16];
+ int rc;
+
+ struct keyring_search_context ctx = {
--- /dev/null
+From 7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 26 Oct 2016 15:02:01 +0100
+Subject: KEYS: Sort out big_key initialisation
+
+From: David Howells <dhowells@redhat.com>
+
+commit 7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb upstream.
+
+big_key has two separate initialisation functions, one that registers the
+key type and one that registers the crypto. If the key type fails to
+register, there's no problem if the crypto registers successfully because
+there's no way to reach the crypto except through the key type.
+
+However, if the key type registers successfully but the crypto does not,
+big_key_rng and big_key_blkcipher may end up set to NULL - but the code
+neither checks for this nor unregisters the big key key type.
+
+Furthermore, since the key type is registered before the crypto, it is
+theoretically possible for the kernel to try adding a big_key before the
+crypto is set up, leading to the same effect.
+
+Fix this by merging big_key_crypto_init() and big_key_init() and calling
+the resulting function late. If they're going to be encrypted, we
+shouldn't be creating big_keys before we have the facilities to do the
+encryption available. The key type registration is also moved after the
+crypto initialisation.
+
+The fix also includes message printing on failure.
+
+If the big_key type isn't correctly set up, simply doing:
+
+ dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s
+
+ought to cause an oops.
+
+Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Peter Hlavaty <zer0mem@yahoo.com>
+cc: Kirill Marinushkin <k.marinushkin@gmail.com>
+cc: Artem Savkov <asavkov@redhat.com>
+Signed-off-by: James Morris <james.l.morris@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/big_key.c | 59 ++++++++++++++++++++++++++----------------------
+ 1 file changed, 32 insertions(+), 27 deletions(-)
+
+--- a/security/keys/big_key.c
++++ b/security/keys/big_key.c
+@@ -9,6 +9,7 @@
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
++#define pr_fmt(fmt) "big_key: "fmt
+ #include <linux/init.h>
+ #include <linux/seq_file.h>
+ #include <linux/file.h>
+@@ -341,44 +342,48 @@ error:
+ */
+ static int __init big_key_init(void)
+ {
+- return register_key_type(&key_type_big_key);
+-}
+-
+-/*
+- * Initialize big_key crypto and RNG algorithms
+- */
+-static int __init big_key_crypto_init(void)
+-{
+- int ret = -EINVAL;
++ struct crypto_skcipher *cipher;
++ struct crypto_rng *rng;
++ int ret;
+
+- /* init RNG */
+- big_key_rng = crypto_alloc_rng(big_key_rng_name, 0, 0);
+- if (IS_ERR(big_key_rng)) {
+- big_key_rng = NULL;
+- return -EFAULT;
++ rng = crypto_alloc_rng(big_key_rng_name, 0, 0);
++ if (IS_ERR(rng)) {
++ pr_err("Can't alloc rng: %ld\n", PTR_ERR(rng));
++ return PTR_ERR(rng);
+ }
+
++ big_key_rng = rng;
++
+ /* seed RNG */
+- ret = crypto_rng_reset(big_key_rng, NULL, crypto_rng_seedsize(big_key_rng));
+- if (ret)
+- goto error;
++ ret = crypto_rng_reset(rng, NULL, crypto_rng_seedsize(rng));
++ if (ret) {
++ pr_err("Can't reset rng: %d\n", ret);
++ goto error_rng;
++ }
+
+ /* init block cipher */
+- big_key_skcipher = crypto_alloc_skcipher(big_key_alg_name,
+- 0, CRYPTO_ALG_ASYNC);
+- if (IS_ERR(big_key_skcipher)) {
+- big_key_skcipher = NULL;
+- ret = -EFAULT;
+- goto error;
++ cipher = crypto_alloc_skcipher(big_key_alg_name, 0, CRYPTO_ALG_ASYNC);
++ if (IS_ERR(cipher)) {
++ ret = PTR_ERR(cipher);
++ pr_err("Can't alloc crypto: %d\n", ret);
++ goto error_rng;
++ }
++
++ big_key_skcipher = cipher;
++
++ ret = register_key_type(&key_type_big_key);
++ if (ret < 0) {
++ pr_err("Can't register type: %d\n", ret);
++ goto error_cipher;
+ }
+
+ return 0;
+
+-error:
++error_cipher:
++ crypto_free_skcipher(big_key_skcipher);
++error_rng:
+ crypto_free_rng(big_key_rng);
+- big_key_rng = NULL;
+ return ret;
+ }
+
+-device_initcall(big_key_init);
+-late_initcall(big_key_crypto_init);
++late_initcall(big_key_init);
--- /dev/null
+From 58d789678546d46d7bbd809dd7dab417c0f23655 Mon Sep 17 00:00:00 2001
+From: "Darrick J. Wong" <darrick.wong@oracle.com>
+Date: Thu, 20 Oct 2016 15:46:18 +1100
+Subject: libxfs: clean up _calc_dquots_per_chunk
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+commit 58d789678546d46d7bbd809dd7dab417c0f23655 upstream.
+
+The function xfs_calc_dquots_per_chunk takes a parameter in units
+of basic blocks. The kernel seems to get the units wrong, but
+userspace got 'fixed' by commenting out the unnecessary conversion.
+Fix both.
+
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Reviewed-by: Eric Sandeen <sandeen@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/libxfs/xfs_dquot_buf.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/fs/xfs/libxfs/xfs_dquot_buf.c
++++ b/fs/xfs/libxfs/xfs_dquot_buf.c
+@@ -191,8 +191,7 @@ xfs_dquot_buf_verify_crc(
+ if (mp->m_quotainfo)
+ ndquots = mp->m_quotainfo->qi_dqperchunk;
+ else
+- ndquots = xfs_calc_dquots_per_chunk(
+- XFS_BB_TO_FSB(mp, bp->b_length));
++ ndquots = xfs_calc_dquots_per_chunk(bp->b_length);
+
+ for (i = 0; i < ndquots; i++, d++) {
+ if (!xfs_verify_cksum((char *)d, sizeof(struct xfs_dqblk),
--- /dev/null
+From 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 Mon Sep 17 00:00:00 2001
+From: Alexander Polakov <apolyakov@beget.ru>
+Date: Thu, 27 Oct 2016 17:46:27 -0700
+Subject: mm/list_lru.c: avoid error-path NULL pointer deref
+
+From: Alexander Polakov <apolyakov@beget.ru>
+
+commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 upstream.
+
+As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821:
+
+After some analysis it seems to be that the problem is in alloc_super().
+In case list_lru_init_memcg() fails it goes into destroy_super(), which
+calls list_lru_destroy().
+
+And in list_lru_init() we see that in case memcg_init_list_lru() fails,
+lru->node is freed, but not set NULL, which then leads list_lru_destroy()
+to believe it is initialized and call memcg_destroy_list_lru().
+memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus,
+which is NULL.
+
+[akpm@linux-foundation.org: add comment]
+Signed-off-by: Alexander Polakov <apolyakov@beget.ru>
+Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/list_lru.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/list_lru.c
++++ b/mm/list_lru.c
+@@ -554,6 +554,8 @@ int __list_lru_init(struct list_lru *lru
+ err = memcg_init_list_lru(lru, memcg_aware);
+ if (err) {
+ kfree(lru->node);
++ /* Do this so a list_lru_destroy() doesn't crash: */
++ lru->node = NULL;
+ goto out;
+ }
+
--- /dev/null
+From 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Thu, 27 Oct 2016 17:46:56 -0700
+Subject: mm: memcontrol: do not recurse in direct reclaim
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+commit 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 upstream.
+
+On 4.0, we saw a stack corruption from a page fault entering direct
+memory cgroup reclaim, calling into btrfs_releasepage(), which then
+tried to allocate an extent and recursed back into a kmem charge ad
+nauseam:
+
+ [...]
+ btrfs_releasepage+0x2c/0x30
+ try_to_release_page+0x32/0x50
+ shrink_page_list+0x6da/0x7a0
+ shrink_inactive_list+0x1e5/0x510
+ shrink_lruvec+0x605/0x7f0
+ shrink_zone+0xee/0x320
+ do_try_to_free_pages+0x174/0x440
+ try_to_free_mem_cgroup_pages+0xa7/0x130
+ try_charge+0x17b/0x830
+ memcg_charge_kmem+0x40/0x80
+ new_slab+0x2d9/0x5a0
+ __slab_alloc+0x2fd/0x44f
+ kmem_cache_alloc+0x193/0x1e0
+ alloc_extent_state+0x21/0xc0
+ __clear_extent_bit+0x2b5/0x400
+ try_release_extent_mapping+0x1a3/0x220
+ __btrfs_releasepage+0x31/0x70
+ btrfs_releasepage+0x2c/0x30
+ try_to_release_page+0x32/0x50
+ shrink_page_list+0x6da/0x7a0
+ shrink_inactive_list+0x1e5/0x510
+ shrink_lruvec+0x605/0x7f0
+ shrink_zone+0xee/0x320
+ do_try_to_free_pages+0x174/0x440
+ try_to_free_mem_cgroup_pages+0xa7/0x130
+ try_charge+0x17b/0x830
+ mem_cgroup_try_charge+0x65/0x1c0
+ handle_mm_fault+0x117f/0x1510
+ __do_page_fault+0x177/0x420
+ do_page_fault+0xc/0x10
+ page_fault+0x22/0x30
+
+On later kernels, kmem charging is opt-in rather than opt-out, and that
+particular kmem allocation in btrfs_releasepage() is no longer being
+charged and won't recurse and overrun the stack anymore.
+
+But it's not impossible for an accounted allocation to happen from the
+memcg direct reclaim context, and we needed to reproduce this crash many
+times before we even got a useful stack trace out of it.
+
+Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC to
+avoid recursing into any other form of direct reclaim. Then let
+recursive charges from PF_MEMALLOC contexts bypass the cgroup limit.
+
+Link: http://lkml.kernel.org/r/20161025141050.GA13019@cmpxchg.org
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Tejun Heo <tj@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memcontrol.c | 9 +++++++++
+ mm/vmscan.c | 2 ++
+ 2 files changed, 11 insertions(+)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -1947,6 +1947,15 @@ retry:
+ current->flags & PF_EXITING))
+ goto force;
+
++ /*
++ * Prevent unbounded recursion when reclaim operations need to
++ * allocate memory. This might exceed the limits temporarily,
++ * but we prefer facilitating memory reclaim and getting back
++ * under the limit over triggering OOM kills in these cases.
++ */
++ if (unlikely(current->flags & PF_MEMALLOC))
++ goto force;
++
+ if (unlikely(task_in_memcg_oom(current)))
+ goto nomem;
+
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -3048,7 +3048,9 @@ unsigned long try_to_free_mem_cgroup_pag
+ sc.gfp_mask,
+ sc.reclaim_idx);
+
++ current->flags |= PF_MEMALLOC;
+ nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
++ current->flags &= ~PF_MEMALLOC;
+
+ trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);
+
--- /dev/null
+From 86d9f48534e800e4d62cdc1b5aaf539f4c1d47d6 Mon Sep 17 00:00:00 2001
+From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Date: Thu, 27 Oct 2016 17:46:18 -0700
+Subject: mm/slab: fix kmemcg cache creation delayed issue
+
+From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+
+commit 86d9f48534e800e4d62cdc1b5aaf539f4c1d47d6 upstream.
+
+There is a bug report that SLAB makes extreme load average due to over
+2000 kworker thread.
+
+ https://bugzilla.kernel.org/show_bug.cgi?id=172981
+
+This issue is caused by kmemcg feature that try to create new set of
+kmem_caches for each memcg. Recently, kmem_cache creation is slowed by
+synchronize_sched() and futher kmem_cache creation is also delayed since
+kmem_cache creation is synchronized by a global slab_mutex lock. So,
+the number of kworker that try to create kmem_cache increases quietly.
+
+synchronize_sched() is for lockless access to node's shared array but
+it's not needed when a new kmem_cache is created. So, this patch rules
+out that case.
+
+Fixes: 801faf0db894 ("mm/slab: lockless decision to grow cache")
+Link: http://lkml.kernel.org/r/1475734855-4837-1-git-send-email-iamjoonsoo.kim@lge.com
+Reported-by: Doug Smythies <dsmythies@telus.net>
+Tested-by: Doug Smythies <dsmythies@telus.net>
+Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Pekka Enberg <penberg@kernel.org>
+Cc: David Rientjes <rientjes@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/slab.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/slab.c
++++ b/mm/slab.c
+@@ -964,7 +964,7 @@ static int setup_kmem_cache_node(struct
+ * guaranteed to be valid until irq is re-enabled, because it will be
+ * freed after synchronize_sched().
+ */
+- if (force_change)
++ if (old_shared && force_change)
+ synchronize_sched();
+
+ fail:
--- /dev/null
+From 09b7e37b18eecc1e347f4b1a3bc863f32801f634 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Fri, 21 Oct 2016 20:04:17 +1100
+Subject: powerpc/64: Fix race condition in setting lock bit in idle/wakeup code
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 09b7e37b18eecc1e347f4b1a3bc863f32801f634 upstream.
+
+This fixes a race condition where one thread that is entering or
+leaving a power-saving state can inadvertently ignore the lock bit
+that was set by another thread, and potentially also clear it.
+The core_idle_lock_held function is called when the lock bit is
+seen to be set. It polls the lock bit until it is clear, then
+does a lwarx to load the word containing the lock bit and thread
+idle bits so it can be updated. However, it is possible that the
+value loaded with the lwarx has the lock bit set, even though an
+immediately preceding lwz loaded a value with the lock bit clear.
+If this happens then we go ahead and update the word despite the
+lock bit being set, and when called from pnv_enter_arch207_idle_mode,
+we will subsequently clear the lock bit.
+
+No identifiable misbehaviour has been attributed to this race.
+
+This fixes it by checking the lock bit in the value loaded by the
+lwarx. If it is set then we just go back and keep on polling.
+
+Fixes: b32aadc1a8ed ("powerpc/powernv: Fix race in updating core_idle_state")
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/idle_book3s.S | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/powerpc/kernel/idle_book3s.S
++++ b/arch/powerpc/kernel/idle_book3s.S
+@@ -90,6 +90,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_3
+ * Threads will spin in HMT_LOW until the lock bit is cleared.
+ * r14 - pointer to core_idle_state
+ * r15 - used to load contents of core_idle_state
++ * r9 - used as a temporary variable
+ */
+
+ core_idle_lock_held:
+@@ -99,6 +100,8 @@ core_idle_lock_held:
+ bne 3b
+ HMT_MEDIUM
+ lwarx r15,0,r14
++ andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT
++ bne core_idle_lock_held
+ blr
+
+ /*
--- /dev/null
+From 56c46222af0d09149fadec2a3ce9d4889de01cc6 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Fri, 21 Oct 2016 20:03:05 +1100
+Subject: powerpc/64: Re-fix race condition between going idle and entering guest
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 56c46222af0d09149fadec2a3ce9d4889de01cc6 upstream.
+
+Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering
+nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one
+thread entering a KVM guest could switch the MMU context to the guest
+while another thread was still in host kernel context with the MMU on.
+That commit moved the point where a thread entering a power-saving
+mode set its kvm_hstate.hwthread_state field in its PACA to
+KVM_HWTHREAD_IN_IDLE from a point where the MMU was on to after the
+MMU had been switched off. That commit also added a comment
+explaining that we have to switch to real mode before setting
+hwthread_state to avoid this race.
+
+Nevertheless, commit 4eae2c9ae54a ("powerpc/powernv: Make
+pnv_powersave_common more generic", 2016-07-08) subsequently moved
+the setting of hwthread_state back to a point where the MMU is on,
+thus reintroducing the race, despite the comment saying that this
+should not be done being included in full in the context lines of
+the patch that did it.
+
+This fixes the race again and adds a bigger and shoutier comment
+explaining the potential race condition.
+
+Fixes: 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic")
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Reviewed-by: Shreyas B. Prabhu <shreyasbp@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/idle_book3s.S | 32 ++++++++++++++++++++++++++------
+ 1 file changed, 26 insertions(+), 6 deletions(-)
+
+--- a/arch/powerpc/kernel/idle_book3s.S
++++ b/arch/powerpc/kernel/idle_book3s.S
+@@ -163,12 +163,6 @@ _GLOBAL(pnv_powersave_common)
+ std r9,_MSR(r1)
+ std r1,PACAR1(r13)
+
+-#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+- /* Tell KVM we're entering idle */
+- li r4,KVM_HWTHREAD_IN_IDLE
+- stb r4,HSTATE_HWTHREAD_STATE(r13)
+-#endif
+-
+ /*
+ * Go to real mode to do the nap, as required by the architecture.
+ * Also, we need to be in real mode before setting hwthread_state,
+@@ -185,6 +179,26 @@ _GLOBAL(pnv_powersave_common)
+
+ .globl pnv_enter_arch207_idle_mode
+ pnv_enter_arch207_idle_mode:
++#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
++ /* Tell KVM we're entering idle */
++ li r4,KVM_HWTHREAD_IN_IDLE
++ /******************************************************/
++ /* N O T E W E L L ! ! ! N O T E W E L L */
++ /* The following store to HSTATE_HWTHREAD_STATE(r13) */
++ /* MUST occur in real mode, i.e. with the MMU off, */
++ /* and the MMU must stay off until we clear this flag */
++ /* and test HSTATE_HWTHREAD_REQ(r13) in the system */
++ /* reset interrupt vector in exceptions-64s.S. */
++ /* The reason is that another thread can switch the */
++ /* MMU to a guest context whenever this flag is set */
++ /* to KVM_HWTHREAD_IN_IDLE, and if the MMU was on, */
++ /* that would potentially cause this thread to start */
++ /* executing instructions from guest memory in */
++ /* hypervisor mode, leading to a host crash or data */
++ /* corruption, or worse. */
++ /******************************************************/
++ stb r4,HSTATE_HWTHREAD_STATE(r13)
++#endif
+ stb r3,PACA_THREAD_IDLE_STATE(r13)
+ cmpwi cr3,r3,PNV_THREAD_SLEEP
+ bge cr3,2f
+@@ -250,6 +264,12 @@ enter_winkle:
+ * r3 - requested stop state
+ */
+ power_enter_stop:
++#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
++ /* Tell KVM we're entering idle */
++ li r4,KVM_HWTHREAD_IN_IDLE
++ /* DO THIS IN REAL MODE! See comment above. */
++ stb r4,HSTATE_HWTHREAD_STATE(r13)
++#endif
+ /*
+ * Check if the requested state is a deep idle state.
+ */
--- /dev/null
+From 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 Mon Sep 17 00:00:00 2001
+From: Segher Boessenkool <segher@kernel.crashing.org>
+Date: Thu, 6 Oct 2016 13:42:19 +0000
+Subject: powerpc: Convert cmp to cmpd in idle enter sequence
+
+From: Segher Boessenkool <segher@kernel.crashing.org>
+
+commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream.
+
+PowerPC's "cmp" instruction has four operands. Normally people write
+"cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
+people forget, and write "cmp" with just three operands.
+
+With older binutils this is silently accepted as if this was "cmpw",
+while often "cmpd" is wanted. With newer binutils GAS will complain
+about this for 64-bit code. For 32-bit code it still silently assumes
+"cmpw" is what is meant.
+
+In this instance the code comes directly from ISA v2.07, including the
+cmp, but cmpd is correct. Backport to stable so that new toolchains can
+build old kernels.
+
+Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
+Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
+Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/cpuidle.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/include/asm/cpuidle.h
++++ b/arch/powerpc/include/asm/cpuidle.h
+@@ -26,7 +26,7 @@ extern u64 pnv_first_deep_stop_state;
+ std r0,0(r1); \
+ ptesync; \
+ ld r0,0(r1); \
+-1: cmp cr0,r0,r0; \
++1: cmpd cr0,r0,r0; \
+ bne 1b; \
+ IDLE_INST; \
+ b .
--- /dev/null
+From bd77c4498616e27d5725b5959d880ce2272fefa9 Mon Sep 17 00:00:00 2001
+From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
+Date: Mon, 24 Oct 2016 08:50:43 +0530
+Subject: powerpc/mm/radix: Use tlbiel only if we ever ran on the current cpu
+
+From: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
+
+commit bd77c4498616e27d5725b5959d880ce2272fefa9 upstream.
+
+Before this patch, we used tlbiel, if we ever ran only on this core.
+That was mostly derived from the nohash usage of the same. But is
+incorrect, the ISA 3.0 clarifies tlbiel such that:
+
+"All TLB entries that have all of the following properties are made
+invalid on the thread executing the tlbiel instruction"
+
+ie. tlbiel only invalidates TLB entries on the current thread. So if the
+mm has been used on any other thread (aka. cpu) then we must broadcast
+the invalidate.
+
+This bug could lead to invalid TLB entries if a program runs on multiple
+threads of a core.
+
+Hence use tlbiel, if we only ever ran on only the current cpu.
+
+Fixes: 1a472c9dba6b ("powerpc/mm/radix: Add tlbflush routines")
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/tlb.h | 12 ++++++++++++
+ arch/powerpc/mm/tlb-radix.c | 8 ++++----
+ 2 files changed, 16 insertions(+), 4 deletions(-)
+
+--- a/arch/powerpc/include/asm/tlb.h
++++ b/arch/powerpc/include/asm/tlb.h
+@@ -52,11 +52,23 @@ static inline int mm_is_core_local(struc
+ return cpumask_subset(mm_cpumask(mm),
+ topology_sibling_cpumask(smp_processor_id()));
+ }
++
++static inline int mm_is_thread_local(struct mm_struct *mm)
++{
++ return cpumask_equal(mm_cpumask(mm),
++ cpumask_of(smp_processor_id()));
++}
++
+ #else
+ static inline int mm_is_core_local(struct mm_struct *mm)
+ {
+ return 1;
+ }
++
++static inline int mm_is_thread_local(struct mm_struct *mm)
++{
++ return 1;
++}
+ #endif
+
+ #endif /* __KERNEL__ */
+--- a/arch/powerpc/mm/tlb-radix.c
++++ b/arch/powerpc/mm/tlb-radix.c
+@@ -175,7 +175,7 @@ void radix__flush_tlb_mm(struct mm_struc
+ if (unlikely(pid == MMU_NO_CONTEXT))
+ goto no_context;
+
+- if (!mm_is_core_local(mm)) {
++ if (!mm_is_thread_local(mm)) {
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+
+ if (lock_tlbie)
+@@ -201,7 +201,7 @@ void radix__flush_tlb_pwc(struct mmu_gat
+ if (unlikely(pid == MMU_NO_CONTEXT))
+ goto no_context;
+
+- if (!mm_is_core_local(mm)) {
++ if (!mm_is_thread_local(mm)) {
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+
+ if (lock_tlbie)
+@@ -226,7 +226,7 @@ void radix__flush_tlb_page_psize(struct
+ pid = mm ? mm->context.id : 0;
+ if (unlikely(pid == MMU_NO_CONTEXT))
+ goto bail;
+- if (!mm_is_core_local(mm)) {
++ if (!mm_is_thread_local(mm)) {
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+
+ if (lock_tlbie)
+@@ -321,7 +321,7 @@ void radix__flush_tlb_range_psize(struct
+ {
+ unsigned long pid;
+ unsigned long addr;
+- int local = mm_is_core_local(mm);
++ int local = mm_is_thread_local(mm);
+ unsigned long ap = mmu_get_ap(psize);
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+ unsigned long page_size = 1UL << mmu_psize_defs[psize].shift;
--- /dev/null
+From 31e6ec4519c0fe0ee4a2f6ba3ab278e9506b9500 Mon Sep 17 00:00:00 2001
+From: Artem Savkov <asavkov@redhat.com>
+Date: Wed, 26 Oct 2016 15:02:09 +0100
+Subject: security/keys: make BIG_KEYS dependent on stdrng.
+
+From: Artem Savkov <asavkov@redhat.com>
+
+commit 31e6ec4519c0fe0ee4a2f6ba3ab278e9506b9500 upstream.
+
+Since BIG_KEYS can't be compiled as module it requires one of the "stdrng"
+providers to be compiled into kernel. Otherwise big_key_crypto_init() fails
+on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in
+big_key_preparse()) results in a NULL pointer dereference.
+
+Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')
+Signed-off-by: Artem Savkov <asavkov@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Stephan Mueller <smueller@chronox.de>
+cc: Kirill Marinushkin <k.marinushkin@gmail.com>
+Signed-off-by: James Morris <james.l.morris@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/security/keys/Kconfig
++++ b/security/keys/Kconfig
+@@ -41,7 +41,7 @@ config BIG_KEYS
+ bool "Large payload keys"
+ depends on KEYS
+ depends on TMPFS
+- select CRYPTO
++ depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y)
+ select CRYPTO_AES
+ select CRYPTO_ECB
+ select CRYPTO_RNG
spi-fsl-espi-avoid-processing-uninitalized-data-on-error.patch
spi-mark-device-nodes-only-in-case-of-successful-instantiation.patch
h8300-fix-syscall-restarting.patch
+gpio-acpi-fix-returned-error-from-acpi_dev_gpio_irq_get.patch
+gpio-gpio_get_chipinfo_ioctl-fix-line-offset-validation.patch
+gpio-gpio_get_chipinfo_ioctl-fix-information-leak.patch
+gpio-gpio_get_linehandle_ioctl-validate-line-offset.patch
+gpio-gpiohandle_get_line_values_ioctl-fix-information-leak.patch
+gpio-gpio_get_lineevent_ioctl-validate-line-offset.patch
+gpio-gpio_get_linehandle_ioctl-reject-invalid-line-flags.patch
+gpio-gpio_get_lineevent_ioctl-reject-invalid-line-and-event-flags.patch
+gpio-gpiohandle_get_line_values_ioctl-fix-another-information-leak.patch
+gpio-gpio_get_line-handle-event-_ioctl-fix-file-descriptor-leak.patch
+libxfs-clean-up-_calc_dquots_per_chunk.patch
+mm-list_lru.c-avoid-error-path-null-pointer-deref.patch
+mm-slab-fix-kmemcg-cache-creation-delayed-issue.patch
+mm-memcontrol-do-not-recurse-in-direct-reclaim.patch
+thermal-powerclamp-correct-cpu-support-check.patch
+keys-fix-short-sprintf-buffer-in-proc-keys-show-function.patch
+keys-sort-out-big_key-initialisation.patch
+security-keys-make-big_keys-dependent-on-stdrng.patch
+device-dax-fix-percpu_ref_exit-ordering.patch
+alsa-usb-audio-add-quirk-for-syntek-stk1160.patch
+alsa-seq-fix-time-account-regression.patch
+alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch
+alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch
+alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch
+alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch
+android-binder-add-strong-ref-checks.patch
+android-binder-clear-binder-and-cookie-when-setting-handle-in-flat-binder-struct.patch
+cxl-fix-leaking-pid-refs-in-some-error-paths.patch
+btrfs-fix-races-on-root_log_ctx-lists.patch
+powerpc-convert-cmp-to-cmpd-in-idle-enter-sequence.patch
+powerpc-mm-radix-use-tlbiel-only-if-we-ever-ran-on-the-current-cpu.patch
+powerpc-64-re-fix-race-condition-between-going-idle-and-entering-guest.patch
+powerpc-64-fix-race-condition-in-setting-lock-bit-in-idle-wakeup-code.patch
+x86-microcode-amd-fix-more-fallout-from-config_randomize_memory-y.patch
--- /dev/null
+From 3105f234e0aba43e44e277c20f9b32ee8add43d4 Mon Sep 17 00:00:00 2001
+From: Eric Ernst <eric.ernst@linux.intel.com>
+Date: Thu, 6 Oct 2016 08:56:49 -0700
+Subject: thermal/powerclamp: correct cpu support check
+
+From: Eric Ernst <eric.ernst@linux.intel.com>
+
+commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 upstream.
+
+Initial logic for checking CPU match resulted in OR of CPU features
+rather than the intended AND.
+
+Updated to use boot_cpu_has macro rather than x86_match_cpu.
+
+In addition, MWAIT is the only required CPU feature for idle
+injection to work. Drop other feature requirements since they are
+only needed for optimal efficiency.
+
+Signed-off-by: Eric Ernst <eric.ernst@linux.intel.com>
+Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/thermal/intel_powerclamp.c | 14 ++------------
+ 1 file changed, 2 insertions(+), 12 deletions(-)
+
+--- a/drivers/thermal/intel_powerclamp.c
++++ b/drivers/thermal/intel_powerclamp.c
+@@ -669,20 +669,10 @@ static struct thermal_cooling_device_ops
+ .set_cur_state = powerclamp_set_cur_state,
+ };
+
+-static const struct x86_cpu_id intel_powerclamp_ids[] __initconst = {
+- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_MWAIT },
+- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_ARAT },
+- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_NONSTOP_TSC },
+- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_CONSTANT_TSC},
+- {}
+-};
+-MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);
+-
+ static int __init powerclamp_probe(void)
+ {
+- if (!x86_match_cpu(intel_powerclamp_ids)) {
+- pr_err("Intel powerclamp does not run on family %d model %d\n",
+- boot_cpu_data.x86, boot_cpu_data.x86_model);
++ if (!boot_cpu_has(X86_FEATURE_MWAIT)) {
++ pr_err("CPU does not support MWAIT");
+ return -ENODEV;
+ }
+
--- /dev/null
+From 1c27f646b18fb56308dff82784ca61951bad0b48 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Thu, 27 Oct 2016 14:36:23 +0200
+Subject: x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y
+
+From: Borislav Petkov <bp@suse.de>
+
+commit 1c27f646b18fb56308dff82784ca61951bad0b48 upstream.
+
+We needed the physical address of the container in order to compute the
+offset within the relocated ramdisk. And we did this by doing __pa() on
+the virtual address.
+
+However, __pa() does checks whether the physical address is within
+PAGE_OFFSET and __START_KERNEL_map - see __phys_addr() - which fail
+if we have CONFIG_RANDOMIZE_MEMORY enabled: we feed a virtual address
+which *doesn't* have the randomization offset into a function which uses
+PAGE_OFFSET which *does* have that offset.
+
+This makes this check fire:
+
+ VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x));
+ ^^^^^^
+
+due to the randomization offset.
+
+The fix is as simple as using __pa_nodebug() because we do that
+randomization offset accounting later in that function ourselves.
+
+Reported-by: Bob Peterson <rpeterso@redhat.com>
+Tested-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: Andreas Gruenbacher <agruenba@redhat.com>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Steven Whitehouse <swhiteho@redhat.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-mm <linux-mm@kvack.org>
+Link: http://lkml.kernel.org/r/20161027123623.j2jri5bandimboff@pd.tnic
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/microcode/amd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/microcode/amd.c
++++ b/arch/x86/kernel/cpu/microcode/amd.c
+@@ -429,7 +429,7 @@ int __init save_microcode_in_initrd_amd(
+ * We need the physical address of the container for both bitness since
+ * boot_params.hdr.ramdisk_image is a physical address.
+ */
+- cont = __pa(container);
++ cont = __pa_nodebug(container);
+ cont_va = container;
+ #endif
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
