commit 284bbc782445283e9a5124666dda8010f379f179 Author: Greg Kroah-Hartman Date: Tue Dec 5 11:24:35 2017 +0100 Linux 4.9.67 commit f990312aaa74faf14d00a1b050c55a66dfe3153a Author: Ville Syrjälä Date: Thu Nov 23 21:41:57 2017 +0200 drm/i915: Prevent zero length "index" write commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream. The hardware always writes one or two bytes in the index portion of an indexed transfer. Make sure the message we send as the index doesn't have a zero length. Cc: Daniel Kurtz Cc: Chris Wilson Cc: Daniel Vetter Cc: Sean Paul Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 838cdb26a538aa83326639f53ce4f8112f23dd96 Author: Ville Syrjälä Date: Thu Nov 23 21:41:56 2017 +0200 drm/i915: Don't try indexed reads to alternate slave addresses commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream. We can only specify the one slave address to indexed reads/writes. Make sure the messages we check are destined to the same slave address before deciding to do an indexed transfer. Cc: Daniel Kurtz Cc: Chris Wilson Cc: Daniel Vetter Cc: Sean Paul Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit daf3a68d52826e697eb20c1f290aa198d43dfad5 Author: NeilBrown Date: Fri Aug 25 17:34:41 2017 +1000 NFS: revalidate "." etc correctly on "open". commit b688741cb06695312f18b730653d6611e1bad28d upstream. For correct close-to-open semantics, NFS must validate the change attribute of a directory (or file) on open. Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op"), open() of "." or a path ending ".." is not revalidated reliably (except when that direct is a mount point). Prior to that commit, "." was revalidated using nfs_lookup_revalidate() which checks the LOOKUP_OPEN flag and forces revalidation if the flag is set. Since that commit, nfs_weak_revalidate() is used for NFSv3 (which ignores the flags) and nothing is used for NFSv4. This is fixed by using nfs_lookup_verify_inode() in nfs_weak_revalidate(). This does the revalidation exactly when needed. Also, add a definition of .d_weak_revalidate for NFSv4. The incorrect behavior is easily demonstrated by running "echo *" in some non-mountpoint NFS directory while watching network traffic. Without this patch, "echo *" sometimes doesn't produce any traffic. With the patch it always does. Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op") cc: stable@vger.kernel.org (3.9+) Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit a11ca51bf70c81240c2c17af66813e549abb691a Author: Greg Kroah-Hartman Date: Mon Dec 4 12:59:57 2017 +0100 Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" This reverts commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 which is commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream. Andy writes: I think the thing to do is to revert the patch from -stable. The bug it fixes is very minor, and the regression is that it made a pre-existing bug in some nearly-undebuggable core resume code much easier to hit. I don't feel comfortable with a backport of the latter fix until it has a good long soak in Linus' tree. Reported-by: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit fb541279bbe07a2e14ee9324c336984ae23e23c3 Author: Rex Zhu Date: Fri Nov 17 16:41:16 2017 +0800 drm/amd/pp: fix typecast error in powerplay. commit 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca upstream. resulted in unexpected data truncation Reviewed-by: Alex Deucher Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5b1c8c96dfab3a15fafcbb573e98d17a12fbfcbc Author: Christian König Date: Mon Oct 30 14:57:43 2017 +0100 drm/ttm: once more fix ttm_buffer_object_transfer commit 4d98e5ee6084f6d7bc578c5d5f86de7156aaa4cb upstream. When the mutex is locked just in the moment we copy it we end up with a warning that we release a locked mutex. Fix this by properly reinitializing the mutex. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 44df87e6dfadc423407f2b7a546396b86a37d462 Author: Peter Griffin Date: Tue Aug 15 15:14:25 2017 +0100 drm/hisilicon: Ensure LDI regs are properly configured. commit a2f042430784d86eb2b7a6d2a869f552da30edba upstream. This patch fixes the following soft lockup: BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] On weston idle-timeout the IP is powered down and reset asserted. On weston resume we get a massive vblank IRQ storm due to the LDI registers having lost some state. This state loss is caused by ade_crtc_atomic_begin() not calling ade_ldi_set_mode(). With this patch applied resuming from Weston idle-timeout works well. Signed-off-by: Peter Griffin Tested-by: John Stultz Reviewed-by: Xinliang Liu Signed-off-by: Xinliang Liu Signed-off-by: Greg Kroah-Hartman commit 25abe3a9585eeadbbb65851c2082f232f1b6ee40 Author: Jonathan Liu Date: Mon Aug 7 21:55:45 2017 +1000 drm/panel: simple: Add missing panel_simple_unprepare() calls commit f3621a8eb59a913612c8e6e37d81f16b649f8b6c upstream. During panel removal or system shutdown panel_simple_disable() is called which disables the panel backlight but the panel is still powered due to missing calls to panel_simple_unprepare(). Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown") Signed-off-by: Jonathan Liu Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3405805db8bbe72e831059f93775e7048d5f742d Author: Roman Kapl Date: Mon Oct 30 11:56:13 2017 +0100 drm/radeon: fix atombios on big endian commit 4f626a4ac8f57ddabf06d03870adab91e463217f upstream. The function for byteswapping the data send to/from atombios was buggy for num_bytes not divisible by four. The function must be aware of the fact that after byte-swapping the u32 units, valid bytes might end up after the num_bytes boundary. This patch was tested on kernel 3.12 and allowed us to sucesfully use DisplayPort on and Radeon SI card. Namely it fixed the link training and EDID readout. The function is patched both in radeon and amd drivers, since the functions and the fixes are identical. Signed-off-by: Roman Kapl Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9cd48ba5fc9d1699fce31b625c32fd8bc77a28c0 Author: Dan Carpenter Date: Sat Sep 30 11:14:13 2017 +0300 drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories() commit 78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 upstream. After commit ea09729c9302 ("drm/amdgpu: rework page directory filling v2") then it becomes a lot harder to verify that "r" is initialized. My static checker complains and so I've reviewed the code. It does look like it might be buggy... Anyway, it doesn't hurt to set "r" to zero at the start. Reviewed-by: Christian König Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d316675a9da4c2bb28a247ad5e1044e5bd0daaf7 Author: Dan Carpenter Date: Sat Sep 30 11:13:28 2017 +0300 drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs() commit 40a9960b046290939b56ce8e51f365258f27f264 upstream. We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into find_mapping") and now my static checker complains that "r" might not be initialized at the end of the function. I've reviewed the code, and that seems possible, but it's also possible I may have missed something. Reviewed-by: Christian König Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b0f63389dab9c7fe819e898f69b63c686e491f28 Author: Alex Deucher Date: Tue Nov 14 17:19:29 2017 -0500 Revert "drm/radeon: dont switch vt on suspend" commit 18c437caa5b18a235dd65cec224eab54bebcee65 upstream. Fixes distorted colors on some cards on resume from suspend. This reverts commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001 Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f425b050254ed8ccd996bb0a943b5d7d8259ac72 Author: Jeff Lien Date: Tue Nov 21 10:44:37 2017 -0600 nvme-pci: add quirk for delay before CHK RDY for WDC SN200 commit 8c97eeccf0ad8783c057830119467b877bdfced7 upstream. And increase the existing delay to cover this device as well. Signed-off-by: Jeff Lien Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit eafbee43b7ec603c002e34597ab5f8fc170d7ab4 Author: Peter Rosin Date: Mon Nov 27 17:31:00 2017 +0100 hwmon: (jc42) optionally try to disable the SMBUS timeout commit 68615eb01f82256c19e41967bfb3eef902f77033 upstream. With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out. This also affects the eeprom half of the nxp-se97 chip, where this silent corruption was originally noticed. Other I2C adapters probably suffer similar issues, e.g. bit-banging comes to mind as risky... The SMBUS register in the nxp chip is not a standard Jedec register, but it is not special to the nxp chips either, at least the atmel chips have the same mechanism. Therefore, do not special case this on the manufacturer, it is opt-in via the device property anyway. Signed-off-by: Peter Rosin Acked-by: Rob Herring Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8588eb0ce6a639be06110d7bbc8f59d8468ed9b7 Author: Huacai Chen Date: Fri Nov 24 15:14:25 2017 -0800 bcache: Fix building error on MIPS 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 commit 53cf83b3c73446a3f047e6abb805521a83baa133 Author: Hans de Goede Date: Wed Nov 22 12:28:17 2017 +0100 i2c: i801: Fix Failed to allocate irq -2147483648 error 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 commit 19699abea32154abcf2135c71f2eb0f260f3ffa2 Author: Heiner Kallweit Date: Fri Nov 24 07:47:50 2017 +0100 eeprom: at24: check at24_read/write arguments 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 commit d3da2efa6d9db2be41615fbc514cd056a06f5deb Author: Bartosz Golaszewski Date: Mon Nov 27 22:06:13 2017 +0100 eeprom: at24: correctly set the size for at24mac402 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 commit 388d8c9fa37194a782f7a7d7c21b7590fd08893d Author: Heiner Kallweit Date: Mon Nov 27 20:46:22 2017 +0100 eeprom: at24: fix reading from 24MAC402/24MAC602 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 commit c814d6701b08fe58d6eb95641a089bde51afe951 Author: Bastian Stender Date: Tue Nov 28 09:24:07 2017 +0100 mmc: core: prepend 0x to OCR entry in sysfs 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 commit 0bf4d0517667877c2b0955586070fd7198943896 Author: Adrian Hunter Date: Tue Nov 21 15:42:29 2017 +0200 mmc: core: Do not leave the block driver in a suspended state 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 commit 9aad75786e3d986499934fdaec7f911949a2f3e3 Author: Dr. David Alan Gilbert Date: Fri Nov 17 11:52:50 2017 +0000 KVM: lapic: Fixup LDR on load in x2apic 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 commit e02746e22d24233dca60302ddad1c071603394d7 Author: Dr. David Alan Gilbert Date: Fri Nov 17 11:52:49 2017 +0000 KVM: lapic: Split out x2apic ldr calculation 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 commit 67945527ee240ff96daee0ef33d997a2fe43a419 Author: Paolo Bonzini Date: Fri Nov 10 10:49:38 2017 +0100 KVM: x86: inject exceptions produced by x86_decode_insn 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 commit c0a4c22aad0f80a88b2c7cae652a29f385a12e9d Author: Liran Alon Date: Sun Nov 5 16:56:32 2017 +0200 KVM: x86: Exit to user-mode on #UD intercept when emulator requires 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 commit f5477da6c3b0f8df578a55dfdeebe18458303e4d Author: Liran Alon Date: Sun Nov 5 16:11:30 2017 +0200 KVM: x86: pvclock: Handle first-time write to pvclock-page contains random junk 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 commit e18a963b36a001b0067f9091b4ea23aa152af341 Author: Adam Ford Date: Tue Jan 3 11:37:48 2017 -0600 ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate 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 commit dc554abdaee496a8dd0dbafec7abb83328a575ae Author: Adam Ford Date: Sun Jan 29 06:40:15 2017 -0600 mfd: twl4030-power: Fix pmic for boards that need vmmc1 on reboot 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 commit aa1a6cf1586bb0aa7c6585ebaffd7b5e3ae4f040 Author: Naofumi Honda Date: Thu Nov 9 10:57:16 2017 -0500 nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat 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 commit 1c404259164405f9a61379285f6e1fcb57ea43aa Author: Trond Myklebust Date: Fri Nov 3 08:00:11 2017 -0400 nfsd: Fix another OPEN stateid race 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 commit 1c8ea4145097f8a69a8230b0e40c083ffc1b53e4 Author: Trond Myklebust Date: Fri Nov 3 08:00:10 2017 -0400 nfsd: Fix stateid races between OPEN and CLOSE 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 commit c251267c8826027af32fe7195650d29797539847 Author: Josef Bacik Date: Fri Nov 17 14:50:46 2017 -0500 btrfs: clear space cache inode generation always 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 commit ba32d7dce43f14ef1a1cb0540959431526cf7fe0 Author: chenjie Date: Wed Nov 29 16:10:54 2017 -0800 mm/madvise.c: fix madvise() infinite loop under special circumstances commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream. MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings. Unfortunately madvise_willneed() doesn't communicate this information properly to the generic madvise syscall implementation. The calling convention is quite subtle there. madvise_vma() is supposed to either return an error or update &prev otherwise the main loop will never advance to the next vma and it will keep looping for ever without a way to get out of the kernel. It seems this has been broken since introduction. Nobody has noticed because nobody seems to be using MADVISE_WILLNEED on these DAX mappings. [mhocko@suse.com: rewrite changelog] Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place") Signed-off-by: chenjie Signed-off-by: guoxuenan Acked-by: Michal Hocko Cc: Minchan Kim Cc: zhangyi (F) Cc: Miao Xie Cc: Mike Rapoport Cc: Shaohua Li Cc: Andrea Arcangeli Cc: Mel Gorman Cc: Kirill A. Shutemov Cc: David Rientjes Cc: Anshuman Khandual Cc: Rik van Riel Cc: Carsten Otte Cc: Dan Williams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cebe139e5712d6925a9b70f3769df6818b6c14dd Author: Dan Williams Date: Wed Nov 29 16:10:28 2017 -0800 mm, hugetlbfs: introduce ->split() to vm_operations_struct commit 31383c6865a578834dd953d9dbc88e6b19fe3997 upstream. Patch series "device-dax: fix unaligned munmap handling" When device-dax is operating in huge-page mode we want it to behave like hugetlbfs and fail attempts to split vmas into unaligned ranges. It would be messy to teach the munmap path about device-dax alignment constraints in the same (hstate) way that hugetlbfs communicates this constraint. Instead, these patches introduce a new ->split() vm operation. This patch (of 2): The device-dax interface has similar constraints as hugetlbfs in that it requires the munmap path to unmap in huge page aligned units. Rather than add more custom vma handling code in __split_vma() introduce a new vm operation to perform this vma specific check. Link: http://lkml.kernel.org/r/151130418135.4029.6783191281930729710.stgit@dwillia2-desk3.amr.corp.intel.com Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap") Signed-off-by: Dan Williams Cc: Jeff Moyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 436f19a2e49e57b39e1d46ee018eb5f64ec1031f Author: Mike Kravetz Date: Wed Nov 29 16:10:01 2017 -0800 mm/cma: fix alloc_contig_range ret code/potential leak commit 63cd448908b5eb51d84c52f02b31b9b4ccd1cb5a upstream. If the call __alloc_contig_migrate_range() in alloc_contig_range returns -EBUSY, processing continues so that test_pages_isolated() is called where there is a tracepoint to identify the busy pages. However, it is possible for busy pages to become available between the calls to these two routines. In this case, the range of pages may be allocated. Unfortunately, the original return code (ret == -EBUSY) is still set and returned to the caller. Therefore, the caller believes the pages were not allocated and they are leaked. Update the comment to indicate that allocation is still possible even if __alloc_contig_migrate_range returns -EBUSY. Also, clear return code in this case so that it is not accidentally used or returned to caller. Link: http://lkml.kernel.org/r/20171122185214.25285-1-mike.kravetz@oracle.com Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure") Signed-off-by: Mike Kravetz Acked-by: Vlastimil Babka Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Joonsoo Kim Cc: Michal Nazarewicz Cc: Laura Abbott Cc: Michal Hocko Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7031ae2ab37d3df53c4a4e9903329a5d38c745ec Author: Kirill A. Shutemov Date: Mon Nov 27 06:21:25 2017 +0300 mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d() commit a8f97366452ed491d13cf1e44241bc0b5740b1f0 upstream. Currently, we unconditionally make page table dirty in touch_pmd(). It may result in false-positive can_follow_write_pmd(). We may avoid the situation, if we would only make the page table entry dirty if caller asks for write access -- FOLL_WRITE. The patch also changes touch_pud() in the same way. Signed-off-by: Kirill A. Shutemov Cc: Michal Hocko Cc: Hugh Dickins Signed-off-by: Linus Torvalds [Salvatore Bonaccorso: backport for 4.9: - Adjust context - Drop specific part for PUD-sized transparent hugepages. Support for PUD-sized transparent hugepages was added in v4.11-rc1 ] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 29bd7003134a3220119e7a75c4b06ac567f966e7 Author: Adam Ford Date: Thu Aug 17 06:01:28 2017 -0500 ARM: dts: omap3: logicpd-torpedo-37xx-devkit: Fix MMC1 cd-gpio commit b7ace5ed8867ca54503727988adec6b20af54eeb upstream. Fixes commit 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") This patch corrects an issue where the cd-gpios was improperly setup using IRQ_TYPE_LEVEL_LOW instead of GPIO_ACTIVE_LOW. Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 64e916dea413f16e1a49ef3241f9a3435ca713d5 Author: Adam Ford Date: Thu May 11 12:21:19 2017 -0500 ARM: dts: LogicPD Torpedo: Fix camera pin mux commit 56322e123235370f1449c7444e311cce857d12f5 upstream. Fix commit 05c4ffc3a266 ("ARM: dts: LogicPD Torpedo: Add MT9P031 Support") In the previous commit, I indicated that the only testing was done by showing the camera showed up when probing. This patch fixes an incorrect pin muxing on cam_d0, cam_d1 and cam_d2. Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman