commit f151e73cea45b97a5690806f3391d10e547d04d9 Author: Sasha Levin Date: Tue Apr 19 07:57:18 2016 -0400 Linux 3.18.31 Signed-off-by: Sasha Levin commit 7855e916590ab8d97abcba3d0dc735bcfa55561d Author: Herbert Xu Date: Fri Feb 26 12:44:11 2016 +0100 crypto: algif_skcipher - Fix race condition in skcipher_check_key commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream. We need to lock the child socket in skcipher_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 801492e27fb9f24b4e05bc79047301408d5a6a0d Author: Herbert Xu Date: Fri Feb 26 12:44:10 2016 +0100 crypto: algif_skcipher - Remove custom release parent function commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream. This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 50d7bf3d3dc47b13de6aefc397bd75ce145b9ef4 Author: Herbert Xu Date: Fri Feb 26 12:44:09 2016 +0100 crypto: algif_skcipher - Add nokey compatibility path commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream. This patch adds a compatibility path to support old applications that do acept(2) before setkey. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu [backported to 3.18 by Milan Broz ] Signed-off-by: Sasha Levin commit 1f45c38917129af49a187aae8f2ef76d098d66ca Author: Herbert Xu Date: Fri Feb 26 12:44:08 2016 +0100 crypto: algif_skcipher - Require setkey before accept(2) commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream. Some cipher implementations will crash if you try to use them without calling setkey first. This patch adds a check so that the accept(2) call will fail with -ENOKEY if setkey hasn't been done on the socket yet. Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Tested-by: Dmitry Vyukov [backported to 3.18 by Milan Broz ] Signed-off-by: Sasha Levin commit 0f7ec538eb0b8cf59f0e314dbe5cd5ac9946f2af Author: Hyungwon Hwang Date: Wed Apr 13 09:27:39 2016 +0900 ALSA: hda - Fix regression of monitor_present flag in eld proc file [ Upstream commit 023d8218ec0dfc30e11d4ec54f640e8f127d1fbe ] The commit [bd48128539ab: ALSA: hda - Fix forgotten HDMI monitor_present update] covered the missing update of monitor_present flag, but this caused a regression for devices without the i915 eld notifier. Since the old code supposed that pin_eld->monitor_present was updated by the caller side, the hdmi_present_sense_via_verbs() doesn't update the temporary eld->monitor_present but only pin_eld->monitor_present, which is now overridden in update_eld(). The fix is to update pin_eld->monitor_present as well before calling update_eld(). Note that this may still leave monitor_present flag in an inconsistent state when the driver repolls, but this is at least the old behavior. More proper fix will follow in the later patch. Fixes: bd48128539ab ('ALSA: hda - Fix forgotten HDMI monitor_present update') Signed-off-by: Hyungwon Hwang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8afa97ba940aec46ad0ac07ad36b77c600c1fe0b Author: dann frazier Date: Mon Jan 25 16:52:16 2016 -0700 arm64: errata: Add -mpc-relative-literal-loads to build flags [ Upstream commit 67dfa1751ce71e629aad7c438e1678ad41054677 ] GCC6 (and Linaro's 2015.12 snapshot of GCC5) has a new default that uses adrp/ldr or adrp/add to address literal pools. When CONFIG_ARM64_ERRATUM_843419 is enabled, modules built with this toolchain fail to load: module libahci: unsupported RELA relocation: 275 This patch fixes the problem by passing '-mpc-relative-literal-loads' to the compiler. Cc: stable@vger.kernel.org Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") BugLink: http://bugs.launchpad.net/bugs/1533009 Acked-by: Ard Biesheuvel Suggested-by: Christophe Lyon Signed-off-by: Dann Frazier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d0706774e7b2c1509c339bfb37e061eb45ef65f8 Author: Vlastimil Babka Date: Fri Mar 25 14:21:50 2016 -0700 mm/page_alloc: prevent merging between isolated and other pageblocks [ Upstream commit d9dddbf556674bf125ecd925b24e43a5cf2a568a ] 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" Cc: [3.18+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 972c6ab7bf6590ccfd3904528de6cc72fefdecc9 Author: Kirill A. Shutemov Date: Fri Nov 6 16:29:57 2015 -0800 mm: use 'unsigned int' for page order [ Upstream commit d00181b96eb86c914cb327d1de974a1b71366e1b ] Let's try to be consistent about data type of page order. [sfr@canb.auug.org.au: fix build (type of pageblock_order)] [hughd@google.com: some configs end up with MAX_ORDER and pageblock_order having different types] Signed-off-by: Kirill A. Shutemov Acked-by: Michal Hocko Acked-by: Vlastimil Babka Reviewed-by: Andrea Arcangeli Cc: "Paul E. McKenney" Cc: Andi Kleen Cc: Aneesh Kumar K.V Cc: Christoph Lameter Cc: David Rientjes Cc: Joonsoo Kim Cc: Sergey Senozhatsky Signed-off-by: Stephen Rothwell Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 302ea3eccb3317a4f4a04e00b6d7a1e811f87fa0 Author: Mel Gorman Date: Tue Jun 30 14:56:52 2015 -0700 mm: page_alloc: pass PFN to __free_pages_bootmem [ Upstream commit d70ddd7a5d9aa335f9b4b0c3d879e1e70ee1e4e3 ] __free_pages_bootmem prepares a page for release to the buddy allocator and assumes that the struct page is initialised. Parallel initialisation of struct pages defers initialisation and __free_pages_bootmem can be called for struct pages that cannot yet map struct page to PFN. This patch passes PFN to __free_pages_bootmem with no other functional change. Signed-off-by: Mel Gorman Tested-by: Nate Zimmer Tested-by: Waiman Long Tested-by: Daniel J Blueman Acked-by: Pekka Enberg Cc: Robin Holt Cc: Nate Zimmer Cc: Dave Hansen Cc: Waiman Long Cc: Scott Norton Cc: "Luck, Tony" Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7700775a587cfaa5f5d7e52e100bae48cc6360c9 Author: Joseph Qi Date: Fri Mar 25 14:21:29 2016 -0700 ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list [ Upstream commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c ] 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2fd6e6b6bbaf3822aaffe19f1d037e12c8f93c94 Author: Joseph Qi Date: Fri Mar 25 14:21:26 2016 -0700 ocfs2/dlm: fix race between convert and recovery [ Upstream commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac ] 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 37735ed2c8c12e9671a3742d6b9028bad43852df Author: Vladis Dronov Date: Wed Mar 23 11:53:46 2016 -0700 Input: ati_remote2 - fix crashes on detecting device with invalid descriptor [ Upstream commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d ] 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 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 45ff8f5963fd240a6f60950e586a6118a199ef96 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 [ Upstream commit 4db9675d927a71faa66e5ab128d2390d6329750b ] 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 Cc: Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 233f3510873b56ded9ae992a38849348c55e74b4 Author: H Hartley Sweeten Date: Tue Mar 22 10:04:48 2016 -0700 staging: comedi: ni_mio_common: fix the ni_write[blw]() functions [ Upstream commit bd3a3cd6c27b117fb9a43a38c8072c95332beecc ] 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)") Cc: # 3.17+ Signed-off-by: H Hartley Sweeten Reviewed-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e3bad33ccfa12b4e40338a4539b5f4ad8ffd7e3 Author: Aurelien Jacquiot Date: Tue Mar 22 14:25:42 2016 -0700 rapidio/rionet: fix deadlock on SMP [ Upstream commit 36915976eca58f2eefa040ba8f9939672564df61 ] 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1249f099a3ffd474d7531bd558620c233445880c Author: Jann Horn Date: Tue Mar 22 14:25:36 2016 -0700 fs/coredump: prevent fsuid=0 dumps into user-controlled directories [ Upstream commit 378c6520e7d29280f400ef2ceaf155c86f05a71a ] 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 51d109b05dea76910c6b5c95908e9e334888f46f Author: Steven Rostedt (Red Hat) Date: Tue Mar 22 17:30:58 2016 -0400 tracing: Fix trace_printk() to print when not using bprintk() [ Upstream commit 3debb0a9ddb16526de8b456491b7db60114f7b5e ] 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()" Cc: stable@vger.kernel.org # v3.5+ Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 241a9a816bc95d7bbc7c422c60e880491a59ac1b Author: Paolo Bonzini Date: Mon Mar 21 10:15:25 2016 +0100 KVM: fix spin_lock_init order on x86 [ Upstream commit e9ad4ec8379ad1ba6f68b8ca1c26b50b5ae0a327 ] 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. Cc: stable@vger.kernel.org Reported-by: Borislav Petkov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 7aae44c91487a1f7210a1fb7e3ed608f6f6ef653 Author: Paolo Bonzini Date: Fri Mar 18 16:53:29 2016 +0100 KVM: VMX: avoid guest hang on invalid invept instruction [ Upstream commit 2849eb4f99d54925c543db12917127f88b3c38ff ] A guest executing an invalid invept instruction would hang because the instruction pointer was not updated. Cc: stable@vger.kernel.org Fixes: bfd0a56b90005f8c8a004baf407ad90045c2b11e Reviewed-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 65d83d876f80afef16c27b62d79e160bf73df652 Author: Himanshu Madhani Date: Mon Mar 14 22:47:37 2016 -0700 target: Fix target_release_cmd_kref shutdown comp leak [ Upstream commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e ] 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 Cc: stable@vger.kernel.org Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 2b45fad3434ae14a854aad1483331b0950f07598 Author: Peter Zijlstra Date: Wed Mar 9 12:40:54 2016 +0100 bitops: Do not default to __clear_bit() for __clear_bit_unlock() [ Upstream commit f75d48644c56a31731d17fa693c8175328957e1d ] __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 Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 5a43ab953aa698726d01bafa1e85ddfa0b8f50e2 Author: Victor Clément Date: Sat Mar 19 13:17:42 2016 +0100 ALSA: usb-audio: add Microsoft HD-5001 to quirks [ Upstream commit 0ef21100ae912f76ed89f76ecd894f4ffb3689c1 ] 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0651623b0d2d44343184791e7145f0fe871eec6e Author: Rabin Vincent Date: Thu Mar 10 21:19:06 2016 +0100 splice: handle zero nr_pages in splice_to_pipe() [ Upstream commit d6785d9152147596f60234157da2b02540c3e60f ] 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. Cc: stable@vger.kernel.org Signed-off-by: Rabin Vincent Reviewed-by: Christoph Hellwig Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 53c83cddcf243ea06ce8b41b0328a2733b3aa88e Author: Steven Rostedt (Red Hat) Date: Fri Mar 18 15:46:48 2016 -0400 tracing: Fix crash from reading trace_pipe with sendfile [ Upstream commit a29054d9478d0435ab01b7544da4f674ab13f533 ] 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 Cc: stable@vger.kernel.org # 2.6.30+ Reported-by: Rabin Vincent Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 75f5d86e8020072909984e867727961594649290 Author: Hans de Goede Date: Mon Mar 7 20:11:52 2016 +0100 USB: uas: Reduce can_queue to MAX_CMNDS [ Upstream commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 ] 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. Cc: stable@vger.kernel.org Reported-and-tested-by: Yves-Alexis Perez Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4576d5d818abff73e363027f52da09519573c924 Author: Oliver Neukum Date: Tue Mar 15 10:14:04 2016 +0100 USB: cdc-acm: more sanity checking [ Upstream commit 8835ba4a39cf53f705417b3b3a94eb067673f2c9 ] 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 CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 99790a913e5dbf8cf23f776aa546fc2feec767c7 Author: Oliver Neukum Date: Wed Mar 16 13:26:17 2016 +0100 USB: usb_driver_claim_interface: add sanity checking [ Upstream commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd ] 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 CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7e28ea3b8945ae73ef5372e1ed99cf54355e225c Author: Josh Boyer Date: Mon Mar 14 10:42:38 2016 -0400 USB: iowarrior: fix oops with malicious USB descriptors [ Upstream commit 4ec0ef3a82125efc36173062a50624550a900ae0 ] 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 Cc: stable Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3496f12f95df9beb21e79dee3a78a704b0951187 Author: Dave Jones Date: Mon Mar 14 21:20:54 2016 -0400 x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt() [ Upstream commit 7834c10313fb823e538f2772be78edcdeed2e6e3 ] 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 ------------------------------- ./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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 79a6f040d874e0dec6adf116034ac59fbb5710fd Author: Zhang Rui Date: Fri Mar 18 10:03:24 2016 +0800 Thermal: Ignore invalid trip points [ Upstream commit 81ad4276b505e987dd8ebbdf63605f92cd172b52 ] 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 CC: #3.18+ 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: Sasha Levin commit 8eefdb0cfd7d4285ba26a21544a94a630c4d2d6b Author: Benjamin Tissoires Date: Thu Mar 17 17:12:54 2016 -0700 Input: synaptics - handle spurious release of trackstick buttons, again [ Upstream commit 82be788c96ed5978d3cb4a00079e26b981a3df3f ] Looks like the fimware 8.2 still has the extra buttons spurious release bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321 Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 7ca573e32c0a6634d679540314a80d235f224bfb Author: Oliver Neukum Date: Thu Mar 17 14:00:17 2016 -0700 Input: ims-pcu - sanity check against missing interfaces [ Upstream commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff ] A malicious device missing interface can make the driver oops. Add sanity checking. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 46f2d8689df2b63a3c96f384873905ec9b0a7a4e Author: Adrian Hunter Date: Mon Mar 7 13:33:55 2016 +0200 mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout [ Upstream commit 995136247915c5cee633d55ba23f6eebf67aa567 ] 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 Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9c6167f2e64c024b1e9b8ee2e484599c33352a9c Author: Andy Lutomirski Date: Wed Mar 16 14:14:22 2016 -0700 x86/iopl: Fix iopl capability check on Xen PV [ Upstream commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e ] 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 Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 3cc3cf9f926dbcab22d9f779802d2abce7d26b86 Author: Hans de Goede Date: Sun Mar 8 21:53:42 2015 +0100 ARM: dts: sunxi: Adjust touchscreen compatible for sun5i and later [ Upstream commit 8bf1b9b3d90194a174493febc731f7783f2adf1a ] The touchscreen controller in the A13 and later has a different temperature curve than the one in the original A10, change the compatible for the A13 and later so that the kernel will use the correct curve. Reported-by: Tong Zhang Signed-off-by: Hans de Goede Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 652181312ec344432085373c90d46d129a7b51ef Author: J. Bruce Fields Date: Wed Mar 2 16:36:21 2016 -0800 nfsd: fix deadlock secinfo+readdir compound [ Upstream commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 ] 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. Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 53b7c0ed67fecfb2123a14b4d1ae246fb2807283 Author: Takashi Iwai Date: Tue Mar 15 12:09:10 2016 +0100 ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk() [ Upstream commit 0f886ca12765d20124bd06291c82951fd49a33be ] 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5cb0beae3394b7c12219ccd234ba4e42f9f38742 Author: Magnus Damm Date: Tue Feb 16 13:06:41 2016 +0900 mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case [ Upstream commit bcdc9f260bdce09913db1464be9817170d51044a ] 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 Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c35cf32190d36ded702ba2742aff6c2c4f4f1e8b Author: Takashi Iwai Date: Tue Mar 15 16:44:55 2016 +0100 ALSA: hda - Fix unconditional GPIO toggle via automute [ Upstream commit 1f7c6658962fa1260c1658d681bd6bb0c746b99a ] 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e5190d1af6282c6d8262d059159f6786c374dc5f 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() [ Upstream commit 3b654288b196ceaa156029d9457ccbded0489b98 ] 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. Cc: stable@vger.kernel.org Reported-by: Alexander Potapenko Signed-off-by: Dmitry Torokhov Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9e6188f5fbedd4fafd242a88121023e24a487172 Author: Dmitri Epshtein Date: Sat Mar 12 18:44:18 2016 +0100 net: mvneta: enable change MAC address when interface is up [ Upstream commit 928b6519afeb2a5e2dc61154380b545ed66c476a ] 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") Cc: stable@vger.kernel.org Signed-off-by: Dmitri Epshtein Signed-off-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 015e566a0e0d9bcd2b0538d001e65e0b63d3d5ff Author: Ming Lei Date: Sat Mar 12 09:29:40 2016 +0800 md: multipath: don't hardcopy bio in .make_request path [ Upstream commit fafcde3ac1a418688a734365203a12483b83907a ] 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. Cc: stable@vger.kernel.org (v3.14+) Reported-and-tested-by: Andrea Righi Signed-off-by: Ming Lei Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit ef8259645a0592cdf37ecbc466806d7e78248d5a Author: Alex Deucher Date: Thu Mar 10 15:55:26 2016 -0500 drm/radeon: rework fbdev handling on chips with no connectors [ Upstream commit e5f243bd2edd95c6cc1d90c1878f821068e83fba ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit cb1625e4abe1434f3ebc321d8a52e8041ddb0b7a Author: Dave Airlie Date: Tue Feb 24 09:23:59 2015 +1000 radeon/fb: add wrapper functions around fb connector add/remove [ Upstream commit bb26270ed2d1944e0d7d573b4c46b5dade8db095 ] These are just two wrappers to be used in the MST code later. Signed-off-by: Dave Airlie Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b684cb33d6867e10ba45375a12ef9f3ceb6f0aa7 Author: Josh Boyer Date: Mon Mar 14 09:33:40 2016 -0700 Input: powermate - fix oops with malicious USB descriptors [ Upstream commit 9c6ba456711687b794dcf285856fc14e2c76074f ] 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 Cc: stable Signed-off-by: Josh Boyer Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit cc1f245678051ff224e9aca9502ae430a8bdf5d9 Author: Sebastian Ott Date: Mon Mar 14 15:47:23 2016 +0100 s390/pci: enforce fmb page boundary rule [ Upstream commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 ] 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") Cc: stable@vger.kernel.org # v3.8+ Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit f0ed9d88d009fdaf30fe93c366c1f1f87df73a19 Author: Sebastian Ott Date: Fri Apr 10 14:33:08 2015 +0200 s390/pci: extract software counters from fmb [ Upstream commit 6001018ae8c659e624351d2e73b1272bacd68d6a ] The software counters are not a part of the function measurement block. Also we do not check for zdev->fmb != NULL when using these counters (function measurement can be toggled at runtime). Just move the software counters to struct zpci_dev. Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 949211e6fbf57cbf460f36941f785d720b43c3dc 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. [ Upstream commit 4061db03dd71d195b9973ee466f6ed32f6a3fc16 ] 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 Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 80ddd8acdf9226bda1266e68b059372ea1b83063 Author: Sasha Levin Date: Thu Apr 7 18:19:07 2016 -0400 ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hda [ Upstream commit 3ec622f40913ae036f218e5e7e92df9c1f1753d9 ] Vendor ID 0x10de0083 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: Sasha Levin commit 73cce865131a1214d71570a5369eb366565c896a Author: Aaron Plattner Date: Sun Mar 13 13:58:57 2016 -0700 ALSA: hda - Add new GPU codec ID 0x10de0082 to snd-hda [ Upstream commit 2d369c748c2ecc2a012ee85412a04007e67913ec ] 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4f6b633d6d1dc9e48d1559901898fbd3862be79c Author: Aaron Plattner Date: Mon Jul 20 17:14:14 2015 -0700 ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda [ Upstream commit 6c3d91193d829bf58a35a10650415b05a736ca6c ] Vendor ID 0x10de007d 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9de250999c5c3ef93aced491db8d9560220768f9 Author: Fabio Estevam Date: Mon Feb 22 09:01:53 2016 -0300 bus: imx-weim: Take the 'status' property value into account [ Upstream commit 33b96d2c9579213cf3f36d7b29841b1e464750c4 ] Currently we have an incorrect behaviour when multiple devices are present under the weim node. For example: &weim { ... status = "okay"; sram@0,0 { ... status = "okay"; }; mram@0,0 { ... status = "disabled"; }; }; In this case only the 'sram' device should be probed and not 'mram'. However what happens currently is that the status variable is ignored, causing the 'sram' device to be disabled and 'mram' to be enabled. Change the weim_parse_dt() function to use for_each_available_child_of_node()so that the devices marked with 'status = disabled' are not probed. Cc: Suggested-by: Wolfgang Netbal Signed-off-by: Fabio Estevam Reviewed-by: Sascha Hauer Acked-by: Shawn Guo Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit a4e6ab6425bda36516505a15afa96f76ffa64cb7 Author: Max Filippov Date: Thu Mar 3 18:34:29 2016 +0300 xtensa: clear all DBREAKC registers on start [ Upstream commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab ] 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 Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 223e720da8b5078f3a165754e338615f615107db Author: Max Filippov Date: Thu Feb 25 23:27:51 2016 +0300 xtensa: fix preemption in {clear,copy}_user_highpage [ Upstream commit a67cc9aa2dfc6e66addf240bbd79e16e01565e81 ] Disabling pagefault makes little sense there, preemption disabling is what was meant. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit e8e05a75cac99144bda2618ea177f10e52a4dcfb Author: Max Filippov Date: Tue Feb 9 01:02:38 2016 +0300 xtensa: ISS: don't hang if stdin EOF is reached [ Upstream commit 362014c8d9d51d504c167c44ac280169457732be ] 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. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 19f840f34154c67db702c02daf50e48f474eb918 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 [ Upstream commit 6ef2f68fa38bf415830f67903d87180d933e0f47 ] 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. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1555912 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 41aed1ba771cf743f9a465fbd98ead55239dca20 Author: Dmitry Tunin Date: Fri Mar 4 01:32:19 2016 +0300 Bluetooth: btusb: Add a new AR3012 ID 13d3:3472 [ Upstream commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7d974c26f1dc39573f5f6c7d65fe21892e8246d2 Author: Luck, Tony Date: Wed Mar 9 16:40:48 2016 -0800 EDAC/sb_edac: Fix computation of channel address [ Upstream commit eb1af3b71f9d83e45f2fd2fd649356e98e1c582c ] 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 Cc: stable@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 44d77496ba729e62328930e9f949adb32b4c3af7 Author: OGAWA Hirofumi Date: Wed Mar 9 23:47:25 2016 -0500 jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path [ Upstream commit c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b90a66cdab6fc988e973c7c863f475c46e465847 Author: Douglas Gilbert Date: Thu Mar 3 00:31:29 2016 -0500 sg: fix dxferp in from_to case [ Upstream commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ] 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 Cc: #v2.6.28+ Signed-off-by: Douglas Gilbert Reviewed-by: Ewan Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bfe0248670a2e877c97f6509888dea50b453a8bb 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. [ Upstream commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0c4ed2f42fdd3c471f9aba2f051a22ca362c23bd Author: Alex Deucher Date: Wed Mar 2 11:47:29 2016 -0500 drm/radeon: disable runtime pm on PX laptops without dGPU power control [ Upstream commit e64c952efb8e0c15ae82cec8e455ab4910690ef1 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 64556df8779eac2000c7c2d8c5686da07173d584 Author: Maurizio Lombardi Date: Fri Mar 4 10:41:49 2016 +0100 be2iscsi: set the boot_kset pointer to NULL in case of failure [ Upstream commit 84bd64993f916bcf86270c67686ecf4cea7b8933 ] 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. Cc: Signed-off-by: Maurizio Lombardi Reviewed-by: Johannes Thumshirn Reviewed-by: Jitendra Bhivare Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5f59838bb3a068332e06dff3d20ff4b97c8902d5 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 [ Upstream commit b894157145e4ac7598d7062bc93320898a5e059e ] 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 CC: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 3629c42c9918a763d75786479f384a00324ec4f0 Author: Eric Wheeler Date: Mon Mar 7 15:17:50 2016 -0800 bcache: fix cache_set_flush() NULL pointer dereference on OOM [ Upstream commit f8b11260a445169989d01df75d35af0f56178f95 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 6af6167c3f1905018cde0262ceae7e07b70cb577 Author: Eric Wheeler Date: Fri Feb 26 14:33:56 2016 -0800 bcache: cleaned up error handling around register_cache() [ Upstream commit 9b299728ed777428b3908ac72ace5f8f84b97789 ] 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 Cc: Signed-off-by: Sasha Levin commit c2f87b5d704608a0ca412d511ff2ca8b7eb1ff36 Author: Eric Wheeler Date: Fri Feb 26 14:39:06 2016 -0800 bcache: fix race of writeback thread starting before complete initialization [ Upstream commit 07cc6ef8edc47f8b4fc1e276d31127a0a5863d4d ] 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 Cc: Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e62daff6d23932a38b45f005ba4736bdf230ff84 Author: Chris Friesen Date: Sat Mar 5 23:18:48 2016 -0600 sched/cputime: Fix steal_account_process_tick() to always return jiffies [ Upstream commit f9c904b7613b8b4c85b10cd6b33ad41b2843fa9d ] 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: 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: Sasha Levin commit 1011e8d090703e119111809f7550c8453d572444 Author: Stephane Eranian Date: Thu Mar 3 20:50:40 2016 +0100 perf/x86/intel: Add definition for PT PMI bit [ Upstream commit 5690ae28e472d25e330ad0c637a5cea3fc39fb32 ] 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: 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: Sasha Levin commit 7a6e8996cc8a8fa91a0893d957751d241067d0b9 Author: Andi Kleen Date: Sun May 10 12:22:41 2015 -0700 x86: Add new MSRs and MSR bits used for Intel Skylake PMU support [ Upstream commit b83ff1c8617aac03a1cf807aafa848fe0f0908f2 ] Add new MSRs (LBR_INFO) and some new MSR bits used by the Intel Skylake PMU driver. Signed-off-by: Andi Kleen Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: eranian@google.com Link: http://lkml.kernel.org/r/1431285767-27027-4-git-send-email-andi@firstfloor.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 948536bf4148ad08cc2d87aedde1ab97ff3d5291 Author: Radim Krčmář Date: Wed Mar 2 22:56:38 2016 +0100 KVM: i8254: change PIT discard tick policy [ Upstream commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 ] 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. Cc: Reported-by: Yuki Shibuya Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b7f66a07f4d525ead43d073eed407a140861248b 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 [ Upstream commit 0d5ce778c43bf888328231bcdce05d5c860655aa ] 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 CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c0fd92c4a0cac1f210b5868cec69df5ccb4a3146 Author: Vinayak Menon Date: Mon Feb 22 19:15:44 2016 +0530 of: alloc anywhere from memblock if range not specified [ Upstream commit e53b50c0cbe392c946807abf7d07615a3c588642 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 08c198b51ee50d3c3b500eb5548d69d5835d2b52 Author: Asai Thambi SP Date: Wed Feb 24 21:18:20 2016 -0800 mtip32xx: Handle FTL rebuild failure state during device initialization [ Upstream commit aae4a033868c496adae86fc6f9c3e0c405bbf360 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1a40a875741947f095efe7981eb9c6e66a86c7d5 Author: Asai Thambi SP Date: Mon May 11 15:50:50 2015 -0700 mtip32xx: fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT [ Upstream commit ee04bed690cb49a49512a641405bac42d13c2b2a ] Fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT Signed-off-by: Selvan Mani Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 30eedbf1acc501740283fd105113feb9e03d59ac Author: Asai Thambi SP Date: Wed Feb 24 21:18:10 2016 -0800 mtip32xx: Handle safe removal during IO [ Upstream commit 51c6570eb922146470c2fe660c34585414679bd6 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8a2f53911aee658cdb7351037abfedea84bbdd9c Author: Asai Thambi SP Date: Mon May 11 15:53:18 2015 -0700 mtip32xx: fix crash on surprise removal of the drive [ Upstream commit 2132a544727eb17f76bfef8b550a016a41c38821 ] pci and block layers have changed a lot compared to when SRSI support was added. Given the current state of pci and block layers, this driver do not have to do any specific handling. Signed-off-by: Asai Thambi S P Signed-off-by: Selvan Mani Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a6a71fff116e8579ce1efc3d52712870327a3fc6 Author: Asai Thambi SP Date: Mon May 11 15:48:00 2015 -0700 mtip32xx: fix rmmod issue [ Upstream commit 02b48265e7437bfe153af16337b14ee74f00905f ] put_disk() need to be called after del_gendisk() to free the disk object structure. Signed-off-by: Selvan Mani Signed-off-by: Asai Thambi S P Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2e358eb95fa5730956896d723b268c86b4e9b7ca Author: Asai Thambi SP Date: Wed Feb 24 21:17:32 2016 -0800 mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild [ Upstream commit d8a18d2d8f5de55666c6011ed175939d22c8e3d8 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 861d6774a2b25828f63343bb008a1b096b4c7bd6 Author: Asai Thambi SP Date: Wed Feb 24 21:16:38 2016 -0800 mtip32xx: Print exact time when an internal command is interrupted [ Upstream commit 5b7e0a8ac85e2dfd83830dc9e0b3554d153a37e3 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c5bfa5379d7fbd8cc92e54e3e4a6558e1683539b Author: Nikolay Borisov Date: Thu Mar 3 10:54:57 2016 +0100 quota: Fix possible GPF due to uninitialised pointers [ Upstream commit ab73ef46398e2c0159f3a71de834586422d2a44a ] 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. CC: stable@vger.kernel.org Signed-off-by: Nikolay Borisov Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit a8dabc28e0b21f70d9e27b04a42efc7f093c7c18 Author: Mateusz Guzik Date: Wed Mar 2 09:51:09 2016 +1100 xfs: fix two memory leaks in xfs_attr_list.c error paths [ Upstream commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f ] This plugs 2 trivial leaks in xfs_attr_shortform_list and xfs_attr3_leaf_list_int. Signed-off-by: Mateusz Guzik Cc: Reviewed-by: Eric Sandeen Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 6e36f1cf9ef686acfefeea38503f333e5f495e79 Author: J. Bruce Fields Date: Mon Feb 29 20:21:21 2016 -0500 nfsd4: fix bad bounds checking [ Upstream commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 ] 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. Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 582f7a0cda283ff517f225b08e61a531a4269a32 Author: Michael S. Tsirkin Date: Sun Feb 28 17:44:09 2016 +0200 watchdog: rc32434_wdt: fix ioctl error handling [ Upstream commit 10e7ac22cdd4d211cef99afcb9371b70cb175be6 ] 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. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 5a33c3154479fabeae1a78cbb7c469982fc33a82 Author: Hans de Goede Date: Sun Feb 7 09:24:29 2016 -0200 [media] bttv: Width must be a multiple of 16 when capturing planar formats [ Upstream commit 5c915c68763889f0183a1cc61c84bb228b60124a ] 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. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 88155b6f0560f43d101cc415c70a17b09046e532 Author: Bart Van Assche Date: Thu Feb 11 11:03:09 2016 -0800 IB/srpt: Simplify srpt_handle_tsk_mgmt() [ Upstream commit 51093254bf879bc9ce96590400a87897c7498463 ] 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 Cc: stable Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 37c9e8469aa1adb57d3ce569a8f0d7a84dee76bf Author: Russell King Date: Tue Jan 26 13:41:04 2016 +0000 mmc: sdhci: fix data timeout (part 2) [ Upstream commit 7f05538af71c7d30b5fc821cbe9f318edc645961 ] 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 Cc: stable@vger.kernel.org # v3.15+ Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 87017f54b25e46c3fb725ef3d4097b25885c31a4 Author: Russell King Date: Tue Jan 26 13:40:58 2016 +0000 mmc: sdhci: fix data timeout (part 1) [ Upstream commit fafcfda9e78cae8796d1799f14e6457790797555 ] 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 Cc: stable@vger.kernel.org # v3.15+ Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a2fdc9e72b3eb455690b6e3c60183f8b19f5ef65 Author: Dmitry Tunin Date: Sun Feb 28 11:04:06 2016 +0300 Bluetooth: btusb: Add a new AR3012 ID 04ca:3014 [ Upstream commit 81d90442eac779938217c3444b240aa51fd3db47 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ead3fd505c30494ef27420c3ef70f42cb13ff5de Author: Tom Lendacky Date: Thu Feb 25 16:48:13 2016 -0600 crypto: ccp - memset request context to zero during import [ Upstream commit ce0ae266feaf35930394bd770c69778e4ef03ba9 ] 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(). Cc: # 3.14.x- Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e7edaa59629178afb2a76002593b57f9ff5f0fd7 Author: Jes Sorensen Date: Tue Feb 16 16:44:24 2016 -0500 md/raid5: Compare apples to apples (or sectors to sectors) [ Upstream commit e7597e69dec59b65c5525db1626b9d34afdfa678 ] '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") Cc: stable@vger.kernel.org v3.7+ Signed-off-by: Jes Sorensen Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 0b9d890939fa8916c83a6186190b7868df60c6ca Author: Bjorn Helgaas Date: Thu Feb 25 14:35:57 2016 -0600 PCI: Disable IO/MEM decoding for devices with non-compliant BARs [ Upstream commit b84106b4e2290c081cdab521fa832596cdfea246 ] 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 CC: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 27aa83d92c1573a3418307e7a49f298419e4dacf Author: Yijing Wang Date: Thu May 21 15:05:02 2015 +0800 PCI: Add dev->has_secondary_link to track downstream PCIe links [ Upstream commit d0751b98dfa391f862e02dc36a233a54615e3f1d ] A PCIe Port is an interface to a Link. A Root Port is a PCI-PCI bridge in a Root Complex and has a Link on its secondary (downstream) side. For other Ports, the Link may be on either the upstream (closer to the Root Complex) or downstream side of the Port. The usual topology has a Root Port connected to an Upstream Port. We previously assumed this was the only possible topology, and that a Downstream Port's Link was always on its downstream side, like this: +---------------------+ +------+ | Downstream | | Root | | Upstream Port +--Link-- | Port +--Link--+ Port | +------+ | Downstream | | Port +--Link-- +---------------------+ But systems do exist (see URL below) where the Root Port is connected to a Downstream Port. In this case, a Downstream Port's Link may be on either the upstream or downstream side: +---------------------+ +------+ | Upstream | | Root | | Downstream Port +--Link-- | Port +--Link--+ Port | +------+ | Downstream | | Port +--Link-- +---------------------+ We can't use the Port type to determine which side the Link is on, so add a bit in struct pci_dev to keep track. A Root Port's Link is always on the Port's secondary side. A component (Endpoint or Port) on the other end of the Link obviously has the Link on its upstream side. If that component is a Port, it is part of a Switch or a Bridge. A Bridge has a PCI or PCI-X bus on its secondary side, not a Link. The internal bus of a Switch connects the Port to another Port whose Link is on the downstream side. [bhelgaas: changelog, comment, cache "type", use if/else] Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361 Suggested-by: Bjorn Helgaas Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit ec5e2836d844e57bfe26640c998f62678c415ac6 Author: Jiang Liu Date: Mon Oct 27 13:21:42 2014 +0800 x86, irq: Keep balance of IOAPIC pin reference count [ Upstream commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 ] To keep balance of IOAPIC pin reference count, we need to protect pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable() from reentrance. There are two cases which will cause reentrance. The first case is caused by suspend/hibernation. If pcibios_disable_irq is called during suspending/hibernating, we don't release the assigned IRQ number, otherwise it may break the suspend/hibernation. So late when pcibios_enable_irq is called during resume, we shouldn't allocate IRQ number again. The second case is that function acpi_pci_irq_enable() may be called twice for PCI devices present at boot time as below: 1) pci_acpi_init() --> acpi_pci_irq_enable() if pci_routeirq is true 2) pci_enable_device() --> pcibios_enable_device() --> acpi_pci_irq_enable() We can't kill kernel parameter pci_routeirq yet because it's still needed for debugging purpose. So flag irq_managed is introduced to track whether IRQ number is assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable() from reentrance. Signed-off-by: Jiang Liu Cc: Konrad Rzeszutek Wilk Cc: Tony Luck Cc: Joerg Roedel Cc: Greg Kroah-Hartman Cc: Benjamin Herrenschmidt Cc: Rafael J. Wysocki Cc: Bjorn Helgaas Cc: Randy Dunlap Cc: Yinghai Lu Cc: Borislav Petkov Cc: Len Brown Link: http://lkml.kernel.org/r/1414387308-27148-13-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 1583c88c78b1c26258ab16870902263e3edd7db5 Author: Aaro Koskinen Date: Sat Feb 20 22:27:48 2016 +0200 mtd: onenand: fix deadlock in onenand_block_markbad [ Upstream commit 5e64c29e98bfbba1b527b0a164f9493f3db9e8cb ] 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 Cc: Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit bb403c355af83b32b7d16b988596a84d449b0762 Author: Raghava Aditya Renukunta Date: Wed Feb 3 15:06:02 2016 -0800 aacraid: Fix memory leak in aac_fib_map_free [ Upstream commit f88fa79a61726ce9434df9b4aede36961f709f17 ] 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" Cc: stable@vger.kernel.org Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Johannes Thumshirn Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7e93840107727ac6a6ed2e985ab0a1f74cd45eaf Author: Dmitry Tunin Date: Wed Feb 10 00:49:11 2016 +0300 Bluetooth: Add new AR3012 ID 0489:e095 [ Upstream commit 28c971d82fb58ef7cba22e5308be6d2d2590473d ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c52af9b0e4b7362280b52fab7a4ab94a608f8978 Author: Dmitry Tunin Date: Wed Feb 10 15:33:17 2016 +0300 Bluetooth: btusb: Add new AR3012 ID 13d3:3395 [ Upstream commit 609574eb46335cfac1421a07c0505627cbbab1f0 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e05bb3ae6eab46c0846a56ce71bdad34d7048adb Author: Andi Kleen Date: Wed Feb 17 14:44:55 2016 -0800 perf tools: Dont stop PMU parsing on alias parse error [ Upstream commit 940db6dcd3f4659303fdf6befe7416adc4d24118 ] 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 Cc: stable@vger.kernel.org # v3.6+ 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: Sasha Levin commit d3b9f52c79ea65d9256e7a49a1c9c259bae2bd68 Author: Eryu Guan Date: Sun Feb 21 18:38:44 2016 -0500 ext4: iterate over buffer heads correctly in move_extent_per_page() [ Upstream commit 87f9a031af48defee9f34c6aaf06d6f1988c244d ] In commit bcff24887d00 ("ext4: don't read blocks from disk after extents being swapped") bh is not updated correctly in the for loop and wrong data has been written to disk. generic/324 catches this on sub-page block size ext4. Fixes: bcff24887d00 ("ext4: don't read blocks from disk after extentsbeing swapped") Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d14fefe00f42efae8471b4f48674bc5b4e5ed999 Author: Hans de Goede Date: Sun Feb 14 17:51:37 2016 -0200 [media] saa7134: Fix bytesperline not being set correctly for planar formats [ Upstream commit 3e71da19f9dc22e39a755d6ae9678661abb66adc ] 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 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e744412de36cb37cea64fe6e3a90948baebaf942 Author: Hans Verkuil Date: Wed Feb 10 09:32:25 2016 -0200 [media] adv7511: TX_EDID_PRESENT is still 1 after a disconnect [ Upstream commit b339a72e04a62f0b1882c43492fc712f1176b3e6 ] 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 Cc: # for v3.12 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ddd0a5b094bb79ea21dc8fd91b49e11c10e9ec63 Author: Julia Lawall Date: Thu Feb 18 00:16:14 2016 +0100 scripts/coccinelle: modernize & [ Upstream commit 1b669e713f277a4d4b3cec84e13d16544ac8286d ] & is no longer allowed in column 0, since Coccinelle 1.0.4. Signed-off-by: Julia Lawall Tested-by: Nishanth Menon Cc: stable@vger.kernel.org Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit e2a09ee529370549b13a5eb425b911950ceb6c0a Author: Romain Perier Date: Sun Aug 23 11:32:37 2015 +0200 clk: rockchip: Add pclk_peri to critical clocks on RK3066/RK3188 [ Upstream commit 3bba75a2ec32bd5fa7024a4de3b8cf9ee113a76a ] Now that the rockchip clock subsystem does clock gating with GPIO banks, these are no longer enabled once during probe and no longer stay enabled for eternity. When all these clocks are disabled, the parent clock pclk_peri might be disabled too, as no other child claims it. So, we need to add pclk_peri to the critical clocks. Signed-off-by: Romain Perier Tested-by: Michael Niewoehner Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 02c7a92be50f6f9595bb3c82d42609047c79fea2 Author: Michael Niewoehner Date: Tue Aug 25 22:22:07 2015 +0200 clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks [ Upstream commit 1166160ab531198f7abc773992c0e04d0f9b7600 ] pclk_cpu needs to keep running because it is needed for devices like the act8865 regulator but with the recent gpio clock handling this is not always the case anymore. So add it to the list of critical clocks. Signed-off-by: Michael Niewoehner Reviewed-by: Heiko Stuebner Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 88965e61d381a0d3cd3e0d49aa5fb6481a9447cc Author: Vasily Kulikov Date: Wed Sep 9 15:36:00 2015 -0700 include/linux/poison.h: fix LIST_POISON{1,2} offset [ Upstream commit 8a5e5e02fc83aaf67053ab53b359af08c6c49aaf ] Poison pointer values should be small enough to find a room in non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space" is located starting from 0x0. Given unprivileged users cannot mmap anything below mmap_min_addr, it should be safe to use poison pointers lower than mmap_min_addr. The current poison pointer values of LIST_POISON{1,2} might be too big for mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu uses only 0x10000). There is little point to use such a big value given the "poison pointer space" below 1 MB is not yet exhausted. Changing it to a smaller value solves the problem for small mmap_min_addr setups. The values are suggested by Solar Designer: http://www.openwall.com/lists/oss-security/2015/05/02/6 Signed-off-by: Vasily Kulikov Cc: Solar Designer Cc: Thomas Gleixner Cc: "Kirill A. Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3fee6398ce8a0f1d5411b0a75e70f80a1196467d Author: David Howells Date: Tue Nov 24 21:36:31 2015 +0000 KEYS: Fix handling of stored error in a negatively instantiated user key [ Upstream commit 096fe9eaea40a17e125569f9e657e34cdb6d73bd ] If a user key gets negatively instantiated, an error code is cached in the payload area. A negatively instantiated key may be then be positively instantiated by updating it with valid data. However, the ->update key type method must be aware that the error code may be there. The following may be used to trigger the bug in the user key type: keyctl request2 user user "" @u keyctl add user user "a" @u which manifests itself as: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 PGD 7cc30067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000 RIP: 0010:[] [] __call_rcu.constprop.76+0x1f/0x280 [] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246 RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001 RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82 RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82 R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700 FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0 Stack: ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620 Call Trace: [] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136 [] user_update+0x8b/0xb0 security/keys/user_defined.c:129 [< inline >] __key_update security/keys/key.c:730 [] key_create_or_update+0x291/0x440 security/keys/key.c:908 [< inline >] SYSC_add_key security/keys/keyctl.c:125 [] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60 [] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185 Note the error code (-ENOKEY) in EDX. A similar bug can be tripped by: keyctl request2 trusted user "" @u keyctl add trusted user "a" @u This should also affect encrypted keys - but that has to be correctly parameterised or it will fail with EINVAL before getting to the bit that will crashes. Reported-by: Dmitry Vyukov Signed-off-by: David Howells Acked-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Sasha Levin commit 8dc1d26b1bae170d1d11e6460cf745ef10d90bfd Author: Andrew Honig Date: Wed Nov 18 14:50:23 2015 -0800 KVM: x86: Reload pit counters for all channels when restoring state [ Upstream commit 0185604c2d82c560dab2f2933a18f797e74ab5a8 ] Currently if userspace restores the pit counters with a count of 0 on channels 1 or 2 and the guest attempts to read the count on those channels, then KVM will perform a mod of 0 and crash. This will ensure that 0 values are converted to 65536 as per the spec. This is CVE-2015-7513. Signed-off-by: Andy Honig Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f3d07a0163039d322ee03bc953d105684c616e0f Author: Linus Torvalds Date: Mon Mar 7 13:15:09 2016 -0800 Revert "drm/radeon: call hpd_irq_event on resume" [ Upstream commit 256faedcfd646161477d47a1a78c32a562d2e845 ] This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9. It turns out that commit can cause problems for systems with multiple GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid graphics. This got noticed originally in 4.4.4, where this patch had already gotten back-ported, but 4.5-rc7 was verified to have the same problem. Alexander Deucher says: "It looks like you have a muxed system so I suspect what's happening is that one of the display is being reported as connected for both the IGP and the dGPU and then the desktop environment gets confused or there some sort problem in the detect functions since the mux is not switched to the dGPU. I don't see an easy fix unless Dave has any ideas. I'd say just revert for now" Reported-by: Jörg-Volker Peetz Acked-by: Alexander Deucher Cc: Dave Airlie Cc: stable@kernel.org # wherever dbb17a21c131 got back-ported Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c9e8928aeeb09bfb7e647ac997c29ac3e6e5eeaa Author: Rusty Russell Date: Wed Feb 3 16:55:26 2016 +1030 modules: fix longstanding /proc/kallsyms vs module insertion race. [ Upstream commit 8244062ef1e54502ef55f54cced659913f244c3e ] For CONFIG_KALLSYMS, we keep two symbol tables and two string tables. There's one full copy, marked SHF_ALLOC and laid out at the end of the module's init section. There's also a cut-down version that only contains core symbols and strings, and lives in the module's core section. After module init (and before we free the module memory), we switch the mod->symtab, mod->num_symtab and mod->strtab to point to the core versions. We do this under the module_mutex. However, kallsyms doesn't take the module_mutex: it uses preempt_disable() and rcu tricks to walk through the modules, because it's used in the oops path. It's also used in /proc/kallsyms. There's nothing atomic about the change of these variables, so we can get the old (larger!) num_symtab and the new symtab pointer; in fact this is what I saw when trying to reproduce. By grouping these variables together, we can use a carefully-dereferenced pointer to ensure we always get one or the other (the free of the module init section is already done in an RCU callback, so that's safe). We allocate the init one at the end of the module init section, and keep the core one inside the struct module itself (it could also have been allocated at the end of the module core, but that's probably overkill). Reported-by: Weilong Chen Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541 Cc: stable@kernel.org Signed-off-by: Rusty Russell Signed-off-by: Sasha Levin commit 03f41fac326b77e5f5baf059f7f007677a1b70c8 Author: Qu Wenruo Date: Fri Jan 22 09:28:38 2016 +0800 btrfs: async-thread: Fix a use-after-free error for trace [ Upstream commit 0a95b851370b84a4b9d92ee6d1fa0926901d0454 ] Parameter of trace_btrfs_work_queued() can be freed in its workqueue. So no one use use that pointer after queue_work(). Fix the user-after-free bug by move the trace line before queue_work(). Reported-by: Dave Jones Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit 6050b33fcc3538549cd59a19eb17a4a5fb1e6134 Author: Jann Horn Date: Wed Jan 20 15:00:01 2016 -0800 security: let security modules use PTRACE_MODE_* with bitmasks [ Upstream commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 ] It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. Signed-off-by: Jann Horn Acked-by: Kees Cook Acked-by: Casey Schaufler Cc: Oleg Nesterov Cc: Ingo Molnar Cc: James Morris Cc: "Serge E. Hallyn" Cc: Andy Shevchenko Cc: Andy Lutomirski Cc: Al Viro Cc: "Eric W. Biederman" Cc: Willy Tarreau Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 805d5d71d712b47812b75b43f7805a9ca9580300 Author: Simon Guinot Date: Thu Sep 10 00:15:18 2015 +0200 kernel/resource.c: fix muxed resource handling in __request_region() [ Upstream commit 59ceeaaf355fa0fb16558ef7c24413c804932ada ] In __request_region, if a conflict with a BUSY and MUXED resource is detected, then the caller goes to sleep and waits for the resource to be released. A pointer on the conflicting resource is kept. At wake-up this pointer is used as a parent to retry to request the region. A first problem is that this pointer might well be invalid (if for example the conflicting resource have already been freed). Another problem is that the next call to __request_region() fails to detect a remaining conflict. The previously conflicting resource is passed as a parameter and __request_region() will look for a conflict among the children of this resource and not at the resource itself. It is likely to succeed anyway, even if there is still a conflict. Instead, the parent of the conflicting resource should be passed to __request_region(). As a fix, this patch doesn't update the parent resource pointer in the case we have to wait for a muxed region right after. Reported-and-tested-by: Vincent Pelletier Signed-off-by: Simon Guinot Tested-by: Vincent Donnefort Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 720db91c2e5fb56544f935bd8d62d07faedbfb2a Author: Laura Abbott Date: Mon Oct 5 19:33:29 2015 -0300 [media] si2157: return -EINVAL if firmware blob is too big [ Upstream commit d2cc2f0b35465951eaaf0387fd55e29835ed7ea6 ] A previous patch added a check if the firmware is too big, but it didn't set the return error code with the right value. [mchehab@osg.samsung.com: I ended by applying a v1 of Laura's patch, without the proper return code. This patch contains the difference between v2 and v1 of the Laura's "si2157: Bounds check firmware" patch] Cc: stable@kernel.org Signed-off-by: Laura Abbott Reviewed-by: Olli Salonen Tested-by: Olli Salonen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7bd07d0aae76e8331183bbbc2a60cfe7547fafcf Author: Laura Abbott Date: Tue Sep 29 21:10:10 2015 -0300 [media] si2157: Bounds check firmware [ Upstream commit a828d72df216c36e9c40b6c24dc4b17b6f7b5a76 ] When reading the firmware and sending commands, the length must be bounds checked to avoid overrunning the size of the command buffer and smashing the stack if the firmware is not in the expected format. Add the proper check. Cc: stable@kernel.org Signed-off-by: Laura Abbott Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fb9f9481e5bcd352755cfe4ecbd11e46cd76e714 Author: Sebastian Andrzej Siewior Date: Fri Jan 15 14:37:15 2016 +0100 btrfs: initialize the seq counter in struct btrfs_device [ Upstream commit 546bed631203344611f42b2af1d224d2eedb4e6b ] I managed to trigger this: | INFO: trying to register non-static key. | the code is fine but needs lockdep annotation. | turning off the locking correctness validator. | CPU: 1 PID: 781 Comm: systemd-gpt-aut Not tainted 4.4.0-rt2+ #14 | Hardware name: ARM-Versatile Express | [<80307cec>] (dump_stack) | [<80070e98>] (__lock_acquire) | [<8007184c>] (lock_acquire) | [<80287800>] (btrfs_ioctl) | [<8012a8d4>] (do_vfs_ioctl) | [<8012ac14>] (SyS_ioctl) so I think that btrfs_device_data_ordered_init() is not invoked behind a macro somewhere. Fixes: 7cc8e58d53cd ("Btrfs: fix unprotected device's variants on 32bits machine") Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6a53a87e873c4370cee24b60d5004fa5f7f26928 Author: Filipe Manana Date: Tue Jan 5 16:24:05 2016 +0000 Btrfs: fix transaction handle leak on failure to create hard link [ Upstream commit 271dba4521aed0c37c063548f876b49f5cd64b2e ] If we failed to create a hard link we were not always releasing the the transaction handle we got before, resulting in a memory leak and preventing any other tasks from being able to commit the current transaction. Fix this by always releasing our transaction handle. Signed-off-by: Filipe Manana Reviewed-by: Liu Bo Signed-off-by: Sasha Levin commit 6f575610bd36c501330193fbb61e568d32bbe331 Author: Filipe Manana Date: Thu Dec 31 18:16:29 2015 +0000 Btrfs: fix number of transaction units required to create symlink [ Upstream commit 9269d12b2d57d9e3d13036bb750762d1110d425c ] We weren't accounting for the insertion of an inline extent item for the symlink inode nor that we need to update the parent inode item (through the call to btrfs_add_nondir()). So fix this by including two more transaction units. Signed-off-by: Filipe Manana Signed-off-by: Sasha Levin commit 52558f0483edecf668bd5f55cc22121fe7c865b0 Author: Filipe Manana Date: Thu Dec 31 18:07:59 2015 +0000 Btrfs: send, don't BUG_ON() when an empty symlink is found [ Upstream commit a879719b8c90e15c9e7fa7266d5e3c0ca962f9df ] When a symlink is successfully created it always has an inline extent containing the source path. However if an error happens when creating the symlink, we can leave in the subvolume's tree a symlink inode without any such inline extent item - this happens if after btrfs_symlink() calls btrfs_end_transaction() and before it calls the inode eviction handler (through the final iput() call), the transaction gets committed and a crash happens before the eviction handler gets called, or if a snapshot of the subvolume is made before the eviction handler gets called. Sadly we can't just avoid this by making btrfs_symlink() call btrfs_end_transaction() after it calls the eviction handler, because the later can commit the current transaction before it removes any items from the subvolume tree (if it encounters ENOSPC errors while reserving space for removing all the items). So make send fail more gracefully, with an -EIO error, and print a message to dmesg/syslog informing that there's an empty symlink inode, so that the user can delete the empty symlink or do something else about it. Reported-by: Stephen R. van den Berg Signed-off-by: Filipe Manana Signed-off-by: Sasha Levin commit 9c5ed372d05a253ab33750061023e616c5e457df Author: David Sterba Date: Sat Oct 10 17:59:53 2015 +0200 btrfs: statfs: report zero available if metadata are exhausted [ Upstream commit ca8a51b3a979d57b082b14eda38602b7f52d81d1 ] There is one ENOSPC case that's very confusing. There's Available greater than zero but no file operation succeds (besides removing files). This happens when the metadata are exhausted and there's no possibility to allocate another chunk. In this scenario it's normal that there's still some space in the data chunk and the calculation in df reflects that in the Avail value. To at least give some clue about the ENOSPC situation, let statfs report zero value in Avail, even if there's still data space available. Current: /dev/sdb1 4.0G 3.3G 719M 83% /mnt/test New: /dev/sdb1 4.0G 3.3G 0 100% /mnt/test We calculate the remaining metadata space minus global reserve. If this is (supposedly) smaller than zero, there's no space. But this does not hold in practice, the exhausted state happens where's still some positive delta. So we apply some guesswork and compare the delta to a 4M threshold. (Practically observed delta was 2M.) We probably cannot calculate the exact threshold value because this depends on the internal reservations requested by various operations, so some operations that consume a few metadata will succeed even if the Avail is zero. But this is better than the other way around. Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9f7a29fce43a97c004c66a23b8976efa989754c0 Author: Josef Bacik Date: Thu Oct 22 15:05:09 2015 -0400 Btrfs: igrab inode in writepage [ Upstream commit be7bd730841e69fe8f70120098596f648cd1f3ff ] We hit this panic on a few of our boxes this week where we have an ordered_extent with an NULL inode. We do an igrab() of the inode in writepages, but weren't doing it in writepage which can be called directly from the VM on dirty pages. If the inode has been unlinked then we could have I_FREEING set which means igrab() would return NULL and we get this panic. Fix this by trying to igrab in btrfs_writepage, and if it returns NULL then just redirty the page and return AOP_WRITEPAGE_ACTIVATE; so the VM knows it wasn't successful. Thanks, Signed-off-by: Josef Bacik Reviewed-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit db16f2f8f389f648c74df9468c3696a3541e0f58 Author: Anand Jain Date: Wed Oct 7 17:23:23 2015 +0800 Btrfs: add missing brelse when superblock checksum fails [ Upstream commit b2acdddfad13c38a1e8b927d83c3cf321f63601a ] Looks like oversight, call brelse() when checksum fails. Further down the code, in the non error path, we do call brelse() and so we don't see brelse() in the goto error paths. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 07508eb3c9a18afdb25b69d68c0fd3dd0698e148 Author: Hariprasad S Date: Fri Dec 11 13:59:17 2015 +0530 iw_cxgb3: Fix incorrectly returning error on success [ Upstream commit 67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 ] The cxgb3_*_send() functions return NET_XMIT_ values, which are positive integers values. So don't treat positive return values as an error. Signed-off-by: Steve Wise Signed-off-by: Hariprasad Shenai Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 63e236fd7ab3a9fc10cfe7d27e218a8116ae8cf6 Author: Jason Andryuk Date: Fri Feb 12 23:13:33 2016 +0000 lib/ucs2_string: Correct ucs2 -> utf8 conversion [ Upstream commit a68075908a37850918ad96b056acc9ac4ce1bd90 ] The comparisons should be >= since 0x800 and 0x80 require an additional bit to store. For the 3 byte case, the existing shift would drop off 2 more bits than intended. For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in byte 2. Signed-off-by: Jason Andryuk Reviewed-by: Laszlo Ersek Cc: Peter Jones Cc: Matthew Garrett Cc: "Lee, Chun-Yi" Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit 67427f6025518f1fb1332823a0d1810d5b220b96 Author: Matt Fleming Date: Mon Feb 15 10:34:05 2016 +0000 efi: Add pstore variables to the deletion whitelist [ Upstream commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 ] Laszlo explains why this is a good idea, 'This is because the pstore filesystem can be backed by UEFI variables, and (for example) a crash might dump the last kilobytes of the dmesg into a number of pstore entries, each entry backed by a separate UEFI variable in the above GUID namespace, and with a variable name according to the above pattern. Please see "drivers/firmware/efi/efi-pstore.c". While this patch series will not prevent the user from deleting those UEFI variables via the pstore filesystem (i.e., deleting a pstore fs entry will continue to delete the backing UEFI variable), I think it would be nice to preserve the possibility for the sysadmin to delete Linux-created UEFI variables that carry portions of the crash log, *without* having to mount the pstore filesystem.' There's also no chance of causing machines to become bricked by deleting these variables, which is the whole purpose of excluding things from the whitelist. Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so that we don't have to update the string in the future if new variable name formats are created for crash dump variables. Reported-by: Laszlo Ersek Acked-by: Peter Jones Tested-by: Peter Jones Cc: Matthew Garrett Cc: "Lee, Chun-Yi" Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit 0dc03db627e3e900f329ba34f827be27851f1d7b Author: Peter Jones Date: Mon Feb 8 14:48:15 2016 -0500 efi: Make efivarfs entries immutable by default [ Upstream commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 ] "rm -rf" is bricking some peoples' laptops because of variables being used to store non-reinitializable firmware driver data that's required to POST the hardware. These are 100% bugs, and they need to be fixed, but in the mean time it shouldn't be easy to *accidentally* brick machines. We have to have delete working, and picking which variables do and don't work for deletion is quite intractable, so instead make everything immutable by default (except for a whitelist), and make tools that aren't quite so broad-spectrum unset the immutable flag. Signed-off-by: Peter Jones Tested-by: Lee, Chun-Yi Acked-by: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit 414f7950ec63762b79a1738c5c5de76809d3ce1e Author: Peter Jones Date: Mon Feb 8 14:48:14 2016 -0500 efi: Make our variable validation list include the guid [ Upstream commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f ] All the variables in this list so far are defined to be in the global namespace in the UEFI spec, so this just further ensures we're validating the variables we think we are. Including the guid for entries will become more important in future patches when we decide whether or not to allow deletion of variables based on presence in this list. Signed-off-by: Peter Jones Tested-by: Lee, Chun-Yi Acked-by: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit c5d0b20cb5d48ae1711421419065a7637b61e6b2 Author: Peter Jones Date: Mon Feb 8 14:48:13 2016 -0500 efi: Do variable name validation tests in utf8 [ Upstream commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 ] Actually translate from ucs2 to utf8 before doing the test, and then test against our other utf8 data, instead of fudging it. Signed-off-by: Peter Jones Acked-by: Matthew Garrett Tested-by: Lee, Chun-Yi Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit b58934689d96a6d1edd4b351770574a75a7f3f54 Author: Peter Jones Date: Mon Feb 8 14:48:12 2016 -0500 efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version [ Upstream commit e0d64e6a880e64545ad7d55786aa84ab76bac475 ] Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming all variable names fit in ASCII. Signed-off-by: Peter Jones Acked-by: Matthew Garrett Tested-by: Lee, Chun-Yi Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit d05a3921f825d808b312c4448e957c046d8eec10 Author: Dan Carpenter Date: Tue Apr 21 12:21:53 2015 +0300 efi: efivar_create_sysfs_entry() should return negative error codes [ Upstream commit f7ef7e3e506023f826c1ee60b7e59b985316e180 ] It's not very normal to return 1 on failure and 0 on success. There isn't a reason for it here, the callers don't care so long as it's non-zero on failure. Signed-off-by: Dan Carpenter Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit dc1351fcd88d287a1b1069f67b06fb3fd69a3a7f Author: Peter Jones Date: Mon Feb 8 14:48:11 2016 -0500 lib/ucs2_string: Add ucs2 -> utf8 helper functions [ Upstream commit 73500267c930baadadb0d02284909731baf151f7 ] This adds ucs2_utf8size(), which tells us how big our ucs2 string is in bytes, and ucs2_as_utf8, which translates from ucs2 to utf8.. Signed-off-by: Peter Jones Tested-by: Lee, Chun-Yi Acked-by: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit dbcfee724255ae171af51aaa56d8c5b78342adc9 Author: Arnd Bergmann Date: Thu Nov 19 15:03:57 2015 +0100 ARM: 8457/1: psci-smp is built only for SMP [ Upstream commit be95485a0b8288a93402705730d3ea32f9f812b9 ] The PSCI SMP implementation is built only when both CONFIG_SMP and CONFIG_ARM_PSCI are set, so a configuration that has the latter but not the former can get a link error when it tries to call psci_smp_available(). arch/arm/mach-tegra/built-in.o: In function `tegra114_cpuidle_init': cpuidle-tegra114.c:(.init.text+0x52a): undefined reference to `psci_smp_available' This corrects the #ifdef in the psci.h header file to match the Makefile conditional we have for building that function. Signed-off-by: Arnd Bergmann Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 22300ab67643a184e8619160ddb95ae215a9d332 Author: Daniel Vetter Date: Mon Nov 23 10:32:49 2015 +0100 drm/gma500: Use correct unref in the gem bo create function [ Upstream commit d3e376f52d095103ca51dbda4d6ff8aaf488f98f ] This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Cc: Patrik Jakobsson Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 99cdf12b43cb0db5c770b6a5c6375d553edad647 Author: Rusty Russell Date: Wed Feb 3 16:55:26 2016 +1030 module: wrapper for symbol name. [ Upstream commit 2e7bac536106236104e9e339531ff0fcdb7b8147 ] This trivial wrapper adds clarity and makes the following patch smaller. Cc: stable@kernel.org Signed-off-by: Rusty Russell Signed-off-by: Sasha Levin commit 983cabe4e2b071090fe22f1c4d07a64f2a263ef2 Author: Akinobu Mita Date: Thu Jan 21 01:07:31 2016 +0900 iio: pressure: mpl115: fix temperature offset sign [ Upstream commit 431386e783a3a6c8b7707bee32d18c353b8688b2 ] According to the datasheet, the resolusion of temperature sensor is -5.35 counts/C. Temperature ADC is 472 counts at 25C. (https://www.sparkfun.com/datasheets/Sensors/Pressure/MPL115A1.pdf NOTE: This is older revision, but this information is removed from the latest datasheet from nxp somehow) Temp [C] = (Tadc - 472) / -5.35 + 25 = (Tadc - 605.750000) * -0.186915888 So the correct offset is -605.750000. Signed-off-by: Akinobu Mita Acked-by: Peter Meerwald-Stadler Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c0472847dcb2a89afea3b4a9bbac68bd66706125 Author: Yong Li Date: Wed Jan 6 09:09:43 2016 +0800 iio: dac: mcp4725: set iio name property in sysfs [ Upstream commit 97a249e98a72d6b79fb7350a8dd56b147e9d5bdb ] Without this change, the name entity for mcp4725 is missing in /sys/bus/iio/devices/iio\:device*/name With this change, name is reported correctly Signed-off-by: Yong Li Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 23fa192a4df567101d35e946ae8749add3ac622a Author: Lars-Peter Clausen Date: Fri Nov 27 14:55:56 2015 +0100 iio: adis_buffer: Fix out-of-bounds memory access [ Upstream commit d590faf9e8f8509a0a0aa79c38e87fcc6b913248 ] The SPI tx and rx buffers are both supposed to be scan_bytes amount of bytes large and a common allocation is used to allocate both buffers. This puts the beginning of the tx buffer scan_bytes bytes after the rx buffer. The initialization of the tx buffer pointer is done adding scan_bytes to the beginning of the rx buffer, but since the rx buffer is of type __be16 this will actually add two times as much and the tx buffer ends up pointing after the allocated buffer. Fix this by using scan_count, which is scan_bytes / 2, instead of scan_bytes when initializing the tx buffer pointer. Fixes: aacff892cbd5 ("staging:iio:adis: Preallocate transfer message") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b68c9b9a3f934851babe4862a19cedaeb20aa36b Author: Jann Horn Date: Wed Jan 20 15:00:04 2016 -0800 ptrace: use fsuid, fsgid, effective creds for fs access checks [ Upstream commit caaee6234d05a58c5b4d05e7bf766131b810a657 ] By checking the effective credentials instead of the real UID / permitted capabilities, ensure that the calling process actually intended to use its credentials. To ensure that all ptrace checks use the correct caller credentials (e.g. in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS flag), use two new flags and require one of them to be set. The problem was that when a privileged task had temporarily dropped its privileges, e.g. by calling setreuid(0, user_uid), with the intent to perform following syscalls with the credentials of a user, it still passed ptrace access checks that the user would not be able to pass. While an attacker should not be able to convince the privileged task to perform a ptrace() syscall, this is a problem because the ptrace access check is reused for things in procfs. In particular, the following somewhat interesting procfs entries only rely on ptrace access checks: /proc/$pid/stat - uses the check for determining whether pointers should be visible, useful for bypassing ASLR /proc/$pid/maps - also useful for bypassing ASLR /proc/$pid/cwd - useful for gaining access to restricted directories that contain files with lax permissions, e.g. in this scenario: lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar drwx------ root root /root drwxr-xr-x root root /root/foobar -rw-r--r-- root root /root/foobar/secret Therefore, on a system where a root-owned mode 6755 binary changes its effective credentials as described and then dumps a user-specified file, this could be used by an attacker to reveal the memory layout of root's processes or reveal the contents of files he is not allowed to access (through /proc/$pid/cwd). [akpm@linux-foundation.org: fix warning] Signed-off-by: Jann Horn Acked-by: Kees Cook Cc: Casey Schaufler Cc: Oleg Nesterov Cc: Ingo Molnar Cc: James Morris Cc: "Serge E. Hallyn" Cc: Andy Shevchenko Cc: Andy Lutomirski Cc: Al Viro Cc: "Eric W. Biederman" Cc: Willy Tarreau Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5c644d8d287f7eb715449c1243bbecd3604ad093 Author: Benjamin Tissoires Date: Tue Dec 1 12:41:38 2015 +0100 HID: multitouch: fix input mode switching on some Elan panels [ Upstream commit 73e7d63efb4d774883a338997943bfa59e127085 ] as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c8d69b6b02be32cb2eca20b704c5c54fd1420c8e Author: Raghavendra K T Date: Sat Jan 16 00:31:23 2016 +0530 sched: Fix crash in sched_init_numa() [ Upstream commit 9c03ee147193645be4c186d3688232fa438c57c7 ] The following PowerPC commit: c118baf80256 ("arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes") avoids allocating bootmem memory for non existent nodes. But when DEBUG_PER_CPU_MAPS=y is enabled, my powerNV system failed to boot because in sched_init_numa(), cpumask_or() operation was done on unallocated nodes. Fix that by making cpumask_or() operation only on existing nodes. [ Tested with and w/o DEBUG_PER_CPU_MAPS=y on x86 and PowerPC. ] Reported-by: Jan Stancek Tested-by: Jan Stancek Signed-off-by: Raghavendra K T Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Link: http://lkml.kernel.org/r/1452884483-11676-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit dfa8b700663c32bc45e25a9f5d93830a46c92956 Author: Takashi Iwai Date: Tue Dec 8 17:00:42 2015 +0100 ALSA: hda - Implement loopback control switch for Realtek and other codecs [ Upstream commit e7fdd52779a6c2b49d457f452296a77c8cffef6a ] Many codecs, typically found on Realtek codecs, have the analog loopback path merged to the secondary input of the middle of the output paths. Currently, we don't offer the dynamic switching in such configuration but let each loopback path mute by itself. This should work well in theory, but in reality, we often see that such a dead loopback path causes some background noises even if all the elements get muted. Such a problem has been fixed by adding the quirk accordingly to disable aamix, and it's the right fix, per se. The only problem is that it's not so trivial to achieve it; user needs to pass a hint string via patch module option or sysfs. This patch gives a bit improvement on the situation: it adds "Loopback Mixing" control element for such codecs like other codecs (e.g. IDT or VIA codecs) with the individual loopback paths. User can turn on/off the loopback path simply via a mixer app. For keeping the compatibility, the loopback is still enabled on these codecs. But user can try to turn it off if experiencing a suspicious background or click noise on the fly, then build a static fixup later once after the problem is addressed. Other than the addition of the loopback enable/disablement control, there should be no changes. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b4d367c40333bc13693c891fbf7abf841d64883a Author: Johan Rastén Date: Thu Jun 11 10:04:51 2015 +0200 ALSA: usb-audio: Set correct type for some UAC2 mixer controls. [ Upstream commit 27c41dad3a012c5acead1d903d1743297457b69c ] Changed ctl type for Input Gain Control and Input Gain Pad Control to USB_MIXER_S16 as per section 5.2.5.7.11-12 in the USB Audio Class 2.0 definition. Signed-off-by: Johan Rastén Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 13309bed3ddf6f8a5b91a46bdbaa00b44d78e58e Author: Benjamin Tissoires Date: Fri Feb 12 17:10:37 2016 +0100 HID: fix hid_ignore_special_drivers module parameter [ Upstream commit 4392bf333388cabdad5afe5b1500002d7b9c318e ] 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 CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 15d4c43031493078c46a754543a96b67358e9940 Author: Benjamin Tissoires Date: Tue Sep 30 13:18:24 2014 -0400 HID: core: do not scan reports if the group is already set [ Upstream commit 9578f41aeaee5010384f4f8484da1566e2ce4901 ] This allows the transport layer (I have in mind hid-logitech-dj and uhid) to set the group before it is added to the hid bus. This way, it can bypass the hid_scan_report() call, and choose in advance which driver will handle the newly created hid device. Signed-off-by: Benjamin Tisssoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 8f021777cd74076d941625b5341d3e3cc2679548 Author: Oliver Neukum Date: Wed Feb 10 11:33:18 2016 +0100 usb: retry reset if a device times out [ Upstream commit 264904ccc33c604d4b3141bbd33808152dfac45b ] 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 CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7c76bf7c2c787e6fb6eacab19dede3f814880f88 Author: Lior Amsalem Date: Wed Feb 10 17:29:15 2016 +0100 ARM: dts: armada-375: use armada-370-sata for SATA [ Upstream commit b3a7f31eb7375633cd6a742f19488fc5a4208b36 ] The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which requires the PHY speed to be set in the LP_PHY_CTL register for SATA hotplug to work. Therefore, this commit updates the compatible string used to describe the SATA IP in Armada 375 from marvell,orion-sata to marvell,armada-370-sata. Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC") Cc: Signed-off-by: Lior Amsalem Signed-off-by: Thomas Petazzoni Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 519aaf8eead83fb351dfaaca8d43338e57348fdc Author: Kamal Mostafa Date: Wed Jan 27 22:29:33 2016 -0800 tools/hv: Use include/uapi with __EXPORTED_HEADERS__ [ Upstream commit 50fe6dd10069e7c062e27f29606f6e91ea979399 ] 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") Cc: Signed-off-by: Kamal Mostafa Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e7addf18ca5b38b8f46f1970095927a369404f2a Author: Matej Muzila Date: Sun Dec 28 15:54:13 2014 +0100 tools: hv: Makefile: Add hv_fcopy_daemon to Makefile [ Upstream commit ca04455fba937eb2d85f437900cd1726166192e6 ] hv_fcopy_daemon is not mentioned in Makefile so it must be built manually. Add hv_fcopy_daemon to Makefile. Signed-off-by: Matej Muzila Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e304757ffc0b1c208cd2e1553b1112317ae10e21 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 [ Upstream commit 1fd24a4702d2af0ea4d5845126cf57d4d1796216 ] 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") Cc: # 3.17+ Signed-off-by: Spencer E. Olson Reviewed-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b82bdec794280cfd76235f4f06124f7a47af8e1 Author: Peter Hurley Date: Sat Jan 9 17:48:45 2016 -0800 net: irda: Fix use-after-free in irtty_open() [ Upstream commit 401879c57f01cbf2da204ad2e8db910525c6dbea ] 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 Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 52a497f9b5f1cfc5a2fbb507fbc4832f43e6a93b Author: Tom Lendacky Date: Tue Feb 2 11:38:21 2016 -0600 crypto: ccp - Don't assume export/import areas are aligned [ Upstream commit b31dde2a5cb1bf764282abf934266b7193c2bc7c ] 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. Cc: # 3.14.x- Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit eabdb09463bb2474b8b47dffea3a0231671aaaa4 Author: Tom Lendacky Date: Fri Jan 29 12:45:14 2016 -0600 crypto: ccp - Limit the amount of information exported [ Upstream commit d1662165ae612ec8b5f94a6b07e65ea58b6dce34 ] Since the exported information can be exposed to user-space, instead of exporting the entire request context only export the minimum information needed. Cc: # 3.14.x- Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8a6b0a961872618ed5296b65b311a07044c59c43 Author: Hans de Goede Date: Fri Jan 22 08:53:55 2016 -0200 [media] pwc: Add USB id for Philips Spc880nc webcam [ Upstream commit 7445e45d19a09e5269dc85f17f9635be29d2f76c ] SPC 880NC PC camera discussions: http://www.pclinuxos.com/forum/index.php/topic,135688.0.html Cc: stable@vger.kernel.org Reported-by: Kikim Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3e09d4172f8b3923033b8fb04496c4b9e512428b Author: Tiffany Lin Date: Tue Jan 19 05:56:50 2016 -0200 [media] media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32 [ Upstream commit 7df5ab8774aa383c6d2bff00688d004585d96dfd ] 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 Cc: # for v3.7 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f2f1ca55069617cf85bca3f5f61b4aed9a9866b6 Author: Peter Hurley Date: Sun Jan 10 20:36:12 2016 -0800 tty: Fix GPF in flush_to_ldisc(), part 2 [ Upstream commit f33798deecbd59a2955f40ac0ae2bc7dff54c069 ] 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(). Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 597a8627d548be5127c774aa0c1204ec04e8b764 Author: Tom Lendacky Date: Tue Jan 12 11:17:38 2016 -0600 crypto: ccp - Add hash state import and export support [ Upstream commit 952bce9792e6bf36fda09c2e5718abb5d9327369 ] 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. Cc: # 3.14.x- Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 14b538491eadcade73b2de1fcbd843012f5e75a8 Author: Dan Carpenter Date: Wed Jan 20 12:54:51 2016 +0300 EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr() [ Upstream commit 6f3508f61c814ee852c199988a62bd954c50dfc1 ] 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 Cc: Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwanda Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin commit d48d21de5e8054d38360e09d5f16508c0a17dd62 Author: Roman Gushchin Date: Mon Oct 12 16:33:44 2015 +0300 fuse: break infinite loop in fuse_fill_write_pages() [ Upstream commit 3ca8138f014a913f98e6ef40e939868e1e9ea876 ] I got a report about unkillable task eating CPU. Further investigation shows, that the problem is in the fuse_fill_write_pages() function. If iov's first segment has zero length, we get an infinite loop, because we never reach iov_iter_advance() call. Fix this by calling iov_iter_advance() before repeating an attempt to copy data from userspace. A similar problem is described in 124d3b7041f ("fix writev regression: pan hanging unkillable and un-straceable"). If zero-length segmend is followed by segment with invalid address, iov_iter_fault_in_readable() checks only first segment (zero-length), iov_iter_copy_from_user_atomic() skips it, fails at second and returns zero -> goto again without skipping zero-length segment. Patch calls iov_iter_advance() before goto again: we'll skip zero-length segment at second iteraction and iov_iter_fault_in_readable() will detect invalid address. Special thanks to Konstantin Khlebnikov, who helped a lot with the commit description. Cc: Andrew Morton Cc: Maxim Patlasov Cc: Konstantin Khlebnikov Signed-off-by: Roman Gushchin Signed-off-by: Miklos Szeredi Fixes: ea9b9907b82a ("fuse: implement perform_write") Cc: Signed-off-by: Sasha Levin commit 931858a0bce673fad1855373631641c8250f83ea Author: Miklos Szeredi Date: Fri Dec 4 19:18:48 2015 +0100 ovl: fix permission checking for setattr [ Upstream commit acff81ec2c79492b180fade3c2894425cd35a545 ] [Al Viro] The bug is in being too enthusiastic about optimizing ->setattr() away - instead of "copy verbatim with metadata" + "chmod/chown/utimes" (with the former being always safe and the latter failing in case of insufficient permissions) it tries to combine these two. Note that copyup itself will have to do ->setattr() anyway; _that_ is where the elevated capabilities are right. Having these two ->setattr() (one to set verbatim copy of metadata, another to do what overlayfs ->setattr() had been asked to do in the first place) combined is where it breaks. Signed-off-by: Miklos Szeredi Cc: Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 6abc54fe3ba93970e2b892c233f4fa32965cbfdb Author: Andreas Schwab Date: Fri Feb 5 19:50:03 2016 +0100 powerpc: Fix dedotify for binutils >= 2.26 [ Upstream commit f15838e9cac8f78f0cc506529bb9d3b9fa589c1f ] Since binutils 2.26 BFD is doing suffix merging on STRTAB sections. But dedotify modifies the symbol names in place, which can also modify unrelated symbols with a name that matches a suffix of a dotted name. To remove the leading dot of a symbol name we can just increment the pointer into the STRTAB section instead. Backport to all stables to avoid breakage when people update their binutils - mpe. Cc: stable@vger.kernel.org Signed-off-by: Andreas Schwab Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 7488eb19ffbf689f2488180d565875671f64c7f6 Author: Ard Biesheuvel Date: Tue Mar 8 21:09:29 2016 +0700 arm64: account for sparsemem section alignment when choosing vmemmap offset [ Upstream commit 36e5cd6b897e17d03008f81e075625d8e43e52d0 ] Commit dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear region") fixed an issue where the struct page array would overflow into the adjacent virtual memory region if system RAM was placed so high up in physical memory that its addresses were not representable in the build time configured virtual address size. However, the fix failed to take into account that the vmemmap region needs to be relatively aligned with respect to the sparsemem section size, so that a sequence of page structs corresponding with a sparsemem section in the linear region appears naturally aligned in the vmemmap region. So round up vmemmap to sparsemem section size. Since this essentially moves the projection of the linear region up in memory, also revert the reduction of the size of the vmemmap region. Cc: Fixes: dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear region") Tested-by: Mark Langsdorf Tested-by: David Daney Tested-by: Robert Richter Acked-by: Catalin Marinas Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ab754494cbe4dd44a9e1354b3d93c8d5d5139aad Author: Ard Biesheuvel Date: Fri Feb 26 17:57:13 2016 +0100 arm64: vmemmap: use virtual projection of linear region [ Upstream commit dfd55ad85e4a7fbaa82df12467515ac3c81e8a3e ] Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made some changes to the memory mapping code to allow physical memory to reside at an offset that exceeds the size of the virtual mapping. However, since the size of the vmemmap area is proportional to the size of the VA area, but it is populated relative to the physical space, we may end up with the struct page array being mapped outside of the vmemmap region. For instance, on my Seattle A0 box, I can see the following output in the dmesg log. vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum) 0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual) We can fix this by deciding that the vmemmap region is not a projection of the physical space, but of the virtual space above PAGE_OFFSET, i.e., the linear region. This way, we are guaranteed that the vmemmap region is of sufficient size, and we can even reduce the size by half. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 35d25ad0b18c6de730105fcdce2a5d944a12064e Author: Andrey Grodzovsky Date: Fri Jan 22 17:07:29 2016 -0500 drm/dp/mst: Reverse order of MST enable and clearing VC payload table. [ Upstream commit c175cd16df272119534058f28cbd5eeac6ff2d24 ] On DELL U3014 if you clear the table before enabling MST it sometimes hangs the receiver. Signed-off-by: Andrey Grodzovsky Reviewed-by: Harry Wentland Cc: stable@vger.kernel.org Acked-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 47a245e586a0a3e20defadbf72e6f5901f1d0d7b Author: Hersen Wu Date: Fri Jan 22 17:07:28 2016 -0500 drm/dp/mst: move GUID storage from mgr, port to only mst branch [ Upstream commit 5e93b8208d3c419b515fb75e2601931c027e12ab ] Previous implementation does not handle case below: boot up one MST branch to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output of 1st MST, GUID is not created for 2nd MST branch. When downstream port of 2nd MST branch send upstream request, it fails because 2nd MST branch GUID is not available. New Implementation: only create GUID for MST branch and save it within Branch. Signed-off-by: Hersen Wu Reviewed-by: Harry Wentland Cc: stable@vger.kernel.org Acked-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit bb10fd1ac23435fdcc662c282a9eff64fc1017c1 Author: Sekhar Nori Date: Tue Dec 15 19:56:12 2015 +0530 irqchip/omap-intc: Add support for spurious irq handling [ Upstream commit d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d ] Under some conditions, irq sorting procedure used by INTC can go wrong resulting in a spurious irq getting reported. If this condition is not handled, it results in endless stream of: unexpected IRQ trap at vector 00 messages from ack_bad_irq() Handle the spurious interrupt condition in omap-intc driver to prevent this. Measurements using kernel function profiler on AM335x EVM running at 720MHz show that after this patch omap_intc_handle_irq() takes about 37.4us against 34us before this patch. Signed-off-by: Sekhar Nori Acked-by: Tony Lindgren Cc: John Ogness Cc: Felipe Balbi Cc: Jason Cooper Cc: Marc Zyngier Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 290e5305a83aa533e2fc20f435e3df9731c02b62 Author: Felipe Balbi Date: Fri Jan 2 16:18:54 2015 -0600 irqchip: omap-intc: Improve IRQ handler [ Upstream commit 6ed3464897cc825a75218653c710d673282dfcf8 ] As it turns out the current IRQ number will *always* be available from SIR register which renders the reads of PENDING registers as plain unnecessary overhead. In order to catch any situation where SIR reads as zero, we're adding a WARN() to turn it into a very verbose error and users actually report it. With this patch average running time of omap_intc_handle_irq() reduced from about 28.5us to 19.8us as measured by the kernel function profiler. Tested with BeagleBoneBlack Rev A5C. Tested-by: Tony Lindgren Signed-off-by: Felipe Balbi Cc: Linux ARM Kernel Mailing List Link: http://lkml.kernel.org/r/20150720204910.GH5394@saruman.tx.rr.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 4d7a10c5e89fae20d451032bbbcc051241db8bbb Author: Rich Felker Date: Fri Jan 22 15:11:05 2016 -0800 MAINTAINERS: return arch/sh to maintained state, with new maintainers [ Upstream commit 114bf37e04d839b555b3dc460b5e6ce156f49cf0 ] Add Yoshinori Sato and Rich Felker as maintainers for arch/sh (SUPERH). Signed-off-by: Rich Felker Signed-off-by: Yoshinori Sato Acked-by: D. Jeff Dionne Acked-by: Rob Landley Acked-by: Peter Zijlstra (Intel) Acked-by: Simon Horman Acked-by: Geert Uytterhoeven Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e3212b2f21a74e8124d6e9e14dc25920d23b2885 Author: David Henningsson Date: Mon Jan 11 09:33:14 2016 +0100 ALSA: hda - Fixup inverted internal mic for Lenovo E50-80 [ Upstream commit 56f27013482c0803d978b667fe85de04ce9357cd ] Inform userspace that one channel of the internal mic has reversed polarity, so it does not attempt to add both channels together and end up with silence. Cc: stable@vger.kernel.org Reported-by: Andrzej Mendel Alsa-info: http://www.alsa-project.org/db/?f=3088f82a0cf977855f92af9db8ad406c04f71efa BugLink: https://bugs.launchpad.net/bugs/1529624 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fae6f76ce1a42ed2f7f6ec1ba02e29602b0ebc16 Author: Herbert Xu Date: Tue Aug 4 15:42:47 2015 +0800 net: Fix skb_set_peeked use-after-free bug [ Upstream commit a0a2a6602496a45ae838a96db8b8173794b5d398 ] The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone skb before setting peeked flag") introduced a use-after-free bug in skb_recv_datagram. This is because skb_set_peeked may create a new skb and free the existing one. As it stands the caller will continue to use the old freed skb. This patch fixes it by making skb_set_peeked return the new skb (or the old one if unchanged). Fixes: 738ac1ebb96d ("net: Clone skb before setting peeked flag") Reported-by: Brenden Blanco Signed-off-by: Herbert Xu Tested-by: Brenden Blanco Reviewed-by: Konstantin Khlebnikov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9f0b813dfce98f289ca6511f20c9ab38c5670027 Author: Herbert Xu Date: Mon Jul 13 16:04:13 2015 +0800 net: Clone skb before setting peeked flag [ Upstream commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ] Shared skbs must not be modified and this is crucial for broadcast and/or multicast paths where we use it as an optimisation to avoid unnecessary cloning. The function skb_recv_datagram breaks this rule by setting peeked without cloning the skb first. This causes funky races which leads to double-free. This patch fixes this by cloning the skb and replacing the skb in the list when setting skb->peeked. Fixes: a59322be07c9 ("[UDP]: Only increment counter on first peek/recv") Reported-by: Konstantin Khlebnikov Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9dac025573bbde6e69bd2238b803cdd4d881d83b Author: Andy Lutomirski Date: Tue Apr 5 12:24:23 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 [ kamal: backport to 3.19-stable: no X86_FEATURE_XENPV so just call xen_pv_domain() directly ] Acked-by: Andy Lutomirski Signed-off-by: Kamal Mostafa Signed-off-by: Sasha Levin