commit d5441f9249748de6b13a018c63cfbba021edb9a8 Author: Greg Kroah-Hartman Date: Tue Apr 12 08:57:08 2016 -0700 Linux 4.5.1 commit 73d45efd1e8e6cd78ec5b2118989e5a78170b3b0 Author: Andi Kleen Date: Tue Mar 1 14:25:24 2016 -0800 perf/x86/intel: Fix PEBS data source interpretation on Nehalem/Westmere commit e17dc65328057c00db7e1bfea249c8771a78b30b upstream. Jiri reported some time ago that some entries in the PEBS data source table in perf do not agree with the SDM. We investigated and the bits changed for Sandy Bridge, but the SDM was not updated. perf already implements the bits correctly for Sandy Bridge and later. This patch patches it up for Nehalem and Westmere. Signed-off-by: Andi Kleen Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: jolsa@kernel.org Link: http://lkml.kernel.org/r/1456871124-15985-1-git-send-email-andi@firstfloor.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1b3b7e5eff950d6c408b7a55a0074538b3be48d0 Author: Jiri Olsa Date: Tue Mar 1 20:03:52 2016 +0100 perf/x86/intel: Use PAGE_SIZE for PEBS buffer size on Core2 commit e72daf3f4d764c47fb71c9bdc7f9c54a503825b1 upstream. Using PAGE_SIZE buffers makes the WRMSR to PERF_GLOBAL_CTRL in intel_pmu_enable_all() mysteriously hang on Core2. As a workaround, we don't do this. The hard lockup is easily triggered by running 'perf test attr' repeatedly. Most of the time it gets stuck on sample session with small periods. # perf test attr -vv 14: struct perf_event_attr setup : --- start --- ... 'PERF_TEST_ATTR=/tmp/tmpuEKz3B /usr/bin/perf record -o /tmp/tmpuEKz3B/perf.data -c 123 kill >/dev/null 2>&1' ret 1 Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Kan Liang Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: Wang Nan Link: http://lkml.kernel.org/r/20160301190352.GA8355@krava.redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ff8f5b41cf229554f19eb812194c45a14d6a04a5 Author: Kan Liang Date: Thu Mar 3 18:07:28 2016 -0500 perf/x86/intel: Fix PEBS warning by only restoring active PMU in pmi commit c3d266c8a9838cc141b69548bc3b1b18808ae8c4 upstream. This patch tries to fix a PEBS warning found in my stress test. The following perf command can easily trigger the pebs warning or spurious NMI error on Skylake/Broadwell/Haswell platforms: sudo perf record -e 'cpu/umask=0x04,event=0xc4/pp,cycles,branches,ref-cycles,cache-misses,cache-references' --call-graph fp -b -c1000 -a Also the NMI watchdog must be enabled. For this case, the events number is larger than counter number. So perf has to do multiplexing. In perf_mux_hrtimer_handler, it does perf_pmu_disable(), schedule out old events, rotate_ctx, schedule in new events and finally perf_pmu_enable(). If the old events include precise event, the MSR_IA32_PEBS_ENABLE should be cleared when perf_pmu_disable(). The MSR_IA32_PEBS_ENABLE should keep 0 until the perf_pmu_enable() is called and the new event is precise event. However, there is a corner case which could restore PEBS_ENABLE to stale value during the above period. In perf_pmu_disable(), GLOBAL_CTRL will be set to 0 to stop overflow and followed PMI. But there may be pending PMI from an earlier overflow, which cannot be stopped. So even GLOBAL_CTRL is cleared, the kernel still be possible to get PMI. At the end of the PMI handler, __intel_pmu_enable_all() will be called, which will restore the stale values if old events haven't scheduled out. Once the stale pebs value is set, it's impossible to be corrected if the new events are non-precise. Because the pebs_enabled will be set to 0. x86_pmu.enable_all() will ignore the MSR_IA32_PEBS_ENABLE setting. As a result, the following NMI with stale PEBS_ENABLE trigger pebs warning. The pending PMI after enabled=0 will become harmless if the NMI handler does not change the state. This patch checks cpuc->enabled in pmi and only restore the state when PMU is active. Here is the dump: Call Trace: [] dump_stack+0x63/0x85 [] warn_slowpath_common+0x82/0xc0 [] warn_slowpath_null+0x1a/0x20 [] intel_pmu_drain_pebs_nhm+0x2be/0x320 [] intel_pmu_handle_irq+0x279/0x460 [] ? native_write_msr_safe+0x6/0x40 [] ? vunmap_page_range+0x20d/0x330 [] ? unmap_kernel_range_noflush+0x11/0x20 [] ? ghes_copy_tofrom_phys+0x10f/0x2a0 [] ? ghes_read_estatus+0x98/0x170 [] perf_event_nmi_handler+0x2d/0x50 [] nmi_handle+0x69/0x120 [] default_do_nmi+0xe6/0x100 [] do_nmi+0xe2/0x130 [] end_repeat_nmi+0x1a/0x1e [] ? native_write_msr_safe+0x6/0x40 [] ? native_write_msr_safe+0x6/0x40 [] ? native_write_msr_safe+0x6/0x40 <> [] ? x86_perf_event_set_period+0xd8/0x180 [] x86_pmu_start+0x4c/0x100 [] x86_pmu_enable+0x28d/0x300 [] perf_pmu_enable.part.81+0x7/0x10 [] perf_mux_hrtimer_handler+0x200/0x280 [] ? __perf_install_in_context+0xc0/0xc0 [] __hrtimer_run_queues+0xfd/0x280 [] hrtimer_interrupt+0xa8/0x190 [] ? __perf_read_group_add.part.61+0x1a0/0x1a0 [] local_apic_timer_interrupt+0x38/0x60 [] smp_apic_timer_interrupt+0x3d/0x50 [] apic_timer_interrupt+0x8c/0xa0 [] ? __perf_read_group_add.part.61+0x1a0/0x1a0 [] ? smp_call_function_single+0xd5/0x130 [] ? smp_call_function_single+0xcb/0x130 [] ? __perf_read_group_add.part.61+0x1a0/0x1a0 [] event_function_call+0x10a/0x120 [] ? ctx_resched+0x90/0x90 [] ? cpu_clock_event_read+0x30/0x30 [] ? _perf_event_disable+0x60/0x60 [] _perf_event_enable+0x5b/0x70 [] perf_event_for_each_child+0x38/0xa0 [] ? _perf_event_disable+0x60/0x60 [] perf_ioctl+0x12d/0x3c0 [] ? selinux_file_ioctl+0x95/0x1e0 [] do_vfs_ioctl+0xa1/0x5a0 [] ? sched_clock+0x9/0x10 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 ---[ end trace aef202839fe9a71d ]--- Uhhuh. NMI received for unknown reason 2d on CPU 2. Do you have a strange power saving mode enabled? Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: http://lkml.kernel.org/r/1457046448-6184-1-git-send-email-kan.liang@intel.com [ Fixed various typos and other small details. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e5b6971c2a7dd22760d0001d908660fc52ec49d9 Author: Kan Liang Date: Wed Feb 24 05:07:43 2016 -0500 perf/x86/intel/uncore: Remove SBOX support for BDX-DE commit 6cb2f1d9af5b0f0afdd4e689d969df4b5c76a4c2 upstream. BDX-DE and BDX-EP share the same uncore code path. But there is no sbox in BDX-DE. This patch remove SBOX support for BDX-DE. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Tony Battersby Cc: Vince Weaver Link: http://lkml.kernel.org/r/37D7C6CF3E00A74B8858931C1DB2F0770589D336@SHSMSX103.ccr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 41585808f5f877106a69b8ab4d6ca8d660a522a3 Author: Stephane Eranian Date: Thu Mar 3 20:50:41 2016 +0100 perf/x86/pebs: Add workaround for broken OVFL status on HSW+ commit 8077eca079a212f26419c57226f28696b7100683 upstream. This patch fixes an issue with the GLOBAL_OVERFLOW_STATUS bits on Haswell, Broadwell and Skylake processors when using PEBS. The SDM stipulates that when the PEBS iterrupt threshold is crossed, an interrupt is posted and the kernel is interrupted. The kernel will find GLOBAL_OVF_SATUS bit 62 set indicating there are PEBS records to drain. But the bits corresponding to the actual counters should NOT be set. The kernel follows the SDM and assumes that all PEBS events are processed in the drain_pebs() callback. The kernel then checks for remaining overflows on any other (non-PEBS) events and processes these in the for_each_bit_set(&status) loop. As it turns out, under certain conditions on HSW and later processors, on PEBS buffer interrupt, bit 62 is set but the counter bits may be set as well. In that case, the kernel drains PEBS and generates SAMPLES with the EXACT tag, then it processes the counter bits, and generates normal (non-EXACT) SAMPLES. I ran into this problem by trying to understand why on HSW sampling on a PEBS event was sometimes returning SAMPLES without the EXACT tag. This should not happen on user level code because HSW has the eventing_ip which always point to the instruction that caused the event. The workaround in this patch simply ensures that the bits for the counters used for PEBS events are cleared after the PEBS buffer has been drained. With this fix 100% of the PEBS samples on my user code report the EXACT tag. Before: $ perf record -e cpu/event=0xd0,umask=0x81/upp ./multichase $ perf report -D | fgrep SAMPLES PERF_RECORD_SAMPLE(IP, 0x2): 11775/11775: 0x406de5 period: 73469 addr: 0 exact=Y \--- EXACT tag is missing After: $ perf record -e cpu/event=0xd0,umask=0x81/upp ./multichase $ perf report -D | fgrep SAMPLES PERF_RECORD_SAMPLE(IP, 0x4002): 11775/11775: 0x406de5 period: 73469 addr: 0 exact=Y \--- EXACT tag is set The problem tends to appear more often when multiple PEBS events are used. Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vince Weaver Cc: adrian.hunter@intel.com Cc: kan.liang@intel.com Cc: namhyung@kernel.org Link: http://lkml.kernel.org/r/1457034642-21837-3-git-send-email-eranian@google.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a9a3cef503366cfaf0ac6c98b27a80f9164c186a Author: Thomas Gleixner Date: Fri Mar 4 15:59:42 2016 +0100 sched/cputime: Fix steal time accounting vs. CPU hotplug commit e9532e69b8d1d1284e8ecf8d2586de34aec61244 upstream. On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time value over CPU down and up. So after the CPU comes up again the delta calculation in steal_account_process_tick() wreckages itself due to the unsigned math: u64 steal = paravirt_steal_clock(smp_processor_id()); steal -= this_rq()->prev_steal_time; So if steal is smaller than rq->prev_steal_time we end up with an insane large value which then gets added to rq->prev_steal_time, resulting in a permanent wreckage of the accounting. As a consequence the per CPU stats in /proc/stat become stale. Nice trick to tell the world how idle the system is (100%) while the CPU is 100% busy running tasks. Though we prefer realistic numbers. None of the accounting values which use a previous value to account for fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity check for prev_irq_time and prev_steal_time_rq, but that sanity check solely deals with clock warps and limits the /proc/stat visible wreckage. The prev_time values are still wrong. Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again. Signed-off-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Frederic Weisbecker Cc: Glauber Costa Cc: Linus Torvalds Cc: Peter Zijlstra Fixes: commit 095c0aa83e52 "sched: adjust scheduler cpu power for stolen time" Fixes: commit aa483808516c "sched: Remove irq time from available CPU power" Fixes: commit e6e6685accfa "KVM guest: Steal time accounting" Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603041539490.3686@nanos Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit be7cc5a6ea59e48780c993fc11e4bee67abf2197 Author: Hannes Reinecke Date: Fri Mar 18 14:55:38 2016 +0100 scsi_common: do not clobber fixed sense information commit ba08311647892cc7912de74525fd78416caf544a upstream. For fixed sense the information field is 32 bits, to we need to truncate the information field to avoid clobbering the sense code. Fixes: a1524f226a02 ("libata-eh: Set 'information' field for autosense") Signed-off-by: Hannes Reinecke Reviewed-by: Lee Duncan Reviewed-by: Bart Van Assche Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ab8a436573282b96a22bb2fd20bb91b1f544b724 Author: Lukas Wunner Date: Wed Mar 23 00:11:20 2016 +0100 PM / sleep: Clear pm_suspend_global_flags upon hibernate commit 276142730c39c9839465a36a90e5674a8c34e839 upstream. When suspending to RAM, waking up and later suspending to disk, we gratuitously runtime resume devices after the thaw phase. This does not occur if we always suspend to RAM or always to disk. pm_complete_with_resume_check(), which gets called from pci_pm_complete() among others, schedules a runtime resume if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during a suspend-to-RAM cycle. It is cleared at the beginning of the suspend-to-RAM cycle but not afterwards and it is not cleared during a suspend-to-disk cycle at all. Fix it. Fixes: ef25ba047601 (PM / sleep: Add flags to indicate platform firmware involvement) Signed-off-by: Lukas Wunner Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 87afa6a7540b3c90a34cc7b84bb0ff8603c39118 Author: Len Brown Date: Sun Mar 13 00:33:48 2016 -0500 intel_idle: prevent SKL-H boot failure when C8+C9+C10 enabled commit d70e28f57e14a481977436695b0c9ba165472431 upstream. Some SKL-H configurations require "intel_idle.max_cstate=7" to boot. While that is an effective workaround, it disables C10. This patch detects the problematic configuration, and disables C8 and C9, keeping C10 enabled. Note that enabling SGX in BIOS SETUP can also prevent this issue, if the system BIOS provides that option. https://bugzilla.kernel.org/show_bug.cgi?id=109081 "Freezes with Intel i7 6700HQ (Skylake), unless intel_idle.max_cstate=7" Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 5bb18668065377dd6e3213e11badb83f3b307489 Author: Aaro Koskinen Date: Sat Feb 20 22:27:48 2016 +0200 mtd: onenand: fix deadlock in onenand_block_markbad commit 5e64c29e98bfbba1b527b0a164f9493f3db9e8cb upstream. Commit 5942ddbc500d ("mtd: introduce mtd_block_markbad interface") incorrectly changed onenand_block_markbad() to call mtd_block_markbad instead of onenand_chip's block_markbad function. As a result the function will now recurse and deadlock. Fix by reverting the change. Fixes: 5942ddbc500d ("mtd: introduce mtd_block_markbad interface") Signed-off-by: Aaro Koskinen Acked-by: Artem Bityutskiy Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit cbb6e048311be61c6e59d2bd413330a52eb97fab Author: Vlastimil Babka Date: Fri Mar 25 14:21:50 2016 -0700 mm/page_alloc: prevent merging between isolated and other pageblocks commit d9dddbf556674bf125ecd925b24e43a5cf2a568a upstream. Hanjun Guo has reported that a CMA stress test causes broken accounting of CMA and free pages: > Before the test, I got: > -bash-4.3# cat /proc/meminfo | grep Cma > CmaTotal: 204800 kB > CmaFree: 195044 kB > > > After running the test: > -bash-4.3# cat /proc/meminfo | grep Cma > CmaTotal: 204800 kB > CmaFree: 6602584 kB > > So the freed CMA memory is more than total.. > > Also the the MemFree is more than mem total: > > -bash-4.3# cat /proc/meminfo > MemTotal: 16342016 kB > MemFree: 22367268 kB > MemAvailable: 22370528 kB Laura Abbott has confirmed the issue and suspected the freepage accounting rewrite around 3.18/4.0 by Joonsoo Kim. Joonsoo had a theory that this is caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA pageblocks: > CMA isolates MAX_ORDER aligned blocks, but, during the process, > partialy isolated block exists. If MAX_ORDER is 11 and > pageblock_order is 9, two pageblocks make up MAX_ORDER > aligned block and I can think following scenario because pageblock > (un)isolation would be done one by one. > > (each character means one pageblock. 'C', 'I' means MIGRATE_CMA, > MIGRATE_ISOLATE, respectively. > > CC -> IC -> II (Isolation) > II -> CI -> CC (Un-isolation) > > If some pages are freed at this intermediate state such as IC or CI, > that page could be merged to the other page that is resident on > different type of pageblock and it will cause wrong freepage count. This was supposed to be prevented by CMA operating on MAX_ORDER blocks, but since it doesn't hold the zone->lock between pageblocks, a race window does exist. It's also likely that unexpected merging can occur between MIGRATE_ISOLATE and non-CMA pageblocks. This should be prevented in __free_one_page() since commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock"). However, we only check the migratetype of the pageblock where buddy merging has been initiated, not the migratetype of the buddy pageblock (or group of pageblocks) which can be MIGRATE_ISOLATE. Joonsoo has suggested checking for buddy migratetype as part of page_is_buddy(), but that would add extra checks in allocator hotpath and bloat-o-meter has shown significant code bloat (the function is inline). This patch reduces the bloat at some expense of more complicated code. The buddy-merging while-loop in __free_one_page() is initially bounded to pageblock_border and without any migratetype checks. The checks are placed outside, bumping the max_order if merging is allowed, and returning to the while-loop with a statement which can't be possibly considered harmful. This fixes the accounting bug and also removes the arguably weird state in the original commit 3c605096d315 where buddies could be left unmerged. Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock") Link: https://lkml.org/lkml/2016/3/2/280 Signed-off-by: Vlastimil Babka Reported-by: Hanjun Guo Tested-by: Hanjun Guo Acked-by: Joonsoo Kim Debugged-by: Laura Abbott Debugged-by: Joonsoo Kim Cc: Mel Gorman Cc: "Kirill A. Shutemov" Cc: Johannes Weiner Cc: Minchan Kim Cc: Yasuaki Ishimatsu Cc: Zhang Yanfei Cc: Michal Nazarewicz Cc: Naoya Horiguchi Cc: "Aneesh Kumar K.V" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ce492bc84ea6888be8b565dfe7989d6e63dd46e1 Author: Joseph Qi Date: Fri Mar 25 14:21:29 2016 -0700 ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c upstream. When master handles convert request, it queues ast first and then returns status. This may happen that the ast is sent before the request status because the above two messages are sent by two threads. And right after the ast is sent, if master down, it may trigger BUG in dlm_move_lockres_to_recovery_list in the requested node because ast handler moves it to grant list without clear lock->convert_pending. So remove BUG_ON statement and check if the ast is processed in dlmconvert_remote. Signed-off-by: Joseph Qi Reported-by: Yiwen Jiang Cc: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Tariq Saeed Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e12a8511a2b0700aa7ddc6230ad487981f59df68 Author: Joseph Qi Date: Fri Mar 25 14:21:26 2016 -0700 ocfs2/dlm: fix race between convert and recovery commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac upstream. There is a race window between dlmconvert_remote and dlm_move_lockres_to_recovery_list, which will cause a lock with OCFS2_LOCK_BUSY in grant list, thus system hangs. dlmconvert_remote { spin_lock(&res->spinlock); list_move_tail(&lock->list, &res->converting); lock->convert_pending = 1; spin_unlock(&res->spinlock); status = dlm_send_remote_convert_request(); >>>>>> race window, master has queued ast and return DLM_NORMAL, and then down before sending ast. this node detects master down and calls dlm_move_lockres_to_recovery_list, which will revert the lock to grant list. Then OCFS2_LOCK_BUSY won't be cleared as new master won't send ast any more because it thinks already be authorized. spin_lock(&res->spinlock); lock->convert_pending = 0; if (status != DLM_NORMAL) dlm_revert_pending_convert(res, lock); spin_unlock(&res->spinlock); } In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set (res is still in recovering) or res master changed (new master has finished recovery), reset the status to DLM_RECOVERING, then it will retry convert. Signed-off-by: Joseph Qi Reported-by: Yiwen Jiang Reviewed-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Tariq Saeed Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9aff4c76eda73aec0f2ba21c9033817c2d802c7e Author: Junxiao Bi Date: Fri Mar 25 14:20:50 2016 -0700 ocfs2: o2hb: fix double free bug commit 9e13f1f9de1cb143fbae6f1170f26c8544b64cff upstream. This is a regression issue and caused the following kernel panic when do ocfs2 multiple test. BUG: unable to handle kernel paging request at 00000002000800c0 IP: [] kmem_cache_alloc+0x78/0x160 PGD 7bbe5067 PUD 0 Oops: 0000 [#1] SMP Modules linked in: ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi xen_kbdfront xen_netfront xen_fbfront xen_blkfront CPU: 2 PID: 4044 Comm: mpirun Not tainted 4.5.0-rc5-next-20160225 #1 Hardware name: Xen HVM domU, BIOS 4.3.1OVM 05/14/2014 task: ffff88007a521a80 ti: ffff88007aed0000 task.ti: ffff88007aed0000 RIP: 0010:[] [] kmem_cache_alloc+0x78/0x160 RSP: 0018:ffff88007aed3a48 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000001991 RDX: 0000000000001990 RSI: 00000000024000c0 RDI: 000000000001b330 RBP: ffff88007aed3a98 R08: ffff88007d29b330 R09: 00000002000800c0 R10: 0000000c51376d87 R11: ffff8800792cac38 R12: ffff88007cc30f00 R13: 00000000024000c0 R14: ffffffff811b053f R15: ffff88007aed3ce7 FS: 0000000000000000(0000) GS:ffff88007d280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000002000800c0 CR3: 000000007aeb2000 CR4: 00000000000406e0 Call Trace: __d_alloc+0x2f/0x1a0 d_alloc+0x17/0x80 lookup_dcache+0x8a/0xc0 path_openat+0x3c3/0x1210 do_filp_open+0x80/0xe0 do_sys_open+0x110/0x200 SyS_open+0x19/0x20 do_syscall_64+0x72/0x230 entry_SYSCALL64_slow_path+0x25/0x25 Code: 05 e6 77 e7 7e 4d 8b 08 49 8b 40 10 4d 85 c9 0f 84 dd 00 00 00 48 85 c0 0f 84 d4 00 00 00 49 63 44 24 20 49 8b 3c 24 48 8d 4a 01 <49> 8b 1c 01 4c 89 c8 65 48 0f c7 0f 0f 94 c0 3c 01 75 b6 49 63 RIP kmem_cache_alloc+0x78/0x160 CR2: 00000002000800c0 ---[ end trace 823969e602e4aaac ]--- Fixes: a4a1dfa4bb8b("ocfs2/cluster: fix memory leak in o2hb_region_release") Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e0a40d844832eb90c6ac790dada3d060332d654c Author: Vladis Dronov Date: Wed Mar 23 11:53:46 2016 -0700 Input: ati_remote2 - fix crashes on detecting device with invalid descriptor commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d upstream. The ati_remote2 driver expects at least two interfaces with one endpoint each. If given malicious descriptor that specify one interface or no endpoints, it will crash in the probe function. Ensure there is at least two interfaces and one endpoint for each interface before using it. The full disclosure: http://seclists.org/bugtraq/2016/Mar/90 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit cadaf14c349dfd9dae5113a53f0d7f6d49b9d4ef Author: Oliver Neukum Date: Thu Mar 17 14:00:17 2016 -0700 Input: ims-pcu - sanity check against missing interfaces commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff upstream. A malicious device missing interface can make the driver oops. Add sanity checking. Signed-off-by: Oliver Neukum Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 2c84af5604ae7bb60f2709da908a81e63394b0ed Author: Benjamin Tissoires Date: Thu Mar 17 17:12:54 2016 -0700 Input: synaptics - handle spurious release of trackstick buttons, again commit 82be788c96ed5978d3cb4a00079e26b981a3df3f upstream. Looks like the fimware 8.2 still has the extra buttons spurious release bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321 Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5fc5642b73a39936b781bdaef0cf45f256ac1d11 Author: Tejun Heo Date: Fri Mar 18 13:52:04 2016 -0400 writeback, cgroup: fix use of the wrong bdi_writeback which mismatches the inode commit aaf2559332ba272671bb870464a99b909b29a3a1 upstream. When cgroup writeback is in use, there can be multiple wb's (bdi_writeback's) per bdi and an inode may switch among them dynamically. In a couple places, the wrong wb was used leading to performing operations on the wrong list under the wrong lock corrupting the io lists. * writeback_single_inode() was taking @wb parameter and used it to remove the inode from io lists if it becomes clean after writeback. The callers of this function were always passing in the root wb regardless of the actual wb that the inode was associated with, which could also change while writeback is in progress. Fix it by dropping the @wb parameter and using inode_to_wb_and_lock_list() to determine and lock the associated wb. * After writeback_sb_inodes() writes out an inode, it re-locks @wb and inode to remove it from or move it to the right io list. It assumes that the inode is still associated with @wb; however, the inode may have switched to another wb while writeback was in progress. Fix it by using inode_to_wb_and_lock_list() to determine and lock the associated wb after writeback is complete. As the function requires the original @wb->list_lock locked for the next iteration, in the unlikely case where the inode has changed association, switch the locks. Kudos to Tahsin for pinpointing these subtle breakages. Signed-off-by: Tejun Heo Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching") Link: http://lkml.kernel.org/g/CAAeU0aMYeM_39Y2+PaRvyB1nqAPYZSNngJ1eBRmrxn7gKAt2Mg@mail.gmail.com Reported-and-diagnosed-by: Tahsin Erdogan Tested-by: Tahsin Erdogan Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7ea4d0c10a65a294b2e36afa31d084417a5171b6 Author: Tejun Heo Date: Fri Mar 18 13:50:03 2016 -0400 writeback, cgroup: fix premature wb_put() in locked_inode_to_wb_and_lock_list() commit 614a4e3773148a31f58dc174bbf578ceb63510c2 upstream. locked_inode_to_wb_and_lock_list() wb_get()'s the wb associated with the target inode, unlocks inode, locks the wb's list_lock and verifies that the inode is still associated with the wb. To prevent the wb going away between dropping inode lock and acquiring list_lock, the wb is pinned while inode lock is held. The wb reference is put right after acquiring list_lock citing that the wb won't be dereferenced anymore. This isn't true. If the inode is still associated with the wb, the inode has reference and it's safe to return the wb; however, if inode has been switched, the wb still needs to be unlocked which is a dereference and can lead to use-after-free if it it races with wb destruction. Fix it by putting the reference after releasing list_lock. Signed-off-by: Tejun Heo Fixes: 87e1d789bf55 ("writeback: implement [locked_]inode_to_wb_and_lock_list()") Tested-by: Tahsin Erdogan Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2444c61a380e6cf549b22eddd209affcd2a39d9e Author: Lukas Wunner Date: Wed Mar 23 00:11:20 2016 +0100 ACPI / PM: Runtime resume devices when waking from hibernate commit fbda4b38fa3995aa0777fe9cbbdcb223c6292083 upstream. Commit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been reset by firmware") added a runtime resume for devices that were runtime suspended when the system entered suspend-to-RAM. Briefly, the motivation was to ensure that devices did not remain in a reset-power-on state after resume, potentially preventing deep SoC-wide low-power states from being entered on idle. Currently we're not doing the same when leaving suspend-to-disk and this asymmetry is a problem if drivers rely on the automatic resume triggered by pm_complete_with_resume_check(). Fix it. Fixes: 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware) Signed-off-by: Lukas Wunner Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5af4e0bed45100e49468a8555dbf03f041a1b647 Author: Ludovic Desroches Date: Fri Mar 11 11:35:10 2016 +0100 ARM: dts: at91: sama5d4 Xplained: don't disable hsmci regulator commit b02acd4e62602a6ab307da84388a16bf60106c48 upstream. If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue. Signed-off-by: Ludovic Desroches Fixes: 8d545f32bd77 ("ARM: at91/dt: sama5d4 xplained: add regulators for v(q)mmc1 supplies") Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 8daeb0405111da31185d718267a8cbf3ff945bc7 Author: Ludovic Desroches Date: Fri Mar 11 11:43:39 2016 +0100 ARM: dts: at91: sama5d3 Xplained: don't disable hsmci regulator commit ae3fc8ea08e405682f1fa959f94b6e4126afbc1b upstream. If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue. Signed-off-by: Ludovic Desroches Fixes: 1b53e3416dd0 ("ARM: at91/dt: sama5d3 xplained: add fixed regulator for vmmc0") Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 4eb648c686228f1830c56f5341dc0d73a084fda8 Author: J. Bruce Fields Date: Wed Mar 2 16:36:21 2016 -0800 nfsd: fix deadlock secinfo+readdir compound commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 upstream. nfsd_lookup_dentry exits with the parent filehandle locked. fh_put also unlocks if necessary (nfsd filehandle locking is probably too lenient), so it gets unlocked eventually, but if the following op in the compound needs to lock it again, we can deadlock. A fuzzer ran into this; normal clients don't send a secinfo followed by a readdir in the same compound. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit cbeacd73ea4e3ddba3c02ae1119c34377e2d03c2 Author: J. Bruce Fields Date: Mon Feb 29 20:21:21 2016 -0500 nfsd4: fix bad bounds checking commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 upstream. A number of spots in the xdr decoding follow a pattern like n = be32_to_cpup(p++); READ_BUF(n + 4); where n is a u32. The only bounds checking is done in READ_BUF itself, but since it's checking (n + 4), it won't catch cases where n is very large, (u32)(-4) or higher. I'm not sure exactly what the consequences are, but we've seen crashes soon after. Instead, just break these up into two READ_BUF()s. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 924d4bb8248a08837d70c02c4744601e34a28179 Author: Jenny Derzhavetz Date: Wed Feb 24 19:24:01 2016 +0200 iser-target: Rework connection termination commit 6d1fba0c2cc7efe42fd761ecbba833ed0ea7b07e upstream. When we receive an event that triggers connection termination, we have a a couple of things we may want to do: 1. In case we are already terminating, bailout early 2. In case we are connected but not bound, disconnect and schedule a connection cleanup silently (don't reinstate) 3. In case we are connected and bound, disconnect and reinstate the connection This rework fixes a bug that was detected against a mis-behaved initiator which rejected our rdma_cm accept, in this stage the isert_conn is no bound and reinstate caused a bogus dereference. What's great about this is that we don't need the post_recv_buf_count anymore, so get rid of it. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 86ea155a13db977b1134b7045123209fede9cfab Author: Jenny Derzhavetz Date: Wed Feb 24 19:24:00 2016 +0200 iser-target: Separate flows for np listeners and connections cma events commit f81bf458208ef6d12b2fc08091204e3859dcdba4 upstream. No need to restrict this check to specific events. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 8cfea5d3dc7988d5270cb73335c5b8174d6878f1 Author: Jenny Derzhavetz Date: Wed Feb 24 19:23:59 2016 +0200 iser-target: Add new state ISER_CONN_BOUND to isert_conn commit aea92980601f7ddfcb3c54caa53a43726314fe46 upstream. We need an indication that isert_conn->iscsi_conn binding has happened so we'll know not to invoke a connection reinstatement on an unbound connection which will lead to a bogus isert_conn->conn dereferece. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit cce41f40d86dac51a7fa8b876d425fa66e9b1314 Author: Jenny Derzhavetz Date: Wed Feb 24 19:23:58 2016 +0200 iser-target: Fix identification of login rx descriptor type commit b89a7c25462b164db280abc3b05d4d9d888d40e9 upstream. Once connection request is accepted, one rx descriptor is posted to receive login request. This descriptor has rx type, but is outside the main pool of rx descriptors, and thus was mistreated as tx type. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 653a9b30240d8439ecc26bd1ad8d246d360218f4 Author: Himanshu Madhani Date: Mon Mar 14 22:47:37 2016 -0700 target: Fix target_release_cmd_kref shutdown comp leak commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e upstream. This patch fixes an active I/O shutdown bug for fabric drivers using target_wait_for_sess_cmds(), where se_cmd descriptor shutdown would result in hung tasks waiting indefinitely for se_cmd->cmd_wait_comp to complete(). To address this bug, drop the incorrect list_del_init() usage in target_wait_for_sess_cmds() and always complete() during se_cmd target_release_cmd_kref() put, in order to let caller invoke the final fabric release callback into se_cmd->se_tfo->release_cmd() code. Reported-by: Himanshu Madhani Tested-by: Himanshu Madhani Signed-off-by: Himanshu Madhani Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 68e89b1188f4750d0da97f2072d3f550d2d6b7b0 Author: Eric Anholt Date: Mon Feb 15 19:03:57 2016 -0800 clk: bcm2835: Fix setting of PLL divider clock rates commit 773b3966dd3cdaeb68e7f2edfe5656abac1dc411 upstream. Our dividers weren't being set successfully because CM_PASSWORD wasn't included in the register write. It looks easier to just compute the divider to write ourselves than to update clk-divider for the ability to OR in some arbitrary bits on write. Fixes about half of the video modes on my HDMI monitor (everything except 720x400). Signed-off-by: Eric Anholt Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit df775ddbb1f1603df4c4fd56b45ae2ccf30ae7d4 Author: Alexander Kochetkov Date: Tue Jan 26 16:34:00 2016 +0300 clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks commit e8b63288b37dbb8457b510c9d96f6006da4653f6 upstream. hclk_cpubus needs to keep running because it is needed for devices like the rom, i2s0 or spdif to be accessible via cpu. Without that all accesses to devices (readl/writel) return wrong data. So add it to the list of critical clocks. Fixes: 78eaf6095cc763c ("clk: rockchip: disable unused clocks") Signed-off-by: Alexander Kochetkov Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 76f5f39b0f9da3499f00118343b94e88aa617567 Author: Heiko Stuebner Date: Wed Jan 20 21:47:57 2016 +0100 clk: rockchip: rk3368: fix hdmi_cec gate-register commit fd0c0740fac17a014704ef89d8c8b1768711ca59 upstream. Fix a typo making the sclk_hdmi_cec access a wrong register to handle its gate. Fixes: 3536c97a52db ("clk: rockchip: add rk3368 clock controller") Signed-off-by: Heiko Stuebner Reviewed-by: zhangqing Signed-off-by: Greg Kroah-Hartman commit c21ff6a51626a9f7d213ba21f707c3e31ca42fff Author: Heiko Stuebner Date: Wed Jan 20 19:22:38 2016 +0100 clk: rockchip: rk3368: fix parents of video encoder/decoder commit 0f28d98463498c61c61a38aacbf9f69e92e85e9d upstream. The vdpu and vepu clocks can also be parented to the npll and current parent list also is wrong as it would use the npll as "usbphy" source, so adapt the parent to the correct one. Fixes: 3536c97a52db ("clk: rockchip: add rk3368 clock controller") Signed-off-by: Heiko Stuebner Reviewed-by: zhangqing Signed-off-by: Greg Kroah-Hartman commit 2c72f04687ad0818c0c9fc50dfad315368d3c4bb Author: Heiko Stuebner Date: Tue Jan 19 10:09:22 2016 +0100 clk: rockchip: rk3368: fix cpuclk core dividers commit c6d5fe2ca8286f35a79f7345c9378c39d48a1527 upstream. Similar to commit 9880d4277f6a ("clk: rockchip: fix rk3288 cpuclk core dividers") it seems the cpuclk dividers are one to high on the rk3368 as well. And again similar to the previous fix, we opt to make the divider list contain the values to be written to use the same paradigm for them on all supported socs. Fixes: 3536c97a52db ("clk: rockchip: add rk3368 clock controller") Reported-by: Zhang Qing Signed-off-by: Heiko Stuebner Reviewed-by: zhangqing Signed-off-by: Greg Kroah-Hartman commit 02bde5aae8d4b0120a8efb6ed6c53f10ca2c3727 Author: Heiko Stuebner Date: Tue Jan 19 10:01:08 2016 +0100 clk: rockchip: rk3368: fix cpuclk mux bit of big cpu-cluster commit 535ebd428aeb07c3327947281306f2943f2c9faa upstream. Both clusters have their mux bit in bit 7 of their respective register. For whatever reason the big cluster currently lists bit 15 which is definitly wrong. Fixes: 3536c97a52db ("clk: rockchip: add rk3368 clock controller") Reported-by: Zhang Qing Signed-off-by: Heiko Stuebner Reviewed-by: zhangqing Signed-off-by: Greg Kroah-Hartman commit ae854643c178226d63c273df8bc1d42556d80540 Author: Brent Taylor Date: Sun Mar 13 00:25:31 2016 -0600 mmc: atmel-mci: Check pdata for NULL before dereferencing it at DMA config commit 93c77d2999b09f2084b033ea6489915e0104ad9c upstream. Using an at91sam9g20ek development board with DTS configuration may trigger a kernel panic because of a NULL pointer dereference exception, while configuring DMA. Let's fix this by adding a check for pdata before dereferencing it. Signed-off-by: Brent Taylor Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6576116d94b923ace418c020364a29c98fa62bfb Author: Adrian Hunter Date: Mon Mar 7 13:33:55 2016 +0200 mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout commit 995136247915c5cee633d55ba23f6eebf67aa567 upstream. Normally the timeout clock frequency is read from the capabilities register. It is also possible to set the value prior to calling sdhci_add_host() in which case that value will override the capabilities register value. However that was being done after calculating max_busy_timeout so that max_busy_timeout was being calculated using the wrong value of timeout_clk. Fix that by moving the override before max_busy_timeout is calculated. The result is that the max_busy_timeout and max_discard increase for BSW devices so that, for example, the time for mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds to about 20 seconds. Note, in the future, the capabilities setting will be tidied up and this override won't be used anymore. However this fix is needed for stable. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6eadae1a14afdb5352d900a2577084c13ae273a3 Author: Lucas Stach Date: Mon Feb 29 21:56:24 2016 +0100 mmc: tegra: properly disable card clock commit 3491b69045b1926a198ba70dc1296ca253f2fbdd upstream. The new code to do the clock rate setting externally to the SDMMC module has a shortcut to not propagate changes with a 0 rate to the CAR by simply bailing out. This breaks proper cutting of the card clock. Fix it by directly calling the correct sdhci function. Fixes: a8e326a911d3 "mmc: tegra: implement module external clock change" Signed-off-by: Lucas Stach Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8af2553596473a9b94ede36e78cfe75f5c16dd91 Author: Jon Hunter Date: Fri Feb 26 09:34:17 2016 +0000 mmc: tegra: Disable UHS-I modes for tegra114 commit 7bf037d6ac4768e228e337afd7b6c6d98f947f9f upstream. SD card support for Tegra114 started failing after commit a8e326a911d3 ("mmc: tegra: implement module external clock change") was merged. This commit was part of a series to enable UHS-I modes for Tegra. To workaround this problem for now, disable UHS-I modes for Tegra114 by separating the soc data structures for Tegra114 and Tegra124 so that UHS-I is still enabled for Tegra124 but not Tegra114. Fixes: a8e326a911d3 ("mmc: tegra: implement module external clock change") Signed-off-by: Jon Hunter Reviewed-by: Lucas Stach Acked-by: Thierry Reding Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 82e3506e81d91e84725c5b50e3562816ef6b4eb1 Author: Russell King Date: Tue Jan 26 13:40:47 2016 +0000 mmc: sdhci-pxav3: fix higher speed mode capabilities commit 0ca33b4ad9cfc133bb3d93eec1ad0eea83d6f252 upstream. Commit 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes being used. The commit claims that SDR50 and DDR50 require clock adjustments in the SDIO3 Configuration register, which is located via the "conf-sdio3" resource. However, when this resource is given, we fail to read the host capabilities 1 register, resulting in host->caps1 being zero. Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain zero, disabling the SDR50 and DDR50 modes. The underlying idea in this function appears to be to read the device capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause our modified capabilities to be used. Implement exactly that. Fixes: 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") Signed-off-by: Russell King Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1909289bc8f8f7c1ee718abc804d0fbc2ed793e2 Author: Russell King Date: Tue Jan 26 13:41:04 2016 +0000 mmc: sdhci: fix data timeout (part 2) commit 7f05538af71c7d30b5fc821cbe9f318edc645961 upstream. The calculation for the timeout based on the number of card clocks is incorrect. The calculation assumed: timeout in microseconds = clock cycles / clock in Hz which is clearly a several orders of magnitude wrong. Fix this by multiplying the clock cycles by 1000000 prior to dividing by the Hz based clock. Also, as per part 1, ensure that the division rounds up. As this needs 64-bit math via do_div(), avoid it if the clock cycles is zero. Signed-off-by: Russell King Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e2592e824e559a93b9dce086499b0b8b7002b6d0 Author: Russell King Date: Tue Jan 26 13:40:58 2016 +0000 mmc: sdhci: fix data timeout (part 1) commit fafcfda9e78cae8796d1799f14e6457790797555 upstream. The data timeout gives the minimum amount of time that should be waited before timing out if no data is received from the card. Simply dividing the nanosecond part by 1000 does not give this required guarantee, since such a division rounds down. Use DIV_ROUND_UP() to give the desired timeout. Signed-off-by: Russell King Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit aef1cde843c7b68d6b792ffbf5b59db1144e93a0 Author: Russell King Date: Tue Jan 26 13:40:42 2016 +0000 mmc: sdhci: plug DMA mapping leak on error commit 054cedff5e025a54ceefff891c6ea42ee8b37eab upstream. If we terminate a command early, we fail to properly clean up the DMA mappings for the data part of the request. Put this clean up to the tasklet, which is the common path for finishing a request so we always clean up after ourselves. Signed-off-by: Russell King [ Split original patch so that it now contains only the fix ] Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 15c1e7e44eca833be1d9c165706778dfbb2917d9 Author: Russell King Date: Tue Jan 26 13:39:50 2016 +0000 mmc: sdhci: avoid unnecessary mapping/unmapping of align buffer commit edd63fcc97cdb53279a7c43fa1691f5913d92793 upstream. Unnecessarily mapping and unmapping the align buffer for SD cards is expensive: performance measurements on iMX6 show that this gives a hit of 10% on hdparm buffered disk reads. MMC/SD card IO comes from the mm/vfs which gives us page based IO, so for this case, the align buffer is not going to be used. However, we still map and unmap this buffer. Eliminate this by switching the align buffer to be a DMA coherent buffer, which needs no DMA maintenance to access the buffer. Signed-off-by: Russell King Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ef9ddac5e4640ce6ae78cc70f2b2b1cb80b1e8ac Author: Russell King Date: Tue Jan 26 13:40:53 2016 +0000 mmc: sdhci: further fix for DMA unmapping in sdhci_post_req() commit 771a3dc225815b7cc691c1ce703a3af8488e48df upstream. sdhci_post_req() exists to unmap a previously mapped but already finished request, while the next request is in progress. However, the state of the SDHCI_REQ_USE_DMA flag depends on the last submitted request. This means we can end up clearing the flag due to a quirk, which then means that sdhci_post_req() fails to unmap the DMA buffer, potentially leading to data corruption. We can safely ignore the SDHCI_REQ_USE_DMA here, as testing data->host_cookie is entirely sufficient. Signed-off-by: Russell King [ Re-based to apply as a separate fix ] Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ef78a0cea7c57d9326fefc525b57bd365c563fd0 Author: Russell King Date: Tue Jan 26 13:39:45 2016 +0000 mmc: sdhci: fix command response CRC error handling commit 71fcbda0fcddd0896c4982a484f6c8aa802d28b1 upstream. When we get a response CRC error on a command, it means that the response we received back from the card was not correct. It does not mean that the card did not receive the command correctly. If the command is one which initiates a data transfer, the card can enter the data transfer state, and start sending data. Moreover, if the request contained a data phase, we do not clean this up, and this results in the driver triggering DMA API debug warnings, and also creates a race condition in the driver, between running the finish_tasklet and the data transfer interrupts, which can trigger a "Got data interrupt" state dump. Fix this by handing a response CRC error slightly differently: record the failure of the data initiating command, but allow the remainder of the request to be processed normally. This is safe as core MMC checks the status of all commands and data transfer phases of the request. If the card does not initiate a data transfer, then we should time out according to the data transfer parameters. Signed-off-by: Russell King [ Fix missing parenthesis around bitwise-AND expression, and tweak subject ] Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d2ee2ed103d48f32303360c9f8e975916151abbb Author: Russell King Date: Tue Jan 26 13:39:39 2016 +0000 mmc: sdhci: clean up command error handling commit ec014cbacf6229c583cb832726ca39be1ae3d8c3 upstream. Avoid multiple tests while handling a command error; simplify the code. Signed-off-by: Russell King Signed-off-by: Adrian Hunter [ Goes with "mmc: sdhci: fix command response CRC error handling" ] Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 54ce1ca8aa758944a22270f918d36be25a9d3174 Author: Russell King Date: Tue Jan 26 13:39:34 2016 +0000 mmc: sdhci: move initialisation of command error member commit 96776200898cf9c1965b9f8b9a128e94bb6dce18 upstream. When a command is started, logically it has no error. Initialise the command's error member to zero whenever we start a command. Signed-off-by: Russell King Signed-off-by: Adrian Hunter [ Goes with "mmc: sdhci: fix command response CRC error handling" ] Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 384640f9028958da8d5a0d0e9df6fe7c13632ab2 Author: Magnus Damm Date: Tue Feb 16 13:06:41 2016 +0900 mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case commit bcdc9f260bdce09913db1464be9817170d51044a upstream. This patch fixes the MMC SPI driver from doing polling card detect when a CD GPIO that supports interrupts is specified using the gpios DT property. Without this patch the DT node below results in the following output: spi_gpio: spi-gpio { /* SD2 @ CN12 */ compatible = "spi-gpio"; #address-cells = <1>; #size-cells = <0>; gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>; gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>; gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>; num-chipselects = <1>; cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>; status = "okay"; spi@0 { compatible = "mmc-spi-slot"; reg = <0>; voltage-ranges = <3200 3400>; spi-max-frequency = <25000000>; gpios = <&gpio6 22 GPIO_ACTIVE_LOW>; /* CD */ }; }; # dmesg | grep mmc mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling mmc0: host does not support reading read-only switch, assuming write-enable mmc0: new SDHC card on SPI mmcblk0: mmc0:0000 SU04G 3.69 GiB mmcblk0: p1 With this patch applied the "cd polling" portion above disappears. Signed-off-by: Magnus Damm Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3c5f48963fd4695517693a325863418ca2748e61 Author: Shawn Lin Date: Wed Mar 16 18:15:47 2016 +0800 mmc: block: fix ABI regression of mmc_blk_ioctl commit 83c742c344c08c2bbe338d45c6ec63110e9d5e3d upstream. If mmc_blk_ioctl returns -EINVAL, blkdev_ioctl continues to work without returning err to user-space. But now we check CAP_SYS_RAWIO firstly, so we return -EPERM to blkdev_ioctl, which make blkdev_ioctl return -EPERM to user-space directly. So this will break all the ioctl with BLKROSET. Now we find Android-adb suffer it for the following log: remount of /system failed; couldn't make block device writable: Operation not permitted openat(AT_FDCWD, "/dev/block/platform/ff420000.dwmmc/by-name/system", O_RDONLY) = 3 ioctl(3, BLKROSET, 0) = -1 EPERM (Operation not permitted) Fixes: a5f5774c55a2 ("mmc: block: Add new ioctl to send multi commands") Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 40f781f1ce0fe80d4ddce019baf500abcfb52dd2 Author: John Dahlstrom Date: Sat Feb 27 00:09:58 2016 -0600 ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list commit 4db9675d927a71faa66e5ab128d2390d6329750b upstream. Some Lenovo ideapad models lack a physical rfkill switch. On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, ideapad-laptop would wrongly report all radios as blocked by hardware which caused wireless network connections to fail. Add these models without an rfkill switch to the no_hw_rfkill list. Signed-off-by: John Dahlstrom Cc: # 3.17.x-: 4fa9dab: ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit 30b11ea2bfee6dfc1ff403eafa72d42ed47bf04b Author: Guenter Roeck Date: Tue Mar 22 15:11:03 2016 -0700 MAINTAINERS: Update mailing list and web page for hwmon subsystem commit 968ce1b1f45a7d76b5471b19bd035dbecc72f32d upstream. The old web page for the hwmon subsystem is no longer operational, and the mailing list has become unreliable. Move both to kernel.org. Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 84cc3bee5e2322e137e311aa2f16e100040afd74 Author: Jiri Kosina Date: Fri Feb 26 16:15:17 2016 +0100 kbuild/mkspec: fix grub2 installkernel issue commit c8b08ca558c0067bc9e15ce3f1e70af260410bb2 upstream. mkspec is copying built kernel to temporrary location /boot/vmlinuz-$KERNELRELEASE-rpm and runs installkernel on it. This however directly leads to grub2 menuentry for this suffixed binary being generated as well during the run of installkernel script. Later in the process the temporary -rpm suffixed files are removed, and therefore we end up with spurious (and non-functional) grub2 menu entries for each installed kernel RPM. Fix that by using a different temporary name (prefixed by '.'), so that the binary is not recognized as an actual kernel binary and no menuentry is created for it. Signed-off-by: Jiri Kosina Fixes: 3c9c7a14b627 ("rpm-pkg: add %post section to create initramfs and grub hooks") Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 96948d63f84ece478a4bdb22ea09e1cd7d5b2b8f Author: Jan Beulich Date: Mon Jan 25 09:45:47 2016 -0700 scripts/kconfig: allow building with make 3.80 again commit 42f9d3c6888bceef6dc7ba72c77acf47347dcf05 upstream. Documentation/Changes still lists this as the minimal required version, so it ought to remain usable for the time being. Fixes: d2036f30cf ("scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target") Signed-off-by: Jan Beulich Cc: Michael Ellerman Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 1c77b5c4060a7e96e86eb332e0a9f5a3e7a95be0 Author: Julia Lawall Date: Thu Feb 18 00:16:14 2016 +0100 scripts/coccinelle: modernize & commit 1b669e713f277a4d4b3cec84e13d16544ac8286d upstream. & is no longer allowed in column 0, since Coccinelle 1.0.4. Signed-off-by: Julia Lawall Tested-by: Nishanth Menon Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 3c2aed0537b998d2b003fbd7b2f83faa6b77b80b Author: Peter Zijlstra Date: Wed Mar 9 12:40:54 2016 +0100 bitops: Do not default to __clear_bit() for __clear_bit_unlock() commit f75d48644c56a31731d17fa693c8175328957e1d upstream. __clear_bit_unlock() is a special little snowflake. While it carries the non-atomic '__' prefix, it is specifically documented to pair with test_and_set_bit() and therefore should be 'somewhat' atomic. Therefore the generic implementation of __clear_bit_unlock() cannot use the fully non-atomic __clear_bit() as a default. If an arch is able to do better; is must provide an implementation of __clear_bit_unlock() itself. Specifically, this came up as a result of hackbench livelock'ing in slab_lock() on ARC with SMP + SLUB + !LLSC. The issue was incorrect pairing of atomic ops. slab_lock() -> bit_spin_lock() -> test_and_set_bit() slab_unlock() -> __bit_spin_unlock() -> __clear_bit() The non serializing __clear_bit() was getting "lost" 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set 80543b90: or r3,r2,1 <--- (B) other core unlocks right here 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock) Fixes ARC STAR 9000817404 (and probably more). Reported-by: Vineet Gupta Tested-by: Vineet Gupta Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Christoph Lameter Cc: David Rientjes Cc: Helge Deller Cc: James E.J. Bottomley Cc: Joonsoo Kim Cc: Linus Torvalds Cc: Noam Camus Cc: Paul E. McKenney Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 085bf9a35c8e102315881a4bd8d2596f8a767739 Author: Steven Rostedt (Red Hat) Date: Tue Mar 22 17:30:58 2016 -0400 tracing: Fix trace_printk() to print when not using bprintk() commit 3debb0a9ddb16526de8b456491b7db60114f7b5e upstream. The trace_printk() code will allocate extra buffers if the compile detects that a trace_printk() is used. To do this, the format of the trace_printk() is saved to the __trace_printk_fmt section, and if that section is bigger than zero, the buffers are allocated (along with a message that this has happened). If trace_printk() uses a format that is not a constant, and thus something not guaranteed to be around when the print happens, the compiler optimizes the fmt out, as it is not used, and the __trace_printk_fmt section is not filled. This means the kernel will not allocate the special buffers needed for the trace_printk() and the trace_printk() will not write anything to the tracing buffer. Adding a "__used" to the variable in the __trace_printk_fmt section will keep it around, even though it is set to NULL. This will keep the string from being printed in the debugfs/tracing/printk_formats section as it is not needed. Reported-by: Vlastimil Babka Fixes: 07d777fe8c398 "tracing: Add percpu buffers for trace_printk()" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit df71f9def05fd07d5c3efafafcec062d37c766ca Author: Steven Rostedt (Red Hat) Date: Fri Mar 18 15:46:48 2016 -0400 tracing: Fix crash from reading trace_pipe with sendfile commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream. If tracing contains data and the trace_pipe file is read with sendfile(), then it can trigger a NULL pointer dereference and various BUG_ON within the VM code. There's a patch to fix this in the splice_to_pipe() code, but it's also a good idea to not let that happen from trace_pipe either. Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.in Reported-by: Rabin Vincent Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit aad387ef9b0712b46ab4ac7ef8d8603dca8ca22b Author: Steven Rostedt (Red Hat) Date: Fri Mar 18 12:27:43 2016 -0400 tracing: Have preempt(irqs)off trace preempt disabled functions commit cb86e05390debcc084cfdb0a71ed4c5dbbec517d upstream. Joel Fernandes reported that the function tracing of preempt disabled sections was not being reported when running either the preemptirqsoff or preemptoff tracers. This was due to the fact that the function tracer callback for those tracers checked if irqs were disabled before tracing. But this fails when we want to trace preempt off locations as well. Joel explained that he wanted to see funcitons where interrupts are enabled but preemption was disabled. The expected output he wanted: <...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit <...>-2265 1d..1 3419us : __do_softirq <-irq_exit <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq There's a comment saying that the irq disabled check is because there's a possible race that tracing_cpu may be set when the function is executed. But I don't remember that race. For now, I added a check for preemption being enabled too to not record the function, as there would be no race if that was the case. I need to re-investigate this, as I'm now thinking that the tracing_cpu will always be correct. But no harm in keeping the check for now, except for the slight performance hit. Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com Fixes: 5e6d2b9cfa3a "tracing: Use one prologue for the preempt irqs off tracer function tracers" Reported-by: Joel Fernandes Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit be2a595b893abc01e33cde4f5a131059fbb314fe Author: Eric Huang Date: Tue Mar 15 17:00:22 2016 -0400 drm/amd/powerplay: add uvd/vce dpm enabling flag to fix the performance issue for CZ commit 60123300db80b17251b4de5e98c63e288c6f7b46 upstream. Set the UVD and VCE DPM flags otherwise UVD and VCE DPM won't get enabled. Reviewed-by: Alex Deucher Signed-off-by: Eric Huang Signed-off-by: Greg Kroah-Hartman commit 3cb70ad5ba726f8183ce36eddd2d01f84cd1a694 Author: Ken Wang Date: Thu Mar 17 17:26:57 2016 +0800 drm/amdgpu: include the right version of gmc header files for iceland commit 16a8a49be1b878ef6dd5d1663d456e254e54ae3d upstream. Signed-off-by: Ken Wang Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4eda74c8f554de83f7a99bb1b3582faea359bd8f Author: Alex Deucher Date: Wed Mar 2 12:10:20 2016 -0500 drm/amdgpu: disable runtime pm on PX laptops without dGPU power control commit bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1 upstream. Some PX laptops don't provide an ACPI method to control dGPU power. On those systems, the driver is responsible for handling the dGPU power state. Disable runtime PM on them until support for this is implemented. Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 43b98d3da00ba39c8231b072e95fa6dda800563f Author: Dave Airlie Date: Tue Mar 22 09:38:18 2016 +1000 drm/radeon/mst: fix regression in lane/link handling. commit b36f7d26a7fdc0b07b1217368ee09bb8560269f8 upstream. The function this used changed in 092c96a8ab9d1bd60ada2ed385cc364ce084180e drm/radeon: fix dp link rate selection (v2) However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it. This fixes my 30" monitor with MST enabled. Signed-off-by: Dave Airlie Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit daefb5da59e30eb96117fe61953d59da4d9e47fd Author: Alex Deucher Date: Thu Mar 10 15:55:26 2016 -0500 drm/radeon: rework fbdev handling on chips with no connectors commit e5f243bd2edd95c6cc1d90c1878f821068e83fba upstream. Move all the logic to radeon_fb.c and add checks to functions called frome elsewhere. bug: https://bugzilla.kernel.org/show_bug.cgi?id=112781 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2ed9f0a85932797d2ce9bbd7b1d26f3301b59812 Author: Mario Kleiner Date: Sun Mar 6 02:39:53 2016 +0100 drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards. commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream. As observed on Apple iMac10,1, DCE-3.2, RV-730, link rate of 2.7 Ghz is not selected, because the args.v1.ucConfig flag setting for 2.7 Ghz gets overwritten by a following assignment of the transmitter to use. Move link rate setup a few lines down to fix this. In practice this didn't have any positive or negative effect on display setup on the tested iMac10,1 so i don't know if backporting to stable makes sense or not. Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5a427809cd9143bef89ee3110f45e84f37484218 Author: Alex Deucher Date: Wed Mar 2 11:47:29 2016 -0500 drm/radeon: disable runtime pm on PX laptops without dGPU power control commit e64c952efb8e0c15ae82cec8e455ab4910690ef1 upstream. Some PX laptops don't provide an ACPI method to control dGPU power. On those systems, the driver is responsible for handling the dGPU power state. Disable runtime PM on them until support for this is implemented. Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e53000e9501a8a369bff6be75b1e389f5bce9547 Author: Dan Carpenter Date: Tue Mar 8 15:09:41 2016 +0300 drm/vc4: Return -EFAULT on copy_from_user() failure commit 585cb132a48190b554aecda2ebc3e2911fcbb665 upstream. The copy_from_user() function returns the number of bytes not copied but we want to return a negative error code. Fixes: 463873d57014 ('drm/vc4: Add an API for creating GPU shaders in GEM BOs.') Signed-off-by: Dan Carpenter Reviewed-by: Eric Anholt Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 82432aeba3f6fad3ab7419065a1599c9376e26ca Author: Aurelien Jacquiot Date: Tue Mar 22 14:25:42 2016 -0700 rapidio/rionet: fix deadlock on SMP commit 36915976eca58f2eefa040ba8f9939672564df61 upstream. Fix deadlocking during concurrent receive and transmit operations on SMP platforms caused by the use of incorrect lock: on transmit 'tx_lock' spinlock should be used instead of 'lock' which is used for receive operation. This fix is applicable to kernel versions starting from v2.15. Signed-off-by: Aurelien Jacquiot Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: Andre van Herk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 440447be970afd7563826ee839854e06f48b2215 Author: Jann Horn Date: Tue Mar 22 14:25:36 2016 -0700 fs/coredump: prevent fsuid=0 dumps into user-controlled directories commit 378c6520e7d29280f400ef2ceaf155c86f05a71a upstream. This commit fixes the following security hole affecting systems where all of the following conditions are fulfilled: - The fs.suid_dumpable sysctl is set to 2. - The kernel.core_pattern sysctl's value starts with "/". (Systems where kernel.core_pattern starts with "|/" are not affected.) - Unprivileged user namespace creation is permitted. (This is true on Linux >=3.8, but some distributions disallow it by default using a distro patch.) Under these conditions, if a program executes under secure exec rules, causing it to run with the SUID_DUMP_ROOT flag, then unshares its user namespace, changes its root directory and crashes, the coredump will be written using fsuid=0 and a path derived from kernel.core_pattern - but this path is interpreted relative to the root directory of the process, allowing the attacker to control where a coredump will be written with root privileges. To fix the security issue, always interpret core_pattern for dumps that are written under SUID_DUMP_ROOT relative to the root directory of init. Signed-off-by: Jann Horn Acked-by: Kees Cook Cc: Al Viro Cc: "Eric W. Biederman" Cc: Andy Lutomirski Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a8d96c5661026eebaea55ef3cdc20342d83ac010 Author: Jan Kiszka Date: Tue Mar 22 14:27:39 2016 -0700 scripts/gdb: account for changes in module data structure commit ad4db3b24a93e52a92ad8f9b0273a9416f202c23 upstream. Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.") factored out the module_layout structure. Adjust the symbol loader and the lsmod command to this. Signed-off-by: Jan Kiszka Reviewed-by: Kieran Bingham Tested-by: Kieran Bingham (qemu-{ARM,x86}) Cc: Rusty Russell Cc: Jiri Kosina Cc: Jason Wessel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7857985ba3cd8a5c239f0023dedf56a31d9f3458 Author: Seth Forshee Date: Fri Mar 11 10:35:34 2016 -0600 fuse: Add reference counting for fuse_io_priv commit 744742d692e37ad5c20630e57d526c8f2e2fe3c9 upstream. The 'reqs' member of fuse_io_priv serves two purposes. First is to track the number of oustanding async requests to the server and to signal that the io request is completed. The second is to be a reference count on the structure to know when it can be freed. For sync io requests these purposes can be at odds. fuse_direct_IO() wants to block until the request is done, and since the signal is sent when 'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to use the object after the userspace server has completed processing requests. This leads to some handshaking and special casing that it needlessly complicated and responsible for at least one race condition. It's much cleaner and safer to maintain a separate reference count for the object lifecycle and to let 'reqs' just be a count of outstanding requests to the userspace server. Then we can know for sure when it is safe to free the object without any handshaking or special cases. The catch here is that most of the time these objects are stack allocated and should not be freed. Initializing these objects with a single reference that is never released prevents accidental attempts to free the objects. Fixes: 9d5722b7777e ("fuse: handle synchronous iocbs internally") Signed-off-by: Seth Forshee Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit f5b07883c0c3b68c9f04f1d573949c9621ab3395 Author: Robert Doebbelin Date: Mon Mar 7 09:50:56 2016 +0100 fuse: do not use iocb after it may have been freed commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 upstream. There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an iocb that could have been freed if async io has already completed. The fix in this case is simple and obvious: cache the result before starting io. It was discovered by KASan: kernel: ================================================================== kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390 Signed-off-by: Robert Doebbelin Signed-off-by: Miklos Szeredi Fixes: bcba24ccdc82 ("fuse: enable asynchronous processing direct IO") Signed-off-by: Greg Kroah-Hartman commit bdb486fac4c1cc167fe9017e3fd3bc5b88090d6e Author: Ming Lei Date: Sat Mar 12 09:29:40 2016 +0800 md: multipath: don't hardcopy bio in .make_request path commit fafcde3ac1a418688a734365203a12483b83907a upstream. Inside multipath_make_request(), multipath maps the incoming bio into low level device's bio, but it is totally wrong to copy the bio into mapped bio via '*mapped_bio = *bio'. For example, .__bi_remaining is kept in the copy, especially if the incoming bio is chained to via bio splitting, so .bi_end_io can't be called for the mapped bio at all in the completing path in this kind of situation. This patch fixes the issue by using clone style. Reported-and-tested-by: Andrea Righi Signed-off-by: Ming Lei Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit ea43a45d9885879257d985ff139cbb999ff3e830 Author: NeilBrown Date: Wed Mar 9 12:58:25 2016 +1100 md/raid5: preserve STRIPE_PREREAD_ACTIVE in break_stripe_batch_list commit 550da24f8d62fe81f3c13e3ec27602d6e44d43dc upstream. break_stripe_batch_list breaks up a batch and copies some flags from the batch head to the members, preserving others. It doesn't preserve or copy STRIPE_PREREAD_ACTIVE. This is not normally a problem as STRIPE_PREREAD_ACTIVE is cleared when a stripe_head is added to a batch, and is not set on stripe_heads already in a batch. However there is no locking to ensure one thread doesn't set the flag after it has just been cleared in another. This does occasionally happen. md/raid5 maintains a count of the number of stripe_heads with STRIPE_PREREAD_ACTIVE set: conf->preread_active_stripes. When break_stripe_batch_list clears STRIPE_PREREAD_ACTIVE inadvertently this could becomes incorrect and will never again return to zero. md/raid5 delays the handling of some stripe_heads until preread_active_stripes becomes zero. So when the above mention race happens, those stripe_heads become blocked and never progress, resulting is write to the array handing. So: change break_stripe_batch_list to preserve STRIPE_PREREAD_ACTIVE in the members of a batch. URL: https://bugzilla.kernel.org/show_bug.cgi?id=108741 URL: https://bugzilla.redhat.com/show_bug.cgi?id=1258153 URL: http://thread.gmane.org/5649C0E9.2030204@zoner.cz Reported-by: Martin Svec (and others) Tested-by: Tom Weber Fixes: 1b956f7a8f9a ("md/raid5: be more selective about distributing flags across batch.") Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit ab0191ed83bcf1367ea66109eb76a789f8085e85 Author: Shaohua Li Date: Mon Mar 14 11:49:32 2016 -0700 raid10: include bio_end_io_list in nr_queued to prevent freeze_array hang commit 23ddba80ebe836476bb2fa1f5ef305dd1c63dc0b upstream. This is the raid10 counterpart of the bug fixed by Nate (raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang) Fixes: 95af587e95(md/raid10: ensure device failure recorded before write request returns) Cc: Nate Dailey Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 6e3bd6cee9b6f9dab7d175dc19245c0ccbe2376b Author: Shaohua Li Date: Thu Feb 25 16:24:42 2016 -0800 RAID5: revert e9e4c377e2f563 to fix a livelock commit 6ab2a4b806ae21b6c3e47c5ff1285ec06d505325 upstream. Revert commit e9e4c377e2f563(md/raid5: per hash value and exclusive wait_for_stripe) The problem is raid5_get_active_stripe waits on conf->wait_for_stripe[hash]. Assume hash is 0. My test release stripes in this order: - release all stripes with hash 0 - raid5_get_active_stripe still sleeps since active_stripes > max_nr_stripes * 3 / 4 - release all stripes with hash other than 0. active_stripes becomes 0 - raid5_get_active_stripe still sleeps, since nobody wakes up wait_for_stripe[0] The system live locks. The problem is active_stripes isn't a per-hash count. Revert the patch makes the live lock go away. Cc: Yuanhan Liu Cc: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 05961902a0a56dd7531671a13e0fef1a5b01d1e8 Author: Shaohua Li Date: Wed Feb 24 17:38:28 2016 -0800 RAID5: check_reshape() shouldn't call mddev_suspend commit 27a353c026a879a1001e5eac4bda75b16262c44a upstream. check_reshape() is called from raid5d thread. raid5d thread shouldn't call mddev_suspend(), because mddev_suspend() waits for all IO finish but IO is handled in raid5d thread, we could easily deadlock here. This issue is introduced by 738a273 ("md/raid5: fix allocation of 'scribble' array.") Reported-and-tested-by: Artur Paszkiewicz Reviewed-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit e7ffd7dbb5bc025c6d63416b8acba2b162f29bcb Author: Jes Sorensen Date: Tue Feb 16 16:44:24 2016 -0500 md/raid5: Compare apples to apples (or sectors to sectors) commit e7597e69dec59b65c5525db1626b9d34afdfa678 upstream. 'max_discard_sectors' is in sectors, while 'stripe' is in bytes. This fixes the problem where DISCARD would get disabled on some larger RAID5 configurations (6 or more drives in my testing), while it worked as expected with smaller configurations. Fixes: 620125f2bf8 ("MD: raid5 trim support") Signed-off-by: Jes Sorensen Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 43bcbdfec07740e5aa9e3bc98b66e360b1b22751 Author: Nate Dailey Date: Mon Feb 29 10:43:58 2016 -0500 raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang commit ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb upstream. If raid1d is handling a mix of read and write errors, handle_read_error's call to freeze_array can get stuck. This can happen because, though the bio_end_io_list is initially drained, writes can be added to it via handle_write_finished as the retry_list is processed. These writes contribute to nr_pending but are not included in nr_queued. If a later entry on the retry_list triggers a call to handle_read_error, freeze array hangs waiting for nr_pending == nr_queued+extra. The writes on the bio_end_io_list aren't included in nr_queued so the condition will never be satisfied. To prevent the hang, include bio_end_io_list writes in nr_queued. There's probably a better way to handle decrementing nr_queued, but this seemed like the safest way to avoid breaking surrounding code. I'm happy to supply the script I used to repro this hang. Fixes: 55ce74d4bfe1b(md/raid1: ensure device failure recorded before write request returns.) Signed-off-by: Nate Dailey Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 2011d17edfff18785d4c97d18150750fc7a27678 Author: Mateusz Guzik Date: Wed Mar 2 09:51:09 2016 +1100 xfs: fix two memory leaks in xfs_attr_list.c error paths commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f upstream. This plugs 2 trivial leaks in xfs_attr_shortform_list and xfs_attr3_leaf_list_int. Signed-off-by: Mateusz Guzik Reviewed-by: Eric Sandeen Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit b060595b62fdd94949b7e025edb6b1b709d1338c Author: Nikolay Borisov Date: Thu Mar 3 10:54:57 2016 +0100 quota: Fix possible GPF due to uninitialised pointers commit ab73ef46398e2c0159f3a71de834586422d2a44a upstream. When dqget() in __dquot_initialize() fails e.g. due to IO error, __dquot_initialize() will pass an array of uninitialized pointers to dqput_all() and thus can lead to deference of random data. Fix the problem by properly initializing the array. Signed-off-by: Nikolay Borisov Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit fee23d3f07d7a77358d15b7bf4ed71bdcd79858d Author: Vineet Gupta Date: Tue Mar 8 19:31:24 2016 +0530 ARC: bitops: Remove non relevant comments commit 2a41b6dc28dc71c1a3f1622612a26edc58f7561e upstream. commit 80f420842ff42 removed the ARC bitops microoptimization but failed to prune the comments to same effect Fixes: 80f420842ff42 ("ARC: Make ARC bitops "safer" (add anti-optimization)") Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 0f5136b999d6843f6f01c15dd109faffc26eef64 Author: Lada Trimasova Date: Wed Mar 9 20:21:04 2016 +0300 ARC: [BE] readl()/writel() to work in Big Endian CPU configuration commit f778cc65717687a3d3f26dd21bef62cd059f1b8b upstream. read{l,w}() write{l,w}() primitives should use le{16,32}_to_cpu() and cpu_to_le{16,32}() respectively to ensure device registers are read correctly in Big Endian CPU configuration. Per Arnd Bergmann | Most drivers using readl() or readl_relaxed() expect those to perform byte | swaps on big-endian architectures, as the registers tend to be fixed endian This was needed for getting UART to work correctly on a Big Endian ARC. The ARC accessors originally were fine, and the bug got introduced inadventently by commit b8a033023994 ("ARCv2: barriers") Fixes: b8a033023994 ("ARCv2: barriers") Link: http://lkml.kernel.org/r/201603100845.30602.arnd@arndb.de Cc: Alexey Brodkin Cc: Arnd Bergmann Signed-off-by: Lada Trimasova [vgupta: beefed up changelog, added Fixes/stable tags] Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 21e04f0f54c173acdd03035029e5d17ff3c82d27 Author: Alexey Brodkin Date: Thu Mar 17 12:41:52 2016 +0300 ARC: [plat-axs10x] add Ethernet PHY description in .dts commit 667a490bdb6e27db0887d2ca515b907d6aa87118 upstream. Commit e34d65696d2e ("stmmac: create of compatible mdio bus for stmmac driver") broke DW GMAC functionality on ARC AXS10x boards: That's what happens on eth0 up: --------------------------->8------------------------ | libphy: PHY stmmac-0:ffffffff not found | eth0: Could not attach to PHY | stmmac_open: Cannot attach to PHY (error: -19) --------------------------->8------------------------ Simplest solution is to add PHY description in board's .dts. And so we do here. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Phil Reid Cc: David S. Miller Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Reviewed-by: Sergei Shtylyov Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 91de40e5eb633dcd13e4e4521e37c64f0a7fc199 Author: Max Filippov Date: Thu Mar 3 18:34:29 2016 +0300 xtensa: clear all DBREAKC registers on start commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab upstream. There are XCHAL_NUM_DBREAK registers, clear them all. This also fixes cryptic assembler error message with binutils 2.25 when XCHAL_NUM_DBREAK is 0: as: out of memory allocating 18446744073709551575 bytes after a total of 495616 bytes Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit cee93c37dfee41c807587d81da17131ac5981369 Author: Max Filippov Date: Thu Feb 25 23:27:51 2016 +0300 xtensa: fix preemption in {clear,copy}_user_highpage commit a67cc9aa2dfc6e66addf240bbd79e16e01565e81 upstream. Disabling pagefault makes little sense there, preemption disabling is what was meant. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 1948cf2fd2a56d35ddb0190a1d84faa610f3622c Author: Max Filippov Date: Tue Feb 9 01:02:38 2016 +0300 xtensa: ISS: don't hang if stdin EOF is reached commit 362014c8d9d51d504c167c44ac280169457732be upstream. Simulator stdin may be connected to a file, when its end is reached kernel hangs in infinite loop inside rs_poll, because simc_poll always signals that descriptor 0 is readable and simc_read always returns 0. Check simc_read return value and exit loop if it's not positive. Also don't rewind polling timer if it's zero. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 28145de80722ca9347b3c334ca24b2eb021740b0 Author: Rabin Vincent Date: Thu Mar 10 21:19:06 2016 +0100 splice: handle zero nr_pages in splice_to_pipe() commit d6785d9152147596f60234157da2b02540c3e60f upstream. Running the following command: busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null with any tracing enabled pretty very quickly leads to various NULL pointer dereferences and VM BUG_ON()s, such as these: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [] generic_pipe_buf_release+0xc/0x40 Call Trace: [] splice_direct_to_actor+0x143/0x1e0 [] ? generic_pipe_buf_nosteal+0x10/0x10 [] do_splice_direct+0x8f/0xb0 [] do_sendfile+0x199/0x380 [] SyS_sendfile64+0x90/0xa0 [] entry_SYSCALL_64_fastpath+0x12/0x6d page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0) kernel BUG at include/linux/mm.h:367! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC RIP: [] generic_pipe_buf_release+0x3c/0x40 Call Trace: [] splice_direct_to_actor+0x143/0x1e0 [] ? generic_pipe_buf_nosteal+0x10/0x10 [] do_splice_direct+0x8f/0xb0 [] do_sendfile+0x199/0x380 [] SyS_sendfile64+0x90/0xa0 [] tracesys_phase2+0x84/0x89 (busybox's cat uses sendfile(2), unlike the coreutils version) This is because tracing_splice_read_pipe() can call splice_to_pipe() with spd->nr_pages == 0. spd_pages underflows in splice_to_pipe() and we fill the page pointers and the other fields of the pipe_buffers with garbage. All other callers of splice_to_pipe() avoid calling it when nr_pages == 0, and we could make tracing_splice_read_pipe() do that too, but it seems reasonable to have splice_to_page() handle this condition gracefully. Signed-off-by: Rabin Vincent Reviewed-by: Christoph Hellwig Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b6acfc9ffeaeec2a7439a82f53d224485e079881 Author: Dmitry V. Levin Date: Thu Mar 19 11:10:54 2015 +0000 vfs: show_vfsstat: do not ignore errors from show_devname method commit 5f8d498d4364f544fee17125787a47553db02afa upstream. Explicitly check show_devname method return code and bail out in case of an error. This fixes regression introduced by commit 9d4d65748a5c. Signed-off-by: Dmitry V. Levin Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit f06193469dc0fd269eb185db070412be32755023 Author: Vinayak Menon Date: Mon Feb 22 19:15:44 2016 +0530 of: alloc anywhere from memblock if range not specified commit e53b50c0cbe392c946807abf7d07615a3c588642 upstream. early_init_dt_alloc_reserved_memory_arch passes end as 0 to __memblock_alloc_base, when limits are not specified. But __memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE and limits the end to memblock.current_limit. This results in regions never being placed in HIGHMEM area, for e.g. CMA. Let __memblock_alloc_base allocate from anywhere in memory if limits are not specified. Acked-by: Marek Szyprowski Signed-off-by: Vinayak Menon Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 32f90caa7debdf12a4b582aafef8767254fbe372 Author: Hante Meuleman Date: Mon Feb 8 00:00:30 2016 +0100 brcmfmac: Increase nr of supported flowrings. commit 19c8f421a61947116898c9f8a28823b9d988df74 upstream. New generation devices have firmware which has more than 256 flowrings. E.g. following debugging message comes from 14e4:4365 BCM4366: [ 194.606245] brcmfmac: brcmf_pcie_init_ringbuffers Nr of flowrings is 264 At various code places (related to flowrings) we were using u8 which could lead to storing wrong number or infinite loops when indexing with this type. This issue was quite easy to spot in brcmf_flowring_detach where it led to infinite loop e.g. on failed initialization. This patch switches code to proper types and increases the maximum number of supported flowrings to 512. Originally this change was sent in September 2015, but back it was causing a regression on BCM43602 resulting in: Unable to handle kernel NULL pointer dereference at virtual address ... The reason for this regression was missing update (s/u8/u16) of struct brcmf_flowring_ring. This problem was handled in 9f64df9 ("brcmfmac: Fix bug in flowring management."). Starting with that it's safe to apply this original patch as it doesn't cause a regression anymore. This patch fixes an infinite loop on BCM4366 which is supported since 4.4 so it makes sense to apply it to stable 4.4+. Reviewed-by: Arend Van Spriel Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Hante Meuleman Signed-off-by: Arend van Spriel Signed-off-by: Rafał Miłecki Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit d386b6441a2d3f0f7acf79eff9fad757e3b97834 Author: Dmitri Epshtein Date: Sat Mar 12 18:44:18 2016 +0100 net: mvneta: enable change MAC address when interface is up commit 928b6519afeb2a5e2dc61154380b545ed66c476a upstream. Function eth_prepare_mac_addr_change() is called as part of MAC address change. This function check if interface is running. To enable change MAC address when interface is running: IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by: Dmitri Epshtein Signed-off-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4cb49eb06a537c1fc361226eb2aeff820b7909e2 Author: Tejun Heo Date: Tue Mar 15 20:43:04 2016 -0400 cgroup: ignore css_sets associated with dead cgroups during migration commit 2b021cbf3cb6208f0d40fd2f1869f237934340ed upstream. Before 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups"), all dead tasks were associated with init_css_set. If a zombie task is requested for migration, while migration prep operations would still be performed on init_css_set, the actual migration would ignore zombie tasks. As init_css_set is always valid, this worked fine. However, after 2e91fa7f6d45, zombie tasks stay with the css_set it was associated with at the time of death. Let's say a task T associated with cgroup A on hierarchy H-1 and cgroup B on hiearchy H-2. After T becomes a zombie, it would still remain associated with A and B. If A only contains zombie tasks, it can be removed. On removal, A gets marked offline but stays pinned until all zombies are drained. At this point, if migration is initiated on T to a cgroup C on hierarchy H-2, migration path would try to prepare T's css_set for migration and trigger the following. WARNING: CPU: 0 PID: 1576 at kernel/cgroup.c:474 cgroup_get+0x121/0x160() CPU: 0 PID: 1576 Comm: bash Not tainted 4.4.0-work+ #289 ... Call Trace: [] dump_stack+0x4e/0x82 [] warn_slowpath_common+0x78/0xb0 [] warn_slowpath_null+0x15/0x20 [] cgroup_get+0x121/0x160 [] link_css_set+0x7b/0x90 [] find_css_set+0x3bc/0x5e0 [] cgroup_migrate_prepare_dst+0x89/0x1f0 [] cgroup_attach_task+0x157/0x230 [] __cgroup_procs_write+0x2b7/0x470 [] cgroup_tasks_write+0xc/0x10 [] cgroup_file_write+0x30/0x1b0 [] kernfs_fop_write+0x13c/0x180 [] __vfs_write+0x23/0xe0 [] vfs_write+0xa4/0x1a0 [] SyS_write+0x44/0xa0 [] entry_SYSCALL_64_fastpath+0x12/0x6f It doesn't make sense to prepare migration for css_sets pointing to dead cgroups as they are guaranteed to contain only zombies which are ignored later during migration. This patch makes cgroup destruction path mark all affected css_sets as dead and updates the migration path to ignore them during preparation. Signed-off-by: Tejun Heo Fixes: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups") Signed-off-by: Greg Kroah-Hartman commit 5bf6fa3e6b4537c3270987777b30c0ab5283201d Author: Johan Hedberg Date: Fri Mar 11 09:56:33 2016 +0200 Bluetooth: Fix potential buffer overflow with Add Advertising commit 6a0e78072c2ae7b20b14e0249d8108441ea928d2 upstream. The Add Advertising command handler does the appropriate checks for the AD and Scan Response data, however fails to take into account the general length of the mgmt command itself, which could lead to potential buffer overflows. This patch adds the necessary check that the mgmt command length is consistent with the given ad and scan_rsp lengths. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 407cecfa130ae083363b1e805df050203d7d95e7 Author: Dmitry Tunin Date: Wed Feb 10 00:49:11 2016 +0300 Bluetooth: Add new AR3012 ID 0489:e095 commit 28c971d82fb58ef7cba22e5308be6d2d2590473d upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e095 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 This device requires ar3k/AthrBT_0x31010100.dfu and ar3k/ramps_0x31010100_40.dfu firmware files that are not in linux-firmware yet. BugLink: https://bugs.launchpad.net/bugs/1542944 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 1eb7feed5df0723542f411aa33099cd0b792b1a1 Author: Michael S. Tsirkin Date: Sun Feb 28 17:44:09 2016 +0200 watchdog: rc32434_wdt: fix ioctl error handling commit 10e7ac22cdd4d211cef99afcb9371b70cb175be6 upstream. Calling return copy_to_user(...) in an ioctl will not do the right thing if there's a pagefault: copy_to_user returns the number of bytes not copied in this case. Fix up watchdog/rc32434_wdt to do return copy_to_user(...)) ? -EFAULT : 0; instead. Signed-off-by: Michael S. Tsirkin Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 926a769ebbef28a75467cadf954022287a9a6299 Author: Joshua Hunt Date: Thu Mar 17 14:17:23 2016 -0700 watchdog: don't run proc_watchdog_update if new value is same as old commit a1ee1932aa6bea0bb074f5e3ced112664e4637ed upstream. While working on a script to restore all sysctl params before a series of tests I found that writing any value into the /proc/sys/kernel/{nmi_watchdog,soft_watchdog,watchdog,watchdog_thresh} causes them to call proc_watchdog_update(). NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. There doesn't appear to be a reason for doing this work every time a write occurs, so only do it when the values change. Signed-off-by: Josh Hunt Acked-by: Don Zickus Reviewed-by: Aaron Tomlin Cc: Ulrich Obergfell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fdeceaa4dffac020cc2c82a0479013a67b19a48d Author: Aaro Koskinen Date: Thu Mar 17 14:17:20 2016 -0700 drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy commit 4c11e554fb894b381a3dc47069259d87a2e6ffc9 upstream. Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use __ioread32_copy() instead of open-coding") switched to use a generic copy function, but failed to notice that the header pointer is updated between the two copies, resulting in bogus data being copied in the latter one. Fix by keeping the old header pointer. The patch fixes totally broken networking on WRT54GL router (both LAN and WLAN interfaces fail to probe). Fixes: 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use __ioread32_copy() instead of open-coding") Signed-off-by: Aaro Koskinen Reviewed-by: Stephen Boyd Cc: Rafal Milecki Cc: Hauke Mehrtens Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 84203c99e4c41f96354bc98b31ad5d27f081ee8a Author: Luis R. Rodriguez Date: Thu Mar 17 14:17:16 2016 -0700 ia64: define ioremap_uc() commit b0f84ac352762ed02d7ea9f284942a8cab7f9077 upstream. All architectures now need ioremap_uc(), ia64 seems defines this already through its ioremap_nocache() and it already ensures it *only* uses UC. This is needed since v4.3 to complete an allyesconfig compile on ia64, there were others archs that needed this, and this one seems to have fallen through the cracks. Signed-off-by: Luis R. Rodriguez Reported-by: kbuild test robot Acked-by: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 97729c37439040ec07807f0dbb71ea60ccbafd27 Author: Johannes Weiner Date: Thu Mar 17 14:20:28 2016 -0700 mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage commit b6e6edcfa40561e9c8abe5eecf1c96f8e5fd9c6f upstream. Setting the original memory.limit_in_bytes hardlimit is subject to a race condition when the desired value is below the current usage. The code tries a few times to first reclaim and then see if the usage has dropped to where we would like it to be, but there is no locking, and the workload is free to continue making new charges up to the old limit. Thus, attempting to shrink a workload relies on pure luck and hope that the workload happens to cooperate. To fix this in the cgroup2 memory.max knob, do it the other way round: set the limit first, then try enforcement. And if reclaim is not able to succeed, trigger OOM kills in the group. Keep going until the new limit is met, we run out of OOM victims and there's only unreclaimable memory left, or the task writing to memory.max is killed. This allows users to shrink groups reliably, and the behavior is consistent with what happens when new charges are attempted in excess of memory.max. Signed-off-by: Johannes Weiner Acked-by: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aa748be2b004bdb0c750b2ae2631be1a5da7ed08 Author: Johannes Weiner Date: Thu Mar 17 14:20:25 2016 -0700 mm: memcontrol: reclaim when shrinking memory.high below usage commit 588083bb37a3cea8533c392370a554417c8f29cb upstream. When setting memory.high below usage, nothing happens until the next charge comes along, and then it will only reclaim its own charge and not the now potentially huge excess of the new memory.high. This can cause groups to stay in excess of their memory.high indefinitely. To fix that, when shrinking memory.high, kick off a reclaim cycle that goes after the delta. Signed-off-by: Johannes Weiner Acked-by: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d9eab605571a30eb7224c04bd210fd8c0f62d275 Author: Eric Wheeler Date: Mon Mar 7 15:17:50 2016 -0800 bcache: fix cache_set_flush() NULL pointer dereference on OOM commit f8b11260a445169989d01df75d35af0f56178f95 upstream. When bch_cache_set_alloc() fails to kzalloc the cache_set, the asyncronous closure handling tries to dereference a cache_set that hadn't yet been allocated inside of cache_set_flush() which is called by __cache_set_unregister() during cleanup. This appears to happen only during an OOM condition on bcache_register. Signed-off-by: Eric Wheeler Signed-off-by: Greg Kroah-Hartman commit 1a25cf37e7b81dea32e159602e3df5d20f41421b Author: Eric Wheeler Date: Fri Feb 26 14:39:06 2016 -0800 bcache: fix race of writeback thread starting before complete initialization commit 07cc6ef8edc47f8b4fc1e276d31127a0a5863d4d upstream. The bch_writeback_thread might BUG_ON in read_dirty() if dc->sb==BDEV_STATE_DIRTY and bch_sectors_dirty_init has not yet completed its related initialization. This patch downs the dc->writeback_lock until after initialization is complete, thus preventing bch_writeback_thread from proceeding prematurely. See this thread: http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3453 Signed-off-by: Eric Wheeler Tested-by: Marc MERLIN Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3fad85dd222e33c0fdd2904aee5c5b4a64c1e4f6 Author: Eric Wheeler Date: Fri Feb 26 14:33:56 2016 -0800 bcache: cleaned up error handling around register_cache() commit 9b299728ed777428b3908ac72ace5f8f84b97789 upstream. Fix null pointer dereference by changing register_cache() to return an int instead of being void. This allows it to return -ENOMEM or -ENODEV and enables upper layers to handle the OOM case without NULL pointer issues. See this thread: http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3521 Fixes this error: gargamel:/sys/block/md5/bcache# echo /dev/sdh2 > /sys/fs/bcache/register bcache: register_cache() error opening sdh2: cannot allocate memory BUG: unable to handle kernel NULL pointer dereference at 00000000000009b8 IP: [] cache_set_flush+0x102/0x15c [bcache] PGD 120dff067 PUD 1119a3067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: veth ip6table_filter ip6_tables (...) CPU: 4 PID: 3371 Comm: kworker/4:3 Not tainted 4.4.2-amd64-i915-volpreempt-20160213bc1 #3 Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013 Workqueue: events cache_set_flush [bcache] task: ffff88020d5dc280 ti: ffff88020b6f8000 task.ti: ffff88020b6f8000 RIP: 0010:[] [] cache_set_flush+0x102/0x15c [bcache] Signed-off-by: Eric Wheeler Tested-by: Marc MERLIN Signed-off-by: Greg Kroah-Hartman commit ebd49ea0d0e29e9baafa657fc9e39f6c31f92107 Author: Bart Van Assche Date: Thu Feb 11 11:03:09 2016 -0800 IB/srpt: Simplify srpt_handle_tsk_mgmt() commit 51093254bf879bc9ce96590400a87897c7498463 upstream. Let the target core check task existence instead of the SRP target driver. Additionally, let the target core check the validity of the task management request instead of the ib_srpt driver. This patch fixes the following kernel crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt] Oops: 0002 [#1] SMP Call Trace: [] srpt_process_completion+0xde/0x570 [ib_srpt] [] srpt_compl_thread+0x13f/0x160 [ib_srpt] [] kthread+0xcf/0xe0 [] ret_from_fork+0x7c/0xb0 Signed-off-by: Bart Van Assche Fixes: 3e4f574857ee ("ib_srpt: Convert TMR path to target_submit_tmr") Tested-by: Alex Estrin Reviewed-by: Christoph Hellwig Cc: Nicholas Bellinger Cc: Sagi Grimberg Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit ccdfbd0dff3f3c63256eba9d27c6ec44def623e2 Author: Bart Van Assche Date: Tue Dec 15 16:38:22 2015 +0100 brd: Fix discard request processing commit 5e4298be45e83ecdffaabb370eea9396889b07f1 upstream. Avoid that discard requests with size => PAGE_SIZE fail with -EIO. Refuse discard requests if the discard size is not a multiple of the page size. Fixes: 2dbe54957636 ("brd: Refuse improperly aligned discard requests") Signed-off-by: Bart Van Assche Reviewed-by: Jan Kara Cc: Christoph Hellwig Cc: Robert Elliot Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a47d746eb510afbba2aefcdd52494e3bf44936f2 Author: Catalin Marinas Date: Wed Mar 9 16:31:29 2016 +0000 arm64: Update PTE_RDONLY in set_pte_at() for PROT_NONE permission commit fdc69e7df3cb24f18a93192641786e5b7ecd1dfe upstream. The set_pte_at() function must update the hardware PTE_RDONLY bit depending on the state of the PTE_WRITE and PTE_DIRTY bits of the given entry value. However, it currently only performs this for pte_valid() entries, ignoring PTE_PROT_NONE. The side-effect is that PROT_NONE mappings would not have the PTE_RDONLY bit set. Without CONFIG_ARM64_HW_AFDBM, this is not an issue since such PROT_NONE pages are not accessible anyway. With commit 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits"), the ptep_set_wrprotect() function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, only PTE_RDONLY is checked to assess the "dirty" status. Since set_pte_at() does not set this bit for PROT_NONE mappings, such pages may be considered "dirty" as a result of ptep_set_wrprotect(). This patch updates the pte_valid() check to pte_present() in set_pte_at(). It also adds PTE_PROT_NONE to the swap entry bits comment. Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") Signed-off-by: Catalin Marinas Reported-by: Ganapatrao Kulkarni Tested-by: Ganapatrao Kulkarni Signed-off-by: Greg Kroah-Hartman commit ba6d9e63dc9c43466ce711e685c2fb483749e0ab Author: Geert Uytterhoeven Date: Fri Mar 11 17:31:27 2016 +0100 gpio: pca953x: Fix pca953x_gpio_set_multiple() on 64-bit commit e0a8604f1300cefab4aeafe214fc57954a7b4487 upstream. pca953x_gpio_set_multiple() divides by 4 to convert from longs to bytes, which assumes a 32-bit platform, and is not correct on 64-bit platforms. Use "sizeof(...)" instead to fix this. Fixes: b4818afeacbd8182 ("gpio: pca953x: Add set_multiple to allow multiple bits to be set in one write.") Signed-off-by: Geert Uytterhoeven Acked-by: Phil Reid Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a00731d6f644bc8689a19147aae832e7b61d145d Author: OGAWA Hirofumi Date: Wed Mar 9 23:47:25 2016 -0500 jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path commit c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 upstream. On umount path, jbd2_journal_destroy() writes latest transaction ID (->j_tail_sequence) to be used at next mount. The bug is that ->j_tail_sequence is not holding latest transaction ID in some cases. So, at next mount, there is chance to conflict with remaining (not overwritten yet) transactions. mount (id=10) write transaction (id=11) write transaction (id=12) umount (id=10) <= the bug doesn't write latest ID mount (id=10) write transaction (id=11) crash mount [recovery process] transaction (id=11) transaction (id=12) <= valid transaction ID, but old commit must not replay Like above, this bug become the cause of recovery failure, or FS corruption. So why ->j_tail_sequence doesn't point latest ID? Because if checkpoint transactions was reclaimed by memory pressure (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated. (And another case is, __jbd2_journal_clean_checkpoint_list() is called with empty transaction.) So in above cases, ->j_tail_sequence is not pointing latest transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not done too. So, to fix this problem with minimum changes, this patch updates ->j_tail_sequence, and issue REQ_FLUSH. (With more complex changes, some optimizations would be possible to avoid unnecessary REQ_FLUSH for example though.) BTW, journal->j_tail_sequence = ++journal->j_transaction_sequence; Increment of ->j_transaction_sequence seems to be unnecessary, but ext3 does this. Signed-off-by: OGAWA Hirofumi Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 700c83eeeef5c34f571016bc8b993d11f663dd27 Author: Kamal Mostafa Date: Wed Jan 27 22:29:33 2016 -0800 tools/hv: Use include/uapi with __EXPORTED_HEADERS__ commit 50fe6dd10069e7c062e27f29606f6e91ea979399 upstream. Use the local uapi headers to keep in sync with "recently" added #define's (e.g. VSS_OP_REGISTER1). Fixes: 3eb2094c59e8 ("Adding makefile for tools/hv") Signed-off-by: Kamal Mostafa Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 119c1dacc482ea9c33d4abb400128b61f12181d4 Author: Takashi Iwai Date: Mon Mar 21 16:07:30 2016 +0100 ALSA: hda - Fix missing ELD update at unplugging commit c64c1437afb14ebc900e40910f31ffb20bf652ad upstream. i915 get_eld ops may return an error when no encoder is connected, and currently we regard the error as fatal and skip the whole ELD handling. This ended up with the missing ELD update at unplugging. This patch fixes the issue by treating the error as the unplugged state, instead of skipping the rest. Reported-by: Libin Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6a077092ff4a4db95ddc92161351b538453ad6e6 Author: Takashi Iwai Date: Sat Mar 19 10:40:21 2016 +0100 ALSA: hda - Workaround for unbalanced i915 power refcount by concurrent probe commit 7169701ad3f9fadd7413b354ae317e67c0b37389 upstream. The recent addition of on-demand i915 audio component binding in the codec driver seems leading to the unbalanced i915 power refcount, according to Intel CI tests. Typically, it gets a kernel WARNING like: WARNING: CPU: 3 PID: 173 at sound/hda/hdac_i915.c:91 snd_hdac_display_power+0xf1/0x110 [snd_hda_core]() Call Trace: [] dump_stack+0x67/0x92 [] warn_slowpath_common+0x81/0xc0 [] warn_slowpath_null+0x15/0x20 [] snd_hdac_display_power+0xf1/0x110 [snd_hda_core] [] azx_intel_link_power+0xd/0x10 [snd_hda_intel] [] azx_link_power+0x1a/0x30 [snd_hda_codec] [] snd_hdac_link_power+0x29/0x40 [snd_hda_core] [] hda_codec_runtime_suspend+0x76/0xa0 [snd_hda_codec] ..... The scenario is like below: - HD-audio driver and i915 driver are probed concurrently at the (almost) same time; HDA bus tries to bind with i915, but it fails because i915 initialization is still being processed. - Later on, HD-audio probes the HDMI codec, where it again tries to bind with i915. At this time, it succeeds. - At finishing the probe of HDA, it decreases the refcount as if it were already bound at the bus probe, since the component is bound now. This triggers a kernel WARNING due to the unbalance. As a workaround, in this patch, we just disable the on-demand i915 component binding in the codec driver. This essentially reverts back to the state of 4.4 kernel. We know that this is no real solution, but it's a minimalistic simple change that can be applied to 4.5.x kernel as stable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94566 Reported-by: Ville Syrjälä Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 882485f7e0bd630275bb4ac2663296c831906a1e Author: Takashi Iwai Date: Fri Mar 18 18:01:53 2016 +0100 ALSA: hda - Fix forgotten HDMI monitor_present update commit bd48128539ab89986b24ad08ecd3e027dd1993a1 upstream. We forgot to copy monitor_present value when updating the ELD information. This won't change the ELD retrieval and the jack notification behavior, but appears only in the proc output. In that sense, it's no fatal error, but a bug is a bug is a bug. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit eab276c76a15771c6d4f66880a45db82f7f15b4d Author: Takashi Iwai Date: Fri Mar 18 15:10:08 2016 +0100 ALSA: hda - Really restrict i915 notifier to HSW+ commit 691be973c0621255abb31572a98e35c57be70212 upstream. The commit [b62232d429fa: ALSA: hda - Limit i915 HDMI binding only for HSW and later] tried to limit the usage of i915 audio notifier to the recent Intel models and switch to the old method on pre-Haswell models. However, it assumed that the i915 component binding hasn't been done on such models, and the assumption was wrong: namely, Baytrail had already the i915 component binding due to powerwell control. Thus, the workaround wasn't applied to Baytrail. For fixing this properly, this patch introduces a new flag indicating the usage of audio notifier and codec_has_acomp() refers to this flag instead of checking the existence of audio component. Reported-by: Ville Syrjälä Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2ba6a660925b2d01ff8bf70c7bc0e5b131ddd6fe Author: Takashi Iwai Date: Fri Mar 18 19:45:13 2016 +0100 ALSA: hda - Fix spurious kernel WARNING on Baytrail HDMI commit 93a9ff151754fbdf951b1b993bcf96453f6e36b3 upstream. snd_hdac_sync_audio_rate() call is mandatory only for HSW and later models, but we call the function unconditionally blindly assuming that the function doesn't do anything harmful. But since recently, the function checks the validity of the passed pin NID, and eventually spews the warning if an unexpected pin is passed. This is seen on old chips like Baytrail. The fix is to limit the call of this function again only for the chips with the proper binding. This can be identified by the same flag as the eld notifier. Reported-by: Ville Syrjälä Tested-by: Ville Syrjälä Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4cda9ceeb71eed24a4e641481740333853b53e9f Author: Takashi Iwai Date: Tue Mar 15 18:15:26 2016 +0100 ALSA: hda - Limit i915 HDMI binding only for HSW and later commit b62232d429fa8b1dcf5d8503aa5a5397a03e646a upstream. It turned out that the pre-HSW Intel chips are incompatible with the naive assumption we had -- the fixed mapping between the port and the HD-audio widget. This may result in the bad access, as captured by the recent patch to add a WARN_ON() for the port mapping check. As a quick workaround, disable the i915 audio component binding for all pre-Haswell models. Reported-by: Ville Syrjälä Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d167c1d116598ca41dd4002b7d7ca8f9e75067e6 Author: Takashi Iwai Date: Tue Mar 15 16:44:55 2016 +0100 ALSA: hda - Fix unconditional GPIO toggle via automute commit 1f7c6658962fa1260c1658d681bd6bb0c746b99a upstream. Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically depending on the jack plug state. This works fine for the auto-mute mode where the speaker gets muted upon the HP jack plug. OTOH, when the auto-mute mode is off, this turns off the EAPD unexpectedly depending on the jack state, which results in the silent speaker output. This patch fixes the silent speaker output issue by setting GPIO bits constantly when the auto-mute mode is off. Reported-and-tested-by: moosotc@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9c0b5bef353e04908bd15e004cea703e6d2f9d8d Author: Aaron Plattner Date: Sun Mar 13 13:58:57 2016 -0700 ALSA: hda - Add new GPU codec ID 0x10de0082 to snd-hda commit 2d369c748c2ecc2a012ee85412a04007e67913ec upstream. Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip. This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is appropriate here. Signed-off-by: Aaron Plattner Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8913cc8e4642b31cab1313c227a2613536260d97 Author: Hui Wang Date: Fri Mar 11 12:04:02 2016 +0800 ALSA: hda - fix the mic mute button and led problem for a Lenovo AIO commit 6ef2f68fa38bf415830f67903d87180d933e0f47 upstream. This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and uses GPIO2 to control the mic mute led, so applying this quirk can make both the button and led work. BugLink: https://bugs.launchpad.net/bugs/1555912 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f3e8a9206c6fd6932c79a120de6f8373ccd6b9c6 Author: Takashi Iwai Date: Thu Mar 10 12:02:49 2016 +0100 ALSA: hda - Don't handle ELD notify from invalid port commit 4f8e4f3537cafc4de128e6bfdf83baa78bc60eb1 upstream. The current Intel HDMI codec driver supports only three fixed ports from port B to port D. However, i915 driver may assign a DP on other ports, e.g. port A, when no eDP is used. This incompatibility is caught later at pin_nid_to_pin_index() and results in a warning message like "HDMI: pin nid 4 not registered" at each time. This patch filters out such invalid events beforehand, so that the kernel won't be too grumbling. Reported-by: Stefan Assmann Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3c49e7be596c2b4e46f4e68d41efdf59f0522f96 Author: Vittorio Gambaletta (VittGam) Date: Sun Mar 13 22:19:34 2016 +0100 ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41. commit 4061db03dd71d195b9973ee466f6ed32f6a3fc16 upstream. The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41 will often fail, so add a quirk entry to fix it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087 Signed-off-by: Vittorio Gambaletta Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1a7ee6d661a358f89afd29698742eca6bddfc5e8 Author: Takashi Iwai Date: Thu Mar 10 20:56:20 2016 +0100 ALSA: pcm: Avoid "BUG:" string for warnings again commit 0ab1ace856205d10cbc1924b2d931c01ffd216a6 upstream. The commit [d507941beb1e: ALSA: pcm: Correct PCM BUG error message] made the warning prefix back to "BUG:" due to its previous wrong prefix. But a kernel message containing "BUG:" seems taken as an Oops message wrongly by some brain-dead daemons, and it annoys users in the end. Instead of teaching daemons, change the string again to a more reasonable one. Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message') Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae712cca8fa882fb3edce630d835db4b8a863637 Author: Takashi Iwai Date: Thu Mar 10 11:33:43 2016 +0100 ALSA: hda - Apply reboot D3 fix for CX20724 codec, too commit 56dc66ff1c6d71f9a38c4a7c000b72b921fe4c89 upstream. Just like CX20722, CX7024 codec also requires the power down at reboot in order to reduce the noise at reboot/shutdown. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cf5c079c8112aa87b7c724f91ce878cb127c0848 Author: Takashi Iwai Date: Fri Mar 4 11:34:18 2016 +0100 ALSA: hda - Fix unexpected resume through regmap code path commit fc4f000bf8c0cbf38f44de6bd5e225574e572ed4 upstream. HD-audio driver has a mechanism to trigger the runtime resume automatically at accessing the verbs. This auto-resume, however, causes the mutex deadlock when invoked from the regmap handler since the regmap keeps the mutex while auto-resuming. For avoiding that, there is some tricky check in the HDA regmap handler to return -EAGAIN error to back-off when the codec is powered down. Then the caller of regmap r/w will retry after properly turning on the codec power. This works in most cases, but there seems a slight race between the codec power check and the actual on-demand auto-resume trigger. This resulted in the lockdep splat, eventually leading to a real deadlock. This patch tries to address the race window by getting the runtime PM refcount at the check time using pm_runtime_get_if_in_use(). With this call, we can keep the power on only when the codec has been already turned on, and back off if not. For keeping the code consistency, the code touching the runtime PM is stored in hdac_device.c although it's used only locally in hdac_regmap.c. Reported-by: Jiri Slaby Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 840c32e2275c9e7dd6eb50b0cb13a80a4c64149e Author: Asai Thambi SP Date: Wed Feb 24 21:21:20 2016 -0800 mtip32xx: Cleanup queued requests after surprise removal commit 008e56d200225321371748d95908e6222436f06d upstream. Fail all pending requests after surprise removal of a drive. Signed-off-by: Vignesh Gunasekaran Signed-off-by: Selvan Mani Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c68cbb5d08bb96fa2c2db222e5b3822ab1ca424e Author: Asai Thambi SP Date: Wed Feb 24 21:21:13 2016 -0800 mtip32xx: Implement timeout handler commit abb0ccd185c9e31847709b86192e6c815d1f57ad upstream. Added timeout handler. Replaced blk_mq_end_request() with blk_mq_complete_request() to avoid double completion of a request. Signed-off-by: Selvan Mani Signed-off-by: Rajesh Kumar Sambandam Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d104b7984c24739c843a6febf854a3d5d4e8ce34 Author: Asai Thambi SP Date: Wed Feb 24 21:18:20 2016 -0800 mtip32xx: Handle FTL rebuild failure state during device initialization commit aae4a033868c496adae86fc6f9c3e0c405bbf360 upstream. Allow device initialization to finish gracefully when it is in FTL rebuild failure state. Also, recover device out of this state after successfully secure erasing it. Signed-off-by: Selvan Mani Signed-off-by: Vignesh Gunasekaran Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2b04da830d73677bead3c76af96bab282a576f7c Author: Asai Thambi SP Date: Wed Feb 24 21:18:10 2016 -0800 mtip32xx: Handle safe removal during IO commit 51c6570eb922146470c2fe660c34585414679bd6 upstream. Flush inflight IOs using fsync_bdev() when the device is safely removed. Also, block further IOs in device open function. Signed-off-by: Selvan Mani Signed-off-by: Rajesh Kumar Sambandam Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8549dade0714eea2a41499ec0f4072fbca2d7b93 Author: Asai Thambi SP Date: Wed Feb 24 21:17:47 2016 -0800 mtip32xx: Fix for rmmod crash when drive is in FTL rebuild commit 59cf70e236c96594d9f1e065755d8fce9df5356b upstream. When FTL rebuild is in progress, alloc_disk() initializes the disk but device node will be created by add_disk() only after successful completion of FTL rebuild. So, skip deletion of device node in removal path when FTL rebuild is in progress. Signed-off-by: Selvan Mani Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8fe0b7c5dc3615a9ebb035cb8addbbcce7c770c7 Author: Asai Thambi SP Date: Wed Feb 24 21:16:38 2016 -0800 mtip32xx: Print exact time when an internal command is interrupted commit 5b7e0a8ac85e2dfd83830dc9e0b3554d153a37e3 upstream. Print exact time when an internal command is interrupted. Signed-off-by: Selvan Mani Signed-off-by: Rajesh Kumar Sambandam Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 42c602f22692065c3efd9910c79b2912ac8e6cd2 Author: Asai Thambi SP Date: Wed Feb 24 21:16:21 2016 -0800 mtip32xx: Remove unwanted code from taskfile error handler commit e35b94738a2f7caa12017f69ef385cb6b8028965 upstream. Remove setting and clearing MTIP_PF_EH_ACTIVE_BIT flag in mtip_handle_tfe() as they are redundant. Also avoid waking up service thread from mtip_handle_tfe() because it is already woken up in case of taskfile error. Signed-off-by: Selvan Mani Signed-off-by: Rajesh Kumar Sambandam Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7a1ee4874e3f203c402eb739c52b8e7d3d2184b9 Author: Asai Thambi SP Date: Wed Feb 24 21:16:00 2016 -0800 mtip32xx: Fix broken service thread handling commit cfc05bd31384c4898bf2437a4de5557f3cf9803a upstream. Service thread does not detect the need for taskfile error hanlding. Fixed the flag condition to process taskfile error. Signed-off-by: Selvan Mani Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 38ba8fb38471226498cd028e008845795e26de12 Author: Asai Thambi SP Date: Wed Feb 24 21:17:32 2016 -0800 mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild commit d8a18d2d8f5de55666c6011ed175939d22c8e3d8 upstream. Prevent standby immediate command from being issued in remove, suspend and shutdown paths, while drive is in FTL rebuild process. Signed-off-by: Selvan Mani Signed-off-by: Vignesh Gunasekaran Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2251e0c2f2625379c84bb042aa323e1d2562afc0 Author: Tiffany Lin Date: Tue Jan 19 05:56:50 2016 -0200 media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32 commit 7df5ab8774aa383c6d2bff00688d004585d96dfd upstream. In v4l2-compliance utility, test QUERYBUF required correct length value to go through each planar to check planar's length in multi-planar buffer type Signed-off-by: Tiffany Lin Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d3f602634faa2026c29c3e1b18850b81f8db44b3 Author: Philipp Zabel Date: Mon Jan 4 17:30:09 2016 -0200 coda: fix first encoded frame payload commit 74dc385cb450089b28c28be2c8a0baca296b95f9 upstream. During the recent vb2_buffer restructuring, the calculation of the buffer payload reported to userspace was accidentally broken for the first encoded frame, counting only the length of the headers. This patch re-adds the length of the actual frame data. Fixes: 2d7007153f0c ("[media] media: videobuf2: Restructure vb2_buffer") Reported-by: Michael Olbrich Signed-off-by: Philipp Zabel Tested-by: Jan Luebbe Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1e76c98a17113b972ae5a743355e40c346fa4246 Author: Hans de Goede Date: Sun Feb 7 09:24:29 2016 -0200 bttv: Width must be a multiple of 16 when capturing planar formats commit 5c915c68763889f0183a1cc61c84bb228b60124a upstream. On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max size results in a solid green rectangle being captured (all colors 0 in YUV). This turns out to be caused by max-width (924) not being a multiple of 16. We've likely never hit this problem before since normally xawtv / tvtime, etc. will prefer packed pixel formats. But when using a video card which is using xf86-video-modesetting + glamor, only planar XVideo fmts are available, and xawtv will chose a matching capture format to avoid needing to do conversion, triggering the solid green window problem. Signed-off-by: Hans de Goede Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d7c7fba6e44878c3124812ec029f85ab6a36fbf0 Author: Hans Verkuil Date: Wed Feb 10 09:32:25 2016 -0200 adv7511: TX_EDID_PRESENT is still 1 after a disconnect commit b339a72e04a62f0b1882c43492fc712f1176b3e6 upstream. The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present. The adv7511 however still reported the EDID present after disconnecting the HDMI cable. Fix the logic regarding this control. And when the EDID is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver. This was also missing. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cd91369dc2c521e03bd5b379f65c36128ac7835c Author: Hans de Goede Date: Sun Feb 14 17:51:37 2016 -0200 saa7134: Fix bytesperline not being set correctly for planar formats commit 3e71da19f9dc22e39a755d6ae9678661abb66adc upstream. bytesperline should be the bytesperline for the first plane for planar formats, not that of all planes combined. This fixes a crash in xawtv caused by the wrong bpl. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389 Reported-and-tested-by: Stas Sergeev Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4b49f76bc5b4dfe1c23bd7cfee2f83ccdda61c16 Author: Sebastian Frias Date: Fri Dec 18 17:40:05 2015 +0100 8250: use callbacks to access UART_DLL/UART_DLM commit 0b41ce991052022c030fd868e03877700220b090 upstream. Some UART HW has a single register combining UART_DLL/UART_DLM (this was probably forgotten in the change that introduced the callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9) Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...") Signed-off-by: Sebastian Frias Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 6eb8de25aa0bf84e86d1b1c78e755c2ef40f2762 Author: Peter Hurley Date: Sat Jan 9 17:48:45 2016 -0800 net: irda: Fix use-after-free in irtty_open() commit 401879c57f01cbf2da204ad2e8db910525c6dbea upstream. The N_IRDA line discipline may access the previous line discipline's closed and already-fre private data on open [1]. The tty->disc_data field _never_ refers to valid data on entry to the line discipline's open() method. Rather, the ldisc is expected to initialize that field for its own use for the lifetime of the instance (ie. from open() to close() only). [1] ================================================================== BUG: KASAN: use-after-free in irtty_open+0x422/0x550 at addr ffff8800331dd068 Read of size 4 by task a.out/13960 ============================================================================= BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- ... Call Trace: [] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:279 [] irtty_open+0x422/0x550 drivers/net/irda/irtty-sir.c:436 [] tty_ldisc_open.isra.2+0x60/0xa0 drivers/tty/tty_ldisc.c:447 [] tty_set_ldisc+0x1a0/0x940 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [] tty_ioctl+0xace/0x1fd0 drivers/tty/tty_io.c:2883 [< inline >] vfs_ioctl fs/ioctl.c:43 [] do_vfs_ioctl+0x57c/0xe60 fs/ioctl.c:607 [< inline >] SYSC_ioctl fs/ioctl.c:622 [] SyS_ioctl+0x74/0x80 fs/ioctl.c:613 [] entry_SYSCALL_64_fastpath+0x16/0x7a Reported-and-tested-by: Dmitry Vyukov Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 7c31e4139ac01696ca51b15f578d8c24f1a4be87 Author: Peter Hurley Date: Sun Jan 10 20:36:12 2016 -0800 tty: Fix GPF in flush_to_ldisc(), part 2 commit f33798deecbd59a2955f40ac0ae2bc7dff54c069 upstream. commit 9ce119f318ba ("tty: Fix GPF in flush_to_ldisc()") fixed a GPF caused by a line discipline which does not define a receive_buf() method. However, the vt driver (and speakup driver also) pushes selection data directly to the line discipline receive_buf() method via tty_ldisc_receive_buf(). Fix the same problem in tty_ldisc_receive_buf(). Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit f7bf3f5f62ad05b12e99bec62237d4b0ee4e1fd6 Author: H Hartley Sweeten Date: Tue Mar 22 10:04:48 2016 -0700 staging: comedi: ni_mio_common: fix the ni_write[blw]() functions commit bd3a3cd6c27b117fb9a43a38c8072c95332beecc upstream. Memory mapped io (dev->mmio) should not also be writing to the ioport (dev->iobase) registers. Add the missing 'else' to these functions. Fixes: 0953ee4acca0 ("staging: comedi: ni_mio_common: checkpatch.pl cleanup (else not useful)") Signed-off-by: H Hartley Sweeten Reviewed-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 2f3402712b8cddbb08b62ba920b939469be0fcbe Author: Vladimir Zapolskiy Date: Wed Mar 23 00:38:43 2016 +0200 staging: android: ion_test: fix check of platform_device_register_simple() error code commit ccbc2a9e7878ff09bcaed4893c2a2d3adbb797e2 upstream. On error platform_device_register_simple() returns ERR_PTR() value, check for NULL always fails. The change corrects the check itself and propagates the returned error upwards. Fixes: 81fb0b901397 ("staging: android: ion_test: unregister the platform device") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Greg Kroah-Hartman commit 8434142a993504579fd93d6d76b7b1b441ed5a0f Author: Spencer E. Olson Date: Tue Jan 12 10:33:18 2016 -0700 staging: comedi: ni_tiocmd: change mistaken use of start_src for start_arg commit 1fd24a4702d2af0ea4d5845126cf57d4d1796216 upstream. This fixes a bug in function ni_tio_input_inttrig(). The trigger number should be compared to cmd->start_arg, not cmd->start_src. Fixes: 6a760394d7eb ("staging: comedi: ni_tiocmd: clarify the cmd->start_arg validation and use") Signed-off-by: Spencer E. Olson Reviewed-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit cb26d665143f409261357087982a932a57baad69 Author: Benjamin Tissoires Date: Fri Feb 12 17:10:37 2016 +0100 HID: fix hid_ignore_special_drivers module parameter commit 4392bf333388cabdad5afe5b1500002d7b9c318e upstream. hid_ignore_special_drivers works fine until hid_scan_report autodetects and reassign devices (for hid-multitouch, hid-microsoft and hid-rmi). Simplify the handling of the parameter: if it is there, use hid-generic, no matter what, and if not, scan the device or rely on the hid_have_special_driver table. This was detected while trying to disable hid-multitouch on a Surface Pro cover which prevented to use the keyboard. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a7999775d2022b6f90ac834f3768b8a1719dc59c Author: Benjamin Tissoires Date: Mon Mar 7 11:02:38 2016 +0100 HID: multitouch: force retrieving of Win8 signature blob commit 45c5c6828214605eaefa6755c47bd1a2c7eb203e upstream. The Synaptics 0x11e5 over I2C found in the Asus T100-CHI requires to fetch the signature blob to actually start sending events. With this patch, we should be close enough to the Windows driver which checks the content of the blob at plugin to validate or not the touchscreen. Link: https://bugzilla.kernel.org/show_bug.cgi?id=113481 Fixes: 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c7e16281f6c6a1edde7aab1cba61d7cb0f15f534 Author: Dmitry Torokhov Date: Mon Mar 14 15:21:04 2016 -0700 HID: i2c-hid: fix OOB write in i2c_hid_set_or_send_report() commit 3b654288b196ceaa156029d9457ccbded0489b98 upstream. Even though hid_hw_* checks that passed in data_len is less than HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device reports and select largest size. In-kernel users normally just send as much data as report needs, so there is no problem, but hidraw users can do whatever they please: BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80 Write of size 4101 by task syz-executor/8747 CPU: 2 PID: 8747 Comm: syz-executor Tainted: G BU 3.18.0 #37 Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83 [] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172 [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x90/0x140 lib/dump_stack.c:50 [< inline >] print_error_description mm/kasan/report.c:97 [< inline >] kasan_report_error mm/kasan/report.c:278 [] kasan_report+0x268/0x530 mm/kasan/report.c:305 [] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718 [] memcpy+0x30/0x54 mm/kasan/kasan.c:299 [] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178 [< inline >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321 [] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589 [] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602 [< inline >] hid_hw_output_report include/linux/hid.h:1039 [] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154 [] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177 [] vfs_write+0x1d4/0x3cc fs/read_write.c:534 [< inline >] SYSC_pwrite64 fs/read_write.c:627 [] SyS_pwrite64+0xec/0x144 fs/read_write.c:614 Object at ffffffc07135ea80, in cache kmalloc-512 Object allocated with size 268 bytes. Let's check data length against the buffer size before attempting to copy data over. Reported-by: Alexander Potapenko Signed-off-by: Dmitry Torokhov Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ac051f147d504cf32d805cf3f6cbb2bce9389071 Author: Grazvydas Ignotas Date: Sat Feb 13 22:41:51 2016 +0200 HID: logitech: fix Dual Action gamepad support commit 5d74325a2201376a95520a4a38a1ce2c65761c49 upstream. The patch that added Logitech Dual Action gamepad support forgot to update the special driver list for the device. This caused the logitech driver not to probe unless kernel module load order was favorable. Update the special driver list to fix it. Thanks to Simon Wood for the idea. Cc: Vitaly Katraew Fixes: 56d0c8b7c8fb ("HID: add support for Logitech Dual Action gamepads") Signed-off-by: Grazvydas Ignotas Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b5124d602c1fd106f204428f0fa881d71c7383b2 Author: Jarkko Sakkinen Date: Mon Feb 8 22:31:08 2016 +0200 tpm: fix the cleanup of struct tpm_chip commit 8e0ee3c9faed7ca68807ea45141775856c438ac0 upstream. If the initialization fails before tpm_chip_register(), put_device() will be not called, which causes release callback not to be called. This patch fixes the issue by adding put_device() to devres list of the parent device. Fixes: 313d21eeab ("tpm: device class for tpm") Signed-off-by: Jarkko Sakkinen Reviewed-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 8d95aaebc9866a4e5b4e51ee504cb49d4316a581 Author: Harald Hoyer Date: Sat Feb 6 15:44:42 2016 +0100 tpm_eventlog.c: fix binary_bios_measurements commit 186d124f07da193a8f47e491af85cb695d415f2f upstream. The commit 0cc698af36ff ("vTPM: support little endian guests") copied the event, but without the event data, did an endian conversion on the size and tried to output the event data from the copied version, which has only have one byte of the data, resulting in garbage event data. [jarkko.sakkinen@linux.intel.com: fixed minor coding style issues and renamed the local variable tempPtr as temp_ptr now that there is an excuse to do this.] Signed-off-by: Harald Hoyer Fixes: 0cc698af36ff ("vTPM: support little endian guests") Reviewed-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit b50a9213de2be2c8555065c93e36b616d77aeb8c Author: Jarkko Sakkinen Date: Thu Feb 18 22:11:29 2016 +0200 tpm_crb: tpm2_shutdown() must be called before tpm_chip_unregister() commit 99cda8cb4639de81cde785b5bab9bc52e916e594 upstream. Wrong call order. Reported-by: Jason Gunthorpe Fixes: 74d6b3ceaa17 Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 240e5184991bc8daf60b7dcbfbdec3b3afc16045 Author: Jarkko Sakkinen Date: Fri Jan 29 09:47:22 2016 -0800 tpm: fix the rollback in tpm_chip_register() commit 72c91ce8523ae5828fe5e4417ae0aaab53707a08 upstream. Fixed the rollback and gave more self-documenting names for the functions. Fixes: d972b0523f ("tpm: fix call order in tpm-chip.c") Signed-off-by: Jarkko Sakkinen Reviewed-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 6fae92de438d1b4b7199cf86c4e785cd2d171bea Author: Alexander Usyskin Date: Sun Feb 7 23:35:32 2016 +0200 mei: bus: check if the device is enabled before data transfer commit 15c13dfcad883a1e76b714480fb27be96247fd82 upstream. The bus data transfer interface was missing the check if the device is in enabled state, this may lead to stack corruption during link reset. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 15a75eb1ef158485b00efc47e2e3b5eacf531ef4 Author: David Howells Date: Wed Feb 24 14:37:15 2016 +0000 X.509: Fix leap year handling again commit ac4cbedfdf55455b4c447f17f0fa027dbf02b2a6 upstream. There are still a couple of minor issues in the X.509 leap year handling: (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when determining whether the year is a leap year or not, I divided the year by 100 after doing the modulus-by-100, thereby letting the compiler do one instruction for both, and then did a modulus-by-4. Unfortunately, I then passed the now-modified year value to mktime64() to construct a time value. Since this isn't a fast path and since mktime64() does a bunch of divisions, just condense down to "% 400". It's also easier to read. (2) The default month length for any February where the year doesn't divide by four exactly is obtained from the month_length[] array where the value is 29, not 28. This is fixed by altering the table. Reported-by: Rudolf Polzer Signed-off-by: David Howells Acked-by: David Woodhouse Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit f15a9c184954e4733ec8d790bc10ab97610f1b98 Author: Boris BREZILLON Date: Thu Mar 17 10:47:10 2016 +0100 crypto: marvell/cesa - forward devm_ioremap_resource() error code commit dfe97ad30e8c038261663a18b9e04b8b5bc07bea upstream. Forward devm_ioremap_resource() error code instead of returning -ENOMEM. Signed-off-by: Boris Brezillon Reported-by: Russell King - ARM Linux Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's CESA") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 8b85b7c790477975a8fd5d087592b17d8e6599eb Author: Vladimir Zapolskiy Date: Sun Mar 6 03:22:04 2016 +0200 crypto: ux500 - fix checks of error code returned by devm_ioremap_resource() commit b62917a2622ebcb03a500ef20da47be80d8c8951 upstream. The change fixes potential oops while accessing iomem on invalid address, if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by: Vladimir Zapolskiy Fixes: 5a4eea2658c93 ("crypto: ux500 - Use devm_xxx() managed function") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5aa70ccf2c8d6036b5b4fc26f28a6ac720ba0454 Author: Vladimir Zapolskiy Date: Sun Mar 6 03:21:52 2016 +0200 crypto: atmel - fix checks of error code returned by devm_ioremap_resource() commit 9b52d55f4f0e2bb9a34abbcf99e05e17f1b3b281 upstream. The change fixes potential oops while accessing iomem on invalid address, if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by: Vladimir Zapolskiy Fixes: b0e8b3417a62 ("crypto: atmel - use devm_xxx() managed function") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 86b0e0a0095d1fae9bd6a1a1c7fe2de0931c6f04 Author: Dan Carpenter Date: Sat Jan 30 17:38:28 2016 +0300 crypto: keywrap - memzero the correct memory commit 2b8b28fd232233c22fb61009dd8b0587390d2875 upstream. We're clearing the wrong memory. The memory corruption is likely harmless because we weren't going to use that stack memory again but not zeroing is a potential information leak. Fixes: e28facde3c39 ('crypto: keywrap - add key wrapping block chaining mode') Signed-off-by: Dan Carpenter Acked-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 28059efe875d99a1873d63694ba3b411e44aa738 Author: Tom Lendacky Date: Thu Feb 25 16:48:13 2016 -0600 crypto: ccp - memset request context to zero during import commit ce0ae266feaf35930394bd770c69778e4ef03ba9 upstream. Since a crypto_ahash_import() can be called against a request context that has not had a crypto_ahash_init() performed, the request context needs to be cleared to insure there is no random data present. If not, the random data can result in a kernel oops during crypto_ahash_update(). Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7d1272e1180d237c196887514b9d3a3e92cefd67 Author: Tom Lendacky Date: Tue Feb 2 11:38:21 2016 -0600 crypto: ccp - Don't assume export/import areas are aligned commit b31dde2a5cb1bf764282abf934266b7193c2bc7c upstream. Use a local variable for the exported and imported state so that alignment is not an issue. On export, set a local variable from the request context and then memcpy the contents of the local variable to the export memory area. On import, memcpy the import memory area into a local variable and then use the local variable to set the request context. Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fa2b8df71178833950a5b6ce84273fa88e44ee52 Author: Tom Lendacky Date: Fri Jan 29 12:45:14 2016 -0600 crypto: ccp - Limit the amount of information exported commit d1662165ae612ec8b5f94a6b07e65ea58b6dce34 upstream. Since the exported information can be exposed to user-space, instead of exporting the entire request context only export the minimum information needed. Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 07867d8dd44c6ea91465ec91d34e7d20c23214f0 Author: Tom Lendacky Date: Tue Jan 12 11:17:38 2016 -0600 crypto: ccp - Add hash state import and export support commit 952bce9792e6bf36fda09c2e5718abb5d9327369 upstream. Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") added a check to prevent ahash algorithms from successfully registering if the import and export functions were not implemented. This prevents an oops in the hash_accept function of algif_hash. This commit causes the ccp-crypto module SHA support and AES CMAC support from successfully registering and causing the ccp-crypto module load to fail because the ahash import and export functions are not implemented. Update the CCP Crypto API support to provide import and export support for ahash algorithms. Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 99ed371f70ead62f6f171f6571fcd247371986c7 Author: Dmitry Tunin Date: Fri Mar 4 01:32:19 2016 +0300 Bluetooth: btusb: Add a new AR3012 ID 13d3:3472 commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 upstream. 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=3472 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 BugLink: https://bugs.launchpad.net/bugs/1552925 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 4fea7c5a157018933c8f65a46100d476972de30d Author: Dmitry Tunin Date: Sun Feb 28 11:04:06 2016 +0300 Bluetooth: btusb: Add a new AR3012 ID 04ca:3014 commit 81d90442eac779938217c3444b240aa51fd3db47 upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3014 Rev=00.02 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 BugLink: https://bugs.launchpad.net/bugs/1546694 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 09e8ddc6a250c79db9234a4d3250f1cc926eb8e8 Author: Dmitry Tunin Date: Wed Feb 10 15:33:17 2016 +0300 Bluetooth: btusb: Add new AR3012 ID 13d3:3395 commit 609574eb46335cfac1421a07c0505627cbbab1f0 upstream. T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3395 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 BugLink: https://bugs.launchpad.net/bugs/1542564 Reported-and-tested-by: Christopher Simerly Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit afd4ebd2af01e7a57d747f15da0c7b586e9af0b2 Author: Vladis Dronov Date: Thu Mar 31 12:05:43 2016 -0400 ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call commit 836b34a935abc91e13e63053d0a83b24dfb5ea78 upstream. create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and create_uaxx_quirk() functions allocate the audioformat object by themselves and free it upon error before returning. However, once the object is linked to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be double-freed, eventually resulting in a memory corruption. This patch fixes these failures in the error paths by unlinking the audioformat object before freeing it. Based on a patch by Takashi Iwai [Note for stable backports: this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()')] Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5b9e9675bda585f0c6a5e9a0423b30943ccc1752 Author: Takashi Iwai Date: Tue Mar 15 12:14:49 2016 +0100 ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk() commit 902eb7fd1e4af3ac69b9b30f8373f118c92b9729 upstream. Just a minor code cleanup: unify the error paths. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 22122bc13dad0ae26f0f20f748fff14020f7ace7 Author: Victor Clément Date: Sat Mar 19 13:17:42 2016 +0100 ALSA: usb-audio: add Microsoft HD-5001 to quirks commit 0ef21100ae912f76ed89f76ecd894f4ffb3689c1 upstream. The Microsoft HD-5001 webcam microphone does not support sample rate reading as the HD-5000 one. This results in dmesg errors and sound hanging with pulseaudio. Signed-off-by: Victor Clément Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e16ff31d154a109e9e410da57f111f8896f5d021 Author: Takashi Iwai Date: Tue Mar 15 15:20:58 2016 +0100 ALSA: usb-audio: Add sanity checks for endpoint accesses commit 447d6275f0c21f6cc97a88b3a0c601436a4cdf2a upstream. Add some sanity check codes before actually accessing the endpoint via get_endpoint() in order to avoid the invalid access through a malformed USB descriptor. Mostly just checking bNumEndpoints, but in one place (snd_microii_spdif_default_get()), the validity of iface and altsetting index is checked as well. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7cb483b5cc96cb27d724497a737a3e3aa2126cd9 Author: Takashi Iwai Date: Tue Mar 15 12:09:10 2016 +0100 ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk() commit 0f886ca12765d20124bd06291c82951fd49a33be upstream. create_fixed_stream_quirk() may cause a NULL-pointer dereference by accessing the non-existing endpoint when a USB device with a malformed USB descriptor is used. This patch avoids it simply by adding a sanity check of bNumEndpoints before the accesses. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e97ae5113dd09d459d7f173710ba86ba2ad83a42 Author: Josh Boyer Date: Mon Mar 14 09:33:40 2016 -0700 Input: powermate - fix oops with malicious USB descriptors commit 9c6ba456711687b794dcf285856fc14e2c76074f upstream. The powermate driver expects at least one valid USB endpoint in its probe function. If given malicious descriptors that specify 0 for the number of endpoints, it will crash. Validate the number of endpoints on the interface before using them. The full report for this issue can be found here: http://seclists.org/bugtraq/2016/Mar/85 Reported-by: Ralf Spenneberg Signed-off-by: Josh Boyer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 24fc49c148c34a93631e85f4067234ff5fc3b42b Author: Hans de Goede Date: Fri Jan 22 08:53:55 2016 -0200 pwc: Add USB id for Philips Spc880nc webcam commit 7445e45d19a09e5269dc85f17f9635be29d2f76c upstream. SPC 880NC PC camera discussions: http://www.pclinuxos.com/forum/index.php/topic,135688.0.html Reported-by: Kikim Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0e7ed31563913a559c090c252c42608744788926 Author: Anthony Wong Date: Tue Feb 23 23:09:22 2016 +0800 rt2x00: add new rt2800usb device Buffalo WLI-UC-G450 commit f36f299068794ffc5026f25b6a1b3ed615ea832d upstream. Add USB ID 0411:01fd for Buffalo WLI-UC-G450 wireless adapter, RT chipset 3593 Signed-off-by: Anthony Wong Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 99aee9e8d5642d4f68acf4c231c4905fb7e1ec90 Author: Bjørn Mork Date: Thu Apr 7 12:09:17 2016 +0200 USB: option: add "D-Link DWM-221 B1" device id commit d48d5691ebf88a15d95ba96486917ffc79256536 upstream. Thomas reports: "Windows: 00 diagnostics 01 modem 02 at-port 03 nmea 04 nic Linux: T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7e19 Rev=02.32 S: Manufacturer=Mobile Connect S: Product=Mobile Connect S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage" Reported-by: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 240f59f2c84bd1fdbaaf6eb828380af046772823 Author: Josh Boyer Date: Thu Mar 10 09:48:52 2016 -0500 USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices commit ea6db90e750328068837bed34cb1302b7a177339 upstream. A Fedora user reports that the ftdi_sio driver works properly for the ICP DAS I-7561U device. Further, the user manual for these devices instructs users to load the driver and add the ids using the sysfs interface. Add support for these in the driver directly so that the devices work out of the box instead of needing manual configuration. Reported-by: Signed-off-by: Josh Boyer Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 31f32df660f6d38f26471e86c78382de3683cdb8 Author: Martyn Welch Date: Tue Mar 29 17:47:29 2016 +0100 USB: serial: cp210x: Adding GE Healthcare Device ID commit cddc9434e3dcc37a85c4412fb8e277d3a582e456 upstream. The CP2105 is used in the GE Healthcare Remote Alarm Box, with the Manufacturer ID of 0x1901 and Product ID of 0x0194. Signed-off-by: Martyn Welch Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 674044a0686c4bcb9c94282795de74b747c3b0f1 Author: Oliver Neukum Date: Thu Mar 31 12:04:25 2016 -0400 USB: cypress_m8: add endpoint sanity check commit c55aee1bf0e6b6feec8b2927b43f7a09a6d5f754 upstream. An attack using missing endpoints exists. CVE-2016-3137 Signed-off-by: Oliver Neukum Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f1568bb7d4c28944ee8ab25e34f4bed86f7c4229 Author: Oliver Neukum Date: Thu Mar 31 12:04:26 2016 -0400 USB: digi_acceleport: do sanity checking for the number of ports commit 5a07975ad0a36708c6b0a5b9fea1ff811d0b0c1f upstream. The driver can be crashed with devices that expose crafted descriptors with too few endpoints. See: http://seclists.org/bugtraq/2016/Mar/61 Signed-off-by: Oliver Neukum [johan: fix OOB endpoint check and add error messages ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fc7f87747c9e174b97d7b81fb0b6e1614f60171b Author: Oliver Neukum Date: Thu Mar 31 12:04:24 2016 -0400 USB: mct_u232: add sanity checking in probe commit 4e9a0b05257f29cf4b75f3209243ed71614d062e upstream. An attack using the lack of sanity checking in probe is known. This patch checks for the existence of a second port. CVE-2016-3136 Signed-off-by: Oliver Neukum [johan: add error message ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b03ec9b23dec1d0d02672065442d3c76370dd500 Author: Oliver Neukum Date: Wed Mar 16 13:26:17 2016 +0100 USB: usb_driver_claim_interface: add sanity checking commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd upstream. Attacks that trick drivers into passing a NULL pointer to usb_driver_claim_interface() using forged descriptors are known. This thwarts them by sanity checking. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 3dc95c06c6368afb610fb1eb3e0b8f04ef949289 Author: Josh Boyer Date: Mon Mar 14 10:42:38 2016 -0400 USB: iowarrior: fix oops with malicious USB descriptors commit 4ec0ef3a82125efc36173062a50624550a900ae0 upstream. The iowarrior driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. The full report of this issue can be found here: http://seclists.org/bugtraq/2016/Mar/87 Reported-by: Ralf Spenneberg Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman commit 347e1384659eadc8b6ccd520a5eb005df6493676 Author: Oliver Neukum Date: Tue Mar 15 10:14:04 2016 +0100 USB: cdc-acm: more sanity checking commit 8835ba4a39cf53f705417b3b3a94eb067673f2c9 upstream. An attack has become available which pretends to be a quirky device circumventing normal sanity checks and crashes the kernel by an insufficient number of interfaces. This patch adds a check to the code path for quirky devices. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 52107b93570232585942282976faad939f1bafdb Author: Hans de Goede Date: Mon Mar 7 20:11:52 2016 +0100 USB: uas: Reduce can_queue to MAX_CMNDS commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 upstream. The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags are shared between luns, so there is no need to claim that we can_queue some random large number. Not claiming that we can_queue 65536 commands, fixes the uas driver failing to initialize while allocating the tag map with a "Page allocation failure (order 7)" error on systems which have been running for a while and thus have fragmented memory. Reported-and-tested-by: Yves-Alexis Perez Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit ef68fe7dc72b35a63ea34c1c4ff5a39f9a896e57 Author: Oliver Neukum Date: Wed Feb 17 11:52:43 2016 +0100 usb: hub: fix a typo in hub_port_init() leading to wrong logic commit 0d5ce778c43bf888328231bcdce05d5c860655aa upstream. A typo of j for i led to a logic bug. To rule out future confusion, the variable names are made meaningful. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit f08b2bf1d52332c022606a3e10313997eb99e169 Author: Oliver Neukum Date: Wed Feb 10 11:33:18 2016 +0100 usb: retry reset if a device times out commit 264904ccc33c604d4b3141bbd33808152dfac45b upstream. Some devices I got show an inability to operate right after power on if they are already connected. They are beyond recovery if the descriptors are requested multiple times. So in case of a timeout we rather bail early and reset again. But it must be done only on the first loop lest we get into a reset/time out spiral that can be overcome with a retry. This patch is a rework of a patch that fell through the cracks. http://www.spinics.net/lists/linux-usb/msg103263.html Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 2fdbb141546d17d35edf79f357a16a458f577909 Author: Bryn M. Reeves Date: Mon Mar 14 17:04:34 2016 -0400 dm: fix rq_end_stats() NULL pointer in dm_requeue_original_request() commit 98dbc9c6c61698792e3a66f32f3bf066201d42d7 upstream. An "old" (.request_fn) DM 'struct request' stores a pointer to the associated 'struct dm_rq_target_io' in rq->special. dm_requeue_original_request(), previously named dm_requeue_unmapped_original_request(), called dm_unprep_request() to reset rq->special to NULL. But rq_end_stats() would go on to hit a NULL pointer deference because its call to tio_from_request() returned NULL. Fix this by calling rq_end_stats() _before_ dm_unprep_request() Signed-off-by: Bryn M. Reeves Signed-off-by: Mike Snitzer Fixes: e262f34741 ("dm stats: add support for request-based DM devices") Signed-off-by: Greg Kroah-Hartman commit d6bff398c4f574a5b17bfa03152d3f21d3103ccf Author: Joe Thornber Date: Thu Mar 10 16:20:58 2016 +0000 dm cache: make sure every metadata function checks fail_io commit d14fcf3dd79c0b8a8d0ba469c44a6b04f3a1403b upstream. Otherwise operations may be attempted that will only ever go on to crash (since the metadata device is either missing or unreliable if 'fail_io' is set). Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 65df592d29db04634331b6552ede7c4f7d6c4b55 Author: Joe Thornber Date: Tue Mar 1 10:58:44 2016 +0000 dm thin metadata: don't issue prefetches if a transaction abort has failed commit 2eae9e4489b4cf83213fa3bd508b5afca3f01780 upstream. If a transaction abort has failed then we can no longer use the metadata device. Typically this happens if the superblock is unreadable. This fix addresses a crash seen during metadata device failure testing. Fixes: 8a01a6af75 ("dm thin: prefetch missing metadata pages") Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7f4c67d5c0d599545a134e38b432153898e75a88 Author: Mike Snitzer Date: Fri Feb 5 08:49:01 2016 -0500 dm: fix excessive dm-mq context switching commit 6acfe68bac7e6f16dc312157b1fa6e2368985013 upstream. Request-based DM's blk-mq support (dm-mq) was reported to be 50% slower than if an underlying null_blk device were used directly. One of the reasons for this drop in performance is that blk_insert_clone_request() was calling blk_mq_insert_request() with @async=true. This forced the use of kblockd_schedule_delayed_work_on() to run the blk-mq hw queues which ushered in ping-ponging between process context (fio in this case) and kblockd's kworker to submit the cloned request. The ftrace function_graph tracer showed: kworker-2013 => fio-12190 fio-12190 => kworker-2013 ... kworker-2013 => fio-12190 fio-12190 => kworker-2013 ... Fixing blk_insert_clone_request()'s blk_mq_insert_request() call to _not_ use kblockd to submit the cloned requests isn't enough to eliminate the observed context switches. In addition to this dm-mq specific blk-core fix, there are 2 DM core fixes to dm-mq that (when paired with the blk-core fix) completely eliminate the observed context switching: 1) don't blk_mq_run_hw_queues in blk-mq request completion Motivated by desire to reduce overhead of dm-mq, punting to kblockd just increases context switches. In my testing against a really fast null_blk device there was no benefit to running blk_mq_run_hw_queues() on completion (and no other blk-mq driver does this). So hopefully this change doesn't induce the need for yet another revert like commit 621739b00e16ca2d ! 2) use blk_mq_complete_request() in dm_complete_request() blk_complete_request() doesn't offer the traditional q->mq_ops vs .request_fn branching pattern that other historic block interfaces do (e.g. blk_get_request). Using blk_mq_complete_request() for blk-mq requests is important for performance. It should be noted that, like blk_complete_request(), blk_mq_complete_request() doesn't natively handle partial completions -- but the request-based DM-multipath target does provide the required partial completion support by dm.c:end_clone_bio() triggering requeueing of the request via dm-mpath.c:multipath_end_io()'s return of DM_ENDIO_REQUEUE. dm-mq fix #2 is _much_ more important than #1 for eliminating the context switches. Before: cpu : usr=15.10%, sys=59.39%, ctx=7905181, majf=0, minf=475 After: cpu : usr=20.60%, sys=79.35%, ctx=2008, majf=0, minf=472 With these changes multithreaded async read IOPs improved from ~950K to ~1350K for this dm-mq stacked on null_blk test-case. The raw read IOPs of the underlying null_blk device for the same workload is ~1950K. Fixes: 7fb4898e0 ("block: add blk-mq support to blk_insert_cloned_request()") Fixes: bfebd1cdb ("dm: add full blk-mq support to request-based DM") Reported-by: Sagi Grimberg Signed-off-by: Mike Snitzer Acked-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3c5f85f5f9b4bf70b7ea1d024e84ade87697d3b2 Author: DingXiang Date: Tue Feb 2 12:29:18 2016 +0800 dm snapshot: disallow the COW and origin devices from being identical commit 4df2bf466a9c9c92f40d27c4aa9120f4e8227bfc upstream. Otherwise loading a "snapshot" table using the same device for the origin and COW devices, e.g.: echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap will trigger: BUG: unable to handle kernel NULL pointer dereference at 0000000000000098 [ 1958.979934] IP: [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot] [ 1958.989655] PGD 0 [ 1958.991903] Oops: 0000 [#1] SMP ... [ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G IO 4.5.0-rc5.snitm+ #150 ... [ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000 [ 1959.091865] RIP: 0010:[] [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot] [ 1959.104295] RSP: 0018:ffff88032a957b30 EFLAGS: 00010246 [ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001 [ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00 [ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001 [ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80 [ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80 [ 1959.150021] FS: 00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000 [ 1959.159047] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0 [ 1959.173415] Stack: [ 1959.175656] ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc [ 1959.183946] ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000 [ 1959.192233] ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf [ 1959.200521] Call Trace: [ 1959.203248] [] dm_exception_store_create+0x1d5/0x240 [dm_snapshot] [ 1959.211986] [] snapshot_ctr+0x140/0x630 [dm_snapshot] [ 1959.219469] [] ? dm_split_args+0x64/0x150 [dm_mod] [ 1959.226656] [] dm_table_add_target+0x177/0x440 [dm_mod] [ 1959.234328] [] table_load+0x143/0x370 [dm_mod] [ 1959.241129] [] ? retrieve_status+0x1b0/0x1b0 [dm_mod] [ 1959.248607] [] ctl_ioctl+0x255/0x4d0 [dm_mod] [ 1959.255307] [] ? memzero_explicit+0x12/0x20 [ 1959.261816] [] dm_ctl_ioctl+0x13/0x20 [dm_mod] [ 1959.268615] [] do_vfs_ioctl+0xa6/0x5c0 [ 1959.274637] [] ? __audit_syscall_entry+0xaf/0x100 [ 1959.281726] [] ? do_audit_syscall_entry+0x66/0x70 [ 1959.288814] [] SyS_ioctl+0x79/0x90 [ 1959.294450] [] entry_SYSCALL_64_fastpath+0x12/0x71 ... [ 1959.323277] RIP [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot] [ 1959.333090] RSP [ 1959.336978] CR2: 0000000000000098 [ 1959.344121] ---[ end trace b049991ccad1169e ]--- Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1195899 Signed-off-by: Ding Xiang Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 43a05a0dd8cb197ae91681c90a2176f5d682084b Author: Dan Williams Date: Sun Mar 6 15:20:51 2016 -0800 libnvdimm, pmem: fix kmap_atomic() leak in error path commit b5ebc8ec693281c3c1efff7459a069cbd8b9a149 upstream. When we enounter a bad block we need to kunmap_atomic() before returning. Cc: Ross Zwisler Reviewed-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 58fc850f0e3d68fe404d6f03990d68af54424af5 Author: Jerry Hoemann Date: Wed Jan 6 16:03:41 2016 -0700 libnvdimm: Fix security issue with DSM IOCTL. commit 07accfa9d1a8bac8262f6d24a94a54d2d1f35149 upstream. Code attempts to prevent certain IOCTL DSM from being called when device is opened read only. This security feature can be trivially overcome by changing the size portion of the ioctl_command which isn't used. Check only the _IOC_NR (i.e. the command). Signed-off-by: Jerry Hoemann Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 3b3df6d69f6f9ae3fda900f7a74b76f5d3a3f9d8 Author: Alan Date: Mon Feb 15 18:53:15 2016 +0000 aic7xxx: Fix queue depth handling commit 5a51a7abca133860a6f4429655a9eda3c4afde32 upstream. We were setting the queue depth correctly, then setting it back to two. If you hit this as a bisection point then please send me an email as it would imply we've been hiding other bugs with this one. Signed-off-by: Alan Cox Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c6795a4cbf0ccd8b237019519f7b1f192c1a8640 Author: Maurizio Lombardi Date: Fri Mar 4 10:41:49 2016 +0100 be2iscsi: set the boot_kset pointer to NULL in case of failure commit 84bd64993f916bcf86270c67686ecf4cea7b8933 upstream. In beiscsi_setup_boot_info(), the boot_kset pointer should be set to NULL in case of failure otherwise an invalid pointer dereference may occur later. Signed-off-by: Maurizio Lombardi Reviewed-by: Johannes Thumshirn Reviewed-by: Jitendra Bhivare Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6fa6f336dc71547428764aa8d506f93f27526f6e Author: Vitaly Kuznetsov Date: Mon Mar 7 11:59:44 2016 +0100 scsi: storvsc: fix SRB_STATUS_ABORTED handling commit ff06c5ffbcb4ffa542fb80c897be977956fafecc upstream. Commit 3209f9d780d1 ("scsi: storvsc: Fix a bug in the handling of SRB status flags") filtered SRB_STATUS_AUTOSENSE_VALID out effectively making the (SRB_STATUS_ABORTED | SRB_STATUS_AUTOSENSE_VALID) case a dead code. The logic from this branch (e.g. storvsc_device_scan() call) is still required, fix the check. Fixes: 3209f9d780d1 ("scsi: storvsc: Fix a bug in the handling of SRB status flags") Signed-off-by: Vitaly Kuznetsov Acked-by: K. Y. Srinivasan Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d78baf15b55368b65ab89ff8ffbe8c101120220c Author: Finn Thain Date: Tue Feb 23 10:07:09 2016 +1100 ncr5380: Call scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() as and when appropriate commit 8d5dbec3bcb24a7d071962448e0fecaca8c75cc7 upstream. This bug causes the wrong command to have its sense pointer overwritten, which sometimes leads to a NULL pointer deref. Fix this by checking which command is being requeued before restoring the scsi_eh_save data. It turns out that some targets will disconnect a REQUEST SENSE command. The autosense algorithm doesn't anticipate this. Hence multiple commands can end up undergoing autosense simultaneously, and they will all try to use the same scsi_eh_save struct, which won't work. Defer autosense when the scsi_eh_save storage is in use by another command. Fixes: f27db8eb98a1 ("ncr5380: Fix autosense bugs") Reported-and-tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f4c71dedeb7a66530a31af734b94ffcdcf8e9d7b Author: Finn Thain Date: Tue Feb 23 10:07:08 2016 +1100 ncr5380: Fix NCR5380_select() EH checks and result handling commit ccf6efd78317ef6265829c81a3e1a19f628b1a2d upstream. Add missing checks for EH abort during arbitration and selection. Rework the handling of NCR5380_select() result to improve clarity. Fixes: 707d62b37fbb ("ncr5380: Fix EH during arbitration and selection") Tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ff06b12b1b2a0b9d2b779693a0f481eb40fd6046 Author: Finn Thain Date: Tue Feb 23 10:07:07 2016 +1100 ncr5380: Forget aborted commands commit dc183965282d28c82f192e39cbfa91da85505a6f upstream. The list structures and related logic used in the NCR5380 driver mean that a command cannot be queued twice (i.e. can't appear on more than one queue and can't appear on the same queue more than once). The abort handler must forget the command so that the mid-layer can re-use it. E.g. the ML may send it back to the LLD via via scsi_eh_get_sense(). Fix this and also fix two error paths, so that commands get forgotten iff completed. Fixes: 8b00c3d5d40d ("ncr5380: Implement new eh_abort_handler") Tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a116d5523020a0725c49029b651a6dc4f7dcbc44 Author: Finn Thain Date: Tue Feb 23 10:07:06 2016 +1100 ncr5380: Dont re-enter NCR5380_select() commit 71a00593ec0c2e2c1720e4041cf2926ff1d07826 upstream. Calling NCR5380_select() from the abort handler causes various problems. Firstly, it means potentially re-entering NCR5380_select(). Secondly, it means that the lock is released, which permits the EH handlers to be re-entered. The combination results in crashes. Don't do it. Fixes: 8b00c3d5d40d ("ncr5380: Implement new eh_abort_handler") Reported-and-tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 121188c63609db69c0f0dc294dcbe1d1b1e9fb21 Author: Finn Thain Date: Tue Feb 23 10:07:05 2016 +1100 ncr5380: Dont release lock for PIO transfer commit 1678847ec93040ae8280d19c42ae0ba8a4233e6d upstream. The calls to NCR5380_transfer_pio() for DATA IN and DATA OUT phases will modify cmd->SCp.this_residual, cmd->SCp.ptr and cmd->SCp.buffer. That works as long as EH does not intervene, which became possible in atari_NCR5380.c when I changed the locking to bring it closer to NCR5380.c. If error recovery aborts the command, the scsi_cmnd in question and its buffer will be returned to the mid-layer. So the transfer has to cease, but it can't be stopped by the initiator because the target controls the bus phase. The problem does not arise if the lock is not released. That was fine for atari_scsi, because it implements DMA. For the other drivers, we have to release the lock and re-enable interrupts for long PIO data transfers. The solution is to split the transfer into small chunks. In between chunks the main loop releases the lock and re-enables interrupts. Thus interrupts can be serviced and eh_bus_reset_handler can intervene if need be. This fixes an oops in NCR5380_transfer_pio() that can happen when the EH abort handler is invoked during DATA IN or DATA OUT phase. Fixes: 11d2f63b9cf5 ("ncr5380: Change instance->host_lock to hostdata->lock") Reported-and-tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 058f4656164233e39feda5d3e5c097a6580693c1 Author: Finn Thain Date: Tue Feb 23 10:07:04 2016 +1100 ncr5380: Correctly clear command pointers and lists after bus reset commit 1884c2838f31e6bf20f21459ed9921f8c92ed3ef upstream. Commands subject to exception handling are to be returned to the scsi mid-layer. Make sure that the various command pointers and command lists in the low-level driver are correctly cleansed of affected commands. This fixes some bugs that I accidentally introduced in v4.5-rc1 including the removal of INIT_LIST_HEAD for the 'autosense' and 'disconnected' command lists, and the possible NULL pointer dereference in NCR5380_bus_reset() that was reported by Dan Carpenter. hostdata->sensing may also point to an affected command so this pointer also has to be cleared. The abort handler calls complete_cmd() to take care of this; let's have the bus reset handler do the same. The issue queue may also contain an affected command. If so, remove it. This also follows the abort handler logic. Reported-by: Dan Carpenter Fixes: 62717f537e1b ("ncr5380: Implement new eh_bus_reset_handler") Tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit fe002b79a43aed1f48b11d33e49d1885f6177d13 Author: Martin K. Petersen Date: Sat Mar 5 17:52:02 2016 -0500 sd: Fix discard granularity when LBPRZ=1 commit 6540a65da90c09590897310e31993b1f6e28485a upstream. Commit 397737223c59 ("sd: Make discard granularity match logical block size when LBPRZ=1") accidentally set the granularity to one byte instead of one logical block on devices that provide deterministic zeroes after UNMAP. Signed-off-by: Martin K. Petersen Reported-by: Mike Snitzer Reviewed-by: Ewan Milne Reviewed-by: Bart Van Assche Fixes: 397737223c59e89dca7305feb6528caef8fbef84 Signed-off-by: Greg Kroah-Hartman commit f669832ddf99c93add46a528c1ceb8af6eb1ed9a Author: Raghava Aditya Renukunta Date: Wed Feb 3 15:06:03 2016 -0800 aacraid: Set correct msix count for EEH recovery commit ecc479e00db8eb110b200afe1effcb3df20ca7ae upstream. During EEH recovery number of online CPU's might change thereby changing the number of MSIx vectors. Since each fib is allocated to a vector, changes in the number of vectors causes fib to be sent thru invalid vectors.In addition the correct number of MSIx vectors is not updated in the INIT struct sent to the controller, when it is reinitialized. Fixed by reassigning vectors to fibs based on the updated number of MSIx vectors and updating the INIT structure before sending to controller. Fixes: MSI-X vector calculation for suspend/resume Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Shane Seymour Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6fc34a297e8a70e866986a44cbe0ac170e7e9e3d Author: Raghava Aditya Renukunta Date: Wed Feb 3 15:06:02 2016 -0800 aacraid: Fix memory leak in aac_fib_map_free commit f88fa79a61726ce9434df9b4aede36961f709f17 upstream. aac_fib_map_free() calls pci_free_consistent() without checking that dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are indeed NULL/0, this will result in a hang as pci_free_consistent() will attempt to invalidate cache for the entire 64-bit address space (which would take a very long time). Fixed by adding a check to make sure that dev->hw_fib_va and dev->max_fib_size are not NULL and 0 respectively. Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset" Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a5433bc8a4a950a8b0d1fa04ce98d971e904e687 Author: Raghava Aditya Renukunta Date: Wed Feb 3 15:06:00 2016 -0800 aacraid: Fix RRQ overload commit 3f4ce057d51a9c0ed9b01ba693df685d230ffcae upstream. The driver utilizes an array of atomic variables to keep track of IO submissions to each vector. To submit an IO multiple threads iterate through the array to find a vector which has empty slots to send an IO. The reading and updating of the variable is not atomic, causing race conditions when a thread uses a full vector to submit an IO. Fixed by mapping each FIB to a vector, the submission path then uses said vector to submit IO thereby removing the possibly of a race condition.The vector assignment is started from 1 since vector 0 is reserved for the use of AIF management FIBS.If the number of MSIx vectors is 1 (MSI or INTx mode) then all the fibs are allocated to vector 0. Fixes: 495c0217 "aacraid: MSI-x support" Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3e12218f05607f5b673b3ed489268ffcfd7ac996 Author: Douglas Gilbert Date: Thu Mar 3 00:31:29 2016 -0500 sg: fix dxferp in from_to case commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 upstream. One of the strange things that the original sg driver did was let the user provide both a data-out buffer (it followed the sg_header+cdb) _and_ specify a reply length greater than zero. What happened was that the user data-out buffer was copied into some kernel buffers and then the mid level was told a read type operation would take place with the data from the device overwriting the same kernel buffers. The user would then read those kernel buffers back into the user space. From what I can tell, the above action was broken by commit fad7f01e61bf ("sg: set dxferp to NULL for READ with the older SG interface") in 2008 and syzkaller found that out recently. Make sure that a user space pointer is passed through when data follows the sg_header structure and command. Fix the abnormal case when a non-zero reply_len is also given. Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6 Signed-off-by: Douglas Gilbert Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6042cb2684cff017d26d41795efe5c2c2df60e05 Author: Nadav Amit Date: Fri Apr 1 14:31:23 2016 -0700 x86/mm: TLB_REMOTE_SEND_IPI should count pages commit 18c98243ddf05a1827ad2c359c5ac051101e7ff7 upstream. TLB_REMOTE_SEND_IPI was recently introduced, but it counts bytes instead of pages. In addition, it does not report correctly the case in which flush_tlb_page flushes a page. Fix it to be consistent with other TLB counters. Fixes: 5b74283ab251b9d ("x86, mm: trace when an IPI is about to be sent") Signed-off-by: Nadav Amit Cc: Mel Gorman Cc: Rik van Riel Cc: Dave Hansen Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a74b15a3e7c15df47d35741609fe111e36971dc0 Author: Andy Lutomirski Date: Wed Mar 16 14:14:22 2016 -0700 x86/iopl: Fix iopl capability check on Xen PV commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e upstream. iopl(3) is supposed to work if iopl is already 3, even if unprivileged. This didn't work right on Xen PV. Fix it. Reviewewd-by: Jan Beulich Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3e30e998425d5406e7a7470f4e2680217d23acab Author: Andy Lutomirski Date: Wed Mar 16 14:14:21 2016 -0700 x86/iopl/64: Properly context-switch IOPL on Xen PV commit b7a584598aea7ca73140cb87b40319944dd3393f upstream. On Xen PV, regs->flags doesn't reliably reflect IOPL and the exit-to-userspace code doesn't change IOPL. We need to context switch it manually. I'm doing this without going through paravirt because this is specific to Xen PV. After the dust settles, we can merge this with the 32-bit code, tidy up the iopl syscall implementation, and remove the set_iopl pvop entirely. Fixes XSA-171. Reviewewd-by: Jan Beulich Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 424d868f895461cfa515802db5131db9fa02544d Author: Dave Jones Date: Mon Mar 14 21:20:54 2016 -0400 x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt() commit 7834c10313fb823e538f2772be78edcdeed2e6e3 upstream. Since 4.4, I've been able to trigger this occasionally: =============================== [ INFO: suspicious RCU usage. ] 4.5.0-rc7-think+ #3 Not tainted Cc: Andi Kleen Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman ------------------------------- ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 1 RCU used illegally from extended quiescent state! no locks held by swapper/3/0. stack backtrace: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3 ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6 ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60 Call Trace: [] dump_stack+0x67/0x9d [] lockdep_rcu_suspicious+0xe6/0x100 [] do_trace_write_msr+0x127/0x1a0 [] native_apic_msr_eoi_write+0x23/0x30 [] smp_trace_call_function_interrupt+0x38/0x360 [] trace_call_function_interrupt+0x90/0xa0 [] ? cpuidle_enter_state+0x1b4/0x520 Move the entering_irq() call before ack_APIC_irq(), because entering_irq() tells the RCU susbstems to end the extended quiescent state, so that the following trace call in ack_APIC_irq() works correctly. Suggested-by: Andi Kleen Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()" Signed-off-by: Dave Jones Signed-off-by: Thomas Gleixner commit 4128f77c80f5e5c4c8486f96c3fe3402c77d9f24 Author: Thomas Gleixner Date: Mon Mar 14 09:40:46 2016 +0100 x86/irq: Cure live lock in fixup_irqs() commit 551adc60573cb68e3d55cacca9ba1b7437313df7 upstream. Harry reported, that he's able to trigger a system freeze with cpu hot unplug. The freeze turned out to be a live lock caused by recent changes in irq_force_complete_move(). When fixup_irqs() and from there irq_force_complete_move() is called on the dying cpu, then all other cpus are in stop machine an wait for the dying cpu to complete the teardown. If there is a move of an interrupt pending then irq_force_complete_move() sends the cleanup IPI to the cpus in the old_domain mask and waits for them to clear the mask. That's obviously impossible as those cpus are firmly stuck in stop machine with interrupts disabled. I should have known that, but I completely overlooked it being concentrated on the locking issues around the vectors. And the existance of the call to __irq_complete_move() in the code, which actually sends the cleanup IPI made it reasonable to wait for that cleanup to complete. That call was bogus even before the recent changes as it was just a pointless distraction. We have to look at two cases: 1) The move_in_progress flag of the interrupt is set This means the ioapic has been updated with the new vector, but it has not fired yet. In theory there is a race: set_ioapic(new_vector) <-- Interrupt is raised before update is effective, i.e. it's raised on the old vector. So if the target cpu cannot handle that interrupt before the old vector is cleaned up, we get a spurious interrupt and in the worst case the ioapic irq line becomes stale, but my experiments so far have only resulted in spurious interrupts. But in case of cpu hotplug this should be a non issue because if the affinity update happens right before all cpus rendevouz in stop machine, there is no way that the interrupt can be blocked on the target cpu because all cpus loops first with interrupts enabled in stop machine, so the old vector is not yet cleaned up when the interrupt fires. So the only way to run into this issue is if the delivery of the interrupt on the apic/system bus would be delayed beyond the point where the target cpu disables interrupts in stop machine. I doubt that it can happen, but at least there is a theroretical chance. Virtualization might be able to expose this, but AFAICT the IOAPIC emulation is not as stupid as the real hardware. I've spent quite some time over the weekend to enforce that situation, though I was not able to trigger the delayed case. 2) The move_in_progress flag is not set and the old_domain cpu mask is not empty. That means, that an interrupt was delivered after the change and the cleanup IPI has been sent to the cpus in old_domain, but not all CPUs have responded to it yet. In both cases we can assume that the next interrupt will arrive on the new vector, so we can cleanup the old vectors on the cpus in the old_domain cpu mask. Fixes: 98229aa36caa "x86/irq: Plug vector cleanup race" Reported-by: Harry Junior Tested-by: Tony Luck Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Joe Lawrence Cc: Borislav Petkov Cc: Ben Hutchings Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603140931430.3657@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 71adf9dac3411109e243c302c604572e65d0dede Author: Lorenzo Pieralisi Date: Mon Mar 21 11:12:55 2016 +0000 PCI: ACPI: IA64: fix IO port generic range check commit 4a2e7aab4ffce1e0e79b303dc2f9a03aa9f3a332 upstream. The [0 - 64k] ACPI PCI IO port resource boundary check in: acpi_dev_ioresource_flags() is currently applied blindly in the ACPI resource parsing to all architectures, but only x86 suffers from that IO space limitation. On arches (ie IA64 and ARM64) where IO space is memory mapped, the PCI root bridges IO resource windows are firstly initialized from the _CRS (in acpi_decode_space()) and contain the CPU physical address at which a root bridge decodes IO space in the CPU physical address space with the offset value representing the offset required to translate the PCI bus address into the CPU physical address. The IO resource windows are then parsed and updated in arch code before creating and enumerating PCI buses (eg IA64 add_io_space()) to map in an arch specific way the obtained CPU physical address range to a slice of virtual address space reserved to map PCI IO space, ending up with PCI bridges resource windows containing IO resources like the following on a working IA64 configuration: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x1000000-0x100ffff window] (bus address [0x0000-0xffff]) pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000fffff window] pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff window] pci_bus 0000:00: root bus resource [mem 0x80004000000-0x800ffffffff window] pci_bus 0000:00: root bus resource [bus 00] This implies that the [0 - 64K] check in acpi_dev_ioresource_flags() leaves platforms with memory mapped IO space (ie IA64) broken (ie kernel can't claim IO resources since the host bridge IO resource is disabled and discarded by ACPI core code, see log on IA64 with missing root bridge IO resource, silently filtered by current [0 - 64k] check in acpi_dev_ioresource_flags()): PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000fffff window] pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff window] pci_bus 0000:00: root bus resource [mem 0x80004000000-0x800ffffffff window] pci_bus 0000:00: root bus resource [bus 00] [...] pci 0000:00:03.0: [1002:515e] type 00 class 0x030000 pci 0000:00:03.0: reg 0x10: [mem 0x80000000-0x87ffffff pref] pci 0000:00:03.0: reg 0x14: [io 0x1000-0x10ff] pci 0000:00:03.0: reg 0x18: [mem 0x88020000-0x8802ffff] pci 0000:00:03.0: reg 0x30: [mem 0x88000000-0x8801ffff pref] pci 0000:00:03.0: supports D1 D2 pci 0000:00:03.0: can't claim BAR 1 [io 0x1000-0x10ff]: no compatible bridge window For this reason, the IO port resources boundaries check in generic ACPI parsing code should be guarded with a CONFIG_X86 guard so that more arches (ie ARM64) can benefit from the generic ACPI resources parsing interface without incurring in unexpected resource filtering, fixing at the same time current breakage on IA64. This patch factors out IO ports boundary [0 - 64k] check in generic ACPI code and makes the IO space check X86 specific to make sure that IO space resources are usable on other arches too. Fixes: 3772aea7d6f3 (ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge) Signed-off-by: Lorenzo Pieralisi Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9a6d6a47b4e1b661d00f3046d2e2c284fd438118 Author: Phil Elwell Date: Mon Feb 29 17:30:08 2016 -0800 pinctrl-bcm2835: Fix cut-and-paste error in "pull" parsing commit 2c7e3306d23864d49f686f22e56e180ff0fffb7f upstream. The DT bindings for pinctrl-bcm2835 allow both the function and pull to contain either one entry or one per pin. However, an error in the DT parsing can cause failures if the number of pulls differs from the number of functions. Signed-off-by: Eric Anholt Signed-off-by: Phil Elwell Reviewed-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 4b8be5deb9f3c385f193323864610aaf41e9eaa4 Author: Sebastian Ott Date: Mon Mar 14 15:47:23 2016 +0100 s390/pci: enforce fmb page boundary rule commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 upstream. The function measurement block must not cross a page boundary. Ensure that by raising the alignment requirement to the smallest power of 2 larger than the size of the fmb. Fixes: d0b088531 ("s390/pci: performance statistics and debug infrastructure") Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 1e461c84a2ea952b4590da63135e804feaefe2b3 Author: Heiko Carstens Date: Thu Mar 10 10:32:21 2016 +0100 s390/cpumf: add missing lpp magic initialization commit 8f100bb1ff27873dd71f636da670e503b9ade3c6 upstream. Add the missing lpp magic initialization for cpu 0. Without this all samples on cpu 0 do not have the most significant bit set in the program parameter field, which we use to distinguish between guest and host samples if the pid is also 0. We did initialize the lpp magic in the absolute zero lowcore but forgot that when switching to the allocated lowcore on cpu 0 only. Reported-by: Shu Juan Zhang Acked-by: Christian Borntraeger Fixes: e22cf8ca6f75 ("s390/cpumf: rework program parameter setting to detect guest samples") Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 7bcfb71fea912b3e35f1273bc22c843383249101 Author: Martin Schwidefsky Date: Thu Mar 10 09:52:55 2016 +0100 s390: fix floating pointer register corruption (again) commit e370e4769463a65dcf8806fa26d2874e0542ac41 upstream. There is a tricky interaction between the machine check handler and the critical sections of load_fpu_regs and save_fpu_regs functions. If the machine check interrupts one of the two functions the critical section cleanup will complete the function before the machine check handler s390_do_machine_check is called. Trouble is that the machine check handler needs to validate the floating point registers *before* and not *after* the completion of load_fpu_regs/save_fpu_regs. The simplest solution is to rewind the PSW to the start of the load_fpu_regs/save_fpu_regs and retry the function after the return from the machine check handler. Tested-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 2cba88d0b945c4b1702b7b6d44a551c687b5553a Author: Dan Carpenter Date: Wed Jan 20 12:54:51 2016 +0300 EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr() commit 6f3508f61c814ee852c199988a62bd954c50dfc1 upstream. dct_sel_base_off is declared as a u64 but we're only using the lower 32 bits because of a shift wrapping bug. This can possibly truncate the upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS row. Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset') Signed-off-by: Dan Carpenter Cc: Aravind Gopalakrishnan Cc: linux-edac Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwanda Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 87c58448c23bb26e0eeca142b84eeecec69b2637 Author: Tony Luck Date: Wed Mar 9 16:40:48 2016 -0800 EDAC/sb_edac: Fix computation of channel address commit eb1af3b71f9d83e45f2fd2fd649356e98e1c582c upstream. Large memory Haswell-EX systems with multiple DIMMs per channel were sometimes reporting the wrong DIMM. Found three problems: 1) Debug printouts for socket and channel interleave were not interpreting the register fields correctly. The socket interleave field is a 2^X value (0=1, 1=2, 2=4, 3=8). The channel interleave is X+1 (0=1, 1=2, 2=3. 3=4). 2) Actual use of the socket interleave value didn't interpret as 2^X 3) Conversion of address to channel address was complicated, and wrong. Signed-off-by: Tony Luck Acked-by: Aristeu Rozanski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Mauro Carvalho Chehab Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-edac@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ff3555af94db5bae35932dfdfc28541ee1cb76a8 Author: David Hildenbrand Date: Mon Feb 29 09:19:24 2016 +0100 sched/preempt, sh: kmap_coherent relies on disabled preemption commit b15d53d009558d14c4f394a6d1fa2039c7f45c43 upstream. kmap_coherent needs disabled preemption to not schedule in the critical section, just like kmap_coherent on mips and kmap_atomic in general. Fixes: 8222dbe21e79 "sched/preempt, mm/fault: Decouple preemption from the page fault logic" Reported-by: Hans Verkuil Signed-off-by: David Hildenbrand Tested-by: Hans Verkuil Signed-off-by: Rich Felker Signed-off-by: Greg Kroah-Hartman commit aab265efebfab78ba49e76c4bc77da87fd576134 Author: Byungchul Park Date: Fri Jan 15 16:07:49 2016 +0900 sched/fair: Avoid using decay_load_missed() with a negative value commit 7400d3bbaa229eb8e7631d28fb34afd7cd2c96ff upstream. decay_load_missed() cannot handle nagative values, so we need to prevent using the function with a negative value. Reported-by: Dietmar Eggemann Signed-off-by: Byungchul Park Signed-off-by: Peter Zijlstra (Intel) Cc: Chris Metcalf Cc: Christoph Lameter Cc: Frederic Weisbecker Cc: Linus Torvalds Cc: Luiz Capitulino Cc: Mike Galbraith Cc: Paul E . McKenney Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: perterz@infradead.org Fixes: 59543275488d ("sched/fair: Prepare __update_cpu_load() to handle active tickless") Link: http://lkml.kernel.org/r/20160115070749.GA1914@X58A-UD3R Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5fe34a9655e6844da16f3625b176bd94e4080c9a Author: Chris Friesen Date: Sat Mar 5 23:18:48 2016 -0600 sched/cputime: Fix steal_account_process_tick() to always return jiffies commit f9c904b7613b8b4c85b10cd6b33ad41b2843fa9d upstream. The callers of steal_account_process_tick() expect it to return whether a jiffy should be considered stolen or not. Currently the return value of steal_account_process_tick() is in units of cputime, which vary between either jiffies or nsecs depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN. If cputime has nsecs granularity and there is a tiny amount of stolen time (a few nsecs, say) then we will consider the entire tick stolen and will not account the tick on user/system/idle, causing /proc/stats to show invalid data. The fix is to change steal_account_process_tick() to accumulate the stolen time and only account it once it's worth a jiffy. (Thanks to Frederic Weisbecker for suggestions to fix a bug in my first version of the patch.) Signed-off-by: Chris Friesen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Gleixner Cc: Frederic Weisbecker Cc: Linus Torvalds Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/56DBBDB8.40305@mail.usask.ca Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f772b404a62f9039323faaff271ef11c6cba0aab Author: Zhang Rui Date: Fri Mar 18 10:03:24 2016 +0800 Thermal: Ignore invalid trip points commit 81ad4276b505e987dd8ebbdf63605f92cd172b52 upstream. In some cases, platform thermal driver may report invalid trip points, thermal core should not take any action for these trip points. This fixed a regression that bogus trip point starts to screw up thermal control on some Lenovo laptops, after commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461 Author: Zhang Rui Date: Fri Oct 30 16:31:47 2015 +0800 Thermal: initialize thermal zone device correctly After thermal zone device registered, as we have not read any temperature before, thus tz->temperature should not be 0, which actually means 0C, and thermal trend is not available. In this case, we need specially handling for the first thermal_zone_device_update(). Both thermal core framework and step_wise governor is enhanced to handle this. And since the step_wise governor is the only one that uses trends, so it's the only thermal governor that needs to be updated. Tested-by: Manuel Krause Tested-by: szegad Tested-by: prash Tested-by: amish Tested-by: Matthias Reviewed-by: Javi Merino Signed-off-by: Zhang Rui Signed-off-by: Chen Yu Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190 Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551 Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit bcd8d145c2c3d606f35d9f3b57ce66760cf01989 Author: Jiri Olsa Date: Sat Feb 27 21:21:12 2016 +0100 perf tools: Fix python extension build commit 67d5268908283c187e0a460048a423256c2fb288 upstream. The util/python-ext-sources file contains source files required to build the python extension relative to $(srctree)/tools/perf, Such a file path $(FILE).c is handed over to the python extension build system, which builds the final object in the $(PYTHON_EXTBUILD)/tmp/$(FILE).o path. After the build is done all files from $(PYTHON_EXTBUILD)lib/ are carried as the result binaries. Above system fails when we add source file relative to ../lib, which we do for: ../lib/bitmap.c ../lib/find_bit.c ../lib/hweight.c ../lib/rbtree.c All above objects will be built like: $(PYTHON_EXTBUILD)/tmp/../lib/bitmap.c $(PYTHON_EXTBUILD)/tmp/../lib/find_bit.c $(PYTHON_EXTBUILD)/tmp/../lib/hweight.c $(PYTHON_EXTBUILD)/tmp/../lib/rbtree.c which accidentally happens to be final library path: $(PYTHON_EXTBUILD)/lib/ Changing setup.py to pass full paths of source files to Extension build class and thus keep all built objects under $(PYTHON_EXTBUILD)tmp directory. Reported-by: Jeff Bastian Signed-off-by: Jiri Olsa Tested-by: Josh Boyer Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160227201350.GB28494@krava.redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 755cc377eac8f2465039031c39e7e48d838c56c2 Author: Wang Nan Date: Fri Feb 19 11:43:52 2016 +0000 perf tools: Fix checking asprintf return value commit 26dee028d365fbc0e3326606a8520260b4462381 upstream. According to man pages, asprintf returns -1 when failure. This patch fixes two incorrect return value checker. Signed-off-by: Wang Nan Cc: Adrian Hunter Cc: Alexei Starovoitov Cc: Brendan Gregg Cc: Cody P Schafer Cc: He Kuang Cc: Jeremie Galarneau Cc: Jiri Olsa Cc: Kirill Smelkov Cc: Li Zefan Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zefan Li Cc: pi3orama@163.com Fixes: ffeb883e5662 ("perf tools: Show proper error message for wrong terms of hw/sw events") Link: http://lkml.kernel.org/r/1455882283-79592-5-git-send-email-wangnan0@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 89ea57945fbd06c70a5651cca938256bf4bf662e Author: Andi Kleen Date: Wed Feb 17 14:44:55 2016 -0800 perf tools: Dont stop PMU parsing on alias parse error commit 940db6dcd3f4659303fdf6befe7416adc4d24118 upstream. When an error happens during alias parsing currently the complete parsing of all attributes of the PMU is stopped. This is breaks old perf on a newer kernel that may have not-yet-know alias attributes (such as .scale or .per-pkg). Continue when some attribute is unparseable. This is IMHO a stable candidate and should be backported to older versions to avoid problems with newer kernels. v2: Print warnings when something goes wrong. v3: Change warning to debug output Signed-off-by: Andi Kleen Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1455749095-18358-1-git-send-email-andi@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 00fa143c3b7a637799b771294810043375a8d2cd Author: Alexander Shishkin Date: Wed Mar 2 13:24:14 2016 +0200 perf/core: Fix perf_sched_count derailment commit 927a5570855836e5d5859a80ce7e91e963545e8f upstream. The error path in perf_event_open() is such that asking for a sampling event on a PMU that doesn't generate interrupts will end up in dropping the perf_sched_count even though it hasn't been incremented for this event yet. Given a sufficient amount of these calls, we'll end up disabling scheduler's jump label even though we'd still have active events in the system, thereby facilitating the arrival of the infernal regions upon us. I'm fixing this by moving account_event() inside perf_event_alloc(). Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/1456917854-29427-1-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ab1575d47615260f4075774fb3ed165a515c4dcd Author: Paolo Bonzini Date: Fri Mar 18 16:58:38 2016 +0100 KVM: VMX: fix nested vpid for old KVM guests commit ef697a712a6165aea7779c295604b099e8bfae2e upstream. Old KVM guests invoke single-context invvpid without actually checking whether it is supported. This was fixed by commit 518c8ae ("KVM: VMX: Make sure single type invvpid is supported before issuing invvpid instruction", 2010-08-01) and the patch after, but pre-2.6.36 kernels lack it including RHEL 6. Reported-by: jmontleo@redhat.com Tested-by: jmontleo@redhat.com Fixes: 99b83ac893b84ed1a62ad6d1f2b6cc32026b9e85 Reviewed-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 014278ed6f387435f34833bd72bb9f63442f243b Author: Paolo Bonzini Date: Fri Mar 18 16:53:42 2016 +0100 KVM: VMX: avoid guest hang on invalid invvpid instruction commit f6870ee9e53430f2a318ccf0dd5e66bb46194e43 upstream. A guest executing an invalid invvpid instruction would hang because the instruction pointer was not updated. Reported-by: jmontleo@redhat.com Tested-by: jmontleo@redhat.com Fixes: 99b83ac893b84ed1a62ad6d1f2b6cc32026b9e85 Reviewed-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8c9f1d780ccfc830a8f7fd03135fc34c6fefe378 Author: Paolo Bonzini Date: Fri Mar 18 16:53:29 2016 +0100 KVM: VMX: avoid guest hang on invalid invept instruction commit 2849eb4f99d54925c543db12917127f88b3c38ff upstream. A guest executing an invalid invept instruction would hang because the instruction pointer was not updated. Fixes: bfd0a56b90005f8c8a004baf407ad90045c2b11e Reviewed-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f2979484e31ad7882d7ac33d535dae14e5957217 Author: Paolo Bonzini Date: Mon Mar 21 10:15:25 2016 +0100 KVM: fix spin_lock_init order on x86 commit e9ad4ec8379ad1ba6f68b8ca1c26b50b5ae0a327 upstream. Moving the initialization earlier is needed in 4.6 because kvm_arch_init_vm is now using mmu_lock, causing lockdep to complain: [ 284.440294] INFO: trying to register non-static key. [ 284.445259] the code is fine but needs lockdep annotation. [ 284.450736] turning off the locking correctness validator. ... [ 284.528318] [] lock_acquire+0xd3/0x240 [ 284.533733] [] ? kvm_page_track_register_notifier+0x20/0x60 [kvm] [ 284.541467] [] _raw_spin_lock+0x41/0x80 [ 284.546960] [] ? kvm_page_track_register_notifier+0x20/0x60 [kvm] [ 284.554707] [] kvm_page_track_register_notifier+0x20/0x60 [kvm] [ 284.562281] [] kvm_mmu_init_vm+0x20/0x30 [kvm] [ 284.568381] [] kvm_arch_init_vm+0x1ea/0x200 [kvm] [ 284.574740] [] kvm_dev_ioctl+0xbf/0x4d0 [kvm] However, it also helps fixing a preexisting problem, which is why this patch is also good for stable kernels: kvm_create_vm was incrementing current->mm->mm_count but not decrementing it at the out_err label (in case kvm_init_mmu_notifier failed). The new initialization order makes it possible to add the required mmdrop without adding a new error label. Reported-by: Borislav Petkov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 84331ed8b40e5e01c7bfe1e3ac42c26cd1b44e3e Author: Radim Krčmář Date: Wed Mar 2 22:56:38 2016 +0100 KVM: i8254: change PIT discard tick policy commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 upstream. Discard policy uses ack_notifiers to prevent injection of PIT interrupts before EOI from the last one. This patch changes the policy to always try to deliver the interrupt, which makes a difference when its vector is in ISR. Old implementation would drop the interrupt, but proposed one injects to IRR, like real hardware would. The old policy breaks legacy NMI watchdogs, where PIT is used through virtual wire (LVT0): PIT never sends an interrupt before receiving EOI, thus a guest deadlock with disabled interrupts will stop NMIs. Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt through IOAPIC. (KVM's PIT is deeply rotten and luckily not used much in modern systems.) Even though there is a chance of regressions, I think we can fix the LVT0 NMI bug without introducing a new tick policy. Reported-by: Yuki Shibuya Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2cff86e5cc51a53f3565e92dd3a223c2ec40a57f Author: Paolo Bonzini Date: Wed Feb 10 17:50:23 2016 +0100 KVM: x86: fix missed hardware breakpoints commit 4e422bdd2f849d98fffccbc3295c2f0996097fb3 upstream. Sometimes when setting a breakpoint a process doesn't stop on it. This is because the debug registers are not loaded correctly on VCPU load. The following simple reproducer from Oleg Nesterov tries using debug registers in both the host and the guest, for example by running "./bp 0 1" on the host and "./bp 14 15" under QEMU. #include #include #include #include #include #include #include #include #include #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len) { unsigned long dr7; dr7 = ((len | type) & 0xf) << (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE); if (enable) dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE)); return dr7; } int write_dr(int pid, int dr, unsigned long val) { return ptrace(PTRACE_POKEUSER, pid, offsetof (struct user, u_debugreg[dr]), val); } void set_bp(pid_t pid, void *addr) { unsigned long dr7; assert(write_dr(pid, 0, (long)addr) == 0); dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1); assert(write_dr(pid, 7, dr7) == 0); } void *get_rip(int pid) { return (void*)ptrace(PTRACE_PEEKUSER, pid, offsetof(struct user, regs.rip), 0); } void test(int nr) { void *bp_addr = &&label + nr, *bp_hit; int pid; printf("test bp %d\n", nr); assert(nr < 16); // see 16 asm nops below pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); kill(getpid(), SIGSTOP); for (;;) { label: asm ( "nop; nop; nop; nop;" "nop; nop; nop; nop;" "nop; nop; nop; nop;" "nop; nop; nop; nop;" ); } } assert(pid == wait(NULL)); set_bp(pid, bp_addr); for (;;) { assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0); assert(pid == wait(NULL)); bp_hit = get_rip(pid); if (bp_hit != bp_addr) fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n", bp_hit - &&label, nr); } } int main(int argc, const char *argv[]) { while (--argc) { int nr = atoi(*++argv); if (!fork()) test(nr); } while (wait(NULL) > 0) ; return 0; } Suggested-by: Nadadv Amit Reported-by: Andrey Wagin Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1eea6fc028a63034799f7eb8954f6a4b17aaa646 Author: Bjorn Helgaas Date: Fri Feb 26 09:15:11 2016 -0600 x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs commit b894157145e4ac7598d7062bc93320898a5e059e upstream. The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register where a BAR should be. We don't know what the side effects of sizing the "BAR" would be, and we don't know what address space the "BAR" might appear to describe. Mark these devices as having non-compliant BARs so the PCI core doesn't touch them. Signed-off-by: Bjorn Helgaas Tested-by: Andi Kleen Signed-off-by: Greg Kroah-Hartman commit 591add21a1f098cf92494581b815e5de486faa6e Author: Bjorn Helgaas Date: Thu Feb 25 14:35:57 2016 -0600 PCI: Disable IO/MEM decoding for devices with non-compliant BARs commit b84106b4e2290c081cdab521fa832596cdfea246 upstream. The PCI config header (first 64 bytes of each device's config space) is defined by the PCI spec so generic software can identify the device and manage its usage of I/O, memory, and IRQ resources. Some non-spec-compliant devices put registers other than BARs where the BARs should be. When the PCI core sizes these "BARs", the reads and writes it does may have unwanted side effects, and the "BAR" may appear to describe non-sensical address space. Add a flag bit to mark non-compliant devices so we don't touch their BARs. Turn off IO/MEM decoding to prevent the devices from consuming address space, since we can't read the BARs to find out what that address space would be. Signed-off-by: Bjorn Helgaas Tested-by: Andi Kleen Signed-off-by: Greg Kroah-Hartman commit 319f9d43118f0d3ac29ee30ea6d211ea87917a47 Author: Stephane Eranian Date: Thu Mar 3 20:50:40 2016 +0100 perf/x86/intel: Add definition for PT PMI bit commit 5690ae28e472d25e330ad0c637a5cea3fc39fb32 upstream. This patch adds a definition for GLOBAL_OVFL_STATUS bit 55 which is used with the Processor Trace (PT) feature. Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vince Weaver Cc: adrian.hunter@intel.com Cc: kan.liang@intel.com Cc: namhyung@kernel.org Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 878945292e63f910d95b3c8402b0149a92422ebe Author: Andy Lutomirski Date: Wed Feb 10 14:15:27 2016 -0800 x86/entry/compat: Keep TS_COMPAT set during signal delivery commit 4e79e182b419172e35936a47f098509092d69817 upstream. Signal delivery needs to know the sign of an interrupted syscall's return value in order to detect -ERESTART variants. Normally this works independently of bitness because syscalls internally return long. Under ptrace, however, this can break, and syscall_get_error is supposed to sign-extend regs->ax if needed. We were clearing TS_COMPAT too early, though, and this prevented sign extension, which subtly broke syscall restart under ptrace. Reported-by: Robert O'Callahan Signed-off-by: Andy Lutomirski Cc: Al Viro Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Shuah Khan Cc: Thomas Gleixner Fixes: c5c46f59e4e7 ("x86/entry: Add new, comprehensible entry and exit handlers written in C") Link: http://lkml.kernel.org/r/cbce3cf545522f64eb37f5478cb59746230db3b5.1455142412.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3622d570863a83f6d388c9c3e1de95a48df083a1 Author: Borislav Petkov Date: Wed Feb 3 12:33:29 2016 +0100 x86/microcode: Untangle from BLK_DEV_INITRD commit 5f9c01aa7c49a2d74474d6d879a797b8badf29e6 upstream. Thomas Voegtle reported that doing oldconfig with a .config which has CONFIG_MICROCODE enabled but BLK_DEV_INITRD disabled prevents the microcode loading mechanism from being built. So untangle it from the BLK_DEV_INITRD dependency so that oldconfig doesn't turn it off and add an explanatory text to its Kconfig help what the supported methods for supplying microcode are. Reported-by: Thomas Voegtle Tested-by: Thomas Voegtle Signed-off-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1454499225-21544-2-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit cd47ecf883927f998aa03f94dd928d4ac5ccabdc Author: Borislav Petkov Date: Wed Feb 3 12:33:30 2016 +0100 x86/microcode/intel: Make early loader look for builtin microcode too commit 264285ac01673e70557c43ecee338ce97c4c0672 upstream. Set the initrd @start depending on the presence of an initrd. Otherwise, builtin microcode loading doesn't work as the start is wrong and we're using it to compute offset to the microcode blobs. Tested-by: Thomas Voegtle Signed-off-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1454499225-21544-3-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman