commit 567aeca9fbb7f1f00fc6bbdd6861010ce7ddaf22 Author: Greg Kroah-Hartman Date: Thu Nov 10 16:39:23 2016 +0100 Linux 4.8.7 commit 1bf121d3b234c4158906bcc85913116068f058e7 Author: Oliver Neukum Date: Thu Nov 3 12:31:41 2016 +0100 HID: usbhid: add ATEN CS962 to list of quirky devices commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream. Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 05a833d4b051d0ecdfe39ae164e3365667a9563a Author: Rafael J. Wysocki Date: Wed Oct 19 02:57:22 2016 +0200 cpufreq: intel_pstate: Set P-state upfront in performance mode commit a6c6ead14183ea4ec8ce7551e1f3451024b9c4db upstream. After commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks) the cpufreq governor callbacks may not be invoked on NOHZ_FULL CPUs and, in particular, switching to the "performance" policy via sysfs may not have any effect on them. That is a problem, because it usually is desirable to squeeze the last bit of performance out of those CPUs, so work around it by setting the maximum P-state (within the limits) in intel_pstate_set_policy() upfront when the policy is CPUFREQ_POLICY_PERFORMANCE. Fixes: a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks) Signed-off-by: Rafael J. Wysocki Acked-by: Srinivas Pandruvada Signed-off-by: Greg Kroah-Hartman commit c89771511debaf5f4c488881af59c79d3a6fb023 Author: Boris Brezillon Date: Fri Oct 28 11:08:44 2016 +0200 ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap() commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream. Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists") introduced a bug by changing the possible error codes returned by add_vol(): - this function no longer returns NULL in case of allocation failure but return ERR_PTR(-ENOMEM) - when a duplicate entry in the volume RB tree is found it returns ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL) Fix the tests done on add_vol() return val to match this new behavior. Fixes: e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists") Reported-by: Dan Carpenter Signed-off-by: Boris Brezillon Acked-by: Sheng Yong Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 591bf1362e9ec873110332e6914428a8aff84072 Author: Goldwyn Rodrigues Date: Fri Sep 30 10:40:52 2016 -0500 btrfs: qgroup: Prevent qgroup->reserved from going subzero commit 0b34c261e235a5c74dcf78bd305845bd15fe2b42 upstream. While free'ing qgroup->reserved resources, we much check if the page has not been invalidated by a truncate operation by checking if the page is still dirty before reducing the qgroup resources. Resources in such a case are free'd when the entire extent is released by delayed_ref. This fixes a double accounting while releasing resources in case of truncating a file, reproduced by the following testcase. SCRATCH_DEV=/dev/vdb SCRATCH_MNT=/mnt mkfs.btrfs -f $SCRATCH_DEV mount -t btrfs $SCRATCH_DEV $SCRATCH_MNT cd $SCRATCH_MNT btrfs quota enable $SCRATCH_MNT btrfs subvolume create a btrfs qgroup limit 500m a $SCRATCH_MNT sync for c in {1..15}; do dd if=/dev/zero bs=1M count=40 of=$SCRATCH_MNT/a/file; done sleep 10 sync sleep 5 touch $SCRATCH_MNT/a/newfile echo "Removing file" rm $SCRATCH_MNT/a/file Fixes: b9d0b38928 ("btrfs: Add handler for invalidate page") Signed-off-by: Goldwyn Rodrigues Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0c879624701dc719022950552227516ac87a10d5 Author: Owen Hofmann Date: Thu Oct 27 11:25:52 2016 -0700 kvm: x86: Check memopp before dereference (CVE-2016-8630) commit d9092f52d7e61dd1557f2db2400ddb430e85937e upstream. Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a check for non-NULL under incorrect assumptions. An undefined instruction with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt to dereference a null pointer here. Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5 Message-Id: <1477592752-126650-2-git-send-email-osh@google.com> Signed-off-by: Owen Hofmann Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 725a92be392648440d17e69f5a739eba3dde6ff8 Author: Russell King Date: Tue Oct 18 10:24:49 2016 +0100 ARM: fix oops when using older ARMv4T CPUs commit 04946fb60fb157faafa01658dff3131d49f49ccb upstream. Alexander Shiyan reports that CLPS711x fails at boot time in the data exception handler due to a NULL pointer dereference. This is caused by the late-v4t abort handler overwriting R9 (which becomes zero). Fix this by making the abort handler save and restore R9. Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c3b58000 [00000008] *pgd=800000000, *pte=00000000, *ppte=feff4140 Internal error: Oops: 63c11817 [#1] PREEMPT ARM CPU: 0 PID: 448 Comm: ash Not tainted 4.8.1+ #1 Hardware name: Cirrus Logic CLPS711X (Device Tree Support) task: c39e03a0 ti: c3b4e000 task.ti: c3b4e000 PC is at __dabt_svc+0x4c/0x60 LR is at do_page_fault+0x144/0x2ac pc : [] lr : [] psr: 60000093 sp : c3b4fe6c ip : 00000001 fp : b6f1bf88 r10: c387a5a0 r9 : 00000000 r8 : e4e0e001 r7 : bee3ef83 r6 : 00100000 r5 : 80000013 r4 : c022fcf8 r3 : 00000000 r2 : 00000008 r1 : bf000000 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 0000217f Table: c3b58055 DAC: 00000055 Process ash (pid: 448, stack limit = 0xc3b4e190) Stack: (0xc3b4fe6c to 0xc3b50000) fe60: bee3ef83 c05168d1 ffffffff 00000000 c3adfe80 fe80: c3a03300 00000000 c3b4fed0 c3a03400 bee3ef83 c387a5a0 b6f1bf88 00000001 fea0: c3b4febc 00000076 c022fcf8 80000013 ffffffff 0000003f bf000000 bee3ef83 fec0: 00000004 00000000 c3adfe80 c00e432c 00000812 00000005 00000001 00000006 fee0: b6f1b000 00000000 00010000 0003c944 0004d000 0004d439 00010000 b6f1b000 ff00: 00000005 00000000 00015ecc c3b4fed0 0000000a 00000000 00000000 c00a1dc0 ff20: befff000 c3a03300 c3b4e000 c0507cd8 c0508024 fffffff8 c3a03300 00000000 ff40: c0516a58 c00a35bc c39e03a0 000001c0 bea84ce8 0004e008 c3b3a000 c00a3ac0 ff60: c3b40374 c3b3a000 bea84d11 00000000 c0500188 bea84d11 bea84ce8 00000001 ff80: 0000000b c000a304 c3b4e000 00000000 bea84ce4 c00a3cd0 00000000 bea84d11 ffa0: bea84ce8 c000a160 bea84d11 bea84ce8 bea84d11 bea84ce8 0004e008 0004d450 ffc0: bea84d11 bea84ce8 00000001 0000000b b6f45ee4 00000000 b6f5ff70 bea84ce4 ffe0: b6f2f130 bea84cb0 b6f2f194 b6ef29f4 a0000010 bea84d11 02c7cffa 02c7cffd [] (__dabt_svc) from [] (__copy_to_user_std+0xf8/0x330) [] (__copy_to_user_std) from [] +(load_elf_binary+0x920/0x107c) [] (load_elf_binary) from [] +(search_binary_handler+0x80/0x16c) [] (search_binary_handler) from [] +(do_execveat_common+0x418/0x600) [] (do_execveat_common) from [] (do_execve+0x28/0x30) [] (do_execve) from [] (ret_fast_syscall+0x0/0x30) Code: e1a0200d eb00136b e321f093 e59d104c (e5891008) ---[ end trace 4b4f8086ebef98c5 ]--- Fixes: e6978e4bf181 ("ARM: save and reset the address limit when entering an exception") Reported-by: Alexander Shiyan Tested-by: Alexander Shiyan Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit e339609bf377f3ee11432aac7c8139a35567763d Author: Jiri Slaby Date: Mon Oct 3 11:00:17 2016 +0200 tty: vt, fix bogus division in csi_J commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream. In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is divided by 2 inappropriatelly. But scr_memsetw expects size, not count, because it divides the size by 2 on its own before doing actual memset-by-words. So remove the bogus division. Signed-off-by: Jiri Slaby Cc: Petr Písař Fixes: f8df13e0a9 (tty: Clean console safely) Signed-off-by: Greg Kroah-Hartman commit 4a22930a74acd6976db1eb128337c493ae972875 Author: Laurent Pinchart Date: Fri Jul 8 06:20:51 2016 -0300 v4l: vsp1: Prevent pipelines from running when not streaming commit e4e70a147a48618a36ae1b81c641516cb9d45993 upstream. Pipelines can only be run if all their video nodes are streaming. Commit b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") fixed the pipeline stop sequence, but introduced a race condition that makes it possible to run a pipeline after stopping the stream on a video node by queuing a buffer on the other side of the pipeline. Fix this by clearing the buffers ready flag when stopping the stream, which will prevent the QBUF handler from running the pipeline. Fixes: b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") Reported-by: Kieran Bingham Tested-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 59f9693a170a2d9f2406fa06e81c4c0f5a0426cf Author: Tony Lindgren Date: Wed Oct 19 12:03:39 2016 -0500 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error commit d8e5f0eca1e88215e45aca27115ea747e6164da1 upstream. If we configure musb with 2430 glue as a peripheral, and then rmmod omap2430 module, we'll get the following error: [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] ... rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (&phy->mutex){+.+.+.}, at: [] phy_power_off+0x1c/0xb8 [ 204.678710] and this task is already holding: (&(&musb->lock)->rlock){-.-...}, at: [] musb_gadget_stop+0x24/0xec [musb_hdrc] which would create a new lock dependency: (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.} ... This is because some glue layers expect musb_platform_enable/disable to be called with spinlock held, and 2430 glue layer has USB PHY on the I2C bus using a mutex. We could fix the glue layers to take the spinlock, but we still have a problem of musb_plaform_enable/disable being called in an unbalanced manner. So that would still lead into USB PHY enable/disable related problems for omap2430 glue layer. While it makes sense to only enable USB PHY when needed from PM point of view, in this case we just can't do it yet without breaking things. So let's just revert phy_enable/disable related changes instead and reconsider this after we have fixed musb_platform_enable/disable to be balanced. Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer") Reviewed-by: Laurent Pinchart Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 086ac91804372caeef7e872e0d151fcfb2303932 Author: Stefan Wahren Date: Sat Sep 10 12:53:21 2016 +0000 usb: chipidea: host: fix NULL ptr dereference during shutdown commit 991d5add50a5bb6ab8f12f2129f5c7487f6baaf6 upstream. After commit b09b5224fe86 ("usb: chipidea: implement platform shutdown callback") and commit 43a404577a93 ("usb: chipidea: host: set host to be null after hcd is freed") a NULL pointer dereference is caused on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and we finish interrupt handling before the hcd is deallocated. This avoids the NULL pointer dereference. Suggested-by: Alan Stern Signed-off-by: Stefan Wahren Fixes: b09b5224fe86 ("usb: chipidea: implement platform shutdown callback") Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit 07bae478e1c1c9c6040d69b52c44c550917045e2 Author: Christophe JAILLET Date: Fri Oct 7 22:12:39 2016 +0200 usb: dwc3: Fix size used in dma_free_coherent() commit 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 upstream. In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the size of the memory allocated with 'dma_alloc_coherent()' has been modified but the corresponding calls to 'dma_free_coherent()' have not been updated accordingly. This has been spotted with coccinelle, using the following script: //////////////////// @r@ expression x0, x1, y0, y1, z0, z1, t0, t1, ret; @@ * ret = dma_alloc_coherent(x0, y0, z0, t0); ... * dma_free_coherent(x1, y1, ret, t1); @script:python@ y0 << r.y0; y1 << r.y1; @@ if y1.find(y0) == -1: print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1) //////////////////// Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support") Signed-off-by: Christophe JAILLET Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit fedede0963c48829992a810d9ae61f0424949373 Author: David Hsu Date: Tue Aug 9 14:57:46 2016 -0700 pwm: Unexport children before chip removal commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream. Exported pwm channels aren't removed before the pwmchip and are leaked. This results in invalid sysfs files. This fix removes all exported pwm channels before chip removal. Signed-off-by: David Hsu Fixes: 76abbdde2d95 ("pwm: Add sysfs interface") Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 7b4b77b9566db17afea107bcc70d348a5dd97048 Author: Wei Yongjun Date: Sat Sep 17 15:53:34 2016 +0000 omapfb: fix return value check in dsi_bind() commit 43da7575cdecaf5af2d6b3f3a9e4e6c9144be428 upstream. Fix the retrn value check which testing the wrong variable in dsi_bind(). Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Signed-off-by: Wei Yongjun Reviewed-by: Peter Ujfalusi Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit a3e55d6342b29dc79fadcc35c955be4f3bc2580c Author: Dan Carpenter Date: Fri Jul 15 14:07:32 2016 +0300 video: fbdev: pxafb: potential NULL dereference on error commit e0299908d606a99e7ffb467bc3c11dfe54133af3 upstream. If we "goto out;" then it calls display_timings_release(timings); Since "timings" is NULL, that's going to oops. Just return directly. Fixes: 420a488278e8 ('video: fbdev: pxafb: initial devicetree conversion') Signed-off-by: Dan Carpenter Acked-by: Robert Jarzmik Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 13d0f5b3a399bb3e473457eec756e6e1bbd0ea42 Author: Emilio López Date: Tue Sep 27 11:31:42 2016 -0300 uapi: add missing install of sync_file.h commit 58f0f9f75c1b94dabbfc3daa333a4e68536b0a42 upstream. As part of the sync framework destaging, the sync_file.h header was moved, but an entry was not added on Kbuild to install it. This patch resolves this omission so that "make headers_install" installs this header. Fixes: 460bfc41fd52 ("dma-buf/sync_file: de-stage sync_file headers") Reported-by: Michael Ellerman Reviewed-by: Gustavo Padovan Signed-off-by: Emilio López Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/20160927143142.8975-1-emilio.lopez@collabora.co.uk Signed-off-by: Greg Kroah-Hartman commit db5025bd08ef35d76248846704bbb56354d32499 Author: Boris Brezillon Date: Fri Sep 16 16:59:12 2016 +0200 UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream. scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header region left to 0xff). Make sure we scrub the PEB in this case. Signed-off-by: Boris Brezillon Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit cc94524e89408dab9830cf9822c0e499b1275f36 Author: Liping Zhang Date: Tue Oct 11 21:03:45 2016 +0800 netfilter: xt_NFLOG: fix unexpected truncated packet commit 6d19375b58763fefc2f215fb45117d3353ced888 upstream. Justin and Chris spotted that iptables NFLOG target was broken when they upgraded the kernel to 4.8: "ulogd-2.0.5- IPs are no longer logged" or "results in segfaults in ulogd-2.0.5". Because "struct nf_loginfo li;" is a local variable, and flags will be filled with garbage value, not inited to zero. So if it contains 0x1, packets will not be logged to the userspace anymore. Fixes: 7643507fe8b5 ("netfilter: xt_NFLOG: nflog-range does not truncate packets") Reported-by: Justin Piszcz Reported-by: Chris Caputo Tested-by: Chris Caputo Signed-off-by: Liping Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 720a40113e78fd9377b7852a4bf6a72b085a926e Author: Ralf Ramsauer Date: Mon Oct 17 15:59:57 2016 +0200 i2c: mark device nodes only in case of successful instantiation commit 6a676fb69dcbf3310b9e462c1db66c8e7f6ead38 upstream. Instantiated I2C device nodes are marked with OF_POPULATE. This was introduced in 4f001fd30145a6. On unloading, loaded device nodes will of course be unmarked. The problem are nodes that fail during initialisation: If a node fails, it won't be unloaded and hence not be unmarked. If a I2C driver module is unloaded and reloaded, it will skip nodes that failed before. Skip device nodes that are already populated and mark them only in case of success. Fixes: 4f001fd30145a6 ("i2c: Mark instantiated device nodes with OF_POPULATE") Signed-off-by: Ralf Ramsauer Reviewed-by: Geert Uytterhoeven Acked-by: Pantelis Antoniou [wsa: use 14-digit commit sha] Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit f7d8d44a68de4732d1cd3bb3f129e3a59ff0b7d3 Author: Daniel Stone Date: Fri Oct 21 15:44:54 2016 +0100 drm: i915: Wait for fences on new fb, not old commit 1fb3672eaf6ec95fb34c22734feffd6041531c5b upstream. The previous code would wait for fences on the framebuffer from the old plane state to complete, rather than the new, so you would see tearing everywhere. Fix this to wait on the new state before we make it active. Signed-off-by: Daniel Stone Fixes: 94f050246b42 ("drm/i915: nonblocking commit") Cc: Daniel Vetter Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161021144454.6288-1-daniels@collabora.com (cherry picked from commit 2d2c5ad83f772d7d7b0bb8348ecea42e88f89ab0) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 1cefe4cb4f8c17a7d7ddc253d0d27ef9f0330d15 Author: Paulo Zanoni Date: Fri Oct 21 13:55:45 2016 -0200 drm/i915/fbc: fix CFB size calculation for gen8+ commit e3b9e6e3a989904ae062e7a48a9431edc837ea6b upstream. Broadwell and newer actually compress up to 2560 lines instead of 2048 (as documented in the FBC_CTL page). If we don't take this into consideration we end up reserving too little stolen memory for the CFB, so we may allocate something else (such as a ring) right after what we reserved, and the hardware will overwrite it with the contents of the CFB when FBC is active, causing GPU hangs. Another possibility is that the CFB may be allocated at the very end of the available space, so the CFB will overlap the reserved stolen area, leading to FIFO underruns. This bug has always been a problem on BDW (the only affected platform where FBC is enabled by default), but it's much easier to reproduce since the following commit: commit c58b735fc762e891481e92af7124b85cb0a51fce Author: Chris Wilson Date: Thu Aug 18 17:16:57 2016 +0100 drm/i915: Allocate rings from stolen Of course, you can only reproduce the bug if your screen is taller than 2048 lines. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98213 Fixes: a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Signed-off-by: Paulo Zanoni Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1477065346-13736-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 79f2624b1b9f776b173b41d743fb3dd7374b3827) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 809e9e6fc390a05445b52646182d10b4978a1fb8 Author: Ville Syrjälä Date: Tue Oct 11 20:52:47 2016 +0300 drm/i915: Clean up DDI DDC/AUX CH sanitation commit 0ce140d45a8398b501934ac289aef0eb7f47c596 upstream. Now that we use the AUX and GMBUS assignment from VBT for all ports, let's clean up the sanitization of the port information a bit. Previosuly we only did this for port E, and only complained about a non-standard assignment for the other ports. But as we know that non-standard assignments are a fact of life, let's expand the sanitization to all the ports. v2: Include a commit message, fix up the comments a bit v3: Don't clobber other ports if the current port has no alternate aux ch/ddc pin Cc: Maarten Maathuis Tested-by: Maarten Maathuis References: https://bugs.freedesktop.org/show_bug.cgi?id=97877 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jim Bride (v2) (cherry picked from commit 9454fa871edf15c20a0371548b3ec0d6d944a498) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit ba0a959e0334d6a583ca1e42fe0056bb6121aeca Author: Ville Syrjälä Date: Tue Oct 11 20:52:45 2016 +0300 drm/i915: Respect alternate_aux_channel for all DDI ports commit 198c5ee3c60169f8b64bcd330a34593be80699aa upstream. The VBT provides the platform a way to mix and match the DDI ports vs. AUX channels. Currently we only trust the VBT for DDI E, which has no corresponding AUX channel of its own. However it is possible that some board might use some non-standard DDI vs. AUX port routing even for the other ports. Perhaps for signal routing reasons or something, So let's generalize this and trust the VBT for all ports. For now we'll limit this to DDI platforms, as we trust the VBT a bit more there anyway when it comes to the DDI ports. I've structured the code in a way that would allow us to easily expand this to other platforms as well, by simply filling in the ddi_port_info. v2: Drop whitespace changes, keep MISSING_CASE() for unknown aux ch assignment, include a commit message, include debug message during init Cc: Maarten Maathuis Tested-by: Maarten Maathuis References: https://bugs.freedesktop.org/show_bug.cgi?id=97877 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jim Bride (cherry picked from commit 8f7ce038f1178057733b7e765bf9160a2f9be14b) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 426a724c99725c53f901772245eb53885d7d4053 Author: Felix Monninger Date: Tue Oct 25 22:28:08 2016 +0100 drm: Release reference from blob lookup after replacing property commit cac5fcedaabdadf150c8a9be9fee76defc8ba444 upstream. drm_property_lookup_blob() returns a reference to the returned blob, and drm_atomic_replace_property_blob() takes a references to the blob it stores, so afterwards we are left owning a reference to the new_blob that we never release, and thus leak memory every time we update a property such as during drm_atomic_helper_legacy_gamma_set(). v2: update credentials, drm_property_unreference_blob() is NULL safe and NULL is passed consistently to it throughout drm_atomic.c so do so here. Reported-by: Felix Monninger Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98420 Signed-off-by: Felix Monninger Signed-off-by: Chris Wilson Fixes: 5488dc16fde7 ("drm: introduce pipe color correction properties") Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161025212808.3908-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit 5064a6a053877d66cc448d7ff8b6e4533338ccda Author: Ville Syrjälä Date: Wed Oct 26 12:05:55 2016 +0300 drm/dp/mst: Check peer device type before attempting EDID read commit 4da5caa6a6f82cda3193bca855235b87debf78bd upstream. Only certain types of pdts have the DDC bus registered, so check for that before we attempt the EDID read. Othwewise we risk playing around with an i2c adapter that doesn't actually exist. Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa Tested-by: Kirill A. Shutemov Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-5-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e6fcf953a995fe7590d7d0947bc3bebf2f6caaa4 Author: Paulo Zanoni Date: Fri Oct 7 17:28:57 2016 -0300 drm/i915/gen9: fix watermarks when using the pipe scaler commit 5e33791e1f27c3207e7b44071e7c94a487d1eb39 upstream. Luckily, the necessary adjustments for when we're using the scaler are exactly the same as the ones needed on ILK+, so just reuse the function we already have. v2: Invert the patch order so stable backports get easier. Signed-off-by: Paulo Zanoni Reviewed-by: Matt Roper Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit cfd7e3a20251b9ac95651d64556f87f86128a966) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 0f7f9c45638076910d1356895631ee1403caa4ea Author: Paulo Zanoni Date: Tue Oct 4 14:37:32 2016 -0300 drm/i915/gen9: fix DDB partitioning for multi-screen cases commit 01c72d6c17dc524f04d4dbe361d214e423b35457 upstream. With the previous code we were only recomputing the DDB partitioning for the CRTCs included in the atomic commit, so any other active CRTCs would end up having their DDB registers zeroed. In this patch we make sure that the computed state starts as a copy of the current partitioning, and then we only zero the DDBs that we're actually going to recompute. How to reproduce the bug: 1 - Enable the primary plane on pipe A 2 - Enable the primary plane on pipe B 3 - Enable the cursor or sprite plane on pipe A Step 3 will zero the DDB partitioning for pipe B since it's not included in the commit that enabled the cursor or sprite for pipe A. I expect this to fix many FIFO underrun problems on gen9+. v2: - Mention the cursor on the steps to reproduce the problem (Paulo). - Add Testcase tag provided by Maarten (Maarten). Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97596 Bugzilla: https://www.phoronix.com/scan.php?page=news_item&px=Intel-Skylake-Multi-Screen-Woes Signed-off-by: Paulo Zanoni Reviewed-by: Lyude Link: http://patchwork.freedesktop.org/patch/msgid/1475602652-17326-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 5a920b85f2c6e3fd7d9dd9bb3f3345e9085e2360) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 0cc98b5963f8886887aab0ded61970bdccfc2350 Author: Ville Syrjälä Date: Wed Oct 26 17:41:18 2016 +0300 drm/fb-helper: Keep references for the current set of used connectors commit a2889606636d135148de101fe3311dfea67baf1c upstream. The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively being used. That list is tracked per-crtc and currently doesn't hold any extra references. Let's grab those extra references to avoid oopsing when the connector vanishes. The list of all possible connectors should get updated when the hpd happens, but the list of actively used connectors would not get updated until the next time the fb-helper picks through the set of possible connectors. And so we need to hang on to the connectors until that time. Since we need to clean up in drm_fb_helper_crtc_free() as well, let's pull the code to a common place. And while at it let's pull in up the modeset->mode cleanup in there as well. The case of modeset->fb is a bit less clear. I'm thinking we should probably hold a reference to it, but for now I just slapped on a FIXME. v2: Cleanup things drm_fb_helper_crtc_free() too (Chris) v3: Don't leak modeset->connectors (Chris) Cc: Chris Wilson Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa (v1) Tested-by: Kirill A. Shutemov (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477492878-4990-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 14f4a463dc78db507884c7724910ef4b3691da83 Author: Ville Syrjälä Date: Wed Oct 26 12:05:52 2016 +0300 drm/fb-helper: Fix connector ref leak on error commit 7dfcb36a1f17e4c7c7c12b9d8a6902037c7d98dc upstream. We need to drop the connector references already taken when we abort in the middle of drm_fb_helper_single_add_all_connectors() Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa Tested-by: Kirill A. Shutemov Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-2-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 6222f1e0b9ef0d0c89183cadcc1e780661ce08d3 Author: Takashi Iwai Date: Thu Oct 20 17:05:30 2016 +0200 drm/fb-helper: Don't call dirty callback for untouched clips commit 87d3b6588f9bf205902868d3e5baf68e37ad4ae1 upstream. Since 4.7 kernel, we've seen the error messages like kernel: [TTM] Buffer eviction failed kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001) kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO on QXL when switching and accessing on VT. The culprit was the generic deferred_io code (qxl driver switched to it since 4.7). There is a race between the dirty clip update and the call of callback. In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock, while it kicks off the update worker outside the spinlock. Meanwhile the update worker clears the dirty clip in the spinlock, too. Thus, when drm_fb_helper_dirty() is called concurrently, schedule_work() is called after the clip is cleared in the first worker call. This patch addresses it by validating the clip before calling the dirty fb callback. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322 Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298 Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support') Signed-off-by: Takashi Iwai Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161020150530.5787-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 7290da41b8da4a8a6819966cb9922170f5ae70c6 Author: Peter Wu Date: Mon Oct 31 23:48:22 2016 +0100 drm/nouveau/acpi: fix check for power resources support commit b0a6af8b34c9ad20894aa46f85f4bf59d444f286 upstream. Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not). This is a workaround for a problem where ACPICA and Windows 10 differ in behavior. ACPICA does not correctly enumerate power resources within a conditional block (due to delayed execution of such blocks) and as a result power_resources is set to false even if _PR3 exists. Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM") Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398 Reported-and-tested-by: Rick Kerkhof Reviewed-by: Mika Westerberg Signed-off-by: Peter Wu Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit fd5f9e1e28cb170100653d915805407a47fc7809 Author: Lucas Stach Date: Mon Oct 24 23:32:04 2016 +0200 drm/radeon: drop register readback in cayman_cp_int_cntl_setup commit 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e upstream. The read is taking a considerable amount of time (about 50us on this machine). The register does not ever hold anything other than the ring ID that is updated in this exact function, so there is no need for the read modify write cycle. This chops off a big chunk of the time spent in hardirq disabled context, as this function is called multiple times in the interrupt handler. With this change applied radeon won't show up in the list of the worst IRQ latency offenders anymore, where it was a regular before. Reviewed-by: Christian König Signed-off-by: Lucas Stach Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e136de5d733161fdfd203f23b448434170d189ea Author: Alex Deucher Date: Fri Oct 14 16:38:02 2016 -0400 drm/radeon/si_dpm: workaround for SI kickers commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e upstream. Consolidate existing quirks. Fixes stability issues on some kickers. Signed-off-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fe777e7a595cc57ac7b6015d10da7801eb9bf070 Author: Tom St Denis Date: Thu Oct 13 12:38:07 2016 -0400 drm/radeon/si_dpm: Limit clocks on HD86xx part commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream. Limit clocks on a specific HD86xx part to avoid crashes (while awaiting an appropriate PP fix). Signed-off-by: Tom St Denis Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fa6227dbfd6a60587e5065e7df3e0571f4d1f31a Author: Liu Ying Date: Tue Oct 18 16:44:03 2016 +0800 drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12 commit e73aca5184ad9fc948ba22b4d35dce11db35bb25 upstream. Before accessing the u/v offset(aka, u/vbo for IPUv3) of the old plane state's relevant fb, we should make sure the fb is in YU12 or YV12 pixel format(which are the two YUV pixel formats we support only), otherwise, we are likely to trigger BUG_ON() in drm_plane_state_to_u/vbo() since the fb's pixel format is probably not YU12 or YV12. Link: https://bugs.freedesktop.org/show_bug.cgi?id=98150 Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support") Signed-off-by: Liu Ying Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit d040374f3473124cadf2e44c0afd2c6ac5451c83 Author: Liu Ying Date: Mon Oct 10 14:50:06 2016 +0800 drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset commit 43daa01323da37a3692cabe1579ef5c2c4372e06 upstream. We added active plane reconfiguration support by forcing a full modeset operation. So, looking at old_plane_state->fb to determine whether we need to switch EBA buffer(for hardware double buffering) in ipu_plane_atomic_set_base() or not is no more correct. Instead, we should do that only when we don't need modeset, otherwise, we initialize the two EBA buffers with the buffer address. Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support") Signed-off-by: Liu Ying Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 51ed5a2bbf380bd450e59a6f1a184869341101f5 Author: Michel Dänzer Date: Mon Oct 24 16:52:20 2016 +0900 Revert "drm/radeon: fix DP link training issue with second 4K monitor" commit 9dc79965b21967caebde575f5f5d8bf1aa2c23ab upstream. This reverts commit 1a738347df2ee4977459a8776fe2c62196bdcb1b. It caused at least some Kaveri laptops to incorrectly report DisplayPort connectors as connected. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97857 Reviewed-by: Alex Deucher Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ac6f210dd7a62c5e6f206928db76ee2ecbea1d20 Author: NeilBrown Date: Fri Oct 28 15:59:41 2016 +1100 md: be careful not lot leak internal curr_resync value into metadata. -- (all) commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 upstream. mddev->curr_resync usually records where the current resync is up to, but during the starting phase it has some "magic" values. 1 - means that the array is trying to start a resync, but has yielded to another array which shares physical devices, and also needs to start a resync 2 - means the array is trying to start resync, but has found another array which shares physical devices and has already started resync. 3 - means that resync has commensed, but it is possible that nothing has actually been resynced yet. It is important that this value not be visible to user-space and particularly that it doesn't get written to the metadata, as the resync or recovery checkpoint. In part, this is because it may be slightly higher than the correct value, though this is very rare. In part, because it is not a multiple of 4K, and some devices only support 4K aligned accesses. There are two places where this value is propagates into either ->curr_resync_completed or ->recovery_cp or ->recovery_offset. These currently avoid the propagation of values 1 and 3, but will allow 3 to leak through. Change them to only propagate the value if it is > 3. As this can cause an array to fail, the patch is suitable for -stable. Reported-by: Viswesh Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit eba4fe9db92fe8c00fda6c75c9f320fcbc9c6b82 Author: Shaohua Li Date: Thu Oct 6 14:13:52 2016 -0700 RAID10: ignore discard error commit 579ed34f7b751b8add233cba4cf755258dbdd60a upstream. This is the counterpart of raid10 fix. If a write error occurs, raid10 will try to rewrite the bio in small chunk size. If the rewrite fails, raid10 will record the error in bad block. narrow_write_error will always use WRITE for the bio, but actually it could be a discard. Since discard bio hasn't payload, write the bio will cause different issues. But discard error isn't fatal, we can safely ignore it. This is what this patch does. This issue should exist since discard is added, but only exposed with recent arbitrary bio size feature. Cc: Sitsofe Wheeler Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 21faa6dbf53f6affbea63a008b1fa3ed3862cfa7 Author: Shaohua Li Date: Thu Oct 6 14:09:16 2016 -0700 RAID1: ignore discard error commit e3f948cd3283e4fbe5907f1f3967c839912f480e upstream. If a write error occurs, raid1 will try to rewrite the bio in small chunk size. If the rewrite fails, raid1 will record the error in bad block. narrow_write_error will always use WRITE for the bio, but actually it could be a discard. Since discard bio hasn't payload, write the bio will cause different issues. But discard error isn't fatal, we can safely ignore it. This is what this patch does. This issue should exist since discard is added, but only exposed with recent arbitrary bio size feature. Reported-and-tested-by: Sitsofe Wheeler Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit b80fcd58e6f6ab1a68a6d251fb8bba67e03df8ae Author: Jaehoon Chung Date: Fri Oct 21 19:57:57 2016 +0900 mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream. platform_get_resource can be returned the NULL pointer. Then regs->start should be referred to NULL Pointer. devm_ioremap_resource() checks whether res is NULL or not. Signed-off-by: Jaehoon Chung Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1244d3c3a0f6f5bcfbf6364f2e75b7e4dfda9d82 Author: Ching Huang Date: Wed Oct 19 17:50:26 2016 +0800 scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream. The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller firmware. Depending on how drive caches are handled internally by controller firmware this could potentially lead to data integrity problems. Ensure that cache flushes are passed to the controller. [mkp: applied by hand and removed unused vars] Signed-off-by: Ching Huang Reported-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2a1a0a6f1d60d3cfc5a30783927794c168b8c0fd Author: Ewan D. Milne Date: Wed Oct 26 11:22:53 2016 -0400 scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream. map_storep was not being vfree()'d in the module_exit call. Signed-off-by: Ewan D. Milne Reviewed-by: Laurence Oberman Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5bac49422b4a73bbc2733ba504b32bac76808bfb Author: Marty Faltesek Date: Mon Oct 10 19:00:04 2016 +0300 ath10k: cache calibration data when the core is stopped commit f67b107d4ceddcf7aa65b706aaaf50d68edb52a6 upstream. Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving the calibration data from cal_data debugfs file. The length of file was always zero. The reason is: static ssize_t ath10k_debug_cal_data_read(struct file *file, char __user *user_buf, size_t count, loff_t *ppos) { struct ath10k *ar = file->private_data; void *buf = file->private_data; This is obviously bogus, private_data cannot contain both struct ath10k and the buffer. Fix it by caching calibration data to ar->debug.cal_data. This also allows it to be accessed when the device is not active (interface is down). The cal_data buffer is fixed size because during the first firmware probe we don't yet know what will be the lenght of the calibration data. It was simplest just to use a fixed length. There's a WARN_ON() in ath10k_debug_cal_data_fetch() if the buffer is too small. Tested with qca988x and firmware 10.2.4.70.56. Reported-by: Nikolay Martynov Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") Signed-off-by: Marty Faltesek [kvalo@qca.qualcomm.com: improve commit log and minor other changes] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit a7d092e946f5f6b1234eb69eb4504f54cb1db58f Author: Felix Fietkau Date: Tue Oct 11 19:46:49 2016 +0200 Revert "ath9k_hw: implement temperature compensation support for AR9003+" commit 304e5ac118cc351eb047b6c433a89e13ea7259cf upstream. This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+"). Some users report that this commit causes a regression in performance under some conditions. Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+") Signed-off-by: Felix Fietkau [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit aea7cb3b7ceb4e4f2a30a8474bf2f569b01df476 Author: Johannes Berg Date: Wed Oct 5 10:14:42 2016 +0200 mac80211: discard multicast and 4-addr A-MSDUs commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 27fa1e735c70423f3249c34c7c4049fdedb4320a Author: Stefan Richter Date: Sun Oct 30 17:32:01 2016 +0100 firewire: net: fix fragmented datagram_size off-by-one commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream. RFC 2734 defines the datagram_size field in fragment encapsulation headers thus: datagram_size: The encoded size of the entire IP datagram. The value of datagram_size [...] SHALL be one less than the value of Total Length in the datagram's IP header (see STD 5, RFC 791). Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got this field with a -/+1 offset: ether1394_tx() /* transmit */ ether1394_encapsulate_prep() hdr->ff.dg_size = dg_size - 1; ether1394_data_handler() /* receive */ if (hdr->common.lf == ETH1394_HDR_LF_FF) dg_size = hdr->ff.dg_size + 1; else dg_size = hdr->sf.dg_size + 1; Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500 byte sized datagrams in fragments with datagram_size=1499 if link fragmentation is required. Only firewire-net sets and gets datagram_size without this offset. The result is lacking interoperability of firewire-net with OS X, Windows XP, and presumably Linux' eth1394. (I did not test with the latter.) For example, FTP data transfers to a Linux firewire-net box with max_rec smaller than the 1500 bytes MTU - from OS X fail entirely, - from Win XP start out with a bunch of fragmented datagrams which time out, then continue with unfragmented datagrams because Win XP temporarily reduces the MTU to 576 bytes. So let's fix firewire-net's datagram_size accessors. Note that firewire-net thereby loses interoperability with unpatched firewire-net, but only if link fragmentation is employed. (This happens with large broadcast datagrams, and with large datagrams on several FireWire CardBus cards with smaller max_rec than equivalent PCI cards, and it can be worked around by setting a small enough MTU.) Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 032430fb6a2cb0392801ca260396f31bc7798632 Author: Stefan Richter Date: Sat Oct 29 21:28:18 2016 +0200 firewire: net: guard against rx buffer overflows commit 667121ace9dbafb368618dbabcf07901c962ddac upstream. The IP-over-1394 driver firewire-net lacked input validation when handling incoming fragmented datagrams. A maliciously formed fragment with a respectively large datagram_offset would cause a memcpy past the datagram buffer. So, drop any packets carrying a fragment with offset + length larger than datagram_size. In addition, ensure that - GASP header, unfragmented encapsulation header, or fragment encapsulation header actually exists before we access it, - the encapsulated datagram or fragment is of nonzero size. Reported-by: Eyal Itkin Reviewed-by: Eyal Itkin Fixes: CVE 2016-8633 Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit facb17b67ac9b40b0c98bf4b6c07d938adbfc7e1 Author: Patrick Scheuring Date: Wed Oct 19 12:04:02 2016 -0700 Input: i8042 - add XMG C504 to keyboard reset table commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream. The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop. Therefore it also needs a keyboard reset to detect the Elantech touchpad. Otherwise the touchpad appears to be dead. With this patch the touchpad is detected: $ dmesg | grep -E "(i8042|Elantech|elantech)" [ 2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 2.680372] i8042: Attempting to reset device connected to KBD port [ 2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 [ 3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e) [ 3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f. [ 3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74 [ 3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6 Signed-off-by: Patrick Scheuring Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8b535f07898ab46cd858838b396ee8a1c0f38146 Author: Jes Sorensen Date: Fri Sep 30 19:35:17 2016 -0400 rtl8xxxu: Fix rtl8723bu driver reload issue commit ab05e5ec81c76f3a852919c22984c885edd2414a upstream. The generic disable_rf() function clears bits 22 and 23 in REG_RX_WAIT_CCA, however we did not re-enable them again in rtl8723b_enable_rf() This resolves the problem for me with 8723bu devices not working again after reloading the driver. Signed-off-by: Jes Sorensen Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 1c9edb27261e8fba41ccb8759e31c40b8e86acb8 Author: Jes Sorensen Date: Thu Sep 29 15:40:55 2016 -0400 rtl8xxxu: Fix big-endian problem reporting mactime commit 8a55698f2f29d227825173420d7b99b9277ca88c upstream. The full RX descriptor is converted so converting tsfl again would return it to it's original endian value. Signed-off-by: Jes Sorensen Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ece1b51ae1c40ae576676204ad86e07c7f747ba2 Author: Jes Sorensen Date: Thu Sep 29 15:40:54 2016 -0400 rtl8xxxu: Fix memory leak in handling rxdesc16 packets commit 1e54134ccad00f76ddf00f3e77db3dc8fdefbb47 upstream. A device running without RX package aggregation could return more data in the USB packet than the actual network packet. In this case we could would clone the skb but then determine that that there was no packet to handle and exit without freeing the cloned skb first. This has so far only been observed with 8188eu devices, but could affect others. Signed-off-by: Jes Sorensen Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 5a805cd29284a4fe36add86965754fc1691db1b7 Author: Heinz Mauelshagen Date: Mon Oct 17 21:20:07 2016 +0200 dm raid: fix activation of existing raid4/10 devices commit b052b07c39d593c9954a84d5bbe1563999483f38 upstream. dm-raid 1.9.0 fails to activate existing RAID4/10 devices that have the old superblock format (which does not have takeover/reshaping support that was added via commit 33e53f06850f). Fix validation path for old superblocks by reverting to the old raid4 layout and basing checks on mddev->new_{level,layout,...} members in super_init_validation(). Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6e5456768ba1ee581f8e43c8f90296ead4c30b98 Author: Andy Whitcroft Date: Tue Oct 11 15:16:57 2016 +0100 dm raid: fix compat_features validation commit 5c33677c87cbe44ae04df69c4a29c1750a9ec4e5 upstream. In ecbfb9f118bce4 ("dm raid: add raid level takeover support") a new compatible feature flag was added. Validation for these compat_features was added but this only passes for new raid mappings with this feature flag. This causes previously created raid mappings to be failed at import. Check compat_features for the only valid combination. Fixes: ecbfb9f118bce4 ("dm raid: add raid level takeover support") Signed-off-by: Andy Whitcroft Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 056290446e8a36183b223f20269d1eecc71c425e Author: Mike Snitzer Date: Tue Oct 18 14:02:04 2016 -0400 dm rq: clear kworker_task if kthread_run() returned an error commit 937fa62e8a00d0b4bc2c0a40567d7c88ab2b2e8d upstream. cleanup_mapped_device() calls kthread_stop() if kworker_task is non-NULL. Currently the assigned value could be a valid task struct or an error code (e.g -ENOMEM). Reset md->kworker_task to NULL if kthread_run() returned an erorr. Fixes: 7193a9defc ("dm rq: check kthread_run return for .request_fn request-based DM") Reported-by: Tahsin Erdogan Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 13a59a86875651a62f13fc14774b3c31147b21ce Author: tang.junhui Date: Fri Oct 21 09:35:32 2016 +0800 dm table: fix missing dm_put_target_type() in dm_table_add_target() commit dafa724bf582181d9a7d54f5cb4ca0bf8ef29269 upstream. dm_get_target_type() was previously called so any error returned from dm_table_add_target() must first call dm_put_target_type(). Otherwise the DM target module's reference count will leak and the associated kernel module will be unable to be removed. Also, leverage the fact that r is already -EINVAL and remove an extra newline. Fixes: 36a0456 ("dm table: add immutable feature") Fixes: cc6cbe1 ("dm table: add always writeable feature") Fixes: 3791e2f ("dm table: add singleton feature") Signed-off-by: tang.junhui Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 159a17e8dbf630c5a0ab45db2fb84365068b93cd Author: Heinz Mauelshagen Date: Mon Oct 10 17:58:32 2016 +0200 dm mirror: fix read error on recovery after default leg failure commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream. If a default leg has failed, any read will cause a new operational default leg to be selected and the read is resubmitted. But until now the read will return failure even though it was successful due to resubmission. The reason for this is bio->bi_error was not being cleared before resubmitting the bio. Fix by clearing bio->bi_error before resubmission. Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio") Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit d8db5234adef690428989554edbcde6224aca49f Author: Matt Redfearn Date: Tue Oct 11 12:05:15 2016 +0100 virtio: console: Unlock vqs while freeing buffers commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 upstream. Commit c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") added locking around the freeing of buffers in the vq. However, when free_buf() is called with can_sleep = true and rproc is enabled, it calls dma_free_coherent() directly, requiring interrupts to be enabled. Currently a WARNING is triggered due to the spin locking around free_buf, with a call stack like this: WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433 free_buf+0x1a8/0x288 Call Trace: [<8040c538>] show_stack+0x74/0xc0 [<80757240>] dump_stack+0xd0/0x110 [<80430d98>] __warn+0xfc/0x130 [<80430ee0>] warn_slowpath_null+0x2c/0x3c [<807e7c6c>] free_buf+0x1a8/0x288 [<807ea590>] remove_port_data+0x50/0xac [<807ea6a0>] unplug_port+0xb4/0x1bc [<807ea858>] virtcons_remove+0xb0/0xfc [<807b6734>] virtio_dev_remove+0x58/0xc0 [<807f918c>] __device_release_driver+0xac/0x134 [<807f924c>] device_release_driver+0x38/0x50 [<807f7edc>] bus_remove_device+0xfc/0x130 [<807f4b74>] device_del+0x17c/0x21c [<807f4c38>] device_unregister+0x24/0x38 [<807b6b50>] unregister_virtio_device+0x28/0x44 Fix this by restructuring the loops to allow the locks to only be taken where it is necessary to protect the vqs, and release it while the buffer is being freed. Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") Signed-off-by: Matt Redfearn Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 7569d22a820df0e32b9e4f9e257127d92a133d78 Author: Will Deacon Date: Wed Sep 14 17:33:26 2016 +0100 virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices commit a0be1db4304f51c99af6b6e515549794182a94df upstream. Legacy virtio defines the virtqueue base using a 32-bit PFN field, with a read-only register indicating a fixed page size of 4k. This can cause problems for DMA allocators that allocate top down from the DMA mask, which is set to 64 bits. In this case, the addresses are silently truncated to 44-bit, leading to IOMMU faults, failure to read from the queue or data corruption. This patch restricts the coherent DMA mask for legacy PCI virtio devices to 44 bits, which matches the specification. Cc: Andy Lutomirski Cc: Michael S. Tsirkin Cc: Benjamin Serebrin Signed-off-by: Will Deacon Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 0c2f67a6196d6d877fdd2fb1f34da155e39d39db Author: Ladi Prosek Date: Wed Aug 31 14:00:04 2016 +0200 virtio_ring: Make interrupt suppression spec compliant commit 0ea1e4a6d9b62cf29e210d2b4ba9fd43917522e3 upstream. According to the spec, if the VIRTIO_RING_F_EVENT_IDX feature bit is negotiated the driver MUST set flags to 0. Not dirtying the available ring in virtqueue_disable_cb also has a minor positive performance impact, improving L1 dcache load missed by ~0.5% in vring_bench. Writes to the used event field (vring_used_event) are still unconditional. Cc: Michael S. Tsirkin Signed-off-by: Ladi Prosek Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit c528df925fba556a2e43d03cec64da5dc4b2b9a1 Author: John David Anglin Date: Fri Oct 28 23:00:34 2016 -0400 parisc: Ensure consistent state when switching to kernel stack at syscall entry commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream. We have one critical section in the syscall entry path in which we switch from the userspace stack to kernel stack. In the event of an external interrupt, the interrupt code distinguishes between those two states by analyzing the value of sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that the value of sr7 is in sync with the currently enabled stack. This patch now disables interrupts while executing the critical section. This prevents the interrupt handler to possibly see an inconsistent state which in the worst case can lead to crashes. Interestingly, in the syscall exit path interrupts were already disabled in the critical section which switches back to the userspace stack. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 592de1000694bdc9ce6d4233efca27a490009e06 Author: Miklos Szeredi Date: Mon Oct 31 14:42:14 2016 +0100 ovl: fsync after copy-up commit 641089c1549d8d3df0b047b5de7e9a111362cdce upstream. Make sure the copied up file hits the disk before renaming to the final destination. If this is not done then the copy-up may corrupt the data in the file in case of a crash. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 3ad464dadb7c7abdaf11efe283e2c2679ef55057 Author: Miklos Szeredi Date: Mon Oct 31 14:42:14 2016 +0100 ovl: update S_ISGID when setting posix ACLs commit fd3220d37b1f6f0cab6142d98b0e6c4082e63299 upstream. This change fixes xfstest generic/375, which failed to clear the setgid bit in the following test case on overlayfs: touch $testfile chown 100:100 $testfile chmod 2755 $testfile _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile Reported-by: Amir Goldstein Signed-off-by: Miklos Szeredi Tested-by: Amir Goldstein Fixes: d837a49bd57f ("ovl: fix POSIX ACL setting") Signed-off-by: Greg Kroah-Hartman commit be9015460ed58cd5ec2f944e29d09cdf32f0345c Author: Miklos Szeredi Date: Mon Oct 31 14:42:14 2016 +0100 ovl: fix get_acl() on tmpfs commit b93d4a0eb308d4400b84c8b24c1b80e09a9497d0 upstream. tmpfs doesn't have ->get_acl() because it only uses cached acls. This fixes the acl tests in pjdfstest when tmpfs is used as the upper layer of the overlay. Reported-by: Amir Goldstein Signed-off-by: Miklos Szeredi Fixes: 39a25b2b3762 ("ovl: define ->get_acl() for overlay inodes") Signed-off-by: Greg Kroah-Hartman commit 2b632307635f341559b1df1fec5b8a067223caf4 Author: Matt Redfearn Date: Mon Oct 17 17:21:46 2016 +0100 MIPS: KASLR: Fix handling of NULL FDT commit 4736697963385e6257ee8e260e97347e858cd962 upstream. If platform code returns a NULL pointer to the FDT, initial_boot_params will not get set to a valid pointer and attempting to find the /chosen node in it will cause a NULL pointer dereference and the kernel to crash immediately on startup - with no output to the console. Fix this by checking that initial_boot_params is valid before using it. Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE") Signed-off-by: Matt Redfearn Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14414/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 1734afcce32bc235f097916cbc90324f27c978f5 Author: Chuck Lever Date: Sat Oct 29 18:19:03 2016 -0400 nfsd: Fix general protection fault in release_lock_stateid() commit f46c445b79906a9da55c13e0a6f6b6a006b892fe upstream. When I push NFSv4.1 / RDMA hard, (xfstests generic/089, for example), I get this crash on the server: Oct 28 22:04:30 klimt kernel: general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC Oct 28 22:04:30 klimt kernel: Modules linked in: cts rpcsec_gss_krb5 iTCO_wdt iTCO_vendor_support sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm btrfs irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd xor pcspkr raid6_pq i2c_i801 i2c_smbus lpc_ich mfd_core sg mei_me mei ioatdma shpchp wmi ipmi_si ipmi_msghandler rpcrdma ib_ipoib rdma_ucm acpi_power_meter acpi_pad ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx4_ib mlx4_en ib_core sr_mod cdrom sd_mod ast drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel igb ahci libahci ptp mlx4_core pps_core dca libata i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod Oct 28 22:04:30 klimt kernel: CPU: 7 PID: 1558 Comm: nfsd Not tainted 4.9.0-rc2-00005-g82cd754 #8 Oct 28 22:04:30 klimt kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015 Oct 28 22:04:30 klimt kernel: task: ffff880835c3a100 task.stack: ffff8808420d8000 Oct 28 22:04:30 klimt kernel: RIP: 0010:[] [] release_lock_stateid+0x1f/0x60 [nfsd] Oct 28 22:04:30 klimt kernel: RSP: 0018:ffff8808420dbce0 EFLAGS: 00010246 Oct 28 22:04:30 klimt kernel: RAX: ffff88084e6660f0 RBX: ffff88084e667020 RCX: 0000000000000000 Oct 28 22:04:30 klimt kernel: RDX: 0000000000000007 RSI: 0000000000000000 RDI: ffff88084e667020 Oct 28 22:04:30 klimt kernel: RBP: ffff8808420dbcf8 R08: 0000000000000001 R09: 0000000000000000 Oct 28 22:04:30 klimt kernel: R10: ffff880835c3a100 R11: ffff880835c3aca8 R12: 6b6b6b6b6b6b6b6b Oct 28 22:04:30 klimt kernel: R13: ffff88084e6670d8 R14: ffff880835f546f0 R15: ffff880835f1c548 Oct 28 22:04:30 klimt kernel: FS: 0000000000000000(0000) GS:ffff88087bdc0000(0000) knlGS:0000000000000000 Oct 28 22:04:30 klimt kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 28 22:04:30 klimt kernel: CR2: 00007ff020389000 CR3: 0000000001c06000 CR4: 00000000001406e0 Oct 28 22:04:30 klimt kernel: Stack: Oct 28 22:04:30 klimt kernel: ffff88084e667020 0000000000000000 ffff88084e6670d8 ffff8808420dbd20 Oct 28 22:04:30 klimt kernel: ffffffffa05ac80d ffff880835f54548 ffff88084e640008 ffff880835f545b0 Oct 28 22:04:30 klimt kernel: ffff8808420dbd70 ffffffffa059803d ffff880835f1c768 0000000000000870 Oct 28 22:04:30 klimt kernel: Call Trace: Oct 28 22:04:30 klimt kernel: [] nfsd4_free_stateid+0xfd/0x1b0 [nfsd] Oct 28 22:04:30 klimt kernel: [] nfsd4_proc_compound+0x40d/0x690 [nfsd] Oct 28 22:04:30 klimt kernel: [] nfsd_dispatch+0xd4/0x1d0 [nfsd] Oct 28 22:04:30 klimt kernel: [] svc_process_common+0x3d9/0x700 [sunrpc] Oct 28 22:04:30 klimt kernel: [] svc_process+0xf4/0x330 [sunrpc] Oct 28 22:04:30 klimt kernel: [] nfsd+0xfa/0x160 [nfsd] Oct 28 22:04:30 klimt kernel: [] ? nfsd_destroy+0x170/0x170 [nfsd] Oct 28 22:04:30 klimt kernel: [] kthread+0x10b/0x120 Oct 28 22:04:30 klimt kernel: [] ? kthread_stop+0x280/0x280 Oct 28 22:04:30 klimt kernel: [] ret_from_fork+0x2a/0x40 Oct 28 22:04:30 klimt kernel: Code: c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 87 b0 00 00 00 48 89 fb 4c 8b a0 98 00 00 00 <49> 8b 44 24 20 48 8d b8 80 03 00 00 e8 10 66 1a e1 48 89 df e8 Oct 28 22:04:30 klimt kernel: RIP [] release_lock_stateid+0x1f/0x60 [nfsd] Oct 28 22:04:30 klimt kernel: RSP Oct 28 22:04:30 klimt kernel: ---[ end trace cf5d0b371973e167 ]--- Jeff Layton says: > Hm...now that I look though, this is a little suspicious: > > struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner); > > I wonder if it's possible for the openstateid to have already been > destroyed at this point. > > We might be better off doing something like this to get the client pointer: > > stp->st_stid.sc_client; > > ...which should be more direct and less dependent on other stateids > staying valid. With the suggested change, I am no longer able to reproduce the above oops. v2: Fix unhash_lock_stateid() as well Fix-suggested-by: Jeff Layton Fixes: 42691398be08 ('nfsd: Fix race between FREE_STATEID and LOCK') Signed-off-by: Chuck Lever Reviewed-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 202c6676b9639c83f276da5c858e4c1e3c29c5b1 Author: Linus Walleij Date: Fri Oct 7 10:52:17 2016 +0200 ARM: dts: fix the SD card on the Snowball commit 1b283eea6228880b765bc40fe4e555416437ce58 upstream. This fixes a very annoying regression on the Snowball SD card that has been around for a while. It turns out that the device tree does not configure the direction pins properly, nor sets up the pins for the voltage converter properly at boot. Unless all things are correctly set up, the feedback clock will not work, and makes the driver spew messages in the console (but it works, very slowly): root@Ux500:/ mount /dev/mmcblk0p2 /mnt/ [ 9.953460] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! [ 9.960296] mmcblk0: error -110 sending status command, retrying [ 9.966461] mmcblk0: error -110 sending status command, retrying [ 9.972534] mmcblk0: error -110 sending status command, aborting Fix this by rectifying the device tree to correspond to that of the Ux500 HREF boards plus the DAT31DIR setting that is unique for the Snowball, and things start working smoothly. Add in the SDR12 and SDR25 modes which this host can do without any problems. I don't know if this has ever been correct, sadly. It works after this patch. Reported-by: Daniel Lezcano Cc: Ulf Hansson Signed-off-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit db20b510ca5cdfe2de294c40eac8ddcf98e03b33 Author: Gregory CLEMENT Date: Mon Sep 19 12:02:50 2016 +0200 ARM: mvebu: Select corediv clk for all mvebu v7 SoC commit 33c45ef8adc8a7cf781b2566d50e6ea8e97b3596 upstream. Since the commit bd3677ff31a3 ("clk: mvebu: Remove corediv clock from Armada XP"), the corediv clk is no more selected for Armada XP, however this clock is used for Armada XP using the compatible armada-370-corediv-clock. While since commit 1594d568c6e3 ("clk: mvebu: Move corediv config to mvebu config") Armada 38x and Armada 375 got corediv support again, not only Armada XP was missed but also Armada 39x. Actually all the SoC selecting MVEBU_V7 config need this clock: git grep "\-corediv-clock" arch/arm/boot/dts arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,armada-370-corediv-clock"; arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,armada-375-corediv-clock"; arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,armada-380-corediv-clock"; arch/arm/boot/dts/armada-39x.dtsi: compatible = "marvell,armada-390-corediv-clock" This commit now fixes this behavior by letting MVEBU_V7 select MVEBU_CLK_COREDIV. Fixes: bd3677ff31a3 ("clk: mvebu: Remove corediv clock from Armada XP") Reported-by: Uwe Kleine-König Acked-by: Uwe Kleine-König Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit c627b2e76ae2fdd559e467285f7679b62f1a25c8 Author: James Hogan Date: Tue Oct 25 16:11:12 2016 +0100 KVM: MIPS: Precalculate MMIO load resume PC commit e1e575f6b026734be3b1f075e780e91ab08ca541 upstream. The advancing of the PC when completing an MMIO load is done before re-entering the guest, i.e. before restoring the guest ASID. However if the load is in a branch delay slot it may need to access guest code to read the prior branch instruction. This isn't safe in TLB mapped code at the moment, nor in the future when we'll access unmapped guest segments using direct user accessors too, as it could read the branch from host user memory instead. Therefore calculate the resume PC in advance while we're still in the right context and save it in the new vcpu->arch.io_pc (replacing the no longer needed vcpu->arch.pending_load_cause), and restore it on MMIO completion. Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f3a0c969e788b3bcd22b677cac088114fcf0d774 Author: James Hogan Date: Tue Oct 25 16:11:11 2016 +0100 KVM: MIPS: Make ERET handle ERL before EXL commit ede5f3e7b54a4347be4d8525269eae50902bd7cd upstream. The ERET instruction to return from exception is used for returning from exception level (Status.EXL) and error level (Status.ERL). If both bits are set however we should be returning from ERL first, as ERL can interrupt EXL, for example when an NMI is taken. KVM however checks EXL first. Fix the order of the checks to match the pseudocode in the instruction set manual. Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 961cf133b710fe70c8c615dc37cf6b111a3f2c79 Author: Janosch Frank Date: Wed Oct 26 08:48:11 2016 +0200 KVM: s390: Fix STHYI buffer alignment for diag224 commit 45c7ee43a5184ddbff652ee0d2e826f86f1b616b upstream. Diag224 requires a page-aligned 4k buffer to store the name table into. kmalloc does not guarantee page alignment, hence we replace it with __get_free_page for the buffer allocation. Reported-by: Michael Holzheu Signed-off-by: Janosch Frank Reviewed-by: Cornelia Huck Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 88aca01f8cb4718c0daa43074dca9019a5e0548e Author: Ido Yariv Date: Fri Oct 21 12:39:57 2016 -0400 KVM: x86: fix wbinvd_dirty_mask use-after-free commit bd768e146624cbec7122ed15dead8daa137d909d upstream. vcpu->arch.wbinvd_dirty_mask may still be used after freeing it, corrupting memory. For example, the following call trace may set a bit in an already freed cpu mask: kvm_arch_vcpu_load vcpu_load vmx_free_vcpu_nested vmx_free_vcpu kvm_arch_vcpu_free Fix this by deferring freeing of wbinvd_dirty_mask. Signed-off-by: Ido Yariv Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit ea261d177aede60a6a0e05fe42470e706ac1c34d Author: Tahsin Erdogan Date: Mon Oct 10 05:35:19 2016 -0700 dm: free io_barrier after blk_cleanup_queue call commit d09960b0032174eb493c4c13be5b9c9ef36dc9a7 upstream. dm_old_request_fn() has paths that access md->io_barrier. The party destroying io_barrier should ensure that no future execution of dm_old_request_fn() is possible. Move io_barrier destruction to below blk_cleanup_queue() to ensure this and avoid a NULL pointer crash during request-based DM device shutdown. Signed-off-by: Tahsin Erdogan Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 377a2a273c4b2838f7e2c52b4740dd997c05aab6 Author: Aditya Shankar Date: Fri Oct 7 09:45:03 2016 +0530 Staging: wilc1000: Fix kernel Oops on opening the device commit 1d4f1d53e1e2d5e38f4d3ca3bf60f8be5025540f upstream. Commit 2518ac59eb27 ("staging: wilc1000: Replace kthread with workqueue for host interface") adds an unconditional destroy_workqueue() on the wilc's "hif_workqueue" soon after its creation thereby rendering it unusable. It then further attempts to queue work onto this non-existing hif_worqueue and results in: Unable to handle kernel NULL pointer dereference at virtual address 00000010 pgd = de478000 [00000010] *pgd=3eec0831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: wilc1000_sdio(C) wilc1000(C) CPU: 0 PID: 825 Comm: ifconfig Tainted: G C 4.8.0-rc8+ #37 Hardware name: Atmel SAMA5 task: df56f800 task.stack: deeb0000 PC is at __queue_work+0x90/0x284 LR is at __queue_work+0x58/0x284 pc : [] lr : [] psr: 600f0093 sp : deeb1aa0 ip : def22d78 fp : deea6000 r10: 00000000 r9 : c0a08150 r8 : c0a2f058 r7 : 00000001 r6 : dee9b600 r5 : def22d74 r4 : 00000000 r3 : 00000000 r2 : def22d74 r1 : 07ffffff r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none ... [] (__queue_work) from [] (queue_work_on+0x34/0x40) [] (queue_work_on) from [] (wilc_enqueue_cmd+0x54/0x64 [wilc1000]) [] (wilc_enqueue_cmd [wilc1000]) from [] (wilc_set_wfi_drv_handler+0x48/0x70 [wilc1000]) [] (wilc_set_wfi_drv_handler [wilc1000]) from [] (wilc_mac_open+0x214/0x250 [wilc1000]) [] (wilc_mac_open [wilc1000]) from [] (__dev_open+0xb8/0x11c) [] (__dev_open) from [] (__dev_change_flags+0x94/0x158) [] (__dev_change_flags) from [] (dev_change_flags+0x18/0x48) [] (dev_change_flags) from [] (devinet_ioctl+0x6b4/0x788) [] (devinet_ioctl) from [] (sock_ioctl+0x154/0x2cc) [] (sock_ioctl) from [] (do_vfs_ioctl+0x9c/0x878) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) Code: e5932004 e1520006 01a04003 0affffff (e5943010) ---[ end trace b612328adaa6bf20 ]--- This fix removes the unnecessary call to destroy_workqueue() while opening the device to avoid the above kernel panic. The deinit routine already does a good job of terminating the workqueue when no longer needed. Reported-by: Nicolas Ferre Fixes: 2518ac59eb27 ("staging: wilc1000: Replace kthread with workqueue for host interface") Signed-off-by: Aditya Shankar Signed-off-by: Greg Kroah-Hartman commit 0c4ffbf9e118c4be52ee03c6c666940d222cc7d7 Author: Sandhya Bankar Date: Sun Sep 25 00:46:21 2016 +0530 iio:chemical:atlas-ph-sensor: Fix use of 32 bit int to hold 16 bit big endian value commit d1fe85ec7702917f2f1515b4c421d5d4792201a0 upstream. This will result in a random value being reported on big endian architectures. (thanks to Lars-Peter Clausen for pointing out the effects of this bug) Only effects a value printed to the log, but as this reports the settings of the probe in question it may be of direct interest to users. Also, fixes the following sparse endianness warnings: drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 Signed-off-by: Sandhya Bankar Fixes: e8dd92bfbff25 ("iio: chemical: atlas-ph-sensor: add EC feature") Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 52a1e76f16e2ed83033d09c58170bfc41bb1d480 Author: Marcin Wojtas Date: Tue Sep 6 19:41:11 2016 +0200 arm64: dts: marvell: fix clocksource for CP110 master SPI0 commit 51227bf52008bd4c4c50da4b749bbc6e7bbbca52 upstream. I2C and SPI interfaces share common clock trees within the CP110 HW block. It occurred that SPI0 interface has wrong clock assignment in the device tree, which is fixed in this commit to a proper value. Fixes: 728dacc7f4dd ("arm64: dts: marvell: initial DT description of ...") Signed-off-by: Marcin Wojtas Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 0dff3c6321a5df62d3721758d6d30795ca4526c6 Author: Dmitry Vyukov Date: Fri Oct 14 15:18:28 2016 +0200 tty: limit terminal size to 4M chars commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream. Size of kmalloc() in vc_do_resize() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Put a reasonable upper bound on terminal size to prevent WARNINGs. Signed-off-by: Dmitry Vyukov CC: David Rientjes Cc: One Thousand Gnomes Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Peter Hurley Cc: linux-kernel@vger.kernel.org Cc: syzkaller@googlegroups.com Signed-off-by: Greg Kroah-Hartman commit 44f0722dc9acf2348c1a0f71c88f5d4a3722a81a Author: Mathias Nyman Date: Thu Oct 20 18:09:19 2016 +0300 xhci: workaround for hosts missing CAS bit commit 346e99736c3ce328fd42d678343b70243aca5f36 upstream. If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume. A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset. Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 0894224ae7c048007a391ddd47881dad8ac8cf3b Author: Mathias Nyman Date: Thu Oct 20 18:09:18 2016 +0300 xhci: add restart quirk for Intel Wildcatpoint PCH commit 4c39135aa412d2f1381e43802523da110ca7855c upstream. xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the same quirks to prevent machines from spurious restart while shutting them down. Reported-by: Hasan Mahmood Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit b2d28d93cf83480d69e771c86080461ccdc9c4a5 Author: Long Li Date: Wed Oct 5 16:57:46 2016 -0700 hv: do not lose pending heartbeat vmbus packets commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream. The host keeps sending heartbeat packets independent of the guest responding to them. Even though we respond to the heartbeat messages at interrupt level, we can have situations where there maybe multiple heartbeat messages pending that have not been responded to. For instance this occurs when the VM is paused and the host continues to send the heartbeat messages. Address this issue by draining and responding to all the heartbeat messages that maybe pending. Signed-off-by: Long Li Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit eeae0a12a16650ff494d5faefa371cd9e7079575 Author: Scot Doyle Date: Thu Oct 13 12:12:43 2016 -0500 vt: clear selection before resizing commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream. When resizing a vt its selection may exceed the new size, resulting in an invalid memory access [1]. Clear the selection before resizing. [1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com Reported-and-tested-by: Dmitry Vyukov Signed-off-by: Scot Doyle Signed-off-by: Greg Kroah-Hartman commit 9710f5b193284e7c9f47d70de7378fe758b4e12a Author: Thomas Gleixner Date: Sat Oct 29 13:42:42 2016 +0200 x86/smpboot: Init apic mapping before usage commit 1e90a13d0c3dc94512af1ccb2b6563e8297838fa upstream. The recent changes, which forced the registration of the boot cpu on UP systems, which do not have ACPI tables, have been fixed for systems w/o local APIC, but left a wreckage for systems which have neither ACPI nor mptables, but the CPU has an APIC, e.g. virtualbox. The boot process crashes in prefill_possible_map() as it wants to register the boot cpu, which needs to access the local apic, but the local APIC is not yet mapped. There is no reason why init_apic_mapping() can't be invoked before prefill_possible_map(). So instead of playing another silly early mapping game, as the ACPI/mptables code does, we just move init_apic_mapping() before the call to prefill_possible_map(). In hindsight, I should have noticed that combination earlier. Sorry for the churn (also in stable)! Fixes: ff8560512b8d ("x86/boot/smp: Don't try to poke disabled/non-existent APIC") Reported-and-debugged-by: Michal Necasek Reported-and-tested-by: Wolfgang Bauer Cc: prarit@redhat.com Cc: ville.syrjala@linux.intel.com Cc: michael.thayer@oracle.com Cc: knut.osmundsen@oracle.com Cc: frank.mehnert@oracle.com Cc: Borislav Petkov Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610282114380.5053@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 58b0a7f115f8be2130b8da60a87a3277ee7b0468 Author: Gerald Schaefer Date: Wed Oct 19 12:29:41 2016 +0200 GenWQE: Fix bad page access during abort of resource allocation commit a7a7aeefbca2982586ba2c9fd7739b96416a6d1d upstream. When interrupting an application which was allocating DMAable memory, it was possible, that the DMA memory was deallocated twice, leading to the error symptoms below. Thanks to Gerald, who analyzed the problem and provided this patch. I agree with his analysis of the problem: ddcb_cmd_fixups() -> genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() -> genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and f/lpage maybe also != NULL) In this scenario we would have exactly the kind of double free that would explain the WARNING / Bad page state, and as expected it is caused by broken error handling (cleanup). Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce the "Bad page state" issue, and with the patch on top he could not reproduce it any more. ------------[ cut here ]------------ WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141 Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000 Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400 0000000000000400 0000000000001fff 0000000000000400 0000000116853000 07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001 0000000000001000 0000000116854000 0000000000156402 00000000324e7a38 Krnl Code: 000000000015633a: 95001000 cli 0(%r1),0 000000000015633e: a774ffc3 brc 7,1562c4 #0000000000156342: a7f40001 brc 15,156344 >0000000000156346: 92011000 mvi 0(%r1),1 000000000015634a: a7f4ffbd brc 15,1562c4 000000000015634e: 0707 bcr 0,%r7 0000000000156350: c00400000000 brcl 0,156350 0000000000156356: eb7ff0500024 stmg %r7,%r15,80(%r15) Call Trace: ([<00000000001563e0>] dma_update_trans+0x90/0x228) [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160 [<00000000001567c2>] s390_dma_free+0x62/0x98 [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card] [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card] [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card] [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card] [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card] [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518 [<0000000000325344>] SyS_ioctl+0xa4/0xb8 [<00000000007b86c6>] system_call+0xd6/0x264 [<000003ff9e8e520a>] 0x3ff9e8e520a Last Breaking-Event-Address: [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8 ---[ end trace 35996336235145c8 ]--- BUG: Bad page state in process jbd2/dasdb1-8 pfn:3215b page:000003d100c856c0 count:-1 mapcount:0 mapping: (null) index:0x0 flags: 0x3fffc0000000000() page dumped because: nonzero _count Signed-off-by: Gerald Schaefer Signed-off-by: Frank Haverkamp Signed-off-by: Greg Kroah-Hartman commit b9aa0a7290f53bf2158e3e5b9a306f1006f3cc91 Author: Bryan Paluch Date: Mon Oct 17 08:54:46 2016 -0400 usb: increase ohci watchdog delay to 275 msec commit ed6d6f8f42d7302f6f9b6245f34927ec20d26c12 upstream. Increase ohci watchout delay to 275 ms. Previous delay was 250 ms with 20 ms of slack, after removing slack time some ohci controllers don't respond in time. Logs from systems with controllers that have the issue would show "HcDoneHead not written back; disabled" Signed-off-by: Bryan Paluch Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 241208e7b721ffb8b6b44fd8446c2bf5fb55aa0e Author: Yoshihiro Shimoda Date: Thu Oct 20 13:19:19 2016 +0900 usb: renesas_usbhs: add wait after initialization for R-Car Gen3 commit b76032396d7958f006bccf5fb2535beb5526837c upstream. Since the controller on R-Car Gen3 doesn't have any status registers to detect initialization (LPSTS.SUSPM = 1) and the initialization needs up to 45 usec, this patch adds wait after the initialization. Otherwise, writing other registers (e.g. INTENB0) will fail. Fixes: de18757e272d ("usb: renesas_usbhs: add R-Car Gen3 power control") Cc: Signed-off-by: Yoshihiro Shimoda Signed-off-by: Greg Kroah-Hartman commit 00dbeb06292be1045f4b96da22696e2e138bf2c3 Author: Mathias Nyman Date: Thu Oct 20 18:09:20 2016 +0300 xhci: use default USB_RESUME_TIMEOUT when resuming ports. commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 upstream. USB2 host inititated resume, and system suspend bus resume need to use the same USB_RESUME_TIMEOUT as elsewhere. This resolves a device disconnect issue at system resume seen on Intel Braswell and Apollolake, but is in no way limited to those platforms. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 1e306cd37a6685b10b39aea5b3b039983b7c5cb0 Author: Stefan Tauner Date: Thu Oct 6 18:40:11 2016 +0200 USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7 commit ca006f785fbfd7a5c901900bd3fe2b26e946a1ee upstream. This adds support to ftdi_sio for the Infineon TriBoard TC2X7 engineering board for first-generation Aurix SoCs with Tricore CPUs. Mere addition of the device IDs does the job. Signed-off-by: Stefan Tauner Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d082fd105eb90d2a55670629b8ea1b8b628d6a10 Author: Johan Hovold Date: Wed Oct 19 15:45:07 2016 +0200 USB: serial: cp210x: fix tiocmget error handling commit de24e0a108bc48062e1c7acaa97014bce32a919f upstream. The current tiocmget implementation would fail to report errors up the stack and instead leaked a few bits from the stack as a mask of modem-status flags. Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e8bf726705bd482371f5ba94274e19237717e1a1 Author: Johan Hovold Date: Fri Oct 21 12:56:27 2016 +0200 USB: serial: fix potential NULL-dereference at probe commit 126d26f66d9890a69158812a6caa248c05359daa upstream. Make sure we have at least one port before attempting to register a console. Currently, at least one driver binds to a "dummy" interface and requests zero ports for it. Should such an interface also lack endpoints, we get a NULL-deref during probe. Fixes: e5b1e2062e05 ("USB: serial: make minor allocation dynamic") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 23124735a6f064b048ebaca65a5801ff813350c7 Author: Felipe Balbi Date: Tue Oct 4 15:14:43 2016 +0300 usb: gadget: function: u_ether: don't starve tx request queue commit 6c83f77278f17a7679001027e9231291c20f0d8a upstream. If we don't guarantee that we will always get an interrupt at least when we're queueing our very last request, we could fall into situation where we queue every request with 'no_interrupt' set. This will cause the link to get stuck. The behavior above has been triggered with g_ether and dwc3. Reported-by: Ville Syrjälä Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit fe4af125085a42370f181dc6a748c15774183a2a Author: Alexandre Belloni Date: Thu Sep 15 17:07:22 2016 +0200 usb: gadget: udc: atmel: fix endpoint name commit bbe097f092b0d13e9736bd2794d0ab24547d0e5d upstream. Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"), atmel_usba_udc fails with: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405 ecm_do_notify+0x188/0x1a0 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15 Hardware name: Atmel SAMA5 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (__warn+0xe4/0xfc) [] (__warn) from [] (warn_slowpath_null+0x20/0x28) [] (warn_slowpath_null) from [] (ecm_do_notify+0x188/0x1a0) [] (ecm_do_notify) from [] (ecm_set_alt+0x74/0x1ac) [] (ecm_set_alt) from [] (composite_setup+0xfc0/0x19f8) [] (composite_setup) from [] (usba_udc_irq+0x8f4/0xd9c) [] (usba_udc_irq) from [] (handle_irq_event_percpu+0x9c/0x158) [] (handle_irq_event_percpu) from [] (handle_irq_event+0x28/0x3c) [] (handle_irq_event) from [] (handle_fasteoi_irq+0xa0/0x168) [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x24/0x34) [] (generic_handle_irq) from [] (__handle_domain_irq+0x54/0xa8) [] (__handle_domain_irq) from [] (__irq_svc+0x54/0x70) [] (__irq_svc) from [] (arch_cpu_idle+0x38/0x3c) [] (arch_cpu_idle) from [] (cpu_startup_entry+0x9c/0xdc) [] (cpu_startup_entry) from [] (start_kernel+0x354/0x360) [] (start_kernel) from [<20008078>] (0x20008078) ---[ end trace e7cf9dcebf4815a6 ]--- Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes") Reported-by: Richard Genoud Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 420d1689442585f5a25ac1250c0e11a07ecd5cf9 Author: Alexander Usyskin Date: Wed Oct 19 01:34:48 2016 +0300 mei: txe: don't clean an unprocessed interrupt cause. commit 43605e293eb13c07acb546c14f407a271837af17 upstream. SEC registers are not accessible when the TXE device is in low power state, hence the SEC interrupt cannot be processed if device is not awake. In some rare cases entrance to low power state (aliveness off) and input ready bits can be signaled at the same time, resulting in communication stall as input ready won't be signaled again after waking up. To resolve this IPC_HHIER_SEC bit in HHISR_REG should not be cleaned if the interrupt is not processed. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 5d30e8f65073cc93e00778e50633fbb58f8e151e Author: Richard Weinberger Date: Fri Oct 28 11:49:03 2016 +0200 ubifs: Fix regression in ubifs_readdir() commit a00052a296e54205cf238c75bd98d17d5d02a6db upstream. Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke overlayfs support because the fix exposed an internal error code to VFS. Reported-by: Peter Rosin Tested-by: Peter Rosin Reported-by: Ralph Sennhauser Tested-by: Ralph Sennhauser Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b8176cc56bf1ddabd0ecc48119541b326b131992 Author: Richard Weinberger Date: Wed Oct 19 12:43:07 2016 +0200 ubifs: Abort readdir upon error commit c83ed4c9dbb358b9e7707486e167e940d48bfeed upstream. If UBIFS is facing an error while walking a directory, it reports this error and ubifs_readdir() returns the error code. But the VFS readdir logic does not make the getdents system call fail in all cases. When the readdir cursor indicates that more entries are present, the system call will just return and the libc wrapper will try again since it also knows that more entries are present. This causes the libc wrapper to busy loop for ever when a directory is corrupted on UBIFS. A common approach do deal with corrupted directory entries is skipping them by setting the cursor to the next entry. On UBIFS this approach is not possible since we cannot compute the next directory entry cursor position without reading the current entry. So all we can do is setting the cursor to the "no more entries" position and make getdents exit. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 1755f43e9a90e8331470571a7d98c5c2888f3024 Author: Thomas Gleixner Date: Mon Oct 24 11:55:10 2016 +0200 timers: Lock base for same bucket optimization commit 4da9152a4308dcbf611cde399c695c359fc9145f upstream. Linus stumbled over the unlocked modification of the timer expiry value in mod_timer() which is an optimization for timers which stay in the same bucket - due to the bucket granularity - despite their expiry time getting updated. The optimization itself still makes sense even if we take the lock, because in case that the bucket stays the same, we avoid the pointless queue/enqueue dance. Make the check and the modification of timer->expires protected by the base lock and shuffle the remaining code around so we can keep the lock held when we actually have to requeue the timer to a different bucket. Fixes: f00c0afdfa62 ("timers: Implement optimization for same expiry time in mod_timer()") Reported-by: Linus Torvalds Signed-off-by: Thomas Gleixner Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos Cc: Andrew Morton Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit e18ed431d7daa3c872b30e15044f02460b94a72d Author: Thomas Gleixner Date: Mon Oct 24 11:41:56 2016 +0200 timers: Plug locking race vs. timer migration commit b831275a3553c32091222ac619cfddd73a5553fb upstream. Linus noticed that lock_timer_base() lacks a READ_ONCE() for accessing the timer flags. As a consequence the compiler is allowed to reload the flags between the initial check for TIMER_MIGRATION and the following timer base computation and the spin lock of the base. While this has not been observed (yet), we need to make sure that it never happens. Fixes: 0eeda71bc30d ("timer: Replace timer base by a cpu index") Reported-by: Linus Torvalds Signed-off-by: Thomas Gleixner Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos Cc: Andrew Morton Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit b5e3a038997a4b5b209c0197c373d2e56e6ae673 Author: Thomas Gleixner Date: Sat Oct 22 11:07:37 2016 +0000 timers: Prevent base clock corruption when forwarding commit 6bad6bccf2d717f652d37e63cf261eaa23466009 upstream. When a timer is enqueued we try to forward the timer base clock. This mechanism has two issues: 1) Forwarding a remote base unlocked The forwarding function is called from get_target_base() with the current timer base lock held. But if the new target base is a different base than the current base (can happen with NOHZ, sigh!) then the forwarding is done on an unlocked base. This can lead to corruption of base->clk. Solution is simple: Invoke the forwarding after the target base is locked. 2) Possible corruption due to jiffies advancing This is similar to the issue in get_net_timer_interrupt() which was fixed in the previous patch. jiffies can advance between check and assignement and therefore advancing base->clk beyond the next expiry value. So we need to read jiffies into a local variable once and do the checks and assignment with the local copy. Fixes: a683f390b93f("timers: Forward the wheel clock whenever possible") Reported-by: Ashton Holmes Reported-by: Michael Thayer Signed-off-by: Thomas Gleixner Cc: Michal Necasek Cc: Peter Zijlstra Cc: knut.osmundsen@oracle.com Cc: stern@rowland.harvard.edu Cc: rt@linutronix.de Link: http://lkml.kernel.org/r/20161022110552.253640125@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 665f7bf33aa87733b40221dafb3551de51d34121 Author: Thomas Gleixner Date: Sat Oct 22 11:07:35 2016 +0000 timers: Prevent base clock rewind when forwarding clock commit 041ad7bc758db259bb960ef795197dd14aab19a6 upstream. Ashton and Michael reported, that kernel versions 4.8 and later suffer from USB timeouts which are caused by the timer wheel rework. This is caused by a bug in the base clock forwarding mechanism, which leads to timers expiring early. The scenario which leads to this is: run_timers() while (jiffies >= base->clk) { collect_expired_timers(); base->clk++; expire_timers(); } So base->clk = jiffies + 1. Now the cpu goes idle: idle() get_next_timer_interrupt() nextevt = __next_time_interrupt(); if (time_after(nextevt, base->clk)) base->clk = jiffies; jiffies has not advanced since run_timers(), so this assignment effectively decrements base->clk by one. base->clk is the index into the timer wheel arrays. So let's assume the following state after the base->clk increment in run_timers(): jiffies = 0 base->clk = 1 A timer gets enqueued with an expiry delta of 63 ticks (which is the case with the USB timeout and HZ=250) so the resulting bucket index is: base->clk + delta = 1 + 63 = 64 The timer goes into the first wheel level. The array size is 64 so it ends up in bucket 0, which is correct as it takes 63 ticks to advance base->clk to index into bucket 0 again. If the cpu goes idle before jiffies advance, then the bug in the forwarding mechanism sets base->clk back to 0, so the next invocation of run_timers() at the next tick will index into bucket 0 and therefore expire the timer 62 ticks too early. Instead of blindly setting base->clk to jiffies we must make the forwarding conditional on jiffies > base->clk, but we cannot use jiffies for this as we might run into the following issue: if (time_after(jiffies, base->clk) { if (time_after(nextevt, base->clk)) base->clk = jiffies; jiffies can increment between the check and the assigment far enough to advance beyond nextevt. So we need to use a stable value for checking. get_next_timer_interrupt() has the basej argument which is the jiffies value snapshot taken in the calling code. So we can just that. Thanks to Ashton for bisecting and providing trace data! Fixes: a683f390b93f ("timers: Forward the wheel clock whenever possible") Reported-by: Ashton Holmes Reported-by: Michael Thayer Signed-off-by: Thomas Gleixner Cc: Michal Necasek Cc: Peter Zijlstra Cc: knut.osmundsen@oracle.com Cc: stern@rowland.harvard.edu Cc: rt@linutronix.de Link: http://lkml.kernel.org/r/20161022110552.175308322@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 0d621c57e7392d0ba00be6c0040ecbba027bf123 Author: Borislav Petkov Date: Thu Oct 27 14:36:23 2016 +0200 x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y commit 1c27f646b18fb56308dff82784ca61951bad0b48 upstream. We needed the physical address of the container in order to compute the offset within the relocated ramdisk. And we did this by doing __pa() on the virtual address. However, __pa() does checks whether the physical address is within PAGE_OFFSET and __START_KERNEL_map - see __phys_addr() - which fail if we have CONFIG_RANDOMIZE_MEMORY enabled: we feed a virtual address which *doesn't* have the randomization offset into a function which uses PAGE_OFFSET which *does* have that offset. This makes this check fire: VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x)); ^^^^^^ due to the randomization offset. The fix is as simple as using __pa_nodebug() because we do that randomization offset accounting later in that function ourselves. Reported-by: Bob Peterson Tested-by: Bob Peterson Signed-off-by: Borislav Petkov Cc: Andreas Gruenbacher Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Steven Whitehouse Cc: Thomas Gleixner Cc: linux-mm Link: http://lkml.kernel.org/r/20161027123623.j2jri5bandimboff@pd.tnic Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e599203f55ad13cdfee157529d513ae64e91a7d3 Author: Paul Mackerras Date: Fri Oct 21 20:04:17 2016 +1100 powerpc/64: Fix race condition in setting lock bit in idle/wakeup code commit 09b7e37b18eecc1e347f4b1a3bc863f32801f634 upstream. This fixes a race condition where one thread that is entering or leaving a power-saving state can inadvertently ignore the lock bit that was set by another thread, and potentially also clear it. The core_idle_lock_held function is called when the lock bit is seen to be set. It polls the lock bit until it is clear, then does a lwarx to load the word containing the lock bit and thread idle bits so it can be updated. However, it is possible that the value loaded with the lwarx has the lock bit set, even though an immediately preceding lwz loaded a value with the lock bit clear. If this happens then we go ahead and update the word despite the lock bit being set, and when called from pnv_enter_arch207_idle_mode, we will subsequently clear the lock bit. No identifiable misbehaviour has been attributed to this race. This fixes it by checking the lock bit in the value loaded by the lwarx. If it is set then we just go back and keep on polling. Fixes: b32aadc1a8ed ("powerpc/powernv: Fix race in updating core_idle_state") Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 51d784b54768ecfc056a51205acd1899a505fd79 Author: Paul Mackerras Date: Fri Oct 21 20:03:05 2016 +1100 powerpc/64: Re-fix race condition between going idle and entering guest commit 56c46222af0d09149fadec2a3ce9d4889de01cc6 upstream. Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one thread entering a KVM guest could switch the MMU context to the guest while another thread was still in host kernel context with the MMU on. That commit moved the point where a thread entering a power-saving mode set its kvm_hstate.hwthread_state field in its PACA to KVM_HWTHREAD_IN_IDLE from a point where the MMU was on to after the MMU had been switched off. That commit also added a comment explaining that we have to switch to real mode before setting hwthread_state to avoid this race. Nevertheless, commit 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic", 2016-07-08) subsequently moved the setting of hwthread_state back to a point where the MMU is on, thus reintroducing the race, despite the comment saying that this should not be done being included in full in the context lines of the patch that did it. This fixes the race again and adds a bigger and shoutier comment explaining the potential race condition. Fixes: 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic") Signed-off-by: Paul Mackerras Reviewed-by: Shreyas B. Prabhu Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 2c7ff0e5c31124b77cc44d93906cc95332b081db Author: Aneesh Kumar K.V Date: Mon Oct 24 08:50:43 2016 +0530 powerpc/mm/radix: Use tlbiel only if we ever ran on the current cpu commit bd77c4498616e27d5725b5959d880ce2272fefa9 upstream. Before this patch, we used tlbiel, if we ever ran only on this core. That was mostly derived from the nohash usage of the same. But is incorrect, the ISA 3.0 clarifies tlbiel such that: "All TLB entries that have all of the following properties are made invalid on the thread executing the tlbiel instruction" ie. tlbiel only invalidates TLB entries on the current thread. So if the mm has been used on any other thread (aka. cpu) then we must broadcast the invalidate. This bug could lead to invalid TLB entries if a program runs on multiple threads of a core. Hence use tlbiel, if we only ever ran on only the current cpu. Fixes: 1a472c9dba6b ("powerpc/mm/radix: Add tlbflush routines") Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ae150de2d5e001d9f70cbed122f7328aa712c3f9 Author: Segher Boessenkool Date: Thu Oct 6 13:42:19 2016 +0000 powerpc: Convert cmp to cmpd in idle enter sequence commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream. PowerPC's "cmp" instruction has four operands. Normally people write "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently people forget, and write "cmp" with just three operands. With older binutils this is silently accepted as if this was "cmpw", while often "cmpd" is wanted. With newer binutils GAS will complain about this for 64-bit code. For 32-bit code it still silently assumes "cmpw" is what is meant. In this instance the code comes directly from ISA v2.07, including the cmp, but cmpd is correct. Backport to stable so that new toolchains can build old kernels. Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode") Reviewed-by: Vaidyanathan Srinivasan Signed-off-by: Segher Boessenkool Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1198fbca645e0c38f2e75bc6771b0458bda8ae59 Author: Chris Mason Date: Thu Oct 27 10:42:20 2016 -0700 btrfs: fix races on root_log_ctx lists commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b upstream. btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the list because it knows all of the waiters are patiently waiting for the commit to finish. But, there's a small race where btrfs_sync_log can remove itself from the list if it finds a log commit is already done. Also, it uses list_del_init() to remove itself from the list, but there's no way to know if btrfs_remove_all_log_ctxs has already run, so we don't know for sure if it is safe to call list_del_init(). This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and just calls it with the proper locking. This is part two of the corruption fixed by cbd60aa7cd1. I should have done this in the first place, but convinced myself the optimizations were safe. A 12 hour run of dbench 2048 will eventually trigger a list debug WARN_ON for the list_del_init() in btrfs_sync_log(). Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4 Reported-by: Dave Jones Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit bc720ae2ffab17fa7ff829df84459babadde457d Author: Vaibhav Jain Date: Fri Oct 21 14:53:53 2016 +0530 cxl: Fix leaking pid refs in some error paths commit a05b82d5149dfeef05254a11c3636a89a854520a upstream. In some error paths in functions cxl_start_context and afu_ioctl_start_work pid references to the current & group-leader tasks can leak after they are taken. This patch fixes these error paths to release these pid references before exiting the error path. Fixes: 7b8ad495d592 ("cxl: Fix DSI misses when the context owning task exits") Reviewed-by: Andrew Donnellan Reported-by: Frederic Barrat Signed-off-by: Vaibhav Jain Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 2a997e83960b67ff542f572591c7664847e38fce Author: Arve Hjønnevåg Date: Mon Oct 24 15:20:30 2016 +0200 ANDROID: binder: Clear binder and cookie when setting handle in flat binder struct commit 4afb604e2d14d429ac9e1fd84b952602853b2df5 upstream. Prevents leaking pointers between processes Signed-off-by: Arve Hjønnevåg Signed-off-by: Martijn Coenen Signed-off-by: Greg Kroah-Hartman commit 599cfd58ffde37a044db09deeb371a4863333dc7 Author: Arve Hjønnevåg Date: Mon Oct 24 15:20:29 2016 +0200 ANDROID: binder: Add strong ref checks commit 0a3ffab93fe52530602fe47cd74802cffdb19c05 upstream. Prevent using a binder_ref with only weak references where a strong reference is required. Signed-off-by: Arve Hjønnevåg Signed-off-by: Martijn Coenen Signed-off-by: Greg Kroah-Hartman commit 2a0efa30b15c51d5841a9bbc1b08b16a9abce16d Author: Hui Wang Date: Thu Oct 20 14:03:33 2016 +0800 ALSA: hda - Fix headset mic detection problem for two Dell laptops commit 6aecd8715802d23dc6a0859b50c62d2b0a99de3a upstream. They uses the codec ALC255, and have the different pin cfg definition from the ones in the existing pin quirk table. Now adding them into the table to fix the problem. Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2585e17b71c76e974659900d3a4a597e54ebf5bc Author: Takashi Iwai Date: Thu Oct 20 12:14:51 2016 +0200 ALSA: hda - Fix surround output pins for ASRock B150M mobo commit 1a3f099101b85cc93d864eb030d97e7725c72ea7 upstream. ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide proper pins for the surround outputs, hence we need to specify the pincfgs manually with a couple of other corrections. Reported-and-tested-by: Benjamin Valentin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 14456570a4a5245d58f422bd8f202e1a5616086d Author: Hui Wang Date: Tue Oct 18 10:59:09 2016 +0800 ALSA: hda - Adding a new group of pin cfg into ALC295 pin quirk table commit f771d5bb71d4df9573d12386400540516672208b upstream. We have a new Dell laptop model which uses ALC295, the pin definition is different from the existing ones in the pin quirk table, to fix the headset mic detection and mic mute led's problem, we need to add the new pin defintion into the pin quirk table. Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 54186c7dd2eca004e1bd08cc0fe42c6f4a3fc892 Author: Ard Biesheuvel Date: Mon Oct 17 17:23:59 2016 +0100 ALSA: hda - allow 40 bit DMA mask for NVidia devices commit 3ab7511eafdd5c4f40d2832f09554478dfbea170 upstream. Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits for Nvidia audio controllers") simply disabled any DMA exceeding 32 bits for NVidia devices, even though they are capable of performing DMA up to 40 bits. On some architectures (such as arm64), system memory is not guaranteed to be 32-bit addressable by PCI devices, and so this change prevents NVidia devices from working on platforms such as AMD Seattle. Since the original commit already mentioned that up to 40 bits of DMA is supported, and given that the code has been updated in the meantime to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf and explicitly set the DMA mask to 40 bits for NVidia devices. Fixes: 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...') Signed-off-by: Ard Biesheuvel Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0f574c90d7476474d6b4e1d032e75cdf6c722fb3 Author: Takashi Iwai Date: Tue Oct 25 15:56:35 2016 +0200 ALSA: seq: Fix time account regression commit 9b50898ad96c793a8f7cde9d8f281596d752a7dd upstream. The recent rewrite of the sequencer time accounting using timespec64 in the commit [3915bf294652: ALSA: seq_timer: use monotonic times internally] introduced a bad regression. Namely, the time reported back doesn't increase but goes back and forth. The culprit was obvious: the delta is stored to the result (cur_time = delta), instead of adding the delta (cur_time += delta)! Let's fix it. Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally') Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571 Reported-by: Yves Guillemot Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ccf154b2654867cafc6fbe3a049cecdc29ac972 Author: Marcel Hasler Date: Thu Oct 27 00:42:27 2016 +0200 ALSA: usb-audio: Add quirk for Syntek STK1160 commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream. The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves the issue reported on the mailing list (http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071). Signed-off-by: Marcel Hasler Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d3f5b85ef8b1ace2499d15f799609d5f7819a14 Author: Dan Williams Date: Thu Oct 27 17:04:05 2016 -0700 device-dax: fix percpu_ref_exit ordering commit 52e73eb2872c9af6f382b2b22954ca8214397a4e upstream. We need to wait until the percpu_ref is released before exit. Otherwise, we sometimes lose the race and trigger this new warning that was added in v4.9 (commit a67823c1ed10 "percpu-refcount: init ->confirm_switch member properly"): WARNING: CPU: 0 PID: 3629 at lib/percpu-refcount.c:107 percpu_ref_exit+0x51/0x60 [..] Call Trace: [] dump_stack+0x85/0xc2 [] __warn+0xcb/0xf0 [] warn_slowpath_null+0x1d/0x20 [] percpu_ref_exit+0x51/0x60 [] dax_pmem_percpu_exit+0x1a/0x50 [dax_pmem] [] devm_action_release+0xf/0x20 Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory") Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 33bcff297228350cb908e165c8d3031a6c52dde8 Author: Artem Savkov Date: Wed Oct 26 15:02:09 2016 +0100 security/keys: make BIG_KEYS dependent on stdrng. commit 31e6ec4519c0fe0ee4a2f6ba3ab278e9506b9500 upstream. Since BIG_KEYS can't be compiled as module it requires one of the "stdrng" providers to be compiled into kernel. Otherwise big_key_crypto_init() fails on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in big_key_preparse()) results in a NULL pointer dereference. Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted') Signed-off-by: Artem Savkov Signed-off-by: David Howells cc: Stephan Mueller cc: Kirill Marinushkin Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 5152986c9257e797436688d09ebd582b9eadcd2d Author: David Howells Date: Wed Oct 26 15:02:01 2016 +0100 KEYS: Sort out big_key initialisation commit 7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb upstream. big_key has two separate initialisation functions, one that registers the key type and one that registers the crypto. If the key type fails to register, there's no problem if the crypto registers successfully because there's no way to reach the crypto except through the key type. However, if the key type registers successfully but the crypto does not, big_key_rng and big_key_blkcipher may end up set to NULL - but the code neither checks for this nor unregisters the big key key type. Furthermore, since the key type is registered before the crypto, it is theoretically possible for the kernel to try adding a big_key before the crypto is set up, leading to the same effect. Fix this by merging big_key_crypto_init() and big_key_init() and calling the resulting function late. If they're going to be encrypted, we shouldn't be creating big_keys before we have the facilities to do the encryption available. The key type registration is also moved after the crypto initialisation. The fix also includes message printing on failure. If the big_key type isn't correctly set up, simply doing: dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s ought to cause an oops. Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted') Signed-off-by: David Howells cc: Peter Hlavaty cc: Kirill Marinushkin cc: Artem Savkov Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 5daa841d04370f5234aab2a6b63702584c1be608 Author: David Howells Date: Wed Oct 26 15:01:54 2016 +0100 KEYS: Fix short sprintf buffer in /proc/keys show function commit 03dab869b7b239c4e013ec82aea22e181e441cfc upstream. This fixes CVE-2016-7042. Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector is turned on, this can cause a panic due to stack corruption. The problem is that xbuf[] is not big enough to hold a 64-bit timeout rendered as weeks: (gdb) p 0xffffffffffffffffULL/(60*60*24*7) $2 = 30500568904943 That's 14 chars plus NUL, not 11 chars plus NUL. Expand the buffer to 16 chars. I think the unpatched code apparently works if the stack-protector is not enabled because on a 32-bit machine the buffer won't be overflowed and on a 64-bit machine there's a 64-bit aligned pointer at one side and an int that isn't checked again on the other side. The panic incurred looks something like: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6 ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679 Call Trace: [] dump_stack+0x63/0x84 [] panic+0xde/0x22a [] ? proc_keys_show+0x3ce/0x3d0 [] __stack_chk_fail+0x19/0x30 [] proc_keys_show+0x3ce/0x3d0 [] ? key_validate+0x50/0x50 [] ? key_default_cmp+0x20/0x20 [] seq_read+0x2cc/0x390 [] proc_reg_read+0x42/0x70 [] __vfs_read+0x37/0x150 [] ? security_file_permission+0xa0/0xc0 [] vfs_read+0x96/0x130 [] SyS_read+0x55/0xc0 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 Reported-by: Ondrej Kozina Signed-off-by: David Howells Tested-by: Ondrej Kozina Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 0a38e6c551c471c1cd385721478743513ba8a899 Author: Eric Ernst Date: Thu Oct 6 08:56:49 2016 -0700 thermal/powerclamp: correct cpu support check commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 upstream. Initial logic for checking CPU match resulted in OR of CPU features rather than the intended AND. Updated to use boot_cpu_has macro rather than x86_match_cpu. In addition, MWAIT is the only required CPU feature for idle injection to work. Drop other feature requirements since they are only needed for optimal efficiency. Signed-off-by: Eric Ernst Acked-by: Jacob Pan Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit 5db5e0c11c139a3cd168cb0fb5c6191f803c4f0f Author: Johannes Weiner Date: Thu Oct 27 17:46:56 2016 -0700 mm: memcontrol: do not recurse in direct reclaim commit 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 upstream. On 4.0, we saw a stack corruption from a page fault entering direct memory cgroup reclaim, calling into btrfs_releasepage(), which then tried to allocate an extent and recursed back into a kmem charge ad nauseam: [...] btrfs_releasepage+0x2c/0x30 try_to_release_page+0x32/0x50 shrink_page_list+0x6da/0x7a0 shrink_inactive_list+0x1e5/0x510 shrink_lruvec+0x605/0x7f0 shrink_zone+0xee/0x320 do_try_to_free_pages+0x174/0x440 try_to_free_mem_cgroup_pages+0xa7/0x130 try_charge+0x17b/0x830 memcg_charge_kmem+0x40/0x80 new_slab+0x2d9/0x5a0 __slab_alloc+0x2fd/0x44f kmem_cache_alloc+0x193/0x1e0 alloc_extent_state+0x21/0xc0 __clear_extent_bit+0x2b5/0x400 try_release_extent_mapping+0x1a3/0x220 __btrfs_releasepage+0x31/0x70 btrfs_releasepage+0x2c/0x30 try_to_release_page+0x32/0x50 shrink_page_list+0x6da/0x7a0 shrink_inactive_list+0x1e5/0x510 shrink_lruvec+0x605/0x7f0 shrink_zone+0xee/0x320 do_try_to_free_pages+0x174/0x440 try_to_free_mem_cgroup_pages+0xa7/0x130 try_charge+0x17b/0x830 mem_cgroup_try_charge+0x65/0x1c0 handle_mm_fault+0x117f/0x1510 __do_page_fault+0x177/0x420 do_page_fault+0xc/0x10 page_fault+0x22/0x30 On later kernels, kmem charging is opt-in rather than opt-out, and that particular kmem allocation in btrfs_releasepage() is no longer being charged and won't recurse and overrun the stack anymore. But it's not impossible for an accounted allocation to happen from the memcg direct reclaim context, and we needed to reproduce this crash many times before we even got a useful stack trace out of it. Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC to avoid recursing into any other form of direct reclaim. Then let recursive charges from PF_MEMALLOC contexts bypass the cgroup limit. Link: http://lkml.kernel.org/r/20161025141050.GA13019@cmpxchg.org Signed-off-by: Johannes Weiner Acked-by: Michal Hocko Cc: Vladimir Davydov Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 68adb469dd3b28513c5b548df3437f2bc1a83e43 Author: Joonsoo Kim Date: Thu Oct 27 17:46:18 2016 -0700 mm/slab: fix kmemcg cache creation delayed issue commit 86d9f48534e800e4d62cdc1b5aaf539f4c1d47d6 upstream. There is a bug report that SLAB makes extreme load average due to over 2000 kworker thread. https://bugzilla.kernel.org/show_bug.cgi?id=172981 This issue is caused by kmemcg feature that try to create new set of kmem_caches for each memcg. Recently, kmem_cache creation is slowed by synchronize_sched() and futher kmem_cache creation is also delayed since kmem_cache creation is synchronized by a global slab_mutex lock. So, the number of kworker that try to create kmem_cache increases quietly. synchronize_sched() is for lockless access to node's shared array but it's not needed when a new kmem_cache is created. So, this patch rules out that case. Fixes: 801faf0db894 ("mm/slab: lockless decision to grow cache") Link: http://lkml.kernel.org/r/1475734855-4837-1-git-send-email-iamjoonsoo.kim@lge.com Reported-by: Doug Smythies Tested-by: Doug Smythies Signed-off-by: Joonsoo Kim Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67ae004e2c52637101b8479e7b2d2496c674e7ca Author: Alexander Polakov Date: Thu Oct 27 17:46:27 2016 -0700 mm/list_lru.c: avoid error-path NULL pointer deref commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 upstream. As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821: After some analysis it seems to be that the problem is in alloc_super(). In case list_lru_init_memcg() fails it goes into destroy_super(), which calls list_lru_destroy(). And in list_lru_init() we see that in case memcg_init_list_lru() fails, lru->node is freed, but not set NULL, which then leads list_lru_destroy() to believe it is initialized and call memcg_destroy_list_lru(). memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus, which is NULL. [akpm@linux-foundation.org: add comment] Signed-off-by: Alexander Polakov Acked-by: Vladimir Davydov Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5cb73199ca48749e99d4570caaaa9c4556bc9336 Author: Darrick J. Wong Date: Thu Oct 20 15:46:18 2016 +1100 libxfs: clean up _calc_dquots_per_chunk commit 58d789678546d46d7bbd809dd7dab417c0f23655 upstream. The function xfs_calc_dquots_per_chunk takes a parameter in units of basic blocks. The kernel seems to get the units wrong, but userspace got 'fixed' by commenting out the unnecessary conversion. Fix both. Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit d00057ecf82f8255d714bd1f8820016553bbddba Author: Lars-Peter Clausen Date: Mon Oct 24 13:59:15 2016 +0200 gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak commit 953b956a2e6d35298e684f251bad98ea6c96f982 upstream. When allocating a new line handle or event a file is allocated that it is associated to. The file is attached to a file descriptor of the current process and the file descriptor is returned to userspace using copy_to_user(). If this copy operation fails the line handle or event allocation is aborted, all acquired resources are freed and an error is returned. But the file struct is not freed and left attached to the userspace application and even though the file descriptor number was not copied it is trivial to guess. If a userspace application performs a IOCTL on such a left over file descriptor it will trigger a use-after-free and if the file descriptor is closed (latest when the application exits) a double-free is triggered. anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a file descriptor for the current process and install the file struct in the file descriptor. As soon as the file struct is installed in the file descriptor it is accessible by userspace (even if the IOCTL itself hasn't completed yet), this means uninstalling the fd on the error path is not an option, since userspace might already got a reference to the file. Instead anon_inode_getfd() needs to be broken into its individual steps. The allocation of the file struct and file descriptor is done first, then the copy_to_user() is executed and only if it succeeds the file is installed. Since the file struct is reference counted it can not be just freed, but its reference needs to be dropped, which will also call the release() callback, which will free the state attached to the file. So in this case the normal error cleanup path should not be taken. Fixes: d932cd49182f ("gpio: free handles in fringe cases") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit c70eb2cc1276828a6e05849cca2b446377f47638 Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:04 2016 +0200 gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix another information leak commit d82aa4a8f2e8df9673ddb099262355da4c9b99b1 upstream. The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data struct on the stack and then passes it to copy_to_user(). But only the first element of the values array in the struct is set, which leaves the struct partially initialized. This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized. Cc: stable@vger.kernel.org Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6bba4b226521eb5a43198895d42e21440dd63d0a Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:06 2016 +0200 gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags commit ac7dbb991ee5afc0beacce3a252dcaaa249a7786 upstream. The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined linehandle and lineevent flags. From a backwards and forwards compatibility viewpoint it is highly desirable to reject unknown flags though. On one hand an application that is using newer flags and is running on an older kernel has no way to detect if the new flags were handled correctly if they are silently discarded. On the other hand an application that (accidentally) passes undefined flags will run fine on an older kernel, but may break on a newer kernel when these flags get defined. Ensure that requests that have undefined flags set are rejected with an error, rather than silently discarding the undefined flags. Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit e2144827d96b11363a0934ef294178ee88f1dc78 Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:05 2016 +0200 gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags commit e3e847c7f15a27c80f526b2a7a8d4dd7ce0960a0 upstream. The GPIO_GET_LINEHANDLE_IOCTL currently ignores unknown or undefined linehandle flags. From a backwards and forwards compatibility viewpoint it is highly desirable to reject unknown flags though. On one hand an application that is using newer flags and is running on an older kernel has no way to detect if the new flags were handled correctly if they are silently discarded. On the other hand an application that (accidentally) passes undefined flags will run fine on an older kernel, but may break on a newer kernel when these flags get defined. Ensure that requests that have undefined flags set are rejected with an error, rather than silently discarding the undefined flags. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit c0699405b1477bc4edc7f169c97c0d981fd09255 Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:03 2016 +0200 gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset commit b8b0e3d303654b3bb7b31b0266c513fd6f4132ce upstream. The line offset that is used as an index into the descs array is provided by userspace and might go beyond the bounds of the array. If that happens undefined behavior will occur. Make sure that the offset is within the bounds of the desc array and reject any requests that specify a value outside of it. Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 49bdfb21e37d786e0426d00665c9db9a926cce24 Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:02 2016 +0200 gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak commit 3eded5d83bf4e36ad78775c7ceb44a45480b0abd upstream. The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data struct on the stack and then passes it to copy_to_user(). But depending on the number of requested line handles the struct is only partially initialized. This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit e22edf53b40fabd70ed61d4c1d1f6dc4cfdbb8ef Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:01 2016 +0200 gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream. The line offset that is used as an index into the descs array is provided by userspace and might go beyond the bounds of the array. If that happens undefined behavior will occur. Make sure that the offset is within the bounds of the desc array and reject any requests that specify a value outside of it. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a23a59c56a53db7339e89b0b8b10edf79d1d0865 Author: Lars-Peter Clausen Date: Tue Oct 18 16:54:00 2016 +0200 gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak commit 0f4bbb233743bdfd51d47688b0bc2561f310488b upstream. The GPIO_GET_CHIPINFO_IOCTL handler allocates a gpiochip_info struct on the stack and then passes it to copy_to_user(). But depending on the length of the GPIO chip name and label the struct is only partially initialized. This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized. Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 78ae767553e435d5c3d71521b39d52e3a2e226b1 Author: Lars-Peter Clausen Date: Tue Oct 18 16:53:59 2016 +0200 gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation commit 1f1cc4566bd9dd8d3cf19965a4b6392143618536 upstream. The current line offset validation is off by one. Depending on the data stored behind the descs array this can either cause undefined behavior or disclose arbitrary, potentially sensitive, memory to the issuing userspace application. Make sure that offset is within the bounds of the desc array. Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Signed-off-by: Lars-Peter Clausen Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 56ffab4f532ef9faf05d32d50018b851f3e8fc70 Author: David Arcari Date: Wed Oct 12 18:40:30 2016 +0200 gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get() commit 67bf5156edc4f58241fd7c119ae145c552adddd6 upstream. acpi_dev_gpio_irq_get() currently ignores the error returned by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. Problem is this error can be -EPROBE_DEFER, which just blows up some drivers when the module ordering is not correct. Signed-off-by: David Arcari Signed-off-by: Benjamin Tissoires Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 4366246129cad935dde526023d262d76f2de4868 Author: Mark Rutland Date: Thu Oct 27 17:46:24 2016 -0700 h8300: fix syscall restarting commit 21753583056d48a5fad964d6f272e28168426845 upstream. Back in commit f56141e3e2d9 ("all arches, signal: move restart_block to struct task_struct"), all architectures and core code were changed to use task_struct::restart_block. However, when h8300 support was subsequently restored in v4.2, it was not updated to account for this, and maintains thread_info::restart_block, which is not kept in sync. This patch drops the redundant restart_block from thread_info, and moves h8300 to the common one in task_struct, ensuring that syscall restarting always works as expected. Fixes: f56141e3e2d9 ("all arches, signal: move restart_block to struct task_struct") Link: http://lkml.kernel.org/r/1476714934-11635-1-git-send-email-mark.rutland@arm.com Signed-off-by: Mark Rutland Cc: Andy Lutomirski Cc: Yoshinori Sato Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a639266ae0c343467eafe7f1467d79dd9157b2e7 Author: Ralf Ramsauer Date: Mon Oct 17 15:59:56 2016 +0200 spi: mark device nodes only in case of successful instantiation commit e0af98a7e025a7263ae7e50264f6f79ed29642a7 upstream. Instantiated SPI device nodes are marked with OF_POPULATE. This was introduced in bd6c164. On unloading, loaded device nodes will of course be unmarked. The problem are nodes that fail during initialisation: If a node fails, it won't be unloaded and hence not be unmarked. If a SPI driver module is unloaded and reloaded, it will skip nodes that failed before. Skip device nodes that are already populated and mark them only in case of success. Note that the same issue exists for I2C. Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE") Signed-off-by: Ralf Ramsauer Reviewed-by: Geert Uytterhoeven Acked-by: Pantelis Antoniou Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d6634d8711996c6bdb34a3235d1c4a3389529896 Author: Arnd Bergmann Date: Tue Oct 25 22:57:10 2016 +0200 spi: fsl-espi: avoid processing uninitalized data on error commit 5c0ba57744b1422d528f19430dd66d6803cea86f upstream. When we get a spurious interrupt in fsl_espi_irq, we end up processing four uninitalized bytes of data, as shown in this warning message: drivers/spi/spi-fsl-espi.c: In function 'fsl_espi_irq': drivers/spi/spi-fsl-espi.c:462:4: warning: 'rx_data' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds another check so we skip the data in this case. Fixes: 6319a68011b8 ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()") Signed-off-by: Arnd Bergmann Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0cee66b72accde1f9ad73ad5727d1bae6340a692 Author: Ville Syrjälä Date: Wed Oct 26 16:30:33 2016 +0300 drm/dp/mst: Clear port->pdt when tearing down the i2c adapter commit 36e3fa6a38e135e9478a2f75dec9bf6ff1e6480e upstream. The i2c adapter is only relevant for some peer device types, so let's clear the pdt if it's still the same as the old_pdt when we tear down the i2c adapter. I don't really like this design pattern of updating port->whatever before doing the accompanying changes and passing around old_whatever to figure stuff out. Would make much more sense to me to the pass the new value around and only update the port->whatever when things are consistent. But let's try to work with what we have right now. Quoting a follow-up from Ville: "And naturally I forgot to amend the commit message w.r.t. this guy [the change in drm_dp_destroy_port]. We don't really need to do this here, but I figured I'd try to be a bit more consistent by having it, just to avoid accidental mistakes if/when someone changes this stuff again later." v2: Clear port->pdt in the caller, if needed (Daniel) Cc: Daniel Vetter Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa Tested-by: Kirill A. Shutemov Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477488633-16544-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f2ffb21fb4959de3520b9e843e36cd3b5d17e707 Author: Vladimir Zapolskiy Date: Mon Oct 31 21:46:24 2016 +0200 i2c: core: fix NULL pointer dereference under race condition commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream. Race condition between registering an I2C device driver and deregistering an I2C adapter device which is assumed to manage that I2C device may lead to a NULL pointer dereference due to the uninitialized list head of driver clients. The root cause of the issue is that the I2C bus may know about the registered device driver and thus it is matched by bus_for_each_drv(), but the list of clients is not initialized and commonly it is NULL, because I2C device drivers define struct i2c_driver as static and clients field is expected to be initialized by I2C core: i2c_register_driver() i2c_del_adapter() driver_register() ... bus_add_driver() ... ... bus_for_each_drv(..., __process_removed_adapter) ... i2c_do_del_adapter() ... list_for_each_entry_safe(..., &driver->clients, ...) INIT_LIST_HEAD(&driver->clients); To solve the problem it is sufficient to do clients list head initialization before calling driver_register(). The problem was found while using an I2C device driver with a sluggish registration routine on a bus provided by a physically detachable I2C master controller, but practically the oops may be reproduced under the race between arbitraty I2C device driver registration and managing I2C bus device removal e.g. by unbinding the latter over sysfs: % echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind Unable to handle kernel NULL pointer dereference at virtual address 00000000 Internal error: Oops: 17 [#1] SMP ARM CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) task: e5ada400 task.stack: e4936000 PC is at i2c_do_del_adapter+0x20/0xcc LR is at __process_removed_adapter+0x14/0x1c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 35bd004a DAC: 00000051 Process sh (pid: 533, stack limit = 0xe4936210) Stack: (0xe4937d28 to 0xe4938000) Backtrace: [] (i2c_do_del_adapter) from [] (__process_removed_adapter+0x14/0x1c) [] (__process_removed_adapter) from [] (bus_for_each_drv+0x6c/0xa0) [] (bus_for_each_drv) from [] (i2c_del_adapter+0xbc/0x284) [] (i2c_del_adapter) from [] (i2c_imx_remove+0x44/0x164 [i2c_imx]) [] (i2c_imx_remove [i2c_imx]) from [] (platform_drv_remove+0x2c/0x44) [] (platform_drv_remove) from [] (__device_release_driver+0x90/0x12c) [] (__device_release_driver) from [] (device_release_driver+0x28/0x34) [] (device_release_driver) from [] (unbind_store+0x80/0x104) [] (unbind_store) from [] (drv_attr_store+0x28/0x34) [] (drv_attr_store) from [] (sysfs_kf_write+0x50/0x54) [] (sysfs_kf_write) from [] (kernfs_fop_write+0x100/0x214) [] (kernfs_fop_write) from [] (__vfs_write+0x34/0x120) [] (__vfs_write) from [] (vfs_write+0xa8/0x170) [] (vfs_write) from [] (SyS_write+0x4c/0xa8) [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c) Signed-off-by: Vladimir Zapolskiy Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 0fda1cdcbb726bd78cd38f4e323cd37ef63145b7 Author: Hoan Tran Date: Mon Oct 10 10:13:10 2016 -0700 i2c: xgene: Avoid dma_buffer overrun commit 603616017c35f4d0fbdbcace72adf9bf949c4a65 upstream. SMBus block command uses the first byte of buffer for the data length. The dma_buffer should be increased by 1 to avoid the overrun issue. Reported-by: Phil Endecott Signed-off-by: Hoan Tran Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 9c619c2a8d4d14c7e9fe741239b7b42f610f09d9 Author: David Wu Date: Sat Oct 22 16:43:42 2016 +0800 i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings commit 399c168ab5ab5e12ed55b6c91d61c24eb84c9164 upstream. We found a bug that i2c transfer sometimes failed on 3066a board with stabel-4.8, the con register would be updated by uninitialized tuning value, it made the i2c transfer failed. So give the tuning value to be zero during rk3x_i2c_v0_calc_timings. Signed-off-by: David Wu Tested-by: Andy Yan Reviewed-by: Douglas Anderson Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman