From: Greg Kroah-Hartman Date: Mon, 4 Dec 2017 10:53:26 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v3.18.86~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=82789f60f9d068d9627390b203f32b332a4586b3;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: arm-omap2-fix-wl1283-bluetooth-baud-rate.patch bcache-fix-building-error-on-mips.patch btrfs-clear-space-cache-inode-generation-always.patch eeprom-at24-check-at24_read-write-arguments.patch eeprom-at24-correctly-set-the-size-for-at24mac402.patch eeprom-at24-fix-reading-from-24mac402-24mac602.patch i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch kvm-lapic-fixup-ldr-on-load-in-x2apic.patch kvm-lapic-split-out-x2apic-ldr-calculation.patch kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch mfd-twl4030-power-fix-pmic-for-boards-that-need-vmmc1-on-reboot.patch mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch nfsd-fix-another-open-stateid-race.patch nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch nfsd-fix-stateid-races-between-open-and-close.patch --- diff --git a/queue-4.9/arm-omap2-fix-wl1283-bluetooth-baud-rate.patch b/queue-4.9/arm-omap2-fix-wl1283-bluetooth-baud-rate.patch new file mode 100644 index 00000000000..8e0635c4e40 --- /dev/null +++ b/queue-4.9/arm-omap2-fix-wl1283-bluetooth-baud-rate.patch @@ -0,0 +1,32 @@ +From a3ac350793d90d1da631c8beeee9352387974ed5 Mon Sep 17 00:00:00 2001 +From: Adam Ford +Date: Tue, 3 Jan 2017 11:37:48 -0600 +Subject: ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate + +From: Adam Ford + +commit a3ac350793d90d1da631c8beeee9352387974ed5 upstream. + +Commit 485fa1261f78 ("ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth") +set the wrong baud rate for the UART. The Baud rate was 300,000 and it should +be 3,000,000 for WL1283. + +Signed-off-by: Adam Ford +Signed-off-by: Tony Lindgren +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-omap2/pdata-quirks.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/mach-omap2/pdata-quirks.c ++++ b/arch/arm/mach-omap2/pdata-quirks.c +@@ -162,7 +162,7 @@ static struct ti_st_plat_data wilink7_pd + .nshutdown_gpio = 162, + .dev_name = "/dev/ttyO1", + .flow_cntrl = 1, +- .baud_rate = 300000, ++ .baud_rate = 3000000, + }; + + static struct platform_device wl128x_device = { diff --git a/queue-4.9/bcache-fix-building-error-on-mips.patch b/queue-4.9/bcache-fix-building-error-on-mips.patch new file mode 100644 index 00000000000..de27b97a38d --- /dev/null +++ b/queue-4.9/bcache-fix-building-error-on-mips.patch @@ -0,0 +1,72 @@ +From cf33c1ee5254c6a430bc1538232b49c3ea13e613 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Fri, 24 Nov 2017 15:14:25 -0800 +Subject: bcache: Fix building error on MIPS + +From: Huacai Chen + +commit cf33c1ee5254c6a430bc1538232b49c3ea13e613 upstream. + +This patch try to fix the building error on MIPS. The reason is MIPS +has already defined the PTR macro, which conflicts with the PTR macro +in include/uapi/linux/bcache.h. + +[fixed by mlyle: corrected a line-length issue] + +Signed-off-by: Huacai Chen +Reviewed-by: Michael Lyle +Signed-off-by: Michael Lyle +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/bcache/alloc.c | 2 +- + drivers/md/bcache/extents.c | 2 +- + drivers/md/bcache/journal.c | 2 +- + include/uapi/linux/bcache.h | 2 +- + 4 files changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/md/bcache/alloc.c ++++ b/drivers/md/bcache/alloc.c +@@ -477,7 +477,7 @@ int __bch_bucket_alloc_set(struct cache_ + if (b == -1) + goto err; + +- k->ptr[i] = PTR(ca->buckets[b].gen, ++ k->ptr[i] = MAKE_PTR(ca->buckets[b].gen, + bucket_to_sector(c, b), + ca->sb.nr_this_dev); + +--- a/drivers/md/bcache/extents.c ++++ b/drivers/md/bcache/extents.c +@@ -584,7 +584,7 @@ static bool bch_extent_merge(struct btre + return false; + + for (i = 0; i < KEY_PTRS(l); i++) +- if (l->ptr[i] + PTR(0, KEY_SIZE(l), 0) != r->ptr[i] || ++ if (l->ptr[i] + MAKE_PTR(0, KEY_SIZE(l), 0) != r->ptr[i] || + PTR_BUCKET_NR(b->c, l, i) != PTR_BUCKET_NR(b->c, r, i)) + return false; + +--- a/drivers/md/bcache/journal.c ++++ b/drivers/md/bcache/journal.c +@@ -508,7 +508,7 @@ static void journal_reclaim(struct cache + continue; + + ja->cur_idx = next; +- k->ptr[n++] = PTR(0, ++ k->ptr[n++] = MAKE_PTR(0, + bucket_to_sector(c, ca->sb.d[ja->cur_idx]), + ca->sb.nr_this_dev); + } +--- a/include/uapi/linux/bcache.h ++++ b/include/uapi/linux/bcache.h +@@ -90,7 +90,7 @@ PTR_FIELD(PTR_GEN, 0, 8) + + #define PTR_CHECK_DEV ((1 << PTR_DEV_BITS) - 1) + +-#define PTR(gen, offset, dev) \ ++#define MAKE_PTR(gen, offset, dev) \ + ((((__u64) dev) << 51) | ((__u64) offset) << 8 | gen) + + /* Bkey utility code */ diff --git a/queue-4.9/btrfs-clear-space-cache-inode-generation-always.patch b/queue-4.9/btrfs-clear-space-cache-inode-generation-always.patch new file mode 100644 index 00000000000..3a4b3c06749 --- /dev/null +++ b/queue-4.9/btrfs-clear-space-cache-inode-generation-always.patch @@ -0,0 +1,59 @@ +From 8e138e0d92c6c9d3d481674fb14e3439b495be37 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Fri, 17 Nov 2017 14:50:46 -0500 +Subject: btrfs: clear space cache inode generation always + +From: Josef Bacik + +commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 upstream. + +We discovered a box that had double allocations, and suspected the space +cache may be to blame. While auditing the write out path I noticed that +if we've already setup the space cache we will just carry on. This +means that any error we hit after cache_save_setup before we go to +actually write the cache out we won't reset the inode generation, so +whatever was already written will be considered correct, except it'll be +stale. Fix this by _always_ resetting the generation on the block group +inode, this way we only ever have valid or invalid cache. + +With this patch I was no longer able to reproduce cache corruption with +dm-log-writes and my bpf error injection tool. + +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/extent-tree.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -3397,13 +3397,6 @@ again: + goto again; + } + +- /* We've already setup this transaction, go ahead and exit */ +- if (block_group->cache_generation == trans->transid && +- i_size_read(inode)) { +- dcs = BTRFS_DC_SETUP; +- goto out_put; +- } +- + /* + * We want to set the generation to 0, that way if anything goes wrong + * from here on out we know not to trust this cache when we load up next +@@ -3427,6 +3420,13 @@ again: + } + WARN_ON(ret); + ++ /* We've already setup this transaction, go ahead and exit */ ++ if (block_group->cache_generation == trans->transid && ++ i_size_read(inode)) { ++ dcs = BTRFS_DC_SETUP; ++ goto out_put; ++ } ++ + if (i_size_read(inode) > 0) { + ret = btrfs_check_trunc_cache_free_space(root, + &root->fs_info->global_block_rsv); diff --git a/queue-4.9/eeprom-at24-check-at24_read-write-arguments.patch b/queue-4.9/eeprom-at24-check-at24_read-write-arguments.patch new file mode 100644 index 00000000000..aac674ccaf8 --- /dev/null +++ b/queue-4.9/eeprom-at24-check-at24_read-write-arguments.patch @@ -0,0 +1,42 @@ +From d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Fri, 24 Nov 2017 07:47:50 +0100 +Subject: eeprom: at24: check at24_read/write arguments + +From: Heiner Kallweit + +commit d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 upstream. + +So far we completely rely on the caller to provide valid arguments. +To be on the safe side perform an own sanity check. + +Signed-off-by: Heiner Kallweit +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/eeprom/at24.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/misc/eeprom/at24.c ++++ b/drivers/misc/eeprom/at24.c +@@ -507,6 +507,9 @@ static int at24_read(void *priv, unsigne + if (unlikely(!count)) + return count; + ++ if (off + count > at24->chip.byte_len) ++ return -EINVAL; ++ + /* + * Read data from chip, protecting against concurrent updates + * from this host, but not from other I2C masters. +@@ -539,6 +542,9 @@ static int at24_write(void *priv, unsign + if (unlikely(!count)) + return -EINVAL; + ++ if (off + count > at24->chip.byte_len) ++ return -EINVAL; ++ + /* + * Write data to chip, protecting against concurrent updates + * from this host, but not from other I2C masters. diff --git a/queue-4.9/eeprom-at24-correctly-set-the-size-for-at24mac402.patch b/queue-4.9/eeprom-at24-correctly-set-the-size-for-at24mac402.patch new file mode 100644 index 00000000000..0ad71d6ded6 --- /dev/null +++ b/queue-4.9/eeprom-at24-correctly-set-the-size-for-at24mac402.patch @@ -0,0 +1,47 @@ +From 5478e478eee3b096b8d998d4ed445da30da2dfbc Mon Sep 17 00:00:00 2001 +From: Bartosz Golaszewski +Date: Mon, 27 Nov 2017 22:06:13 +0100 +Subject: eeprom: at24: correctly set the size for at24mac402 + +From: Bartosz Golaszewski + +commit 5478e478eee3b096b8d998d4ed445da30da2dfbc upstream. + +There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down +the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, +making it impossible to read it all. + +Fix it by manually adjusting the value in probe(). + +This patch contains a temporary fix that is suitable for stable +branches. Eventually we'll probably remove the call to ilog2() while +converting the magic values to actual structs. + +Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series") +Signed-off-by: Bartosz Golaszewski +Reviewed-by: Andy Shevchenko +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/eeprom/at24.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/misc/eeprom/at24.c ++++ b/drivers/misc/eeprom/at24.c +@@ -639,6 +639,16 @@ static int at24_probe(struct i2c_client + dev_warn(&client->dev, + "page_size looks suspicious (no power of 2)!\n"); + ++ /* ++ * REVISIT: the size of the EUI-48 byte array is 6 in at24mac402, while ++ * the call to ilog2() in AT24_DEVICE_MAGIC() rounds it down to 4. ++ * ++ * Eventually we'll get rid of the magic values altoghether in favor of ++ * real structs, but for now just manually set the right size. ++ */ ++ if (chip.flags & AT24_FLAG_MAC && chip.byte_len == 4) ++ chip.byte_len = 6; ++ + /* Use I2C operations unless we're stuck with SMBus extensions. */ + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) { + if (chip.flags & AT24_FLAG_ADDR16) diff --git a/queue-4.9/eeprom-at24-fix-reading-from-24mac402-24mac602.patch b/queue-4.9/eeprom-at24-fix-reading-from-24mac402-24mac602.patch new file mode 100644 index 00000000000..a1eaf3564f0 --- /dev/null +++ b/queue-4.9/eeprom-at24-fix-reading-from-24mac402-24mac602.patch @@ -0,0 +1,34 @@ +From 644a1f19c6c8393d0c4168a5adf79056da6822eb Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Mon, 27 Nov 2017 20:46:22 +0100 +Subject: eeprom: at24: fix reading from 24MAC402/24MAC602 + +From: Heiner Kallweit + +commit 644a1f19c6c8393d0c4168a5adf79056da6822eb upstream. + +Chip datasheet mentions that word addresses other than the actual +start position of the MAC delivers undefined results. So fix this. +Current implementation doesn't work due to this wrong offset. + +Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series") +Signed-off-by: Heiner Kallweit +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/eeprom/at24.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/misc/eeprom/at24.c ++++ b/drivers/misc/eeprom/at24.c +@@ -365,7 +365,8 @@ static ssize_t at24_eeprom_read_mac(stru + memset(msg, 0, sizeof(msg)); + msg[0].addr = client->addr; + msg[0].buf = addrbuf; +- addrbuf[0] = 0x90 + offset; ++ /* EUI-48 starts from 0x9a, EUI-64 from 0x98 */ ++ addrbuf[0] = 0xa0 - at24->chip.byte_len + offset; + msg[0].len = 1; + msg[1].addr = client->addr; + msg[1].flags = I2C_M_RD; diff --git a/queue-4.9/i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch b/queue-4.9/i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch new file mode 100644 index 00000000000..b6ffccfefc4 --- /dev/null +++ b/queue-4.9/i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch @@ -0,0 +1,37 @@ +From 6e0c9507bf51e1517a80ad0ac171e5402528fcef Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 22 Nov 2017 12:28:17 +0100 +Subject: i2c: i801: Fix Failed to allocate irq -2147483648 error + +From: Hans de Goede + +commit 6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream. + +On Apollo Lake devices the BIOS does not set up IRQ routing for the i801 +SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED. + +Detect this and do not try to use the irq in this case silencing: +i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107 + +BugLink: https://communities.intel.com/thread/114759 +Signed-off-by: Hans de Goede +Reviewed-by: Jean Delvare +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-i801.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/i2c/busses/i2c-i801.c ++++ b/drivers/i2c/busses/i2c-i801.c +@@ -1592,6 +1592,9 @@ static int i801_probe(struct pci_dev *de + /* Default timeout in interrupt mode: 200 ms */ + priv->adapter.timeout = HZ / 5; + ++ if (dev->irq == IRQ_NOTCONNECTED) ++ priv->features &= ~FEATURE_IRQ; ++ + if (priv->features & FEATURE_IRQ) { + u16 pcictl, pcists; + diff --git a/queue-4.9/kvm-lapic-fixup-ldr-on-load-in-x2apic.patch b/queue-4.9/kvm-lapic-fixup-ldr-on-load-in-x2apic.patch new file mode 100644 index 00000000000..b49c51f74a8 --- /dev/null +++ b/queue-4.9/kvm-lapic-fixup-ldr-on-load-in-x2apic.patch @@ -0,0 +1,56 @@ +From 12806ba937382fdfdbad62a399aa2dce65c10fcd Mon Sep 17 00:00:00 2001 +From: "Dr. David Alan Gilbert" +Date: Fri, 17 Nov 2017 11:52:50 +0000 +Subject: KVM: lapic: Fixup LDR on load in x2apic + +From: Dr. David Alan Gilbert + +commit 12806ba937382fdfdbad62a399aa2dce65c10fcd upstream. + +In x2apic mode the LDR is fixed based on the ID rather +than separately loadable like it was before x2. +When kvm_apic_set_state is called, the base is set, and if +it has the X2APIC_ENABLE flag set then the LDR is calculated; +however that value gets overwritten by the memcpy a few lines +below overwriting it with the value that came from userland. + +The symptom is a lack of EOI after loading the state +(e.g. after a QEMU migration) and is due to the EOI bitmap +being wrong due to the incorrect LDR. This was seen with +a Win2016 guest under Qemu with irqchip=split whose USB mouse +didn't work after a VM migration. + +This corresponds to RH bug: + https://bugzilla.redhat.com/show_bug.cgi?id=1502591 + +Reported-by: Yiqian Wei +Signed-off-by: Dr. David Alan Gilbert +[Applied fixup from Liran Alon. - Paolo] +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2034,6 +2034,7 @@ static int kvm_apic_state_fixup(struct k + { + if (apic_x2apic_mode(vcpu->arch.apic)) { + u32 *id = (u32 *)(s->regs + APIC_ID); ++ u32 *ldr = (u32 *)(s->regs + APIC_LDR); + + if (vcpu->kvm->arch.x2apic_format) { + if (*id != vcpu->vcpu_id) +@@ -2044,6 +2045,10 @@ static int kvm_apic_state_fixup(struct k + else + *id <<= 24; + } ++ ++ /* In x2APIC mode, the LDR is fixed and based on the id */ ++ if (set) ++ *ldr = kvm_apic_calc_x2apic_ldr(*id); + } + + return 0; diff --git a/queue-4.9/kvm-lapic-split-out-x2apic-ldr-calculation.patch b/queue-4.9/kvm-lapic-split-out-x2apic-ldr-calculation.patch new file mode 100644 index 00000000000..7860b68f5b1 --- /dev/null +++ b/queue-4.9/kvm-lapic-split-out-x2apic-ldr-calculation.patch @@ -0,0 +1,38 @@ +From e872fa94662d0644057c7c80b3071bdb9249e5ab Mon Sep 17 00:00:00 2001 +From: "Dr. David Alan Gilbert" +Date: Fri, 17 Nov 2017 11:52:49 +0000 +Subject: KVM: lapic: Split out x2apic ldr calculation + +From: Dr. David Alan Gilbert + +commit e872fa94662d0644057c7c80b3071bdb9249e5ab upstream. + +Split out the ldr calculation from kvm_apic_set_x2apic_id +since we're about to reuse it in the following patch. + +Signed-off-by: Dr. David Alan Gilbert +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/lapic.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -246,9 +246,14 @@ static inline void kvm_apic_set_ldr(stru + recalculate_apic_map(apic->vcpu->kvm); + } + ++static inline u32 kvm_apic_calc_x2apic_ldr(u32 id) ++{ ++ return ((id >> 4) << 16) | (1 << (id & 0xf)); ++} ++ + static inline void kvm_apic_set_x2apic_id(struct kvm_lapic *apic, u32 id) + { +- u32 ldr = ((id >> 4) << 16) | (1 << (id & 0xf)); ++ u32 ldr = kvm_apic_calc_x2apic_ldr(id); + + kvm_lapic_set_reg(apic, APIC_ID, id); + kvm_lapic_set_reg(apic, APIC_LDR, ldr); diff --git a/queue-4.9/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch b/queue-4.9/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch new file mode 100644 index 00000000000..1d4f9cf2e7c --- /dev/null +++ b/queue-4.9/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch @@ -0,0 +1,54 @@ +From 61cb57c9ed631c95b54f8e9090c89d18b3695b3c Mon Sep 17 00:00:00 2001 +From: Liran Alon +Date: Sun, 5 Nov 2017 16:56:32 +0200 +Subject: KVM: x86: Exit to user-mode on #UD intercept when emulator requires +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Liran Alon + +commit 61cb57c9ed631c95b54f8e9090c89d18b3695b3c upstream. + +Instruction emulation after trapping a #UD exception can result in an +MMIO access, for example when emulating a MOVBE on a processor that +doesn't support the instruction. In this case, the #UD vmexit handler +must exit to user mode, but there wasn't any code to do so. Add it for +both VMX and SVM. + +Signed-off-by: Liran Alon +Reviewed-by: Nikita Leshenko +Reviewed-by: Konrad Rzeszutek Wilk +Signed-off-by: Konrad Rzeszutek Wilk +Reviewed-by: Wanpeng Li +Reviewed-by: Paolo Bonzini +Signed-off-by: Radim Krčmář +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/svm.c | 2 ++ + arch/x86/kvm/vmx.c | 2 ++ + 2 files changed, 4 insertions(+) + +--- a/arch/x86/kvm/svm.c ++++ b/arch/x86/kvm/svm.c +@@ -2149,6 +2149,8 @@ static int ud_interception(struct vcpu_s + int er; + + er = emulate_instruction(&svm->vcpu, EMULTYPE_TRAP_UD); ++ if (er == EMULATE_USER_EXIT) ++ return 0; + if (er != EMULATE_DONE) + kvm_queue_exception(&svm->vcpu, UD_VECTOR); + return 1; +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -5502,6 +5502,8 @@ static int handle_exception(struct kvm_v + return 1; + } + er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD); ++ if (er == EMULATE_USER_EXIT) ++ return 0; + if (er != EMULATE_DONE) + kvm_queue_exception(vcpu, UD_VECTOR); + return 1; diff --git a/queue-4.9/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch b/queue-4.9/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch new file mode 100644 index 00000000000..174983f840e --- /dev/null +++ b/queue-4.9/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch @@ -0,0 +1,53 @@ +From 6ea6e84309ca7e0e850b3083e6b09344ee15c290 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 10 Nov 2017 10:49:38 +0100 +Subject: KVM: x86: inject exceptions produced by x86_decode_insn +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Paolo Bonzini + +commit 6ea6e84309ca7e0e850b3083e6b09344ee15c290 upstream. + +Sometimes, a processor might execute an instruction while another +processor is updating the page tables for that instruction's code page, +but before the TLB shootdown completes. The interesting case happens +if the page is in the TLB. + +In general, the processor will succeed in executing the instruction and +nothing bad happens. However, what if the instruction is an MMIO access? +If *that* happens, KVM invokes the emulator, and the emulator gets the +updated page tables. If the update side had marked the code page as non +present, the page table walk then will fail and so will x86_decode_insn. + +Unfortunately, even though kvm_fetch_guest_virt is correctly returning +X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as +a fatal error if the instruction cannot simply be reexecuted (as is the +case for MMIO). And this in fact happened sometimes when rebooting +Windows 2012r2 guests. Just checking ctxt->have_exception and injecting +the exception if true is enough to fix the case. + +Thanks to Eduardo Habkost for helping in the debugging of this issue. + +Reported-by: Yanan Fu +Cc: Eduardo Habkost +Signed-off-by: Paolo Bonzini +Signed-off-by: Radim Krčmář +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -5579,6 +5579,8 @@ int x86_emulate_instruction(struct kvm_v + if (reexecute_instruction(vcpu, cr2, write_fault_to_spt, + emulation_type)) + return EMULATE_DONE; ++ if (ctxt->have_exception && inject_emulated_exception(vcpu)) ++ return EMULATE_DONE; + if (emulation_type & EMULTYPE_SKIP) + return EMULATE_FAIL; + return handle_emulation_failure(vcpu); diff --git a/queue-4.9/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch b/queue-4.9/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch new file mode 100644 index 00000000000..6055159e319 --- /dev/null +++ b/queue-4.9/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch @@ -0,0 +1,51 @@ +From 51c4b8bba674cfd2260d173602c4dac08e4c3a99 Mon Sep 17 00:00:00 2001 +From: Liran Alon +Date: Sun, 5 Nov 2017 16:11:30 +0200 +Subject: KVM: x86: pvclock: Handle first-time write to pvclock-page contains random junk +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Liran Alon + +commit 51c4b8bba674cfd2260d173602c4dac08e4c3a99 upstream. + +When guest passes KVM it's pvclock-page GPA via WRMSR to +MSR_KVM_SYSTEM_TIME / MSR_KVM_SYSTEM_TIME_NEW, KVM don't initialize +pvclock-page to some start-values. It just requests a clock-update which +will happen before entering to guest. + +The clock-update logic will call kvm_setup_pvclock_page() to update the +pvclock-page with info. However, kvm_setup_pvclock_page() *wrongly* +assumes that the version-field is initialized to an even number. This is +wrong because at first-time write, field could be any-value. + +Fix simply makes sure that if first-time version-field is odd, increment +it once more to make it even and only then start standard logic. +This follows same logic as done in other pvclock shared-pages (See +kvm_write_wall_clock() and record_steal_time()). + +Signed-off-by: Liran Alon +Reviewed-by: Nikita Leshenko +Reviewed-by: Konrad Rzeszutek Wilk +Signed-off-by: Konrad Rzeszutek Wilk +Reviewed-by: Paolo Bonzini +Signed-off-by: Radim Krčmář +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -1797,6 +1797,9 @@ static void kvm_setup_pvclock_page(struc + */ + BUILD_BUG_ON(offsetof(struct pvclock_vcpu_time_info, version) != 0); + ++ if (guest_hv_clock.version & 1) ++ ++guest_hv_clock.version; /* first time write, random junk */ ++ + vcpu->hv_clock.version = guest_hv_clock.version + 1; + kvm_write_guest_cached(v->kvm, &vcpu->pv_time, + &vcpu->hv_clock, diff --git a/queue-4.9/mfd-twl4030-power-fix-pmic-for-boards-that-need-vmmc1-on-reboot.patch b/queue-4.9/mfd-twl4030-power-fix-pmic-for-boards-that-need-vmmc1-on-reboot.patch new file mode 100644 index 00000000000..e5536d84360 --- /dev/null +++ b/queue-4.9/mfd-twl4030-power-fix-pmic-for-boards-that-need-vmmc1-on-reboot.patch @@ -0,0 +1,33 @@ +From ad48ed0c5763dc08931407e455dff5acdbe96e81 Mon Sep 17 00:00:00 2001 +From: Adam Ford +Date: Sun, 29 Jan 2017 06:40:15 -0600 +Subject: mfd: twl4030-power: Fix pmic for boards that need vmmc1 on reboot + +From: Adam Ford + +commit ad48ed0c5763dc08931407e455dff5acdbe96e81 upstream. + +At least two different omap3630/3730 boards booting from MMC1 +fail to reboot if the "ti,twl4030-power-idle-osc-off" or +"ti,twl4030-power-idle" compatible flags are set. This patch will +keep the vmmc1 powered up during reboot allowing the bootloader +to load. + +Signed-off-by: Adam Ford +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mfd/twl4030-power.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mfd/twl4030-power.c ++++ b/drivers/mfd/twl4030-power.c +@@ -701,6 +701,7 @@ static struct twl4030_ins omap3_wrst_seq + TWL_RESOURCE_RESET(RES_MAIN_REF), + TWL_RESOURCE_GROUP_RESET(RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2), + TWL_RESOURCE_RESET(RES_VUSB_3V1), ++ TWL_RESOURCE_RESET(RES_VMMC1), + TWL_RESOURCE_GROUP_RESET(RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1), + TWL_RESOURCE_GROUP_RESET(RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0), + TWL_RESOURCE_ON(RES_RESET), diff --git a/queue-4.9/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch b/queue-4.9/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch new file mode 100644 index 00000000000..3d124617415 --- /dev/null +++ b/queue-4.9/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch @@ -0,0 +1,32 @@ +From ebe7dd45cf49e3b49cacbaace17f9f878f21fbea Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Tue, 21 Nov 2017 15:42:29 +0200 +Subject: mmc: core: Do not leave the block driver in a suspended state + +From: Adrian Hunter + +commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea upstream. + +The block driver must be resumed if the mmc bus fails to suspend the card. + +Signed-off-by: Adrian Hunter +Reviewed-by: Linus Walleij +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/bus.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/mmc/core/bus.c ++++ b/drivers/mmc/core/bus.c +@@ -155,6 +155,9 @@ static int mmc_bus_suspend(struct device + return ret; + + ret = host->bus_ops->suspend(host); ++ if (ret) ++ pm_generic_resume(dev); ++ + return ret; + } + diff --git a/queue-4.9/mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch b/queue-4.9/mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch new file mode 100644 index 00000000000..baa5988837f --- /dev/null +++ b/queue-4.9/mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch @@ -0,0 +1,45 @@ +From c892b0d81705c566f575e489efc3c50762db1bde Mon Sep 17 00:00:00 2001 +From: Bastian Stender +Date: Tue, 28 Nov 2017 09:24:07 +0100 +Subject: mmc: core: prepend 0x to OCR entry in sysfs + +From: Bastian Stender + +commit c892b0d81705c566f575e489efc3c50762db1bde upstream. + +The sysfs entry "ocr" was missing the 0x prefix to identify it as hex +formatted. + +Fixes: 5fb06af7a33b ("mmc: core: Extend sysfs with OCR register") +Signed-off-by: Bastian Stender +[Ulf: Amended change to also cover SD-cards] +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/mmc.c | 2 +- + drivers/mmc/core/sd.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -752,7 +752,7 @@ MMC_DEV_ATTR(enhanced_area_offset, "%llu + MMC_DEV_ATTR(enhanced_area_size, "%u\n", card->ext_csd.enhanced_area_size); + MMC_DEV_ATTR(raw_rpmb_size_mult, "%#x\n", card->ext_csd.raw_rpmb_size_mult); + MMC_DEV_ATTR(rel_sectors, "%#x\n", card->ext_csd.rel_sectors); +-MMC_DEV_ATTR(ocr, "%08x\n", card->ocr); ++MMC_DEV_ATTR(ocr, "0x%08x\n", card->ocr); + + static ssize_t mmc_fwrev_show(struct device *dev, + struct device_attribute *attr, +--- a/drivers/mmc/core/sd.c ++++ b/drivers/mmc/core/sd.c +@@ -683,7 +683,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->c + MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name); + MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid); + MMC_DEV_ATTR(serial, "0x%08x\n", card->cid.serial); +-MMC_DEV_ATTR(ocr, "%08x\n", card->ocr); ++MMC_DEV_ATTR(ocr, "0x%08x\n", card->ocr); + + + static ssize_t mmc_dsr_show(struct device *dev, diff --git a/queue-4.9/nfsd-fix-another-open-stateid-race.patch b/queue-4.9/nfsd-fix-another-open-stateid-race.patch new file mode 100644 index 00000000000..b6fc736c94e --- /dev/null +++ b/queue-4.9/nfsd-fix-another-open-stateid-race.patch @@ -0,0 +1,91 @@ +From d8a1a000555ecd1b824ac1ed6df8fe364dfbbbb0 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Fri, 3 Nov 2017 08:00:11 -0400 +Subject: nfsd: Fix another OPEN stateid race + +From: Trond Myklebust + +commit d8a1a000555ecd1b824ac1ed6df8fe364dfbbbb0 upstream. + +If nfsd4_process_open2() is initialising a new stateid, and yet the +call to nfs4_get_vfs_file() fails for some reason, then we must +declare the stateid closed, and unhash it before dropping the mutex. + +Right now, we unhash the stateid after dropping the mutex, and without +changing the stateid type, meaning that another OPEN could theoretically +look it up and attempt to use it. + +Reported-by: Andrew W Elble +Signed-off-by: Trond Myklebust +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfsd/nfs4state.c | 28 +++++++++++++--------------- + 1 file changed, 13 insertions(+), 15 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -4453,6 +4453,7 @@ nfsd4_process_open2(struct svc_rqst *rqs + struct nfs4_ol_stateid *stp = NULL; + struct nfs4_delegation *dp = NULL; + __be32 status; ++ bool new_stp = false; + + /* + * Lookup file; if found, lookup stateid and check open request, +@@ -4472,11 +4473,19 @@ nfsd4_process_open2(struct svc_rqst *rqs + goto out; + } + ++ if (!stp) { ++ stp = init_open_stateid(fp, open); ++ if (!open->op_stp) ++ new_stp = true; ++ } ++ + /* + * OPEN the file, or upgrade an existing OPEN. + * If truncate fails, the OPEN fails. ++ * ++ * stp is already locked. + */ +- if (stp) { ++ if (!new_stp) { + /* Stateid was found, this is an OPEN upgrade */ + status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open); + if (status) { +@@ -4484,22 +4493,11 @@ nfsd4_process_open2(struct svc_rqst *rqs + goto out; + } + } else { +- /* stp is returned locked. */ +- stp = init_open_stateid(fp, open); +- /* See if we lost the race to some other thread */ +- if (stp->st_access_bmap != 0) { +- status = nfs4_upgrade_open(rqstp, fp, current_fh, +- stp, open); +- if (status) { +- mutex_unlock(&stp->st_mutex); +- goto out; +- } +- goto upgrade_out; +- } + status = nfs4_get_vfs_file(rqstp, fp, current_fh, stp, open); + if (status) { +- mutex_unlock(&stp->st_mutex); ++ stp->st_stid.sc_type = NFS4_CLOSED_STID; + release_open_stateid(stp); ++ mutex_unlock(&stp->st_mutex); + goto out; + } + +@@ -4508,7 +4506,7 @@ nfsd4_process_open2(struct svc_rqst *rqs + if (stp->st_clnt_odstate == open->op_odstate) + open->op_odstate = NULL; + } +-upgrade_out: ++ + nfs4_inc_and_copy_stateid(&open->op_stateid, &stp->st_stid); + mutex_unlock(&stp->st_mutex); + diff --git a/queue-4.9/nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch b/queue-4.9/nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch new file mode 100644 index 00000000000..9520debdd5c --- /dev/null +++ b/queue-4.9/nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch @@ -0,0 +1,49 @@ +From 64ebe12494fd5d193f014ce38e1fd83cc57883c8 Mon Sep 17 00:00:00 2001 +From: Naofumi Honda +Date: Thu, 9 Nov 2017 10:57:16 -0500 +Subject: nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat + +From: Naofumi Honda + +commit 64ebe12494fd5d193f014ce38e1fd83cc57883c8 upstream. + +From kernel 4.9, my two nfsv4 servers sometimes suffer from + "panic: unable to handle kernel page request" +in posix_unblock_lock() called from nfs4_laundromat(). + +These panics diseappear if we revert the commit "nfsd: add a LRU list +for blocked locks". + +The cause appears to be a typo in nfs4_laundromat(), which is also +present in nfs4_state_shutdown_net(). + +Fixes: 7919d0a27f1e "nfsd: add a LRU list for blocked locks" +Cc: jlayton@redhat.com +Reveiwed-by: Jeff Layton +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfsd/nfs4state.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -4732,7 +4732,7 @@ nfs4_laundromat(struct nfsd_net *nn) + spin_unlock(&nn->blocked_locks_lock); + + while (!list_empty(&reaplist)) { +- nbl = list_first_entry(&nn->blocked_locks_lru, ++ nbl = list_first_entry(&reaplist, + struct nfsd4_blocked_lock, nbl_lru); + list_del_init(&nbl->nbl_lru); + posix_unblock_lock(&nbl->nbl_lock); +@@ -7143,7 +7143,7 @@ nfs4_state_shutdown_net(struct net *net) + spin_unlock(&nn->blocked_locks_lock); + + while (!list_empty(&reaplist)) { +- nbl = list_first_entry(&nn->blocked_locks_lru, ++ nbl = list_first_entry(&reaplist, + struct nfsd4_blocked_lock, nbl_lru); + list_del_init(&nbl->nbl_lru); + posix_unblock_lock(&nbl->nbl_lock); diff --git a/queue-4.9/nfsd-fix-stateid-races-between-open-and-close.patch b/queue-4.9/nfsd-fix-stateid-races-between-open-and-close.patch new file mode 100644 index 00000000000..d84ee213b72 --- /dev/null +++ b/queue-4.9/nfsd-fix-stateid-races-between-open-and-close.patch @@ -0,0 +1,153 @@ +From 15ca08d3299682dc49bad73251677b2c5017ef08 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Fri, 3 Nov 2017 08:00:10 -0400 +Subject: nfsd: Fix stateid races between OPEN and CLOSE + +From: Trond Myklebust + +commit 15ca08d3299682dc49bad73251677b2c5017ef08 upstream. + +Open file stateids can linger on the nfs4_file list of stateids even +after they have been closed. In order to avoid reusing such a +stateid, and confusing the client, we need to recheck the +nfs4_stid's type after taking the mutex. +Otherwise, we risk reusing an old stateid that was already closed, +which will confuse clients that expect new stateids to conform to +RFC7530 Sections 9.1.4.2 and 16.2.5 or RFC5661 Sections 8.2.2 and 18.2.4. + +Signed-off-by: Trond Myklebust +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfsd/nfs4state.c | 67 +++++++++++++++++++++++++++++++++++++++++++++------- + 1 file changed, 59 insertions(+), 8 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -3513,7 +3513,9 @@ nfsd4_find_existing_open(struct nfs4_fil + /* ignore lock owners */ + if (local->st_stateowner->so_is_open_owner == 0) + continue; +- if (local->st_stateowner == &oo->oo_owner) { ++ if (local->st_stateowner != &oo->oo_owner) ++ continue; ++ if (local->st_stid.sc_type == NFS4_OPEN_STID) { + ret = local; + atomic_inc(&ret->st_stid.sc_count); + break; +@@ -3522,6 +3524,52 @@ nfsd4_find_existing_open(struct nfs4_fil + return ret; + } + ++static __be32 ++nfsd4_verify_open_stid(struct nfs4_stid *s) ++{ ++ __be32 ret = nfs_ok; ++ ++ switch (s->sc_type) { ++ default: ++ break; ++ case NFS4_CLOSED_STID: ++ case NFS4_CLOSED_DELEG_STID: ++ ret = nfserr_bad_stateid; ++ break; ++ case NFS4_REVOKED_DELEG_STID: ++ ret = nfserr_deleg_revoked; ++ } ++ return ret; ++} ++ ++/* Lock the stateid st_mutex, and deal with races with CLOSE */ ++static __be32 ++nfsd4_lock_ol_stateid(struct nfs4_ol_stateid *stp) ++{ ++ __be32 ret; ++ ++ mutex_lock(&stp->st_mutex); ++ ret = nfsd4_verify_open_stid(&stp->st_stid); ++ if (ret != nfs_ok) ++ mutex_unlock(&stp->st_mutex); ++ return ret; ++} ++ ++static struct nfs4_ol_stateid * ++nfsd4_find_and_lock_existing_open(struct nfs4_file *fp, struct nfsd4_open *open) ++{ ++ struct nfs4_ol_stateid *stp; ++ for (;;) { ++ spin_lock(&fp->fi_lock); ++ stp = nfsd4_find_existing_open(fp, open); ++ spin_unlock(&fp->fi_lock); ++ if (!stp || nfsd4_lock_ol_stateid(stp) == nfs_ok) ++ break; ++ nfs4_put_stid(&stp->st_stid); ++ } ++ return stp; ++} ++ + static struct nfs4_openowner * + alloc_init_open_stateowner(unsigned int strhashval, struct nfsd4_open *open, + struct nfsd4_compound_state *cstate) +@@ -3566,6 +3614,7 @@ init_open_stateid(struct nfs4_file *fp, + mutex_init(&stp->st_mutex); + mutex_lock(&stp->st_mutex); + ++retry: + spin_lock(&oo->oo_owner.so_client->cl_lock); + spin_lock(&fp->fi_lock); + +@@ -3590,7 +3639,11 @@ out_unlock: + spin_unlock(&fp->fi_lock); + spin_unlock(&oo->oo_owner.so_client->cl_lock); + if (retstp) { +- mutex_lock(&retstp->st_mutex); ++ /* Handle races with CLOSE */ ++ if (nfsd4_lock_ol_stateid(retstp) != nfs_ok) { ++ nfs4_put_stid(&retstp->st_stid); ++ goto retry; ++ } + /* To keep mutex tracking happy */ + mutex_unlock(&stp->st_mutex); + stp = retstp; +@@ -4411,9 +4464,7 @@ nfsd4_process_open2(struct svc_rqst *rqs + status = nfs4_check_deleg(cl, open, &dp); + if (status) + goto out; +- spin_lock(&fp->fi_lock); +- stp = nfsd4_find_existing_open(fp, open); +- spin_unlock(&fp->fi_lock); ++ stp = nfsd4_find_and_lock_existing_open(fp, open); + } else { + open->op_file = NULL; + status = nfserr_bad_stateid; +@@ -4427,7 +4478,6 @@ nfsd4_process_open2(struct svc_rqst *rqs + */ + if (stp) { + /* Stateid was found, this is an OPEN upgrade */ +- mutex_lock(&stp->st_mutex); + status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open); + if (status) { + mutex_unlock(&stp->st_mutex); +@@ -5314,7 +5364,6 @@ static void nfsd4_close_open_stateid(str + bool unhashed; + LIST_HEAD(reaplist); + +- s->st_stid.sc_type = NFS4_CLOSED_STID; + spin_lock(&clp->cl_lock); + unhashed = unhash_open_stateid(s, &reaplist); + +@@ -5353,10 +5402,12 @@ nfsd4_close(struct svc_rqst *rqstp, stru + nfsd4_bump_seqid(cstate, status); + if (status) + goto out; ++ ++ stp->st_stid.sc_type = NFS4_CLOSED_STID; + nfs4_inc_and_copy_stateid(&close->cl_stateid, &stp->st_stid); +- mutex_unlock(&stp->st_mutex); + + nfsd4_close_open_stateid(stp); ++ mutex_unlock(&stp->st_mutex); + + /* put reference from nfs4_preprocess_seqid_op */ + nfs4_put_stid(&stp->st_stid); diff --git a/queue-4.9/series b/queue-4.9/series index 36acdd03a64..8a049c19206 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -4,3 +4,21 @@ mm-thp-do-not-make-page-table-dirty-unconditionally-in-touch_pd.patch mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch mm-hugetlbfs-introduce-split-to-vm_operations_struct.patch mm-madvise.c-fix-madvise-infinite-loop-under-special-circumstances.patch +btrfs-clear-space-cache-inode-generation-always.patch +nfsd-fix-stateid-races-between-open-and-close.patch +nfsd-fix-another-open-stateid-race.patch +nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch +mfd-twl4030-power-fix-pmic-for-boards-that-need-vmmc1-on-reboot.patch +arm-omap2-fix-wl1283-bluetooth-baud-rate.patch +kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch +kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch +kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch +kvm-lapic-split-out-x2apic-ldr-calculation.patch +kvm-lapic-fixup-ldr-on-load-in-x2apic.patch +mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch +mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch +eeprom-at24-fix-reading-from-24mac402-24mac602.patch +eeprom-at24-correctly-set-the-size-for-at24mac402.patch +eeprom-at24-check-at24_read-write-arguments.patch +i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch +bcache-fix-building-error-on-mips.patch