commit 3066314b22d7ab539ede4546ca62ae48facf7b15 Author: Greg Kroah-Hartman Date: Mon Jun 29 12:29:29 2015 -0700 Linux 4.0.7 commit 9b1853ef280cadfefaf44e616e3a80e639d7a2f0 Author: Sam Bobroff Date: Fri May 1 16:50:34 2015 +1000 powerpc/powernv: Restore non-volatile CRs after nap commit 0aab3747091db309b8a484cfd382a41644552aa3 upstream. Patches 7cba160ad "powernv/cpuidle: Redesign idle states management" and 77b54e9f2 "powernv/powerpc: Add winkle support for offline cpus" use non-volatile condition registers (cr2, cr3 and cr4) early in the system reset interrupt handler (system_reset_pSeries()) before it has been determined if state loss has occurred. If state loss has not occurred, control returns via the power7_wakeup_noloss() path which does not restore those condition registers, leaving them corrupted. Fix this by restoring the condition registers in the power7_wakeup_noloss() case. This is apparent when running a KVM guest on hardware that does not support winkle or sleep and the guest makes use of secondary threads. In practice this means Power7 machines, though some early unreleased Power8 machines may also be susceptible. The secondary CPUs are taken off line before the guest is started and they call pnv_smp_cpu_kill_self(). This checks support for sleep states (in this case there is no support) and power7_nap() is called. When the CPU is woken, power7_nap() returns and because the CPU is still off line, the main while loop executes again. The sleep states support test is executed again, but because the tested values cannot have changed, the compiler has optimized the test away and instead we rely on the result of the first test, which has been left in cr3 and/or cr4. With the result overwritten, the wrong branch is taken and power7_winkle() is called on a CPU that does not support it, leading to it stalling. Fixes: 7cba160ad789 ("powernv/cpuidle: Redesign idle states management") Fixes: 77b54e9f213f ("powernv/powerpc: Add winkle support for offline cpus") [mpe: Massage change log a bit more] Signed-off-by: Sam Bobroff Signed-off-by: Michael Ellerman Cc: Greg Kurz Signed-off-by: Greg Kroah-Hartman commit 44b23a7ca21a27d8d47d4e9d7e27e3450db1154c Author: Peter Antoine Date: Mon May 11 08:50:45 2015 +0100 drm/i915: Avoid GPU hang when coming out of s3 or s4 commit 364aece01a2dd748fc36a1e8bf52ef639b0857bd upstream. This patch fixes a timing issue that causes a GPU hang when the system comes out of power saving. During pm_resume, We are submitting batchbuffers before enabling Interrupts this is causing us to miss the context switch interrupt, and in consequence intel_execlists_handle_ctx_events is not triggered. This patch is based on a patch from Deepak S from another platform. The patch fixes an issue introduced by: commit e7778be1eab918274f79603d7c17b3ec8be77386 drm/i915: Fix startup failure in LRC mode after recent init changes The above patch added a call to init_context() to fix an issue introduced by a previous patch. But, it then opened up a small timing window for the batches being added by the init_context (basically setting up the context) to complete before the interrupts have been turned on, thus hanging the GPU. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89600 Cc: stable@vger.kernel.org # 4.0+ Signed-off-by: Peter Antoine Reviewed-by: Daniel Vetter [Jani: fixed typo in subject, massaged the comments a bit] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 5c0c800356dd545c8da3d6d16e4f06031c41ef21 Author: Junichi Nomura Date: Wed May 27 04:22:07 2015 +0000 dm: fix NULL pointer when clone_and_map_rq returns !DM_MAPIO_REMAPPED commit 3a1407559a593d4360af12dd2df5296bf8eb0d28 upstream. When stacking request-based DM on blk_mq device, request cloning and remapping are done in a single call to target's clone_and_map_rq(). The clone is allocated and valid only if clone_and_map_rq() returns DM_MAPIO_REMAPPED. The "IS_ERR(clone)" check in map_request() does not cover all the !DM_MAPIO_REMAPPED cases that are possible (E.g. if underlying devices are not ready or unavailable, clone_and_map_rq() may return DM_MAPIO_REQUEUE without ever having established an ERR_PTR). Fix this by explicitly checking for a return that is not DM_MAPIO_REMAPPED in map_request(). Without this fix, DM core may call setup_clone() for a NULL clone and oops like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000068 IP: [] blk_rq_prep_clone+0x7d/0x137 ... CPU: 2 PID: 5793 Comm: kdmwork-253:3 Not tainted 4.0.0-nm #1 ... Call Trace: [] map_tio_request+0xa9/0x258 [dm_mod] [] kthread_worker_fn+0xfd/0x150 [] ? kthread_parkme+0x24/0x24 [] ? kthread_parkme+0x24/0x24 [] kthread+0xe6/0xee [] ? put_lock_stats+0xe/0x20 [] ? __init_kthread_worker+0x5b/0x5b [] ret_from_fork+0x58/0x90 [] ? __init_kthread_worker+0x5b/0x5b Fixes: e5863d9ad ("dm: allocate requests in target when stacking on blk-mq devices") Reported-by: Bart Van Assche Signed-off-by: Jun'ichi Nomura Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 49864153b97410f025d90d27cf9a9f55fc13c70a Author: Eugene Shatokhin Date: Tue Mar 17 19:09:18 2015 +0900 kprobes/x86: Return correct length in __copy_instruction() commit c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd upstream. On x86-64, __copy_instruction() always returns 0 (error) if the instruction uses %rip-relative addressing. This is because kernel_insn_init() is called the second time for 'insn' instance in such cases and sets all its fields to 0. Because of this, trying to place a kprobe on such instruction will fail, register_kprobe() will return -EINVAL. This patch fixes the problem. Signed-off-by: Eugene Shatokhin Signed-off-by: Masami Hiramatsu Link: http://lkml.kernel.org/r/20150317100918.28349.94654.stgit@localhost.localdomain Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2db8cc63a99c402851a72e6ccabdec55409626a0 Author: Krzysztof Kozlowski Date: Wed Mar 11 11:13:57 2015 +0100 ARM: EXYNOS: Fix failed second suspend on Exynos4 commit 6f024978e74bda616b27183adee029b65eb27032 upstream. On Exynos4412 boards (Trats2, Odroid U3) after enabling L2 cache in 56b60b8bce4a ("ARM: 8265/1: dts: exynos4: Add nodes for L2 cache controller") the second suspend to RAM failed. First suspend worked fine but the next one hang just after powering down of secondary CPUs (system consumed energy as it would be running but was not responsive). The issue was caused by enabling delayed reset assertion for CPU0 just after issuing power down of cores. This was introduced for Exynos4 in 13cfa6c4f7fa ("ARM: EXYNOS: Fix CPU idle clock down after CPU off"). The whole behavior is not well documented but after checking with vendor code this should be done like this (on Exynos4): 1. Enable delayed reset assertion when system is running (for all CPUs). 2. Disable delayed reset assertion before suspending the system. This can be done after powering off secondary CPUs. 3. Re-enable the delayed reset assertion when system is resumed. Fixes: 13cfa6c4f7fa ("ARM: EXYNOS: Fix CPU idle clock down after CPU off") Signed-off-by: Krzysztof Kozlowski Tested-by: Bartlomiej Zolnierkiewicz Tested-by: Chanwoo Choi Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit 8390661f570a50c09bc5f33c2fa33cabed438d9e Author: Alexey Sokolov Date: Tue Jun 2 11:49:30 2015 +0300 cdc-acm: Add support of ATOL FPrint fiscal printers commit 15bf722e6f6c0b884521a0363204532e849deb7f upstream. ATOL FPrint fiscal printers require usb_clear_halt to be executed to work properly. Add quirk to fix the issue. Signed-off-by: Alexey Sokolov Signed-off-by: Greg Kroah-Hartman commit 82e6b9a0ef7ab8ea9ff487426face0735e3e2414 Author: Rafał Miłecki Date: Sat Jun 6 22:45:59 2015 +0200 b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset commit 90f91b129810c3f169e443252be30ed7c0130326 upstream. It seems Broadcom released two devices with conflicting device id. There are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they can be found in routers, e.g. Netgear WNR834Bv2. However, according to Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY). It's unsure if they meant PCI device id, or "virtual" id (from SPROM). To distinguish these devices lets check PHY type (G vs. N). Signed-off-by: Rafał Miłecki Cc: # 3.16+ Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit a12c5f3f2a3423d9c0bd6163a69749959cad06fb Author: Dmitry Tunin Date: Sat Jun 6 20:29:25 2015 +0300 ath3k: add support of 13d3:3474 AR3012 device commit 0d0cef6183aec0fb6d0c9f00a09ff51ee086bbe2 upstream. BugLink: https://bugs.launchpad.net/bugs/1427680 This device requires new firmware files AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to /lib/firmware/ar3k/ that are not included in linux-firmware yet. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3474 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit f3788d7d526bb7fba0ea82fe60f8e4761730c0bc Author: Dmitry Tunin Date: Sat Jun 6 20:25:40 2015 +0300 ath3k: Add support of 0489:e076 AR3012 device commit 692c062e7c282164fd7cda68077f79dafd176eaf upstream. BugLink: https://bugs.launchpad.net/bugs/1462614 This device requires new firmware files AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to /lib/firmware/ar3k/ that are not included in linux-firmware yet. T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e076 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit f956fddaefb8507a74844bc77b2bcfba07dcf857 Author: Michel Dänzer Date: Tue Jun 16 17:28:16 2015 +0900 drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query commit 3bc980bf19bb62007e923691fa2869ba113be895 upstream. This tells userspace that it's safe to use the RADEON_VA_UNMAP operation of the DRM_RADEON_GEM_VA ioctl. Signed-off-by: Michel Dänzer Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 93ac75d4caa54bb6dba196edff83fbb9c8eebdcb Author: Jani Nikula Date: Mon Jun 15 12:59:37 2015 +0300 Revert "drm/i915: Don't skip request retirement if the active list is empty" commit 245ec9d85696c3e539b23e210f248698b478379c upstream. This reverts commit 0aedb1626566efd72b369c01992ee7413c82a0c5. I messed things up while applying [1] to drm-intel-fixes. Rectify. [1] http://mid.gmane.org/1432827156-9605-1-git-send-email-ville.syrjala@linux.intel.com Fixes: 0aedb1626566 ("drm/i915: Don't skip request retirement if the active list is empty") Acked-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 944fdc1a225445be44d2b9145b9914c2a497fc79 Author: Chris Wilson Date: Thu Jun 11 08:06:08 2015 +0100 drm/i915: Always reset vma->ggtt_view.pages cache on unbinding commit 016a65a39170c3cdca09a6ac343ff4f124668b45 upstream. With the introduction of multiple views of an obj in the same vm, each vma was taught to cache its copy of the pages (so that different views could have different page arrangements). However, this missed decoupling those vma->ggtt_view.pages when the vma released its reference on the obj->pages. As we don't always free the vma, this leads to a possible scenario (e.g. execbuffer interrupted by the shrinker) where the vma points to a stale obj->pages, and explodes. Fixes regression from commit fe14d5f4e5468c5b80a24f1a64abcbe116143670 Author: Tvrtko Ursulin Date: Wed Dec 10 17:27:58 2014 +0000 drm/i915: Infrastructure for supporting different GGTT views per object Tvrtko says, if someone else will be confused how this can happen, key is the reservation execbuffer path. That puts the VMA on the exec_list which prevents i915_vma_unbind and i915_gem_vma_destroy from fully destroying the VMA. So the VMA is left existing as an empty object in the list - unbound and disassociated with the backing store. Kind of a cached memory object. And then re-using it needs to clear the cached pages pointer which is fixed above. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Daniel Vetter Cc: Michel Thierry Reviewed-by: Tvrtko Ursulin [Jani: Added Tvrtko's explanation to commit message.] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 2c94aabff872d175572af9f8b1003a7e53806e5a Author: Adam Jackson Date: Mon Jun 15 16:16:15 2015 -0400 drm/mgag200: Reject non-character-cell-aligned mode widths commit 25161084b1c1b0c29948f6f77266a35f302196b7 upstream. Turns out 1366x768 does not in fact work on this hardware. Signed-off-by: Adam Jackson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit ad57c140b86de638bc841a913fbbd87b4204abf2 Author: Sagi Grimberg Date: Thu Jun 4 19:49:21 2015 +0300 iser-target: Fix possible use-after-free commit 524630d5824c7a75aab568c6bd1423fd748cd3bb upstream. iser connection termination process happens in 2 stages: - isert_wait_conn: - resumes rdma disconnect - wait for session commands - wait for flush completions (post a marked wr to signal we are done) - wait for logout completion - queue work for connection cleanup (depends on disconnected/timewait events) - isert_free_conn - last reference put on the connection In case we are terminating during IOs, we might be posting send/recv requests after we posted the last work request which might lead to a use-after-free condition in isert_handle_wc. After we posted the last wr in isert_wait_conn we are guaranteed that no successful completions will follow (meaning no new work request posts may happen) but other flush errors might still come. So before we put the last reference on the connection, we repeat the process of posting a marked work request (isert_wait4flush) in order to make sure all pending completions were flushed. Signed-off-by: Sagi Grimberg Signed-off-by: Jenny Falkovich Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b4385f224870229f040ed5b1981c6b5e676b8a12 Author: Sagi Grimberg Date: Thu Jun 4 19:49:19 2015 +0300 iser-target: Fix variable-length response error completion commit 9253e667ab50fd4611a60e1cdd6a6e05a1d91cf1 upstream. Since commit "2426bd456a6 target: Report correct response ..." we might get a command with data_size that does not fit to the number of allocated data sg elements. Given that we rely on cmd t_data_nents which might be different than the data_size, we sometimes receive local length error completion. The correct approach would be to take the command data_size into account when constructing the ib sg_list. Signed-off-by: Sagi Grimberg Signed-off-by: Jenny Falkovich Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 402336fed45f72138b0d78d579e4097470e5ecc8 Author: Steven Rostedt Date: Mon Jun 15 17:50:25 2015 -0400 tracing: Have filter check for balanced ops commit 2cf30dc180cea808077f003c5116388183e54f9e upstream. When the following filter is used it causes a warning to trigger: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: No error ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990() Modules linked in: bnep lockd grace bluetooth ... CPU: 3 PID: 1223 Comm: bash Tainted: G W 4.1.0-rc3-test+ #450 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0 0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea Call Trace: [] dump_stack+0x4c/0x6e [] warn_slowpath_common+0x97/0xe0 [] ? _kstrtoull+0x2c/0x80 [] warn_slowpath_null+0x1a/0x20 [] replace_preds+0x3c5/0x990 [] create_filter+0x82/0xb0 [] apply_event_filter+0xd4/0x180 [] event_filter_write+0x8f/0x120 [] __vfs_write+0x28/0xe0 [] ? __sb_start_write+0x53/0xf0 [] ? security_file_permission+0x30/0xc0 [] vfs_write+0xb8/0x1b0 [] SyS_write+0x4f/0xb0 [] system_call_fastpath+0x12/0x6a ---[ end trace e11028bd95818dcd ]--- Worse yet, reading the error message (the filter again) it says that there was no error, when there clearly was. The issue is that the code that checks the input does not check for balanced ops. That is, having an op between a closed parenthesis and the next token. This would only cause a warning, and fail out before doing any real harm, but it should still not caues a warning, and the error reported should work: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: Meaningless filter expression And give no kernel warning. Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Reported-by: Vince Weaver Tested-by: Vince Weaver Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit da1e23975a1ae9361c9024fce7627ae1de8c5592 Author: Hui Wang Date: Mon Jun 15 17:43:39 2015 +0800 ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine commit 6ab42ff44864d26e8e498b8ac655d24ee389d267 upstream. On a HP Envy TouchSmart laptop, there are 2 speakers (main speaker and subwoofer speaker), 1 headphone and 2 DACs, without this fixup, the headphone will be assigned to a DAC and the 2 speakers will be assigned to another DAC, this assignment makes the surround-2.1 channels invalid. To fix it, here using a DAC/pin preference map to bind the main speaker to 1 DAC and the subwoofer speaker will be assigned to another DAC. Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 93db01c6c3c88e045181d14bb725d316f8967271 Author: Nicolas Ferre Date: Thu May 28 15:07:21 2015 +0200 clk: at91: fix h32mx prototype inclusion in pmc header commit 28df9c2fb6f896179fcffd5a3f5a86e2d1dff0a5 upstream. Trivial fix that prevents to compile this pmc clock driver if h32mx clock is present but smd clock isn't. Signed-off-by: Nicolas Ferre Signed-off-by: Boris Brezillon Acked-by: Alexandre Belloni Fixes: bcc5fd49a0fd ("clk: at91: add a driver for the h32mx clock") Signed-off-by: Greg Kroah-Hartman commit 425acc53f004527303496adec2c9c26b6e8932de Author: Boris Brezillon Date: Fri Mar 27 23:53:15 2015 +0100 clk: at91: pll: fix input range validity check commit 6c7b03e1aef2e92176435f4fa562cc483422d20f upstream. The PLL impose a certain input range to work correctly, but it appears that this input range does not apply on the input clock (or parent clock) but on the input clock after it has passed the PLL divisor. Fix the implementation accordingly. Signed-off-by: Boris Brezillon Reported-by: Jonas Andersson Signed-off-by: Greg Kroah-Hartman commit 229367940d16877ec300652fced3e577db2e5769 Author: Radim Krčmář Date: Fri Jun 5 20:57:41 2015 +0200 KVM: x86: fix lapic.timer_mode on restore commit b6ac069532218027f2991cba01d7a72a200688b0 upstream. lapic.timer_mode was not properly initialized after migration, which broke few useful things, like login, by making every sleep eternal. Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore. There are other slowpaths that update lvtt, so this patch makes sure something similar doesn't happen again by calling apic_update_lvtt after every modification. Fixes: f30ebc312ca9 ("KVM: x86: optimize some accesses to LVTT and SPIV") Signed-off-by: Radim Krčmář Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 646d04eb28d66e1be21ba3f4305750390a51e132 Author: Steve Cornelius Date: Mon Jun 15 16:52:59 2015 -0700 crypto: caam - fix RNG buffer cache alignment commit 412c98c1bef65fe7589f1300e93735d96130307c upstream. The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx) allocated in one DMA-tagged region. While the kernel's heap allocator should place the overall struct on a cacheline aligned boundary, the 2 buffers contained within may not necessarily align. Consenquently, the ends of unaligned buffers may not fully flush, and if so, stale data will be left behind, resulting in small repeating patterns. This fix aligns the buffers inside the struct. Note that not all of the data inside caam_rng_ctx necessarily needs to be DMA-tagged, only the buffers themselves require this. However, a fix would incur the expense of error-handling bloat in the case of allocation failure. Signed-off-by: Steve Cornelius Signed-off-by: Victoria Milhoan Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 47c3d197776a94c2e40948b85a4b9204d68e1e28 Author: Steve Cornelius Date: Mon Jun 15 16:52:56 2015 -0700 crypto: caam - improve initalization for context state saves commit 6fd4b15603124c1b56e03db29b41ec39d8a077b9 upstream. Multiple function in asynchronous hashing use a saved-state block, a.k.a. struct caam_hash_state, which holds a stash of information between requests (init/update/final). Certain values in this state block are loaded for processing using an inline-if, and when this is done, the potential for uninitialized data can pose conflicts. Therefore, this patch improves initialization of state data to prevent false assignments using uninitialized data in the state block. This patch addresses the following traceback, originating in ahash_final_ctx(), although a problem like this could certainly exhibit other symptoms: kernel BUG at arch/arm/mm/dma-mapping.c:465! Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = 80004000 [00000000] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT SMP Modules linked in: CPU: 0 Not tainted (3.0.15-01752-gdd441b9-dirty #40) PC is at __bug+0x1c/0x28 LR is at __bug+0x18/0x28 pc : [<80043240>] lr : [<8004323c>] psr: 60000013 sp : e423fd98 ip : 60000013 fp : 0000001c r10: e4191b84 r9 : 00000020 r8 : 00000009 r7 : 88005038 r6 : 00000001 r5 : 2d676572 r4 : e4191a60 r3 : 00000000 r2 : 00000001 r1 : 60000093 r0 : 00000033 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000015 Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0) Stack: (0xe423fd98 to 0xe4240000) fd80: 11807fd1 80048544 fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008 fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007 fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006 fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000 fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90 fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500 fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013 fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000 fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000 ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000 ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400 ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00 ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000 ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000 ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000 ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000 [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84) [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina) [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0) [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc) [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5) [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c) [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8) [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48) [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88) [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8) Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000) ---[ end trace d52a403a1d1eaa86 ]--- Signed-off-by: Steve Cornelius Signed-off-by: Victoria Milhoan Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman