commit adfb98cd3e937104d58ec60fec2e4f565a31c89d Author: Greg Kroah-Hartman Date: Wed Mar 15 10:23:00 2017 +0800 Linux 4.10.3 commit 070dfed4d04ef6c18f07a2d147c1be74c8c84f5b Author: K. Y. Srinivasan Date: Wed Feb 8 18:30:56 2017 -0700 drivers: hv: Turn off write permission on the hypercall page commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 upstream. The hypercall page only needs to be executable but currently it is setup to be writable as well. Fix the issue. Signed-off-by: K. Y. Srinivasan Acked-by: Kees Cook Reported-by: Stephen Hemminger Tested-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman commit 9cafe6bb9aa2584608b4c7e4d8b9ba13e0ff5da1 Author: OGAWA Hirofumi Date: Thu Mar 9 16:17:37 2017 -0800 fat: fix using uninitialized fields of fat_inode/fsinfo_inode commit c0d0e351285161a515396b7b1ee53ec9ffd97e3c upstream. Recently fallocate patch was merged and it uses MSDOS_I(inode)->mmu_private at fat_evict_inode(). However, fat_inode/fsinfo_inode that was introduced in past didn't initialize MSDOS_I(inode) properly. With those combinations, it became the cause of accessing random entry in FAT area. Link: http://lkml.kernel.org/r/87pohrj4i8.fsf@mail.parknet.co.jp Signed-off-by: OGAWA Hirofumi Reported-by: Moreno Bartalucci Tested-by: Moreno Bartalucci Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d9cc8aa34adc801c34ced69754286bb4874697d Author: Dmitry Vyukov Date: Thu Mar 9 16:17:28 2017 -0800 kasan: resched in quarantine_remove_cache() commit 68fd814a3391c7e017ae6ace8855788748edd981 upstream. We see reported stalls/lockups in quarantine_remove_cache() on machines with large amounts of RAM. quarantine_remove_cache() needs to scan whole quarantine in order to take out all objects belonging to the cache. Quarantine is currently 1/32-th of RAM, e.g. on a machine with 256GB of memory that will be 8GB. Moreover quarantine scanning is a walk over uncached linked list, which is slow. Add cond_resched() after scanning of each non-empty batch of objects. Batches are specifically kept of reasonable size for quarantine_put(). On a machine with 256GB of RAM we should have ~512 non-empty batches, each with 16MB of objects. Link: http://lkml.kernel.org/r/20170308154239.25440-1-dvyukov@google.com Signed-off-by: Dmitry Vyukov Acked-by: Andrey Ryabinin Cc: Greg Thelen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 44c95966fb817b0b6f9d17fb0ec524011135d176 Author: Tahsin Erdogan Date: Thu Mar 9 16:17:26 2017 -0800 mm: do not call mem_cgroup_free() from within mem_cgroup_alloc() commit 40e952f9d687928b32db20226f085ae660a7237c upstream. mem_cgroup_free() indirectly calls wb_domain_exit() which is not prepared to deal with a struct wb_domain object that hasn't executed wb_domain_init(). For instance, the following warning message is printed by lockdep if alloc_percpu() fails in mem_cgroup_alloc(): INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 1950 Comm: mkdir Not tainted 4.10.0+ #151 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x67/0x99 register_lock_class+0x36d/0x540 __lock_acquire+0x7f/0x1a30 lock_acquire+0xcc/0x200 del_timer_sync+0x3c/0xc0 wb_domain_exit+0x14/0x20 mem_cgroup_free+0x14/0x40 mem_cgroup_css_alloc+0x3f9/0x620 cgroup_apply_control_enable+0x190/0x390 cgroup_mkdir+0x290/0x3d0 kernfs_iop_mkdir+0x58/0x80 vfs_mkdir+0x10e/0x1a0 SyS_mkdirat+0xa8/0xd0 SyS_mkdir+0x14/0x20 entry_SYSCALL_64_fastpath+0x18/0xad Add __mem_cgroup_free() which skips wb_domain_exit(). This is used by both mem_cgroup_free() and mem_cgroup_alloc() clean up. Fixes: 0b8f73e104285 ("mm: memcontrol: clean up alloc, online, offline, free functions") Link: http://lkml.kernel.org/r/20170306192122.24262-1-tahsin@google.com Signed-off-by: Tahsin Erdogan Acked-by: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 933f0f3ad49ad16fbe6ee8de283c0fd3b7876191 Author: Kirill A. Shutemov Date: Thu Mar 9 16:17:23 2017 -0800 thp: fix another corner case of munlock() vs. THPs commit 6ebb4a1b848fe75323135f93e72c78f8780fd268 upstream. The following test case triggers BUG() in munlock_vma_pages_range(): int main(int argc, char *argv[]) { int fd; system("mount -t tmpfs -o huge=always none /mnt"); fd = open("/mnt/test", O_CREAT | O_RDWR); ftruncate(fd, 4UL << 20); mmap(NULL, 4UL << 20, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED | MAP_LOCKED, fd, 0); mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0); munlockall(); return 0; } The second mmap() create PTE-mapping of the first huge page in file. It makes kernel munlock the page as we never keep PTE-mapped page mlocked. On munlockall() when we handle vma created by the first mmap(), munlock_vma_page() returns page_mask == 0, as the page is not mlocked anymore. On next iteration follow_page_mask() return tail page, but page_mask is HPAGE_NR_PAGES - 1. It makes us skip to the first tail page of the next huge page and step on VM_BUG_ON_PAGE(PageMlocked(page)). The fix is not use the page_mask from follow_page_mask() at all. It has no use for us. Link: http://lkml.kernel.org/r/20170302150252.34120-1-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 459bc5065631ab698917355ba6b2e3167547a801 Author: Daniel Borkmann Date: Sat Mar 11 01:31:19 2017 +0100 x86/tlb: Fix tlb flushing when lguest clears PGE commit 2c4ea6e28dbf15ab93632c5c189f3948366b8885 upstream. Fengguang reported random corruptions from various locations on x86-32 after commits d2852a224050 ("arch: add ARCH_HAS_SET_MEMORY config") and 9d876e79df6a ("bpf: fix unlocking of jited image when module ronx not set") that uses the former. While x86-32 doesn't have a JIT like x86_64, the bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module support built in and therefore never had the DEBUG_SET_MODULE_RONX setting enabled. After investigating the crashes further, it turned out that using set_memory_ro() and set_memory_rw() didn't have the desired effect, for example, setting the pages as read-only on x86-32 would still let probe_kernel_write() succeed without error. This behavior would manifest itself in situations where the vmalloc'ed buffer was accessed prior to set_memory_*() such as in case of bpf_prog_alloc(). In cases where it wasn't, the page attribute changes seemed to have taken effect, leading to the conclusion that a TLB invalidate didn't happen. Moreover, it turned out that this issue reproduced with qemu in "-cpu kvm64" mode, but not for "-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(), though. There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush (depends on X86_FEATURE_PGE), and cr3 based flush. For "-cpu host" case in my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually worked fine, and further investigating the cr4 one turned out that X86_CR4_PGE bit was not set in cr4 register, meaning the __native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same value instead of clearing X86_CR4_PGE in the first write to trigger the flush. It turned out that X86_CR4_PGE was cleared from cr4 during init from lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also cleared from there due to concerns of using PGE in guest kernel that can lead to hard to trace bugs (see bff672e630a0 ("lguest: documentation V: Host") in init()). The CPU feature bits are cleared in dynamic boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB flushing to use, meaning they still used the old setting of the host kernel. Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate to static_cpu_has() checks is too late at this point as sections have been patched already, so for now, it seems reasonable to switch back to boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95992b ("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via cr3 as originally intended, properly makes the new page attributes visible and thus fixes the crashes seen by Fengguang. Fixes: c109bf95992b ("x86/cpufeature: Remove cpu_has_pge") Reported-by: Fengguang Wu Signed-off-by: Daniel Borkmann Cc: bp@suse.de Cc: Kees Cook Cc: "David S. Miller" Cc: netdev@vger.kernel.org Cc: Rusty Russell Cc: Alexei Starovoitov Cc: Linus Torvalds Cc: lkp@01.org Cc: Laura Abbott Link: http://lkml.kernrl.org/r/20170301125426.l4nf65rx4wahohyl@wfg-t540p.sh.intel.com Link: http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.daniel@iogearbox.net Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ac312c7e0a90f5f51b77fd10a4219b427d09b76a Author: Dan Williams Date: Thu Mar 9 16:16:42 2017 -0800 x86, mm: fix gup_pte_range() vs DAX mappings commit ef947b2529f918d9606533eb9c32b187ed6a5ede upstream. gup_pte_range() fails to check pte_allows_gup() before translating a DAX pte entry, pte_devmap(), to a page. This allows writes to read-only mappings, and bypasses the DAX cacheline dirty tracking due to missed 'mkwrite' faults. The gup_huge_pmd() path and the gup_huge_pud() path correctly check pte_allows_gup() before checking for _devmap() entries. Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Link: http://lkml.kernel.org/r/148804251312.36605.12665024794196605053.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ross Zwisler Signed-off-by: Dan Williams Reported-by: Dave Hansen Reported-by: Ross Zwisler Cc: Xiong Zhou Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0af36e434a3cf8a32e68d77da66cad6b8502b532 Author: Arnd Bergmann Date: Mon Jan 16 12:06:09 2017 +0100 libceph: use BUG() instead of BUG_ON(1) commit d24cdcd3e40a6825135498e11c20c7976b9bf545 upstream. I ran into this compile warning, which is the result of BUG_ON(1) not always leading to the compiler treating the code path as unreachable: include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds': include/linux/ceph/osdmap.h:62:1: error: control reaches end of non-void function [-Werror=return-type] Using BUG() here avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Ilya Dryomov Cc: Heinrich Schuchardt Signed-off-by: Greg Kroah-Hartman commit cde805106887b01347a227c0acead5fc087a585b Author: Hans de Goede Date: Tue Feb 14 18:12:38 2017 +0200 drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT commit 998d75730b40afc218c059d811869abe9676b305 upstream. If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding the VBT on a jumper ezpad mini3 cherrytrail tablet and on a ACER SW5_017 machine. Signed-off-by: Hans de Goede Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1487088758-30050-1-git-send-email-jani.nikula@intel.com (cherry picked from commit dfb65e71ea2c1d97ac373cc0587dc60b3307581a) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 5eeb3c0eb7eceebc1bef329669cdd70b679f9e3b Author: Chris Wilson Date: Sun Feb 12 21:53:43 2017 +0000 drm/i915: Pass timeout==0 on to i915_gem_object_wait_fence() commit 636deb5b2277cf57bb0f5e00fc9687de9a96061e upstream. The i915_gem_object_wait_fence() uses an incoming timeout=0 to query whether the current fence is busy or idle, without waiting. This can be used by the wait-ioctl to implement a busy query. Fixes: e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with callers") Testcase: igt/gem_wait/basic-busy-write-all Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Joonas Lahtinen Cc: # v4.10-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170212215344.16600-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen (cherry picked from commit d892e9398ecf6defc7972a62227b77dad6be20bd) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit d11d14c5fc0bf87ae1e922cb0b49525e4f8d78f5 Author: Chris Wilson Date: Wed Feb 8 18:12:38 2017 +0000 drm/i915: Check for timeout completion when waiting for the rq to submitted commit 44a027058b24541cc7ec499e6fb91db4b130648a upstream. We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't know the hw id we need to wait upon). Whilst waiting for the request to be submitted, we may exceed the user's timeout and need to propagate the error back. v2: Make ETIME into an error from wait_for_execute for consistent exit handling. Reported-by: Tvrtko Ursulin Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion") Testcase: igt/gem_wait/basic-await Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: # v4.10-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170208181238.7232-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin (cherry picked from commit 969bb72cbfd906d347cf76dc9b8c8dbaf83ba27a) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit e2a946bb97bb83add75c48ab0be544a84d7f9254 Author: Ville Syrjälä Date: Wed Feb 8 19:52:54 2017 +0200 drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code commit aa9323dd49b23932a09023012f050556de64f118 upstream. Until recently vlv_steal_power_sequencer() wasn't being called for normal DP ports, and hence it could assert that it should only be called for pipe A and B (since pipe C doesn't support eDP). However that changed when we started to consider normal DP ports as well when choosing a PPS. So we will now get spurious warnings when vlv_steal_power_sequencer() does get called for pipe C. Avoid this by moving the WARN down into vlv_detach_power_sequencer() where this assertion should still hold. Cc: Imre Deak Fixes: 9f2bdb006a7e ("drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV") References: https://bugs.freedesktop.org/show_bug.cgi?id=95287 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170208175254.10958-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak (cherry picked from commit d158694f452252d0fef335a775aeb3eb74fe7af0) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit c50f65f12705827df11c0245286d25e85fa09433 Author: Chris Wilson Date: Thu Feb 2 13:27:21 2017 +0000 drm/i915: Recreate internal objects with single page segments if dmar fails commit 2d2cfc12b1270c8451edc7d2dd5f79097b3a17d8 upstream. If we fail to dma-map the object, the most common cause is lack of space inside the SW-IOTLB due to fragmentation. If we recreate the_sg_table using segments of PAGE_SIZE (and single page allocations), we may succeed in remapping the scatterlist. First became a significant problem for the mock selftests after commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen") increased the max_order. Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable private objects") Fixes: 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Link: http://patchwork.freedesktop.org/patch/msgid/20170202132721.12711-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin (cherry picked from commit bb96dcf5830e5d81a1da2e2a14e6c0f7dfc64348) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 4a8a58eed2762c378f0926474edccf014be9a1e7 Author: Chris Wilson Date: Tue Feb 7 12:49:56 2017 +0000 drm: Cancel drm_fb_helper_resume_work on unload commit 24f76b2c87ed68f79f9f0705b11ccbefaaa0d390 upstream. We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Signed-off-by: Chris Wilson Cc: Noralf Trønnes Cc: Daniel Vetter Cc: Jani Nikula Cc: Sean Paul Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-2-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit 616c9bd8b288dec4402d430602fe0929d0e4f78d Author: Chris Wilson Date: Tue Feb 7 12:49:55 2017 +0000 drm: Cancel drm_fb_helper_dirty_work on unload commit f21b9a92ca7c29382909eaab9facc2cf46f2cc0b upstream. We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support") Signed-off-by: Chris Wilson Cc: Noralf Trønnes Cc: Daniel Vetter Cc: Jani Nikula Cc: Sean Paul Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit cdb4f19aae0fbd1d73734af7682552ba67204b10 Author: Chris Wilson Date: Wed Nov 9 10:39:05 2016 +0000 drm/i915/gvt: Disable access to stolen memory as a guest commit ddd09373628adcbdc3f7b9098d22328834f8d772 upstream. Explicitly disable stolen memory when running as a guest in a virtual machine, since the memory is not mediated between clients and reserved entirely for the host. The actual size should be reported as zero, but like every other quirk we want to tell the user what is happening. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028 Signed-off-by: Chris Wilson Cc: Zhenyu Wang Cc: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/20161109103905.17860-1-chris@chris-wilson.co.uk Reviewed-by: Zhenyu Wang (cherry picked from commit 04a68a35ce6d7b54749989f943993020f48fed62) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit f7189c6bb9f2d07736b82d5929d4910f103246cb Author: Dan Carpenter Date: Wed Feb 8 02:46:01 2017 +0300 drm/atomic: fix an error code in mode_fixup() commit f9ad86e42d0303eeb8e0d41bb208153022ebd9d2 upstream. Having "ret" be a bool type works for everything except ret = funcs->atomic_check(). The other functions all return zero on error but ->atomic_check() returns negative error codes. We want to propagate the error code but instead we return 1. I found this bug with static analysis and I don't know if it affects run time. Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers") Signed-off-by: Dan Carpenter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170207234601.GA23981@mwanda Signed-off-by: Greg Kroah-Hartman commit 99eb5a10a7f7f1192e92f58296022e48064b87c5 Author: Fabio Estevam Date: Wed Feb 8 10:47:49 2017 -0200 drm/imx: imx-tve: Do not set the regulator voltage commit fc12bccda8b6f5c38139eceec9e369ed78091b2b upstream. Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") exposes the following probe issue: 63ff0000.tve supply dac not found, using dummy regulator imx-drm display-subsystem: failed to bind 63ff0000.tve (ops imx_tve_ops): -22 When the 'dac-supply' is not passed in the device tree a dummy regulator is used and setting its voltage is not allowed. To fix this issue, do not set the dac-supply voltage inside the driver and let its voltage be specified in the device tree. Print a warning if the the 'dac-supply' voltage has a value different from 2.75V. Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") Suggested-by: Lucas Stach Signed-off-by: Fabio Estevam Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 5e0b0839f3ced7085d6240d1884b363797ce1051 Author: Thomas Hellstrom Date: Tue Feb 21 17:42:27 2017 +0700 drm/vmwgfx: Work around drm removal of control nodes commit 31788ca803a0c89078f9e604e64286fbd9077926 upstream. vmware tools has a daemon that gets layout information from the GUI and forwards it to DRM so that the modesetting code can set preferred connector locations and modes. This daemon was using control nodes but since control nodes were just removed, make it possible for the daemon to use render- or primary nodes instead. This is a bit ugly but will allow drm to proceed with removal of the mostly unused control-node code and allow vmware to proceed with fixing up automatic layout settings for gnome-shell/wayland. We bump minor to inform user-space about the api change. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170221104227.2854-1-thellstrom@vmware.com Signed-off-by: Greg Kroah-Hartman commit e6d03fc74541fcfc49d82b5f4adbf912a180d5a0 Author: Michel Dänzer Date: Wed Jan 25 17:21:31 2017 +0900 drm/ttm: Make sure BOs being swapped out are cacheable commit 239ac65fa5ffab71adf66e642750f940e7241d99 upstream. The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Signed-off-by: Michel Dänzer Reviewed-by: Thomas Hellstrom Reviewed-by: Christian König . Reviewed-by: Sinclair Yeh Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 0586602fc10fa1982b024235ee3e584c7f90504d Author: Tomeu Vizoso Date: Mon Feb 20 16:25:45 2017 +0100 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058 commit 36fc579761b50784b63dafd0f2e796b659e0f5ee upstream. Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all 1.1. When a sink that supports deep color is connected to the output, the receiver will send EDIDs that advertise this capability, even if it isn't possible with HDMI versions earlier than 1.3. Currently the kernel is assuming that deep color is possible and the sink displays an error. This quirk will make sure that deep color isn't used with this particular receiver. Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Signed-off-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20170220152545.13153-1-tomeu.vizoso@collabora.com Cc: Matt Horan Tested-by: Matt Horan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869 Reviewed-by: Ville Syrjälä Signed-off-by: Ville Syrjälä Signed-off-by: Greg Kroah-Hartman commit 68279b15119b5d3ea024789c4cf470f5a725a084 Author: Alex Deucher Date: Wed Jan 25 15:33:44 2017 -0500 drm/radeon: handle vfct with multiple vbios images commit a882f5de402ded769af74fbf276132f9c175049c upstream. The vfct table can contain multiple vbios images if the platform contains multiple GPUs. Noticed by netkas on phoronix forums. This patch fixes those platforms. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e5135309218279e324d8125c63c61a8113fce028 Author: Y.C. Chen Date: Thu Feb 23 15:52:33 2017 +0800 drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS commit 3856081eede297b617560b85e948cfb00bb395ec upstream. The current POST code for the AST2300/2400 family doesn't work properly if the chip hasn't been initialized previously by either the BMC own FW or the VBIOS. This fixes it. Signed-off-by: Y.C. Chen Signed-off-by: Benjamin Herrenschmidt Tested-by: Y.C. Chen Acked-by: Joel Stanley Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit cd8183923984ed106978f498492c529165fa15f2 Author: Y.C. Chen Date: Wed Feb 22 15:14:19 2017 +1100 drm/ast: Call open_key before enable_mmio in POST code commit 9bb92f51558f2ef5f56c257bdcea0588f31d857e upstream. open_key enables access the registers used by enable_mmio Signed-off-by: Y.C. Chen Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley Tested-by: Y.C. Chen Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit f38a3c87d6eeee5b3bed7d71887bdbbfe39f79b3 Author: Y.C. Chen Date: Wed Feb 22 15:10:50 2017 +1100 drm/ast: Fix test for VGA enabled commit 905f21a49d388de3e99438235f3301cabf0c0ef4 upstream. The test to see if VGA was already enabled is doing an unnecessary second test from a register that may or may not have been initialized to a valid value. Remove it. Signed-off-by: Y.C. Chen Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley Tested-by: Y.C. Chen Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit af7fe73a14fcfa8a06395bf239a11730cc06b2a1 Author: Russell Currey Date: Fri Feb 17 14:33:01 2017 +1100 drm/ast: Handle configuration without P2A bridge commit 71f677a91046599ece96ebab21df956ce909c456 upstream. The ast driver configures a window to enable access into BMC memory space in order to read some configuration registers. If this window is disabled, which it can be from the BMC side, the ast driver can't function. Closing this window is a necessity for security if a machine's host side and BMC side are controlled by different parties; i.e. a cloud provider offering machines "bare metal". A recent patch went in to try to check if that window is open but it does so by trying to access the registers in question and testing if the result is 0xffffffff. This method will trigger a PCIe error when the window is closed which on some systems will be fatal (it will trigger an EEH for example on POWER which will take out the device). This patch improves this in two ways: - First, if the firmware has put properties in the device-tree containing the relevant configuration information, we use these. - Otherwise, a bit in one of the SCU scratch registers (which are readable via the VGA register space and writeable by the BMC) will indicate if the BMC has closed the window. This bit has been defined by Y.C Chen from Aspeed. If the window is closed and the configuration isn't available from the device-tree, some sane defaults are used. Those defaults are hopefully sufficient for standard video modes used on a server. Signed-off-by: Russell Currey Acked-by: Joel Stanley Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0f9e6fc5b76df7e9c123cdd2690abfd59486a1d0 Author: Jean Delvare Date: Thu Mar 2 18:21:35 2017 +0100 Revert "drm/amdgpu: update tile table for oland/hainan" Revert commit f8d9422ef80c ("drm/amdgpu: update tile table for oland/hainan") as it is causing ugly visual artifacts on at least Oland. This is only an optimization so we can live without it. This fixes kernel bug #194761: amdgpu driver breaks on Oland (SI) https://bugzilla.kernel.org/show_bug.cgi?id=194761 Signed-off-by: Jean Delvare Fixes: f8d9422ef80c ("drm/amdgpu: update tile table for oland/hainan") Cc: Flora Cui Cc: Junwei Zhang Cc: Alex Deucher Acked-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2deaea3e0d07fc9e3ab41e7c6f4d63b85f0fcdbb Author: Alex Deucher Date: Fri Feb 10 18:09:32 2017 -0500 drm/amdgpu/pm: check for headless before calling compute_clocks commit c10c8f7c27103bd7ac02d041d9d6e97296d48fc1 upstream. Don't update display bandwidth on headless asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=99387 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 33d129a09aae8b0f87b49702c96b365fe9d9128d Author: Alex Deucher Date: Fri Feb 10 00:00:52 2017 -0500 drm/amdgpu: add more cases to DCE11 possible crtc mask setup commit 4ce3bd45b351633f2a0512c587f7fcba2ce044e8 upstream. Add cases for asics with 3 and 5 crtcs. Fixes an artificial limitation on asics with 3 or 5 crtcs. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99744 Reviewed-by: Michel Dänzer Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fc758b77745e47ef4e56fb1f1fb1a93d0820ca28 Author: Johannes Berg Date: Mon Feb 27 09:38:11 2017 +0100 mac80211: use driver-indicated transmitter STA only for data frames commit 19d19e960598161be92a7e4828eb7706c6410ce6 upstream. When I originally introduced using the driver-indicated station as an optimisation to avoid the hashtable lookup/iteration, of course it wasn't intended to really functionally change anything. I neglected, however, to take into account VLAN interfaces, which have the property that management and data frames are handled differently: data frames go directly to the station and the VLAN while management frames continue to be processed over the underlying/associated AP-type interface. As a consequence, when a driver used this optimisation for management frames and the user enabled VLANs, my change broke things since any management frames, particularly disassoc/deauth, were missed by hostapd. Fix this by restoring the original code path for non-data frames, they aren't critical for performance to begin with. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=194713. Big thanks goes to Jarek who bisected the issue and provided a very detailed bug report, including the crucial information that he was using VLANs in his configuration. Fixes: 771e846bea9e ("mac80211: allow passing transmitter station on RX") Reported-and-tested-by: Jarek Kamiński Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4a6d105fb27769361a81edf55432f6a11ce8ba9c Author: Felix Fietkau Date: Wed Feb 22 16:16:07 2017 +0100 mac80211: don't handle filtered frames within a BA session commit 890030d3c425f49abaa4acf60e20f288b599f980 upstream. When running a BA session, the driver (or the hardware) already takes care of retransmitting failed frames, since it has to keep the receiver reorder window in sync. Adding another layer of retransmit around that does not improve anything. In fact, it can only lead to some strong reordering with huge latency. Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit df7db05561f67f742b2efa9a5fff6e7b9c243e2d Author: Sara Sharon Date: Mon Feb 6 15:28:42 2017 +0200 mac80211: don't reorder frames with SN smaller than SSN commit b7540d8f25c8034de7e4163fc23ac457bf057731 upstream. When RX aggregation starts, transmitter may continue send frames with SN smaller than SSN until the AddBA response is received. However, the reorder buffer is already initialized at this point, which will cause the drop of such frames as duplicates since the head SN of the reorder buffer is set to the SSN, which is bigger. Signed-off-by: Sara Sharon Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f5bf0a15c63eef8dbcaf5fd7e75cc9cafdb7f652 Author: Matt Chen Date: Sun Jan 22 02:16:58 2017 +0800 mac80211: flush delayed work when entering suspend commit a9e9200d8661c1a0be8c39f93deb383dc940de35 upstream. The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ea708e9581d87d7896be4760a066f8f6c9759ab4 Author: Dan Williams Date: Tue Feb 28 18:32:48 2017 -0800 nfit, libnvdimm: fix interleave set cookie calculation commit 86ef58a4e35e8fa66afb5898cf6dec6a3bb29f67 upstream. The interleave-set cookie is a sum that sanity checks the composition of an interleave set has not changed from when the namespace was initially created. The checksum is calculated by sorting the DIMMs by their location in the interleave-set. The comparison for the sort must be 64-bit wide, not byte-by-byte as performed by memcmp() in the broken case. Fix the implementation to accept correct cookie values in addition to the Linux "memcmp" order cookies, but only allow correct cookies to be generated going forward. It does mean that namespaces created by third-party-tooling, or created by newer kernels with this fix, will not validate on older kernels. However, there are a couple mitigating conditions: 1/ platforms with namespace-label capable NVDIMMs are not widely available. 2/ interleave-sets with a single-dimm are by definition not affected (nothing to sort). This covers the QEMU-KVM NVDIMM emulation case. The cookie stored in the namespace label will be fixed by any write the namespace label, the most straightforward way to achieve this is to write to the "alt_name" attribute of a namespace in sysfs. Fixes: eaf961536e16 ("libnvdimm, nfit: add interleave-set state-tracking infrastructure") Reported-by: Nicholas Moulin Tested-by: Nicholas Moulin Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 3f56c495a42e78c404bc65d8fef6820c1c37c48c Author: Max Filippov Date: Tue Jan 3 09:37:34 2017 -0800 xtensa: move parse_tag_fdt out of #ifdef CONFIG_BLK_DEV_INITRD commit 4ab18701c66552944188dbcd0ce0012729baab84 upstream. FDT tag parsing is not related to whether BLK_DEV_INITRD is configured or not, move it out of the corresponding #ifdef/#endif block. This fixes passing external FDT to the kernel configured w/o BLK_DEV_INITRD support. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 5a4312c2a65120509a1e0b93469eafe47d768f9c Author: Clemens Gruber Date: Tue Dec 13 16:52:50 2016 +0100 pwm: pca9685: Fix period change with same duty cycle commit 8d254a340efb12b40c4c1ff25a48a4f48f7bbd6b upstream. When first implementing support for changing the output frequency, an optimization was added to continue the PWM after changing the prescaler without having to reprogram the ON and OFF registers for the duty cycle, in case the duty cycle stayed the same. This was flawed, because we compared the absolute value of the duty cycle in nanoseconds instead of the ratio to the period. Fix the problem by removing the shortcut. Fixes: 01ec8472009c9 ("pwm-pca9685: Support changing the output frequency") Signed-off-by: Clemens Gruber Reviewed-by: Mika Westerberg Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit c634f19b9501919202541b1dc721388883c0f94f Author: Trond Myklebust Date: Sat Feb 11 10:37:38 2017 -0500 nlm: Ensure callback code also checks that the files match commit 251af29c320d86071664f02c76f0d063a19fefdf upstream. It is not sufficient to just check that the lock pids match when granting a callback, we also need to ensure that we're granting the callback on the right file. Reported-by: Pankaj Singh Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 1a02f33a6302ed98ad1c71125a93cf65b759184b Author: Gavin Shan Date: Wed Jan 11 11:50:07 2017 +1100 drivers/pci/hotplug: Fix initial state for empty slot commit d0c424971f70501ec0a0364117b9934db039c9cc upstream. In PowerNV PCI hotplug driver, the initial PCI slot's state is set to PNV_PHP_STATE_POPULATED if no PCI devices are connected to the slot. The PCI devices that are hot added to the slot won't be probed and populated because of the check in pnv_php_enable(): /* Check if the slot has been configured */ if (php_slot->state != PNV_PHP_STATE_REGISTERED) return 0; This fixes the issue by leaving the slot in PNV_PHP_STATE_REGISTERED state initially if nothing is connected to the slot. Fixes: 360aebd85a4 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver") Reported-by: Hank Chang Signed-off-by: Gavin Shan Tested-by: Willie Liauw Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 487163f3f316909ffe33bf0aca2ea8f0d0cfb6d8 Author: Gavin Shan Date: Wed Jan 11 11:50:06 2017 +1100 drivers/pci/hotplug: Handle presence detection change properly commit d7d55536c6cd1f80295b6d7483ad0587b148bde4 upstream. The surprise hotplug is driven by interrupt in PowerNV PCI hotplug driver. In the interrupt handler, pnv_php_interrupt(), we bail when pnv_pci_get_presence_state() returns zero wrongly. It causes the presence change event is always ignored incorrectly. This fixes the issue by bailing on error (non-zero value) returned from pnv_pci_get_presence_state(). Fixes: 360aebd85a4 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver") Reported-by: Hank Chang Signed-off-by: Gavin Shan Tested-by: Willie Liauw Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f9b90f20474948f22f2e25abc98a85fa39009db5 Author: Nicholas Bellinger Date: Wed Feb 22 22:06:32 2017 -0800 target: Fix NULL dereference during LUN lookup + active I/O shutdown commit bd4e2d2907fa23a11d46217064ecf80470ddae10 upstream. When transport_clear_lun_ref() is shutting down a se_lun via configfs with new I/O in-flight, it's possible to trigger a NULL pointer dereference in transport_lookup_cmd_lun() due to the fact percpu_ref_get() doesn't do any __PERCPU_REF_DEAD checking before incrementing lun->lun_ref.count after lun->lun_ref has switched to atomic_t mode. This results in a NULL pointer dereference as LUN shutdown code in core_tpg_remove_lun() continues running after the existing ->release() -> core_tpg_lun_ref_release() callback completes, and clears the RCU protected se_lun->lun_se_dev pointer. During the OOPs, the state of lun->lun_ref in the process which triggered the NULL pointer dereference looks like the following on v4.1.y stable code: struct se_lun { lun_link_magic = 4294932337, lun_status = TRANSPORT_LUN_STATUS_FREE, ..... lun_se_dev = 0x0, lun_sep = 0x0, ..... lun_ref = { count = { counter = 1 }, percpu_count_ptr = 3, release = 0xffffffffa02fa1e0 , confirm_switch = 0x0, force_atomic = false, rcu = { next = 0xffff88154fa1a5d0, func = 0xffffffff8137c4c0 } } } To address this bug, use percpu_ref_tryget_live() to ensure once __PERCPU_REF_DEAD is visable on all CPUs and ->lun_ref has switched to atomic_t, all new I/Os will fail to obtain a new lun->lun_ref reference. Also use an explicit percpu_ref_kill_and_confirm() callback to block on ->lun_ref_comp to allow the first stage and associated RCU grace period to complete, and then block on ->lun_ref_shutdown waiting for the final percpu_ref_put() to drop the last reference via transport_lun_remove_cmd() before continuing with core_tpg_remove_lun() shutdown. Reported-by: Rob Millner Tested-by: Rob Millner Cc: Rob Millner Tested-by: Vaibhav Tandon Cc: Vaibhav Tandon Tested-by: Bryant G. Ly Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 81bd29553ee3b86e0f0ddd1c951e41fe04cb73ec Author: Gavin Shan Date: Thu Feb 16 10:22:33 2017 +1100 pci/hotplug/pnv-php: Disable surprise hotplug capability on conflicts commit 303529d6ef1293513c2c73c9ab86489eebb37d08 upstream. The root port or PCIe switch downstream port might have been associated with driver other than pnv-php. The MSI or MSIx might also have been enabled by that driver (e.g. pcieport_drv). Attempt to enable MSI incurs below backtrace: PowerPC PowerNV PCI Hotplug Driver version: 0.1 ------------[ cut here ]------------ WARNING: CPU: 19 PID: 1004 at drivers/pci/msi.c:1071 \ __pci_enable_msi_range+0x84/0x4e0 NIP [c000000000665c34] __pci_enable_msi_range+0x84/0x4e0 LR [c000000000665c24] __pci_enable_msi_range+0x74/0x4e0 Call Trace: [c000000384d67600] [c000000000665c24] __pci_enable_msi_range+0x74/0x4e0 [c000000384d676e0] [d00000000aa31b04] pnv_php_register+0x564/0x5a0 [pnv_php] [c000000384d677c0] [d00000000aa31658] pnv_php_register+0xb8/0x5a0 [pnv_php] [c000000384d678a0] [d00000000aa31658] pnv_php_register+0xb8/0x5a0 [pnv_php] [c000000384d67980] [d00000000aa31dfc] pnv_php_init+0x60/0x98 [pnv_php] [c000000384d679f0] [c00000000000cfdc] do_one_initcall+0x6c/0x1d0 [c000000384d67ab0] [c000000000b92354] do_init_module+0x94/0x254 [c000000384d67b40] [c00000000019719c] load_module+0x258c/0x2c60 [c000000384d67d30] [c000000000197bb0] SyS_finit_module+0xf0/0x170 [c000000384d67e30] [c00000000000b184] system_call+0x38/0xe0 This fixes the issue by skipping enabling the surprise hotplug capability if the MSI or MSIx on the PCI slot's upstream port has been enabled by other driver. Fixes: 360aebd85a4c ("drivers/pci/hotplug: Support surprise hotplug in powernv driver") Signed-off-by: Gavin Shan Reviewed-by: Andrew Donnellan Tested-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 7e8b775284450b9c1d3429f4039bc72e2124fc08 Author: Gavin Shan Date: Thu Feb 16 10:22:32 2017 +1100 pci/hotplug/pnv-php: Remove WARN_ON() in pnv_php_put_slot() commit 36c7c9da40c408a71e5e6bfe12e57dcf549a296d upstream. The WARN_ON() causes unnecessary backtrace when putting the parent slot, which is likely to be NULL. WARNING: CPU: 2 PID: 1071 at drivers/pci/hotplug/pnv_php.c:85 \ pnv_php_release+0xcc/0x150 [pnv_php] : Call Trace: [c0000003bc007c10] [d00000000ad613c4] pnv_php_release+0x144/0x150 [pnv_php] [c0000003bc007c40] [c0000000006641d8] pci_hp_deregister+0x238/0x330 [c0000003bc007cd0] [d00000000ad61440] pnv_php_unregister_one+0x70/0xa0 [pnv_php] [c0000003bc007d10] [d00000000ad614c0] pnv_php_unregister+0x50/0x80 [pnv_php] [c0000003bc007d40] [d00000000ad61e84] pnv_php_exit+0x50/0xcb4 [pnv_php] [c0000003bc007d70] [c00000000019499c] SyS_delete_module+0x1fc/0x2a0 [c0000003bc007e30] [c00000000000b184] system_call+0x38/0xe0 Fixes: 66725152fb9f ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver") Signed-off-by: Gavin Shan Reviewed-by: Andrew Donnellan Tested-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ab3398e159fd60771de132d7aa80e70f1980ecd1 Author: Jeff Layton Date: Tue Feb 14 10:09:40 2017 -0500 ceph: remove req from unsafe list when unregistering it commit df963ea8a082d31521a120e8e31a29ad8a1dc215 upstream. There's no reason a request should ever be on a s_unsafe list but not in the request tree. Link: http://tracker.ceph.com/issues/18474 Signed-off-by: Jeff Layton Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 0569b5ed3e73f12f68a92ec956e43a069d66a9ae Author: Steven Rostedt (VMware) Date: Tue Feb 7 12:05:25 2017 -0500 ktest: Fix child exit code processing commit 32677207dcc5e594254b7fb4fb2352b1755b1d5b upstream. The child_exit errno needs to be shifted by 8 bits to compare against the return values for the bisect variables. Fixes: c5dacb88f0a64 ("ktest: Allow overriding bisect test results") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 9dbea7f7bcec1e8108f1d100fed4b4602faf1fca Author: Wei Yongjun Date: Thu Jan 12 13:55:02 2017 +0000 tracing: Fix return value check in trace_benchmark_reg() commit 8f0994bb8cbde5452e58ce0cacdbf6cb58079d01 upstream. In case of error, the function kthread_run() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Link: http://lkml.kernel.org/r/20170112135502.28556-1-weiyj.lk@gmail.com Fixes: 81dc9f0e ("tracing: Add tracepoint benchmark tracepoint") Signed-off-by: Wei Yongjun Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 8a915b3ccbb255eb71bc5bbf263cad672c964660 Author: Boris Brezillon Date: Mon Nov 28 16:17:56 2016 +0100 memory/atmel-ebi: Fix ns <-> cycles conversions commit ee194289502a6901cc77dc9a893bf2afd351ac5e upstream. at91sam9_ebi_get_config() is incorrectly converting timings in clock cycles into timings in nanoseconds by multiplying the cycle values by the clk rate instead of the clk period. at91sam9_ebi_xslate_config() has the same problem for the tdf_ns -> tdf_cycles conversion. Signed-off-by: Boris Brezillon Reported-by: Chris Leahy Fixes: 6a4ec4cd0888 ("memory: add Atmel EBI (External Bus Interface) driver") Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit a4755943204e4eab9fd456926f1607f5238727e4 Author: Peter Zijlstra Date: Fri Feb 24 16:43:36 2017 +0100 orangefs: Use RCU for destroy_inode commit 0695d7dc1d9f19b82ec2cae24856bddce278cfe6 upstream. freeing of inodes must be RCU-delayed on all filesystems Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 2708a2d33e04af19f7d7ab4ce8982b89288ebd42 Author: Filipe Manana Date: Tue Feb 14 16:56:01 2017 +0000 Btrfs: fix data loss after truncate when using the no-holes feature commit 76b42abbf7488121c4f9f1ea5941123306e25d99 upstream. If we have a file with an implicit hole (NO_HOLES feature enabled) that has an extent following the hole, delayed writes against regions of the file behind the hole happened before but were not yet flushed and then we truncate the file to a smaller size that lies inside the hole, we end up persisting a wrong disk_i_size value for our inode that leads to data loss after umounting and mounting again the filesystem or after the inode is evicted and loaded again. This happens because at inode.c:btrfs_truncate_inode_items() we end up setting last_size to the offset of the extent that we deleted and that followed the hole. We then pass that value to btrfs_ordered_update_i_size() which updates the inode's disk_i_size to a value smaller then the offset of the buffered (delayed) writes. Example reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -f -c "pwrite -S 0x01 0K 32K" /mnt/foo $ xfs_io -d -c "pwrite -S 0x02 -b 32K 64K 32K" /mnt/foo $ xfs_io -c "truncate 60K" /mnt/foo --> inode's disk_i_size updated to 0 $ md5sum /mnt/foo 3c5ca3c3ab42f4b04d7e7eb0b0d4d806 /mnt/foo $ umount /dev/sdb $ mount /dev/sdb /mnt $ md5sum /mnt/foo d41d8cd98f00b204e9800998ecf8427e /mnt/foo --> Empty file, all data lost! Fixes: 16e7549f045d ("Btrfs: incompatible format change to remove hole extents") Signed-off-by: Filipe Manana Reviewed-by: Liu Bo Signed-off-by: Greg Kroah-Hartman commit ade784b0f3a77365323aad169b49dffcbac79a4b Author: Eric W. Biederman Date: Wed Feb 1 06:06:16 2017 +1300 fs: Better permission checking for submounts commit 93faccbbfa958a9668d3ab4e30f38dd205cee8d8 upstream. To support unprivileged users mounting filesystems two permission checks have to be performed: a test to see if the user allowed to create a mount in the mount namespace, and a test to see if the user is allowed to access the specified filesystem. The automount case is special in that mounting the original filesystem grants permission to mount the sub-filesystems, to any user who happens to stumble across the their mountpoint and satisfies the ordinary filesystem permission checks. Attempting to handle the automount case by using override_creds almost works. It preserves the idea that permission to mount the original filesystem is permission to mount the sub-filesystem. Unfortunately using override_creds messes up the filesystems ordinary permission checks. Solve this by being explicit that a mount is a submount by introducing vfs_submount, and using it where appropriate. vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let sget and friends know that a mount is a submount so they can take appropriate action. sget and sget_userns are modified to not perform any permission checks on submounts. follow_automount is modified to stop using override_creds as that has proven problemantic. do_mount is modified to always remove the new MS_SUBMOUNT flag so that we know userspace will never by able to specify it. autofs4 is modified to stop using current_real_cred that was put in there to handle the previous version of submount permission checking. cifs is modified to pass the mountpoint all of the way down to vfs_submount. debugfs is modified to pass the mountpoint all of the way down to trace_automount by adding a new parameter. To make this change easier a new typedef debugfs_automount_t is introduced to capture the type of the debugfs automount function. Fixes: 069d5ac9ae0d ("autofs: Fix automounts by using current_real_cred()->uid") Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds") Reviewed-by: Trond Myklebust Reviewed-by: Seth Forshee Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 35065a1f6ec29ec27ecee5a470ec24435e852203 Author: Bart Van Assche Date: Tue Feb 14 10:56:31 2017 -0800 IB/srp: Fix race conditions related to task management commit 0a6fdbdeb1c25e31763c1fb333fa2723a7d2aba6 upstream. Avoid that srp_process_rsp() overwrites the status information in ch if the SRP target response timed out and processing of another task management function has already started. Avoid that issuing multiple task management functions concurrently triggers list corruption. This patch prevents that the following stack trace appears in the system log: WARNING: CPU: 8 PID: 9269 at lib/list_debug.c:52 __list_del_entry_valid+0xbc/0xc0 list_del corruption. prev->next should be ffffc90004bb7b00, but was ffff8804052ecc68 CPU: 8 PID: 9269 Comm: sg_reset Tainted: G W 4.10.0-rc7-dbg+ #3 Call Trace: dump_stack+0x68/0x93 __warn+0xc6/0xe0 warn_slowpath_fmt+0x4a/0x50 __list_del_entry_valid+0xbc/0xc0 wait_for_completion_timeout+0x12e/0x170 srp_send_tsk_mgmt+0x1ef/0x2d0 [ib_srp] srp_reset_device+0x5b/0x110 [ib_srp] scsi_ioctl_reset+0x1c7/0x290 scsi_ioctl+0x12a/0x420 sd_ioctl+0x9d/0x100 blkdev_ioctl+0x51e/0x9f0 block_ioctl+0x38/0x40 do_vfs_ioctl+0x8f/0x700 SyS_ioctl+0x3c/0x70 entry_SYSCALL_64_fastpath+0x18/0xad Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Laurence Oberman Cc: Steve Feeley Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit a9397e4365d6da6fb2b9e01c3612ca9a87046c2c Author: Bart Van Assche Date: Tue Feb 14 10:56:30 2017 -0800 IB/srp: Avoid that duplicate responses trigger a kernel bug commit 6cb72bc1b40bb2c1750ee7a5ebade93bed49a5fb upstream. After srp_process_rsp() returns there is a short time during which the scsi_host_find_tag() call will return a pointer to the SCSI command that is being completed. If during that time a duplicate response is received, avoid that the following call stack appears: BUG: unable to handle kernel NULL pointer dereference at (null) IP: srp_recv_done+0x450/0x6b0 [ib_srp] Oops: 0000 [#1] SMP CPU: 10 PID: 0 Comm: swapper/10 Not tainted 4.10.0-rc7-dbg+ #1 Call Trace: __ib_process_cq+0x4b/0xd0 [ib_core] ib_poll_handler+0x1d/0x70 [ib_core] irq_poll_softirq+0xba/0x120 __do_softirq+0xba/0x4c0 irq_exit+0xbe/0xd0 smp_apic_timer_interrupt+0x38/0x50 apic_timer_interrupt+0x90/0xa0 RIP: srp_recv_done+0x450/0x6b0 [ib_srp] RSP: ffff88046f483e20 Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Laurence Oberman Cc: Steve Feeley Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit a51892e0c1360857f933b4714cdbd0a266f1ea0f Author: Bart Van Assche Date: Tue Feb 14 10:56:29 2017 -0800 IB/SRP: Avoid using IB_MR_TYPE_SG_GAPS commit d6c58dc40fec35ff6cdb350b53bce0fcf9143709 upstream. Tests have shown that the following error message is reported when using SG-GAPS registration with an mlx5 adapter: scsi host1: ib_srp: failed RECV status WR flushed (5) for CQE ffff880bd4270eb0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0f007806 2500002a ad9fafd1 scsi host1: ib_srp: reconnect succeeded mlx5_0:dump_cqe:262:(pid 7369): dump error cqe 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0f007806 25000032 00105dd0 scsi host1: ib_srp: failed FAST REG status memory management operation error (6) for CQE ffff880b92860138 Hence avoid using SG-GAPS memory registrations. Additionally, always configure the blk_queue_virt_boundary() to avoid to trigger a mapping failure when using adapters that support SG-GAPS (e.g. mlx5). Fixes: commit ad8e66b4a801 ("IB/srp: fix mr allocation when the device supports sg gaps") Fixes: commit 509c5f33f4f6 ("IB/srp: Prevent mapping failures") Reported-by: Laurence Oberman Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Leon Romanovsky Cc: Mark Bloch Cc: Yuval Shaia Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit e0d15d562ee7c61665718549a1ad2826007ce823 Author: Leon Romanovsky Date: Wed Jan 18 14:10:30 2017 +0200 IB/mlx5: Fix out-of-bound access commit 0fd27a88c2e4f548937fd7d93fc6e65c4ad7c278 upstream. When we initialize buffer to create SRQ in kernel, the number of pages was less than actually used in following mlx5_fill_page_array(). Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Leon Romanovsky Reviewed-by: Eli Cohen Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit b92c4a09f58934e95871e8e4b98f184bfaab0196 Author: Erez Shitrit Date: Wed Feb 1 19:10:05 2017 +0200 IB/IPoIB: Add destination address when re-queue packet commit 2b0841766a898aba84630fb723989a77a9d3b4e6 upstream. When sending packet to destination that was not resolved yet via path query, the driver keeps the skb and tries to re-send it again when the path is resolved. But when re-sending via dev_queue_xmit the kernel doesn't call to dev_hard_header, so IPoIB needs to keep 20 bytes in the skb and to put the destination address inside them. In that way the dev_start_xmit will have the correct destination, and the driver won't take the destination from the skb->data, while nothing exists there, which causes to packet be be dropped. The test flow is: 1. Run the SM on remote node, 2. Restart the driver. 4. Ping some destination, 3. Observe that first ICMP request will be dropped. Fixes: fc791b633515 ("IB/ipoib: move back IB LL address into the hard header") Signed-off-by: Erez Shitrit Signed-off-by: Noa Osherovich Signed-off-by: Leon Romanovsky Tested-by: Yuval Shaia Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 91948b0944afdd667f13357b0324a7f525c3207d Author: Feras Daoud Date: Wed Dec 28 14:47:23 2016 +0200 IB/ipoib: Fix deadlock between rmmod and set_mode commit 0a0007f28304cb9fc87809c86abb80ec71317f20 upstream. When calling set_mode from sys/fs, the call flow locks the sys/fs lock first and then tries to lock rtnl_lock (when calling ipoib_set_mod). On the other hand, the rmmod call flow takes the rtnl_lock first (when calling unregister_netdev) and then tries to take the sys/fs lock. Deadlock a->b, b->a. The problem starts when ipoib_set_mod frees it's rtnl_lck and tries to get it after that. set_mod: [] ? check_preempt_curr+0x6d/0x90 [] __mutex_lock_slowpath+0x13e/0x180 [] ? __rtnl_unlock+0x15/0x20 [] mutex_lock+0x2b/0x50 [] rtnl_lock+0x15/0x20 [] ipoib_set_mode+0x97/0x160 [ib_ipoib] [] set_mode+0x3b/0x80 [ib_ipoib] [] dev_attr_store+0x20/0x30 [] sysfs_write_file+0xe5/0x170 [] vfs_write+0xb8/0x1a0 [] sys_write+0x51/0x90 [] system_call_fastpath+0x16/0x1b rmmod: [] ? put_dec+0x10c/0x110 [] ? number+0x2ee/0x320 [] schedule_timeout+0x215/0x2e0 [] ? vsnprintf+0x484/0x5f0 [] ? string+0x40/0x100 [] wait_for_common+0x123/0x180 [] ? default_wake_function+0x0/0x20 [] ? ifind_fast+0x5e/0xb0 [] wait_for_completion+0x1d/0x20 [] sysfs_addrm_finish+0x228/0x270 [] sysfs_remove_dir+0xa3/0xf0 [] kobject_del+0x16/0x40 [] device_del+0x184/0x1e0 [] netdev_unregister_kobject+0xab/0xc0 [] rollback_registered+0xae/0x130 [] unregister_netdevice+0x22/0x70 [] unregister_netdev+0x1e/0x30 [] ipoib_remove_one+0xe0/0x120 [ib_ipoib] [] ib_unregister_device+0x4f/0x100 [ib_core] [] mlx4_ib_remove+0x41/0x180 [mlx4_ib] [] mlx4_remove_device+0x71/0x90 [mlx4_core] Fixes: 862096a8bbf8 ("IB/ipoib: Add more rtnl_link_ops callbacks") Cc: Or Gerlitz Signed-off-by: Feras Daoud Signed-off-by: Erez Shitrit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 6de9d08a9718ee9c12ba6343c50141c2d633e3dc Author: Eric W. Biederman Date: Fri Jan 20 18:28:35 2017 +1300 mnt: Tuck mounts under others instead of creating shadow/side mounts. commit 1064f874abc0d05eeed8993815f584d847b72486 upstream. Ever since mount propagation was introduced in cases where a mount in propagated to parent mount mountpoint pair that is already in use the code has placed the new mount behind the old mount in the mount hash table. This implementation detail is problematic as it allows creating arbitrary length mount hash chains. Furthermore it invalidates the constraint maintained elsewhere in the mount code that a parent mount and a mountpoint pair will have exactly one mount upon them. Making it hard to deal with and to talk about this special case in the mount code. Modify mount propagation to notice when there is already a mount at the parent mount and mountpoint where a new mount is propagating to and place that preexisting mount on top of the new mount. Modify unmount propagation to notice when a mount that is being unmounted has another mount on top of it (and no other children), and to replace the unmounted mount with the mount on top of it. Move the MNT_UMUONT test from __lookup_mnt_last into __propagate_umount as that is the only call of __lookup_mnt_last where MNT_UMOUNT may be set on any mount visible in the mount hash table. These modifications allow: - __lookup_mnt_last to be removed. - attach_shadows to be renamed __attach_mnt and its shadow handling to be removed. - commit_tree to be simplified - copy_tree to be simplified The result is an easier to understand tree of mounts that does not allow creation of arbitrary length hash chains in the mount hash table. The result is also a very slight userspace visible difference in semantics. The following two cases now behave identically, where before order mattered: case 1: (explicit user action) B is a slave of A mount something on A/a , it will propagate to B/a and than mount something on B/a case 2: (tucked mount) B is a slave of A mount something on B/a and than mount something on A/a Histroically umount A/a would fail in case 1 and succeed in case 2. Now umount A/a succeeds in both configurations. This very small change in semantics appears if anything to be a bug fix to me and my survey of userspace leads me to believe that no programs will notice or care of this subtle semantic change. v2: Updated to mnt_change_mountpoint to not call dput or mntput and instead to decrement the counts directly. It is guaranteed that there will be other references when mnt_change_mountpoint is called so this is safe. v3: Moved put_mountpoint under mount_lock in attach_recursive_mnt As the locking in fs/namespace.c changed between v2 and v3. v4: Reworked the logic in propagate_mount_busy and __propagate_umount that detects when a mount completely covers another mount. v5: Removed unnecessary tests whose result is alwasy true in find_topper and attach_recursive_mnt. v6: Document the user space visible semantic difference. Fixes: b90fa9ae8f51 ("[PATCH] shared mount handling: bind and rbind") Tested-by: Andrei Vagin Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit f03d5078063c2cc71bfe5dadbec8c42f6ffb84c3 Author: Gavin Li Date: Tue Jan 17 15:24:05 2017 -0800 brcmfmac: fix incorrect event channel deduction commit 8e290cecdd0178f3d4cf7d463c51dc7e462843b4 upstream. brcmf_sdio_fromevntchan() was being called on the the data frame rather than the software header, causing some frames to be mischaracterized as on the event channel rather than the data channel. This fixes a major performance regression (due to dropped packets). With this patch the download speed jumped from 1Mbit/s back up to 40MBit/s due to the sheer amount of packets being incorrectly processed. Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet") Signed-off-by: Gavin Li Acked-by: Arend van Spriel [kvalo@codeaurora.org: improve commit logs based on email discussion] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 8cdfa0d8b0f549b739e97fff1fe886d5b3df5d2e Author: Andrew Donnellan Date: Mon Feb 6 12:07:17 2017 +1100 cxl: fix nested locking hang during EEH hotplug commit 171ed0fcd8966d82c45376f1434678e7b9d4d9b1 upstream. Commit 14a3ae34bfd0 ("cxl: Prevent read/write to AFU config space while AFU not configured") introduced a rwsem to fix an invalid memory access that occurred when someone attempts to access the config space of an AFU on a vPHB whilst the AFU is deconfigured, such as during EEH recovery. It turns out that it's possible to run into a nested locking issue when EEH recovery fails and a full device hotplug is required. cxl_pci_error_detected() deconfigures the AFU, taking a writer lock on configured_rwsem. When EEH recovery fails, the EEH code calls pci_hp_remove_devices() to remove the device, which in turn calls cxl_remove() -> cxl_pci_remove_afu() -> pci_deconfigure_afu(), which tries to grab the writer lock that's already held. Standard rwsem semantics don't express what we really want to do here and don't allow for nested locking. Fix this by replacing the rwsem with an atomic_t which we can control more finely. Allow the AFU to be locked multiple times so long as there are no readers. Fixes: 14a3ae34bfd0 ("cxl: Prevent read/write to AFU config space while AFU not configured") Signed-off-by: Andrew Donnellan Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit e5603a5c6deb30a5821d364d73947bbe69b1fbef Author: Andrew Donnellan Date: Fri Dec 9 17:18:50 2016 +1100 cxl: Prevent read/write to AFU config space while AFU not configured commit 14a3ae34bfd0bcb1cc12d55b06a8584c11fac6fc upstream. During EEH recovery, we deconfigure all AFUs whilst leaving the corresponding vPHB and virtual PCI device in place. If something attempts to interact with the AFU's PCI config space (e.g. running lspci) after the AFU has been deconfigured and before it's reconfigured, cxl_pcie_{read,write}_config() will read invalid values from the deconfigured struct cxl_afu and proceed to Oops when they try to dereference pointers that have been set to NULL during deconfiguration. Add a rwsem to struct cxl_afu so we can prevent interaction with config space while the AFU is deconfigured. Reported-by: Pradipta Ghosh Suggested-by: Frederic Barrat Signed-off-by: Andrew Donnellan Signed-off-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4144a307cb4638315b0bbe9e5469516c89bb844f Author: Thomas Petazzoni Date: Tue Feb 21 11:28:01 2017 +0100 net: mvpp2: fix DMA address calculation in mvpp2_txq_inc_put() commit 239a3b663647869330955ec59caac0100ef9b60a upstream. When TX descriptors are filled in, the buffer DMA address is split between the tx_desc->buf_phys_addr field (high-order bits) and tx_desc->packet_offset field (5 low-order bits). However, when we re-calculate the DMA address from the TX descriptor in mvpp2_txq_inc_put(), we do not take tx_desc->packet_offset into account. This means that when the DMA address is not aligned on a 32 bytes boundary, we end up calling dma_unmap_single() with a DMA address that was not the one returned by dma_map_single(). This inconsistency is detected by the kernel when DMA_API_DEBUG is enabled. We fix this problem by properly calculating the DMA address in mvpp2_txq_inc_put(). Signed-off-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c9ac3e943deba05e17db732044e6ec44a29e0b7b Author: Heiko Carstens Date: Sun Feb 5 23:03:18 2017 +0100 s390: use correct input data address for setup_randomness commit 4920e3cf77347d7d7373552d4839e8d832321313 upstream. The current implementation of setup_randomness uses the stack address and therefore the pointer to the SYSIB 3.2.2 block as input data address. Furthermore the length of the input data is the number of virtual-machine description blocks which is typically one. This means that typically a single zero byte is fed to add_device_randomness. Fix both of these and use the address of the first virtual machine description block as input data address and also use the correct length. Fixes: bcfcbb6bae64 ("s390: add system information as device randomness") Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 0075504d83cefe2da69e1776956867ac368c4c3f Author: Heiko Carstens Date: Sat Feb 4 11:40:36 2017 +0100 s390: make setup_randomness work commit da8fd820f389a0e29080b14c61bf5cf1d8ef5ca1 upstream. Commit bcfcbb6bae64 ("s390: add system information as device randomness") intended to add some virtual machine specific information to the randomness pool. Unfortunately it uses the page allocator before it is ready to use. In result the page allocator always returns NULL and the setup_randomness function never adds anything to the randomness pool. To fix this use memblock_alloc and memblock_free instead. Fixes: bcfcbb6bae64 ("s390: add system information as device randomness") Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit ca54585dd5dd250fd61ab92ce192183ddc4d03f5 Author: Martin Schwidefsky Date: Sat Feb 4 12:38:12 2017 +0100 s390/topology: correct allocation of topology information commit 8676caa4fb7fc02b2c76842a0024919d0caa4b8d upstream. The data stored by the STSI instruction can be up to a page in size but the memblock_virt_alloc allocation for tl_info only specifies 16 bytes. The memory after the short allocation is overwritten every time arch_update_cpu_topology is called. Fixes: 8c9105802235 "s390/numa: establish cpu to node mapping early" Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit c61a874ea0ec333c064cf97f379030e887360f17 Author: Martin Schwidefsky Date: Fri Feb 24 07:43:51 2017 +0100 s390: TASK_SIZE for kernel threads commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream. Return a sensible value if TASK_SIZE if called from a kernel thread. This gets us around an issue with copy_mount_options that does a magic size calculation "TASK_SIZE - (unsigned long)data" while in a kernel thread and data pointing to kernel space. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 162668c000ab21cc594237bc32fa9ecfb1ce0e3f Author: Peter Oberparleiter Date: Mon Feb 20 14:52:58 2017 +0100 s390/chsc: Add exception handler for CHSC instruction commit 77759137248f34864a8f7a58bbcebfcf1047504a upstream. Prevent kernel crashes due to unhandled exceptions raised by the CHSC instruction which may for example be triggered by invalid ioctl data. Fixes: 64150adf89df ("s390/cio: Introduce generic synchronous CHSC IOCTL") Signed-off-by: Peter Oberparleiter Reviewed-by: Sebastian Ott Reviewed-by: Cornelia Huck Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 836f9814f09291e7404b57f774ee330f668a3bac Author: Michael Holzheu Date: Tue Feb 7 18:09:14 2017 +0100 s390/kdump: Use "LINUX" ELF note name instead of "CORE" commit a4a81d8eebdc1d209d034f62a082a5131e4242b5 upstream. In binutils/libbfd (bfd/elf.c) it is enforced that all s390 specific ELF notes like e.g. NT_S390_PREFIX or NT_S390_CTRS have "LINUX" specified as note name. Otherwise the notes are ignored. For /proc/vmcore we currently use "CORE" for these notes. Up to now this has not been a real problem because the dump analysis tool "crash" does not check the note name. But it will break all programs that use libbfd for processing ELF notes. So fix this and use "LINUX" for all s390 specific notes to comply with libbfd. Reported-by: Philipp Rudo Reviewed-by: Philipp Rudo Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 1f2659aa7dfe2596e0d102f2cf61f20d3266f2f5 Author: Gerald Schaefer Date: Mon Jan 30 15:52:14 2017 +0100 s390/dcssblk: fix device size calculation in dcssblk_direct_access() commit a63f53e34db8b49675448d03ae324f6c5bc04fe6 upstream. Since commit dd22f551 "block: Change direct_access calling convention", the device size calculation in dcssblk_direct_access() is off-by-one. This results in bdev_direct_access() always returning -ENXIO because the returned value is not page aligned. Fix this by adding 1 to the dev_sz calculation. Fixes: dd22f551 ("block: Change direct_access calling convention") Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 3c3c4d25c5897b3484ce33dc6577913ce1fe8701 Author: Julian Wiedmann Date: Mon Nov 21 13:37:48 2016 +0100 s390/qdio: clear DSCI prior to scanning multiple input queues commit 1e4a382fdc0ba8d1a85b758c0811de3a3631085e upstream. For devices with multiple input queues, tiqdio_call_inq_handlers() iterates over all input queues and clears the device's DSCI during each iteration. If the DSCI is re-armed during one of the later iterations, we therefore do not scan the previous queues again. The re-arming also raises a new adapter interrupt. But its handler does not trigger a rescan for the device, as the DSCI has already been erroneously cleared. This can result in queue stalls on devices with multiple input queues. Fix it by clearing the DSCI just once, prior to scanning the queues. As the code is moved in front of the loop, we also need to access the DSCI directly (ie irq->dsci) instead of going via each queue's parent pointer to the same irq. This is not a functional change, and a follow-up patch will clean up the other users. In practice, this bug only affects CQ-enabled HiperSockets devices, ie. devices with sysfs-attribute "hsuid" set. Setting a hsuid is needed for AF_IUCV socket applications that use HiperSockets communication. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Reviewed-by: Ursula Braun Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit ac7c6461addb64525905be81006c83a166c43efa Author: Vivek Gautam Date: Fri Jan 27 13:40:19 2017 +0530 phy: qcom-ufs: Fix misplaced jump label commit 0b10f64dbe60cb1b2056f647c052b4278627fe24 upstream. We want to skip only tx/rx_iface clocks and not ref_clk_src as well. Fix the jump label accordingly. Fixes: 300f96771d78 ("phy: qcom-ufs: Skip obtaining rx/tx_iface_clk for msm8996 based phy") Cc: Subhash Jadavani Cc: Martin K. Petersen Cc: Kishon Vijay Abraham I Signed-off-by: Vivek Gautam Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit 04b5101049ac0e9df86326e33ec1661cf63e22f7 Author: Bjorn Andersson Date: Sun Jan 22 13:17:46 2017 -0800 phy: qcom-ufs: Don't kfree devres resource commit e7d5e412160c2143de1f818668774b33b3cdab0b upstream. Upon failing to acquire regulator supplies the qcom-ufs driver calls kfree() on the devm allocated memory used to store the name of the regulator, leading to devres corruption. Rather than switching to using the appropriate free function the patch acknowledge the fact that "name" is always a constant string and we don't actually need to create a local copy of it, but rather just reference the constant string. Fixes: add78fc05702 ("phy: qcom-ufs: Use devm sibling of kstrdup for regulator names") Reviewed-by: Subhash Jadavani Signed-off-by: Bjorn Andersson Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit a6ed492d6cca980329e37e191dce9b3ed34b3c9a Author: Dmitry Tunin Date: Thu Jan 5 13:19:53 2017 +0300 Bluetooth: Add another AR3012 04ca:3018 device commit 441ad62d6c3f131f1dbd7dcdd9cbe3f74dbd8501 upstream. T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3018 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 3904b32cfe5009ce96f1ba84e6c868abf75c06ac Author: Chao Peng Date: Tue Feb 21 03:50:01 2017 -0500 KVM: VMX: use correct vmcs_read/write for guest segment selector/base commit 96794e4ed4d758272c486e1529e431efb7045265 upstream. Guest segment selector is 16 bit field and guest segment base is natural width field. Fix two incorrect invocations accordingly. Without this patch, build fails when aggressive inlining is used with ICC. Signed-off-by: Chao Peng Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f89d6db0c50caece69fe58089a02cf8dcc35842d Author: Janosch Frank Date: Thu Feb 2 16:39:31 2017 +0100 KVM: s390: Disable dirty log retrieval for UCONTROL guests commit e1e8a9624f7ba8ead4f056ff558ed070e86fa747 upstream. User controlled KVM guests do not support the dirty log, as they have no single gmap that we can check for changes. As they have no single gmap, kvm->arch.gmap is NULL and all further referencing to it for dirty checking will result in a NULL dereference. Let's return -EINVAL if a caller tries to sync dirty logs for a UCONTROL guest. Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.") Signed-off-by: Janosch Frank Reported-by: Martin Schwidefsky Reviewed-by: Cornelia Huck Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit c9dc3873046ea3864fac20c96e96b7a188b66dd7 Author: Ian Abbott Date: Fri Feb 3 20:25:00 2017 +0000 serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards commit 1c9c858e2ff8ae8024a3d75d2ed080063af43754 upstream. The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports, respectively. The first 4 ports are implemented by an OX16PCI954 chip, and the second 4 ports are implemented by an OX16C954 chip on a local bus, bridged by the second PCI function of the OX16PCI954. The ports are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a non-standard oscillator frequency of 20 MHz (base_baud = 1250000). Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 72e5440223836633e2b5e658e7503d8b0e795f5d Author: Alexander Popov Date: Tue Feb 28 19:54:40 2017 +0300 tty: n_hdlc: get rid of racy n_hdlc.tbuf commit 82f2341c94d270421f383641b7cd670e474db56b upstream. Currently N_HDLC line discipline uses a self-made singly linked list for data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after an error. The commit be10eb7589337e5defbe214dae038a53dd21add8 ("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf. After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put one data buffer to tx_free_buf_list twice. That causes double free in n_hdlc_release(). Let's use standard kernel linked list and get rid of n_hdlc.tbuf: in case of tx error put current data buffer after the head of tx_buf_list. Signed-off-by: Alexander Popov Signed-off-by: Greg Kroah-Hartman