commit 6fe78bc1bfcddabbf3d210e18f91da44fa796d8a Author: Sasha Levin Date: Tue Apr 19 07:58:05 2016 -0400 Linux 4.1.22 Signed-off-by: Sasha Levin commit 00e1d655592109ea61e6a1316539ae8ce9cc3813 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 a9e524e20d53b67328c1ba0301c19efae260a0a0 Author: Cyrille Pitchen Date: Fri Feb 5 13:45:12 2016 +0100 crypto: atmel - fix checks of error code returned by devm_ioremap_resource() [ Upstream commit 9b52d55f4f0e2bb9a34abbcf99e05e17f1b3b281 ] The change fixes potential oops while accessing iomem on invalid address, if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by: Vladimir Zapolskiy Fixes: b0e8b3417a62 ("crypto: atmel - use devm_xxx() managed function") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9cd462227bd3eae177704b9f1d8e160cec511d15 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 da2041b6c4bf60904a7732eec0b20c89f54d9693 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 4686552323f938fc04e4e6101a271810a1880f73 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 bbd0b13f917860a686ccaf40cda003332a640a70 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 474b8c6d329cfc40680ef308878d22f5a1a3b02b 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 d5865dc7deb118b1db82dcaf4d249668bc81a311 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 4b586dc3d736a43659acb575c90d33370ba2fb0d 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 9f1aa2840b8f95558470720572f10bd3b046100f 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 30c63e3abff9d92d89e3c7132df09188982a6c66 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 e025091aa3a343703375c66e0bd02675b251411a 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 2e840836fdf9ba0767134dcc5103dd25e442023b 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 0fea20fcc6806c82232a046a872838c0f06999e4 Author: Arnd Bergmann Date: Wed Nov 25 16:22:25 2015 +0100 coredump: Use 64bit time for unix time of coredump [ Upstream commit 03927c8acb63100046260711c06ba28b6b5936fb ] struct timeval on 32-bit systems will have its tv_sec value overflow in year 2038 and beyond. Use a 64 bit value to print time of the coredump in seconds. ktime_get_real_seconds is chosen here for efficiency reasons. Suggested by: Arnd Bergmann Signed-off-by: Tina Ruchandani Signed-off-by: Arnd Bergmann Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit bef794e8c891b60da2dec86c90f1e46fa142ea1e 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 01954dfd48d936199204ae0860897b8aed18c1e2 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 7a33539146bdcbbce25dbe93e853f39058c640a9 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 b90311472f0dc0aa7a7223c1220db47ce4db5447 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 20b25a3a2ce6ab20ceab54a2650809cc191c3287 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 35fe4a174248f3433e8017177a606fba74c86c4c 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 ff6c4184945bb5ec843cde5c3936b93823cf5641 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 ab31b690cdf88cf5cb0493718b89dbc37dd784a3 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 e4fc9a7c67d779795033235a2b5d2c84e39424c2 Author: Takashi Iwai Date: Fri Mar 18 18:01:53 2016 +0100 ALSA: hda - Fix forgotten HDMI monitor_present update [ Upstream commit bd48128539ab89986b24ad08ecd3e027dd1993a1 ] We forgot to copy monitor_present value when updating the ELD information. This won't change the ELD retrieval and the jack notification behavior, but appears only in the proc output. In that sense, it's no fatal error, but a bug is a bug is a bug. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b3d43aeef165fd0df7ba1b59d29eaee019df4923 Author: Takashi Iwai Date: Fri Nov 13 09:12:12 2015 +0100 ALSA: hda - Split ELD update code from hdmi_present_sense() [ Upstream commit e90247f9fceeebe5bdaac2d87e301e73bae9bc1f ] This is a preliminary patch for the later change to support ELD/jack handling with i915 audio component. This splits the ELD update code from hdmi_present_sense() so that it can be called from other places. Just a code refactoring, no functional change. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0b914b30c534502d1d6a68a5859ee65c3d7d8aa5 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 a635bc779e7b7748c9b0b773eaf08a7f2184ec50 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 febfaffe4aa9b0600028f46f50156e3354e34208 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 14a710bbf6b4095876ff682b3066ac485480049c 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 e69b0c2d1686a3344265e26a2ea6197e856f0459 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 fa3c776f1c47bd8cdbaaf1080420a67d4bfdc867 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 dfeccb29d75a2a7dc75d8b2c68b53bd7601d8686 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 62b3bd2a4f98852cefd0df17333362638246aa8f Author: Johannes Weiner Date: Thu Mar 17 14:20:25 2016 -0700 mm: memcontrol: reclaim when shrinking memory.high below usage [ Upstream commit 588083bb37a3cea8533c392370a554417c8f29cb ] When setting memory.high below usage, nothing happens until the next charge comes along, and then it will only reclaim its own charge and not the now potentially huge excess of the new memory.high. This can cause groups to stay in excess of their memory.high indefinitely. To fix that, when shrinking memory.high, kick off a reclaim cycle that goes after the delta. Signed-off-by: Johannes Weiner Acked-by: Michal Hocko Cc: Vladimir Davydov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 15207f3ca364563c590ba170ce40c1f90fd78268 Author: Joshua Hunt Date: Thu Mar 17 14:17:23 2016 -0700 watchdog: don't run proc_watchdog_update if new value is same as old [ Upstream commit a1ee1932aa6bea0bb074f5e3ced112664e4637ed ] While working on a script to restore all sysctl params before a series of tests I found that writing any value into the /proc/sys/kernel/{nmi_watchdog,soft_watchdog,watchdog,watchdog_thresh} causes them to call proc_watchdog_update(). NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. There doesn't appear to be a reason for doing this work every time a write occurs, so only do it when the values change. Signed-off-by: Josh Hunt Acked-by: Don Zickus Reviewed-by: Aaron Tomlin Cc: Ulrich Obergfell Cc: [4.1.x+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3ec245e8591a183e276df89cd7f9e7a15645b9da 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 0db0888f18f37d9ee10e99a7f3e90861b4d525a2 Author: Brent Taylor Date: Sun Mar 13 00:25:31 2016 -0600 mmc: atmel-mci: Check pdata for NULL before dereferencing it at DMA config [ Upstream commit 93c77d2999b09f2084b033ea6489915e0104ad9c ] Using an at91sam9g20ek development board with DTS configuration may trigger a kernel panic because of a NULL pointer dereference exception, while configuring DMA. Let's fix this by adding a check for pdata before dereferencing it. Signed-off-by: Brent Taylor Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7fa28eeed844c4388957095e5c485eb6f87a14de Author: Mans Rullgard Date: Sat Jan 9 12:45:10 2016 +0000 mmc: atmel-mci: restore dma on AVR32 [ Upstream commit 74843787158e9dff249f0528e7d4806102cc2c26 ] Commit ecb89f2f5f3e7 ("mmc: atmel-mci: remove compat for non DT board when requesting dma chan") broke dma on AVR32 and any other boards not using DT. This restores a fallback mechanism for such cases. Signed-off-by: Mans Rullgard Acked-by: Hans-Christian Noren Egtvedt Acked-by: Ludovic Desroches Acked-by: Ulf Hansson Signed-off-by: Sasha Levin commit 112958c534636b0cb8614adef3c7b758409fb27b 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 1a2b820966601499b51d9bfd28c00932f5357e09 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 452718f54822d63ffff0aebb713c5ccd722fd050 Author: Dmitry V. Levin Date: Thu Mar 19 11:10:54 2015 +0000 vfs: show_vfsstat: do not ignore errors from show_devname method [ Upstream commit 5f8d498d4364f544fee17125787a47553db02afa ] Explicitly check show_devname method return code and bail out in case of an error. This fixes regression introduced by commit 9d4d65748a5c. Cc: stable@vger.kernel.org Signed-off-by: Dmitry V. Levin Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 03d44e3d9dd7744fe97ca472fce1725b7179fa2f 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 4fa1657957f668fcc9606268df01bc0f3e4f1379 Author: Takashi Iwai Date: Tue Mar 15 15:20:58 2016 +0100 ALSA: usb-audio: Add sanity checks for endpoint accesses [ Upstream commit 447d6275f0c21f6cc97a88b3a0c601436a4cdf2a ] Add some sanity check codes before actually accessing the endpoint via get_endpoint() in order to avoid the invalid access through a malformed USB descriptor. Mostly just checking bNumEndpoints, but in one place (snd_microii_spdif_default_get()), the validity of iface and altsetting index is checked as well. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6ed72ce6ab8b38803b12df8c62a3a52becf19017 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 4084f3ab4ddb216046de8e3d8652398e9477c03e 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 44a3704dbaf34034426db30963d453d1796693fe 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 33184f68f4b527a6582e8fc5e94a7a7b6ba9c588 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 deba7b5dcc897d28bb84c0c029ec13f738416580 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 79deb9b280a508c77f6cc233e083544712bc2458 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 1a5aee1aaa9110ee4ba03f665f75b8b9ab21fd2c 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 76b69dfeb5f1bf19a6bd65991506bbb00647716b 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 1ee3901b99f165a4fa3ba85ff08d11bc2f61eec4 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 bbd5f23b1eaba29f46f97846b361fab4c5becc78 Author: Seth Forshee Date: Fri Mar 11 10:35:34 2016 -0600 fuse: Add reference counting for fuse_io_priv [ Upstream commit 744742d692e37ad5c20630e57d526c8f2e2fe3c9 ] The 'reqs' member of fuse_io_priv serves two purposes. First is to track the number of oustanding async requests to the server and to signal that the io request is completed. The second is to be a reference count on the structure to know when it can be freed. For sync io requests these purposes can be at odds. fuse_direct_IO() wants to block until the request is done, and since the signal is sent when 'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to use the object after the userspace server has completed processing requests. This leads to some handshaking and special casing that it needlessly complicated and responsible for at least one race condition. It's much cleaner and safer to maintain a separate reference count for the object lifecycle and to let 'reqs' just be a count of outstanding requests to the userspace server. Then we can know for sure when it is safe to free the object without any handshaking or special cases. The catch here is that most of the time these objects are stack allocated and should not be freed. Initializing these objects with a single reference that is never released prevents accidental attempts to free the objects. Fixes: 9d5722b7777e ("fuse: handle synchronous iocbs internally") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Seth Forshee Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 19167d65fabb60ff11fc5f9c4a5248c17a12f615 Author: Robert Doebbelin Date: Mon Mar 7 09:50:56 2016 +0100 fuse: do not use iocb after it may have been freed [ Upstream commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 ] There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an iocb that could have been freed if async io has already completed. The fix in this case is simple and obvious: cache the result before starting io. It was discovered by KASan: kernel: ================================================================== kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390 Signed-off-by: Robert Doebbelin Signed-off-by: Miklos Szeredi Fixes: bcba24ccdc82 ("fuse: enable asynchronous processing direct IO") Cc: # 3.10+ Signed-off-by: Sasha Levin commit f9162af6d940378c5fc24ec379f13a63edd15308 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 e484f76c1c1a601a7db84b4b6fb83f5243bf9951 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 84d5e27af4b08156ee63e73ca40cf247bcfeb760 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 e805ad22beb02c746c741c60508867ffd76463f4 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 e0247000f2d3bd6e8e6061f4ed536d50cbf4f077 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 8375d5ea6e7810b56bf9c43f4fc3abef8a3fcdfe 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 1ef6e487322a28195a9e68bd376944b7ec6db6c2 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 a14fea4d0284643ffd8538d2204cfb1fa8ac804d 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 843513677254865b92c551339103e8eaa2b07669 Author: Jenny Derzhavetz Date: Wed Feb 24 19:24:00 2016 +0200 iser-target: Separate flows for np listeners and connections cma events [ Upstream commit f81bf458208ef6d12b2fc08091204e3859dcdba4 ] No need to restrict this check to specific events. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 82ba90c00ba7e4ffd31a1ad8a5ed224c8e6f3d37 Author: Jenny Derzhavetz Date: Wed Feb 24 19:23:59 2016 +0200 iser-target: Add new state ISER_CONN_BOUND to isert_conn [ Upstream commit aea92980601f7ddfcb3c54caa53a43726314fe46 ] We need an indication that isert_conn->iscsi_conn binding has happened so we'll know not to invoke a connection reinstatement on an unbound connection which will lead to a bogus isert_conn->conn dereferece. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 3c6961458165c0ec909d68191bff4de7bdf50549 Author: Jenny Derzhavetz Date: Wed Feb 24 19:23:58 2016 +0200 iser-target: Fix identification of login rx descriptor type [ Upstream commit b89a7c25462b164db280abc3b05d4d9d888d40e9 ] Once connection request is accepted, one rx descriptor is posted to receive login request. This descriptor has rx type, but is outside the main pool of rx descriptors, and thus was mistreated as tx type. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 78243d0a1221f06af96a8952cd5ac71cd1fe5376 Author: Joe Thornber Date: Tue Mar 1 10:58:44 2016 +0000 dm thin metadata: don't issue prefetches if a transaction abort has failed [ Upstream commit 2eae9e4489b4cf83213fa3bd508b5afca3f01780 ] If a transaction abort has failed then we can no longer use the metadata device. Typically this happens if the superblock is unreadable. This fix addresses a crash seen during metadata device failure testing. Fixes: 8a01a6af75 ("dm thin: prefetch missing metadata pages") Cc: stable@vger.kernel.org # 3.19+ Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 14a33fc00969143f9d5935f486f238e98cc839d8 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 b314ace942506718f3c3bc2787f700bf49d84ea2 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 3b6a70271a4e1e72585b3a7236cbd17d646b38d1 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 6908e712e3f0df114e64f71de084ea8c4829e19f Author: Takashi Iwai Date: Thu Mar 10 11:33:43 2016 +0100 ALSA: hda - Apply reboot D3 fix for CX20724 codec, too [ Upstream commit 56dc66ff1c6d71f9a38c4a7c000b72b921fe4c89 ] Just like CX20722, CX7024 codec also requires the power down at reboot in order to reduce the noise at reboot/shutdown. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 685a50b681ddd07ff2b7714797b5793adcc691e7 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 d61ff6bc3f68be716226091e6ffa3b47b01a29cb 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 0dd18e03c1bdfe39f01b2e56dc66c3be90fa67a0 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 88e2df1b99cfc0087ccd2faa8ca61d7263fc007a Author: NeilBrown Date: Wed Mar 9 12:58:25 2016 +1100 md/raid5: preserve STRIPE_PREREAD_ACTIVE in break_stripe_batch_list [ Upstream commit 550da24f8d62fe81f3c13e3ec27602d6e44d43dc ] break_stripe_batch_list breaks up a batch and copies some flags from the batch head to the members, preserving others. It doesn't preserve or copy STRIPE_PREREAD_ACTIVE. This is not normally a problem as STRIPE_PREREAD_ACTIVE is cleared when a stripe_head is added to a batch, and is not set on stripe_heads already in a batch. However there is no locking to ensure one thread doesn't set the flag after it has just been cleared in another. This does occasionally happen. md/raid5 maintains a count of the number of stripe_heads with STRIPE_PREREAD_ACTIVE set: conf->preread_active_stripes. When break_stripe_batch_list clears STRIPE_PREREAD_ACTIVE inadvertently this could becomes incorrect and will never again return to zero. md/raid5 delays the handling of some stripe_heads until preread_active_stripes becomes zero. So when the above mention race happens, those stripe_heads become blocked and never progress, resulting is write to the array handing. So: change break_stripe_batch_list to preserve STRIPE_PREREAD_ACTIVE in the members of a batch. URL: https://bugzilla.kernel.org/show_bug.cgi?id=108741 URL: https://bugzilla.redhat.com/show_bug.cgi?id=1258153 URL: http://thread.gmane.org/5649C0E9.2030204@zoner.cz Reported-by: Martin Svec (and others) Tested-by: Tom Weber Fixes: 1b956f7a8f9a ("md/raid5: be more selective about distributing flags across batch.") Cc: stable@vger.kernel.org (v4.1 and later) Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit d5226186331401679a52df554a9607022e470983 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 fcc5834794fdcb62637a1deb25bff5787bf73757 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 d09a05998d79dcfaa25de84624dce9f806fe4e7c 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 0e6555443a206655885bc4126d9a3a0e2d9d17a3 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 7269554a57352f66aefb3e85cb7e11c4b63bba59 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 23745ba7ffac8cffbe648812fe7dc485d6df9404 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 559920294e5db893cf5abedb00f56c2d72bca8c8 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 c7af1256a07538167fe1b14a6714e7b92cf82179 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 3068107c9442d27ab2f37d08fca7eb3e862d412a Author: Takashi Iwai Date: Fri Jul 17 16:27:33 2015 +0200 ALSA: hda - Check the return value from pm_runtime_get/put*() [ Upstream commit fbce23a0b95763dfc4961ce6240e055c39f497ed ] This patch changes the return type of snd_hdac_power_up/down() and variants to pass the error code from the underlying pm_runtime_get/put() calls. Currently they are ignored, but in most places, these should be handled properly. As an example, the regmap handler is updated to check the return value and accesses the register only when the wakeup succeeds. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f05c1ef89e7a97f2b1345736574dbef033231001 Author: Phil Elwell Date: Mon Feb 29 17:30:08 2016 -0800 pinctrl-bcm2835: Fix cut-and-paste error in "pull" parsing [ Upstream commit 2c7e3306d23864d49f686f22e56e180ff0fffb7f ] The DT bindings for pinctrl-bcm2835 allow both the function and pull to contain either one entry or one per pin. However, an error in the DT parsing can cause failures if the number of pulls differs from the number of functions. Cc: stable@vger.kernel.org Signed-off-by: Eric Anholt Signed-off-by: Phil Elwell Reviewed-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7ba075c0574015dc329241f7754aed97c9cffae9 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 8e1682fddbd122a565965a83a5f8235e8bcadc10 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 444cf5487d5f51a3ecce2a0dfe237156290dfc7f 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 65963ead8aefa685ec2e22d403461101c243683e 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 0e536ed27652e8d5d74e13378a8f48b52cb21c95 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 afc16b3aab195d12ad40546d3cffcab5e3511ead 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 13af0df20f8e78dc1e7239a29b2862addde3953e 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 6b9d9c35930bd75ddcfafb8eb7db909ceb63af10 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 15d38f73263562c2ebe3cdb7c6380e0b9a98c76c 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 c9d3e69a692eed01045bfa718505c3e887e87d85 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 ab1cc52b3f62f2445c60cbe390d26c50ebc0f3bd 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 594103da3005639712b3123a612791c8f4d3f4e9 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 d876f71611ad9b720cc890075b3c4bec25bd54b5 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 58d550f06dfefe06ae1afed7a2ffaa333d19dfec 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 463c16b5e65df60c9404e0755378a85f581a3145 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 179e72b561d3d331c850e1a5779688d7a7de5246 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 e62c5259a62f3da2a911f8fe6275dbf43d3b624f Author: David Howells Date: Wed Feb 24 14:37:15 2016 +0000 X.509: Fix leap year handling again [ Upstream commit ac4cbedfdf55455b4c447f17f0fa027dbf02b2a6 ] There are still a couple of minor issues in the X.509 leap year handling: (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when determining whether the year is a leap year or not, I divided the year by 100 after doing the modulus-by-100, thereby letting the compiler do one instruction for both, and then did a modulus-by-4. Unfortunately, I then passed the now-modified year value to mktime64() to construct a time value. Since this isn't a fast path and since mktime64() does a bunch of divisions, just condense down to "% 400". It's also easier to read. (2) The default month length for any February where the year doesn't divide by four exactly is obtained from the month_length[] array where the value is 29, not 28. This is fixed by altering the table. Reported-by: Rudolf Polzer Signed-off-by: David Howells Acked-by: David Woodhouse Acked-by: Arnd Bergmann cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f85d91f88486b34679c532a5687466eaf335258f Author: David Howells Date: Wed Jul 29 16:58:32 2015 +0100 PKCS#7: Improve and export the X.509 ASN.1 time object decoder [ Upstream commit fd19a3d195be23e8d9d0d66576b96ea25eea8323 ] Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a struct tm to make comparison easier (unfortunately, this makes readable display less easy) and export it so that it can be used by the PKCS#7 code too. Further, tighten up its parsing to reject invalid dates (eg. weird characters, non-existent hour numbers) and unsupported dates (eg. timezones other than 'Z' or dates earlier than 1970). Signed-off-by: David Howells Reviewed-by: David Woodhouse Signed-off-by: Sasha Levin commit 3ccbbbf7b5ceb75bef47692c39f443a3efb38437 Author: David Howells Date: Mon Jul 20 21:16:26 2015 +0100 X.509: Extract both parts of the AuthorityKeyIdentifier [ Upstream commit b92e6570a992c7d793a209db282f68159368201c ] Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier, as the second part can be used to match X.509 certificates by issuer and serialNumber. Signed-off-by: David Howells Tested-by: Vivek Goyal Signed-off-by: Sasha Levin commit d836abef23b662030fe8f5a2206d5274fe670155 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 68c533586b56051041b35477691d649fb90951c4 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 8b9af4307d02d83bef51f35bc1f0b046a331de13 Author: Russell King Date: Tue Jan 26 13:40:47 2016 +0000 mmc: sdhci-pxav3: fix higher speed mode capabilities [ Upstream commit 0ca33b4ad9cfc133bb3d93eec1ad0eea83d6f252 ] Commit 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes being used. The commit claims that SDR50 and DDR50 require clock adjustments in the SDIO3 Configuration register, which is located via the "conf-sdio3" resource. However, when this resource is given, we fail to read the host capabilities 1 register, resulting in host->caps1 being zero. Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain zero, disabling the SDR50 and DDR50 modes. The underlying idea in this function appears to be to read the device capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause our modified capabilities to be used. Implement exactly that. Fixes: 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") Signed-off-by: Russell King Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Adrian Hunter Tested-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 39786b624c79881f3caf3bc0af05d0a0fb08e759 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 dad41d54081e1bd2ef601c702ff4ea0f7428a965 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 503f8305ab1b82d8788a2f161e7c52c0c0f6aeac Author: Shaohua Li Date: Wed Feb 24 17:38:28 2016 -0800 RAID5: check_reshape() shouldn't call mddev_suspend [ Upstream commit 27a353c026a879a1001e5eac4bda75b16262c44a ] check_reshape() is called from raid5d thread. raid5d thread shouldn't call mddev_suspend(), because mddev_suspend() waits for all IO finish but IO is handled in raid5d thread, we could easily deadlock here. This issue is introduced by 738a273 ("md/raid5: fix allocation of 'scribble' array.") Cc: stable@vger.kernel.org (v4.1+) Reported-and-tested-by: Artur Paszkiewicz Reviewed-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 5255a738ee6ecc0e479728efe5668efd64901197 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 aa57ba13f44426a076ac567e965654453d4be1f1 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 517a021fdba44206722c85bd9267dabd67475fa6 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 084b44e9cbc6eec0b0b13138918fb5935208f3b4 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 cf438ddac48b27e7de0514f96d912e132c908df4 Author: Alan Date: Mon Feb 15 18:53:15 2016 +0000 aic7xxx: Fix queue depth handling [ Upstream commit 5a51a7abca133860a6f4429655a9eda3c4afde32 ] We were setting the queue depth correctly, then setting it back to two. If you hit this as a bisection point then please send me an email as it would imply we've been hiding other bugs with this one. Cc: Signed-off-by: Alan Cox Reviewed-by: Hannes Reinicke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6d2cd58f288e320c5a023219ac8726b30657ddbb 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 34bb7098221c2a37f5d9ef3591971a25719ae21a Author: Raghava Aditya Renukunta Date: Wed Feb 3 15:06:00 2016 -0800 aacraid: Fix RRQ overload [ Upstream commit 3f4ce057d51a9c0ed9b01ba693df685d230ffcae ] The driver utilizes an array of atomic variables to keep track of IO submissions to each vector. To submit an IO multiple threads iterate through the array to find a vector which has empty slots to send an IO. The reading and updating of the variable is not atomic, causing race conditions when a thread uses a full vector to submit an IO. Fixed by mapping each FIB to a vector, the submission path then uses said vector to submit IO thereby removing the possibly of a race condition.The vector assignment is started from 1 since vector 0 is reserved for the use of AIF management FIBS.If the number of MSIx vectors is 1 (MSI or INTx mode) then all the fibs are allocated to vector 0. Fixes: 495c0217 "aacraid: MSI-x support" Cc: stable@vger.kernel.org # v4.1 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 acab7e2cae96f3b69a6d9df27c727d515ab298b7 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 64f25c62a61af96dacbfa8a22b2d30949853f362 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 a6455f2f43dda60c52c857c2332ca5a557c8c449 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 fb1840e257d26b6aad69b864cb7ed4a67ab986b6 Author: Mike Snitzer Date: Fri Feb 5 08:49:01 2016 -0500 dm: fix excessive dm-mq context switching [ Upstream commit 6acfe68bac7e6f16dc312157b1fa6e2368985013 ] Request-based DM's blk-mq support (dm-mq) was reported to be 50% slower than if an underlying null_blk device were used directly. One of the reasons for this drop in performance is that blk_insert_clone_request() was calling blk_mq_insert_request() with @async=true. This forced the use of kblockd_schedule_delayed_work_on() to run the blk-mq hw queues which ushered in ping-ponging between process context (fio in this case) and kblockd's kworker to submit the cloned request. The ftrace function_graph tracer showed: kworker-2013 => fio-12190 fio-12190 => kworker-2013 ... kworker-2013 => fio-12190 fio-12190 => kworker-2013 ... Fixing blk_insert_clone_request()'s blk_mq_insert_request() call to _not_ use kblockd to submit the cloned requests isn't enough to eliminate the observed context switches. In addition to this dm-mq specific blk-core fix, there are 2 DM core fixes to dm-mq that (when paired with the blk-core fix) completely eliminate the observed context switching: 1) don't blk_mq_run_hw_queues in blk-mq request completion Motivated by desire to reduce overhead of dm-mq, punting to kblockd just increases context switches. In my testing against a really fast null_blk device there was no benefit to running blk_mq_run_hw_queues() on completion (and no other blk-mq driver does this). So hopefully this change doesn't induce the need for yet another revert like commit 621739b00e16ca2d ! 2) use blk_mq_complete_request() in dm_complete_request() blk_complete_request() doesn't offer the traditional q->mq_ops vs .request_fn branching pattern that other historic block interfaces do (e.g. blk_get_request). Using blk_mq_complete_request() for blk-mq requests is important for performance. It should be noted that, like blk_complete_request(), blk_mq_complete_request() doesn't natively handle partial completions -- but the request-based DM-multipath target does provide the required partial completion support by dm.c:end_clone_bio() triggering requeueing of the request via dm-mpath.c:multipath_end_io()'s return of DM_ENDIO_REQUEUE. dm-mq fix #2 is _much_ more important than #1 for eliminating the context switches. Before: cpu : usr=15.10%, sys=59.39%, ctx=7905181, majf=0, minf=475 After: cpu : usr=20.60%, sys=79.35%, ctx=2008, majf=0, minf=472 With these changes multithreaded async read IOPs improved from ~950K to ~1350K for this dm-mq stacked on null_blk test-case. The raw read IOPs of the underlying null_blk device for the same workload is ~1950K. Fixes: 7fb4898e0 ("block: add blk-mq support to blk_insert_cloned_request()") Fixes: bfebd1cdb ("dm: add full blk-mq support to request-based DM") Cc: stable@vger.kernel.org # 4.1+ Reported-by: Sagi Grimberg Signed-off-by: Mike Snitzer Acked-by: Jens Axboe Signed-off-by: Sasha Levin commit 31a37d7c7ef7b4f90b600fcddd1c385a39f9d34c 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 3a4db9eef86e230e3b441ea14ab4ed5492b5bf02 Author: Jarkko Sakkinen Date: Thu Feb 18 22:11:29 2016 +0200 tpm_crb: tpm2_shutdown() must be called before tpm_chip_unregister() [ Upstream commit 99cda8cb4639de81cde785b5bab9bc52e916e594 ] Wrong call order. Reported-by: Jason Gunthorpe Fixes: 74d6b3ceaa17 Signed-off-by: Jarkko Sakkinen cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2ecb9996d53c218a536ad796b766c2c1cd06c3c0 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 3aae1bb07b59d62e9ea4b1883d787091070ffe1e 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 ba390f4e74ab0e9b62930f7da629e8b55027c564 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 23c41c6589cacd98e5028217d1db364f5081de03 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 619464b00951d21aa1bc66c542b947c4a8835dba 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 3bab1a558c159d9a8388e11270add2acc100d5c5 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 2168661199ff5eeab52a8aa2408a6b21fbf4f743 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 349420036cac88d1a0ef3fb77ddc9a297cd4d17e 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 79b768dec5d354aeb143f51db11e0cbb758176fb Author: Alexander Usyskin Date: Sun Feb 7 23:35:32 2016 +0200 mei: bus: move driver api functions at the start of the file [ Upstream commit 6238299774377b12c3e24507b100b2687eb5ea32 ] To make the file more organize move mei client driver api to the start of the file and add Kdoc. There are no functional changes in this patch. Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0f412b8aa88883f7e3059c5a2c1e56ce0dd8bf86 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 b053d66b66e702f74ddc986863b30eaac41e7f4c 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 5badf7e00f0968d820bf7bba9081339bfca3489c 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 6896d28d701c95df209e15ce82bcc8024a7dbd90 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 4dc695f3116ba454f9624f15b512b8caa23e5221 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 3beac2b0bffd8e977ef1d464dd424f22af965a96 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 d3e5b294c6a3e78b9a544eede572e239555224db Author: Alexander Kochetkov Date: Tue Jan 26 16:34:00 2016 +0300 clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks [ Upstream commit e8b63288b37dbb8457b510c9d96f6006da4653f6 ] hclk_cpubus needs to keep running because it is needed for devices like the rom, i2s0 or spdif to be accessible via cpu. Without that all accesses to devices (readl/writel) return wrong data. So add it to the list of critical clocks. Fixes: 78eaf6095cc763c ("clk: rockchip: disable unused clocks") Signed-off-by: Alexander Kochetkov Cc: stable@vger.kernel.org # 4.1.x- Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit a0723dc0436813a4bb543a823b146045eb97f35b 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 754d2b7064ccfe6ca116323553f3f44d6f6f9d96 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 1ad241d40ef8d9a50ced5c35bf55e9a21a997516 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 05d13aa39e8c81ad8c4af8dcc3c29129f5634b8a 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 2cc58a1e06ea8b6c9aa6d25ec74d8d1671e500eb Author: Andy Lutomirski Date: Tue Apr 5 12:24:24 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 4.2-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 commit 37dee22181885e7847e8c95843b6e94138edbd43 Author: Vladis Dronov Date: Mon Nov 16 15:55:11 2015 -0200 [media] usbvision: fix crash on detecting device with invalid configuration [ Upstream commit fa52bd506f274b7619955917abfde355e3d19ffe ] The usbvision driver crashes when a specially crafted usb device with invalid number of interfaces or endpoints is detected. This fix adds checks that the device has proper configuration expected by the driver. Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 46460a03f44f1915ded434057fa46332438b3a6e 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 d979e967f848caf908a1401b7ad67cf13f06ef9f 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 90352f3f473a29db1289ec31facc1ac18cc66e9e 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 ea44bf73d956729f3122bbed0661db7b18864277 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 2cadb57dff500076a87b934cac64bb5a2293b644 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 50d93d381508139a35a0f91a364fbdc1a38885d4 Author: James Hogan Date: Fri Mar 4 10:10:51 2016 +0000 MIPS: smp.c: Fix uninitialised temp_foreign_map [ Upstream commit d825c06bfe8b885b797f917ad47365d0e9c21fbb ] When calculate_cpu_foreign_map() recalculates the cpu_foreign_map cpumask it uses the local variable temp_foreign_map without initialising it to zero. Since the calculation only ever sets bits in this cpumask any existing bits at that memory location will remain set and find their way into cpu_foreign_map too. This could potentially lead to cache operations suboptimally doing smp calls to multiple VPEs in the same core, even though the VPEs share primary caches. Therefore initialise temp_foreign_map using cpumask_clear() before use. Fixes: cccf34e9411c ("MIPS: c-r4k: Fix cache flushing for MT cores") Signed-off-by: James Hogan Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12759/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 9c99016a364ab695755e3a66c4dbfb53b9c07a0f 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 a490e8a46260de7257bbb0bfed9316f4a74cf524 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 fc7260739ac5739520454788f2e8e667f92f1a29 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 6d7ac2feca9c07d9ce489dbaab2f51beb3e5c107 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 abae284042df82086a1edbf3512c9f4cd355c6e4 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 b9a54ed91c7bbd5c18a4170be078d9f7e28560ed 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 d5b55a7aae08c0e0785430126bcc4a9ae7f5c737 Author: Zhao Lei Date: Tue Dec 1 18:39:40 2015 +0800 btrfs: Fix no_space in write and rm loop [ Upstream commit 08acfd9dd845dc052c5eae33e6c3976338070069 ] commit e1746e8381cd2af421f75557b5cae3604fc18b35 upstream. I see no_space in v4.4-rc1 again in xfstests generic/102. It happened randomly in some node only. (one of 4 phy-node, and a kvm with non-virtio block driver) By bisect, we can found the first-bad is: commit bdced438acd8 ("block: setup bi_phys_segments after splitting")' But above patch only triggered the bug by making bio operation faster(or slower). Main reason is in our space_allocating code, we need to commit page writeback before wait it complish, this patch fixed above bug. BTW, there is another reason for generic/102 fail, caused by disable default mixed-blockgroup, I'll fix it in xfstests. Signed-off-by: Zhao Lei Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42bd8f4fda813558c3045c60ad6436b1c7430ec7 Author: Zhao Lei Date: Thu Apr 9 12:34:43 2015 +0800 btrfs: wait for delayed iputs on no space [ Upstream commit 9a4e7276d39071576d369e607d7accb84b41d0b4 ] btrfs will report no_space when we run following write and delete file loop: # FILE_SIZE_M=[ 75% of fs space ] # DEV=[ some dev ] # MNT=[ some dir ] # # mkfs.btrfs -f "$DEV" # mount -o nodatacow "$DEV" "$MNT" # for ((i = 0; i < 100; i++)); do dd if=/dev/zero of="$MNT"/file0 bs=1M count="$FILE_SIZE_M"; rm -f "$MNT"/file0; done # Reason: iput() and evict() is run after write pages to block device, if write pages work is not finished before next write, the "rm"ed space is not freed, and caused above bug. Fix: We can add "-o flushoncommit" mount option to avoid above bug, but it have performance problem. Actually, we can to wait for on-the-fly writes only when no-space happened, it is which this patch do. Signed-off-by: Zhao Lei Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit ee6ad435c9872610c5a52cad02e331951cf2fb25 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 1f9780e372264c0cd71571c94da08cc49ae327e3 Author: Andy Lutomirski Date: Wed Feb 24 12:18:49 2016 -0800 x86/entry/compat: Add missing CLAC to entry_INT80_32 [ Upstream commit 3d44d51bd339766f0178f0cf2e8d048b4a4872aa ] This doesn't seem to fix a regression -- I don't think the CLAC was ever there. I double-checked in a debugger: entries through the int80 gate do not automatically clear AC. Stable maintainers: I can provide a backport to 4.3 and earlier if needed. This needs to be backported all the way to 3.10. Reported-by: Brian Gerst Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: # v3.10 and later Fixes: 63bcff2a307b ("x86, smap: Add STAC and CLAC instructions to control user space access") Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit aa1311b426d5cc249887c8cbfa21a6dda2c5a201 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 474510b43af63bc2bddf394270432e6f3ea22433 Author: Hans de Goede Date: Fri Jan 22 11:41:05 2016 +0100 ACPI: Revert "ACPI / video: Add Dell Inspiron 5737 to the blacklist" [ Upstream commit b186b4dcb79b1914c3dadb27ac72dafaa4267998 ] The quirk to get "acpi_backlight=vendor" behavior by default on the Dell Inspiron 5737 was added before we started doing "acpi_backlight=native" by default on Win8 ready machines. Since we now avoid using acpi-video as backlight driver on these machines by default (using the native driver instead) we no longer need this quirk. Moreover the vendor driver does not work after a suspend/resume where as the native driver does. This reverts commit 08a56226d847 (ACPI / video: Add Dell Inspiron 5737 to the blacklist). Link: https://bugzilla.kernel.org/show_bug.cgi?id=111061 Cc: 3.19+ # 3.19+ Reported-and-tested-by: erusan@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e159282ea85a27ebeb4d9c4869b41bf192bcf5f8 Author: Mykola Lysenko Date: Wed Jan 27 09:39:36 2016 -0500 drm/dp/mst: deallocate payload on port destruction [ Upstream commit 91a25e463130c8e19bdb42f2d827836c7937992e ] This is needed to properly deallocate port payload after downstream branch get unplugged. In order to do this unplugged MST topology should be preserved, to find first alive port on path to unplugged MST topology, and send payload deallocation request to branch device of found port. For this mstb and port kref's are used in reversed order to track when port and branch memory could be freed. Added additional functions to find appropriate mstb as described above. Signed-off-by: Mykola Lysenko Reviewed-by: Harry Wentland Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 9cc696013c324d36c1ffbc4160d5cdf698ee490b 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 11dd4e27c5ef9fed4d10a35303903227c5df689d 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 1505f5ae8ac52b4c9cda088ca8113e1f0ec2f32f 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 249ee7541e9bfc313cbe11f2816e902f9612ceec 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 610ed2802923b6d0204513b6cb7cf22fdbeec38b 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 2068256b08824ad53b28fb08952b62dd35e66593 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 c19cd7e350c5ad9f3f4b3e486dbb4dab737a22a4 Author: Chandan Rajendra Date: Thu Jan 7 18:56:59 2016 +0530 Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots [ Upstream commit f32e48e925964c4f8ab917850788a87e1cef3bad ] The following call trace is seen when btrfs/031 test is executed in a loop, [ 158.661848] ------------[ cut here ]------------ [ 158.662634] WARNING: CPU: 2 PID: 890 at /home/chandan/repos/linux/fs/btrfs/ioctl.c:558 create_subvol+0x3d1/0x6ea() [ 158.664102] BTRFS: Transaction aborted (error -2) [ 158.664774] Modules linked in: [ 158.665266] CPU: 2 PID: 890 Comm: btrfs Not tainted 4.4.0-rc6-g511711a #2 [ 158.666251] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 158.667392] ffffffff81c0a6b0 ffff8806c7c4f8e8 ffffffff81431fc8 ffff8806c7c4f930 [ 158.668515] ffff8806c7c4f920 ffffffff81051aa1 ffff880c85aff000 ffff8800bb44d000 [ 158.669647] ffff8808863b5c98 0000000000000000 00000000fffffffe ffff8806c7c4f980 [ 158.670769] Call Trace: [ 158.671153] [] dump_stack+0x44/0x5c [ 158.671884] [] warn_slowpath_common+0x81/0xc0 [ 158.672769] [] warn_slowpath_fmt+0x47/0x50 [ 158.673620] [] create_subvol+0x3d1/0x6ea [ 158.674440] [] btrfs_mksubvol.isra.30+0x369/0x520 [ 158.675376] [] ? percpu_down_read+0x1a/0x50 [ 158.676235] [] btrfs_ioctl_snap_create_transid+0x101/0x180 [ 158.677268] [] btrfs_ioctl_snap_create+0x52/0x70 [ 158.678183] [] btrfs_ioctl+0x474/0x2f90 [ 158.678975] [] ? vma_merge+0xee/0x300 [ 158.679751] [] ? alloc_pages_vma+0x91/0x170 [ 158.680599] [] ? lru_cache_add_active_or_unevictable+0x22/0x70 [ 158.681686] [] ? selinux_file_ioctl+0xff/0x1d0 [ 158.682581] [] do_vfs_ioctl+0x2c1/0x490 [ 158.683399] [] ? security_file_ioctl+0x3e/0x60 [ 158.684297] [] SyS_ioctl+0x74/0x80 [ 158.685051] [] entry_SYSCALL_64_fastpath+0x12/0x6a [ 158.685958] ---[ end trace 4b63312de5a2cb76 ]--- [ 158.686647] BTRFS: error (device loop0) in create_subvol:558: errno=-2 No such entry [ 158.709508] BTRFS info (device loop0): forced readonly [ 158.737113] BTRFS info (device loop0): disk space caching is enabled [ 158.738096] BTRFS error (device loop0): Remounting read-write after error is not allowed [ 158.851303] BTRFS error (device loop0): cleaner transaction attach returned -30 This occurs because, Mount filesystem Create subvol with ID 257 Unmount filesystem Mount filesystem Delete subvol with ID 257 btrfs_drop_snapshot() Add root corresponding to subvol 257 into btrfs_transaction->dropped_roots list Create new subvol (i.e. create_subvol()) 257 is returned as the next free objectid btrfs_read_fs_root_no_name() Finds the btrfs_root instance corresponding to the old subvol with ID 257 in btrfs_fs_info->fs_roots_radix. Returns error since btrfs_root_item->refs has the value of 0. To fix the issue the commit initializes tree root's and subvolume root's highest_objectid when loading the roots from disk. Signed-off-by: Chandan Rajendra Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9bf972e8aa6110d750cf1ddab68511f478a6a751 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 a1f535acffbd95ae6ae81656e8bba39af094c3f0 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 e92c51b734d57e04f0c9b43106b5294834339be6 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 4e3fa12f124507ad17f999c28ef35803596ff2c6 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 bb055e837f904fdc80d4d82819b0a9aaf35dce4a 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 c0109d289de5a48e54a2d070981a629fc241f112 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 dd25a5d97400cb10a85a09eac07d541975e39522 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 2f53ace471375e60b3ba1b5341f673e8b36684aa 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 cbf3d65e135a43cf654f10037eafe6f9be14baf5 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 3e49b9ec16de14ec3210e87c4307ffdb75cfe0b0 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 c3f517d4cd9a1478ae99f873697444a8690de482 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 d5181a51587102a71e7b05021603693f463dcab2 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 4181c95f943d60cff60e36e25368d0f627458ada 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 973fc47992c915d37b1b802188bdfda1cfd2ed51 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 809f952a39a2ccb9667f8b88b4ad283459b2880a 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 17cd5f95550aff7619ed4e2b2b0a0f9607d09431 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 527435d6f08f8b42d23b4ec3616169dc9ab1c40b 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 a7635d6a0849007d2192bc02c038cc1b9d91b274 Author: Jan Kara Date: Fri Feb 19 00:18:25 2016 -0500 ext4: fix bh->b_state corruption [ Upstream commit ed8ad83808f009ade97ebbf6519bc3a97fefbc0c ] ext4 can update bh->b_state non-atomically in _ext4_get_block() and ext4_da_get_block_prep(). Usually this is fine since bh is just a temporary storage for mapping information on stack but in some cases it can be fully living bh attached to a page. In such case non-atomic update of bh->b_state can race with an atomic update which then gets lost. Usually when we are mapping bh and thus updating bh->b_state non-atomically, nobody else touches the bh and so things work out fine but there is one case to especially worry about: ext4_finish_bio() uses BH_Uptodate_Lock on the first bh in the page to synchronize handling of PageWriteback state. So when blocksize < pagesize, we can be atomically modifying bh->b_state of a buffer that actually isn't under IO and thus can race e.g. with delalloc trying to map that buffer. The result is that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock. Fix the problem by always updating bh->b_state bits atomically. CC: stable@vger.kernel.org Reported-by: Nikolay Borisov Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0e3029cfab4a7884b32e1b2d3c19c12eded9804a Author: Dave Chinner Date: Thu Jun 4 09:18:18 2015 +1000 dax: don't abuse get_block mapping for endio callbacks [ Upstream commit e842f2903908934187af7232fb5b21da527d1757 ] dax_fault() currently relies on the get_block callback to attach an io completion callback to the mapping buffer head so that it can run unwritten extent conversion after zeroing allocated blocks. Instead of this hack, pass the conversion callback directly into dax_fault() similar to the get_block callback. When the filesystem allocates unwritten extents, it will set the buffer_unwritten() flag, and hence the dax_fault code can call the completion function in the contexts where it is necessary without overloading the mapping buffer head. Note: The changes to ext4 to use this interface are suspect at best. In fact, the way ext4 did this end_io assignment in the first place looks suspect because it only set a completion callback when there wasn't already some other write() call taking place on the same inode. The ext4 end_io code looks rather intricate and fragile with all it's reference counting and passing to different contexts for modification via inode private pointers that aren't protected by locks... Signed-off-by: Dave Chinner Acked-by: Jan Kara Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 89d27e325a9cb38435074039a43c9d95c1f389ec 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 b7fcd843be1d376f5e43226227707422f74901c7 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 24e6deaf40a702d1f6bf3cc7b809945cca867c58 Author: Tony Lindgren Date: Thu Jan 14 12:20:47 2016 -0800 ARM: OMAP2+: Fix l2_inv_api_params for rodata [ Upstream commit 0a0b13275558c32bbf6241464a7244b1ffd5afb3 ] We don't want to write to .text, so let's move l2_inv_api_params to .data and access it via a pointer. Cc: Kees Cook Cc: Laura Abbott Cc: Nishanth Menon Cc: Richard Woodruff Cc: Russell King Cc: Tero Kristo Acked-by: Nicolas Pitre Cc: stable@vger.kernel.org # v4.0+ Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 17fe8c8b306e4b76078b8b103e1f344970409378 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 5b20b25abab6faba0c91a4d7ccde93e134f29d6d 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 3e77cb858ce67861e142186e3b131c04ddbc6edd 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 ab88ce5feca4204ecf4e7ef6c6693ff67edc2169 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 93d310f6cfd51d7158e2901b0f75babeaf97f3c3 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 8cf0abcfb3b1ce60a9bd866db451a093dc015233 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 7abe6e3537a321a332dc6320f22f27e3e11db750 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 af24c621219ec87b221c1bbade56a506bf09deb9 Author: Ioan-Adrian Ratiu Date: Fri Nov 20 22:19:02 2015 +0200 HID: usbhid: fix recursive deadlock [ Upstream commit e470127e9606b1fa151c4184243e61296d1e0c0f ] The critical section protected by usbhid->lock in hid_ctrl() is too big and because of this it causes a recursive deadlock. "Too big" means the case statement and the call to hid_input_report() do not need to be protected by the spinlock (no URB operations are done inside them). The deadlock happens because in certain rare cases drivers try to grab the lock while handling the ctrl irq which grabs the lock before them as described above. For example newer wacom tablets like 056a:033c try to reschedule proximity reads from wacom_intuos_schedule_prox_event() calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report() which tries to grab the usbhid lock already held by hid_ctrl(). There are two ways to get out of this deadlock: 1. Make the drivers work "around" the ctrl critical region, in the wacom case for ex. by delaying the scheduling of the proximity read request itself to a workqueue. 2. Shrink the critical region so the usbhid lock protects only the instructions which modify usbhid state, calling hid_input_report() with the spinlock unlocked, allowing the device driver to grab the lock first, finish and then grab the lock afterwards in hid_ctrl(). This patch implements the 2nd solution. Signed-off-by: Ioan-Adrian Ratiu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1c0c659983aeb05bbc500f1d3f9ba8082313bb12 Author: Takashi Iwai Date: Fri Jan 15 12:59:25 2016 +0100 ALSA: hda - Add fixup for Dell Latitidue E6540 [ Upstream commit cf52103a218744f3fd18111325c28e95aa9cd226 ] Another Dell model, another fixup entry: Latitude E6540 needs the same fixup as other Latitude E series as workaround for noise problems. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104341 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a0eb05f661f7b67c497e9647f4fb7593260d4e58 Author: Takashi Iwai Date: Sat Nov 14 17:46:31 2015 +0100 ALSA: hda - Fix noise on Dell Latitude E6440 [ Upstream commit 86f799b82f5c011404ddef54600bc5e99b7e0cf2 ] Dell Latitude E6440 (1028:05bd) needs the same fixup as applied to other Latitude E7xxx models for the click noise due to the recent power-saving changes. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=954876 Cc: # v4.1+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 46a190e6a3cd8223534614d306ab76b4811b6cc5 Author: Takashi Iwai Date: Tue Jan 12 14:03:33 2016 +0100 ALSA: usb-audio: Avoid calling usb_autopm_put_interface() at disconnect [ Upstream commit 5c06d68bc2a174a6b82dce9f100f55173b9a5189 ] ALSA PCM may still have a leftover instance after disconnection and it delays its release. The problem is that the PCM close code path of USB-audio driver has a call of snd_usb_autosuspend(). This involves with the call of usb_autopm_put_interface() and it may lead to a kernel Oops due to the NULL object like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000190 IP: [] usb_autopm_put_interface+0xf/0x30 PGD 0 Call Trace: [] snd_usb_autosuspend+0x14/0x20 [] snd_usb_pcm_close.isra.14+0x5c/0x90 [] snd_usb_playback_close+0xf/0x20 [] snd_pcm_release_substream.part.36+0x3a/0x90 [] snd_pcm_release+0xa3/0xb0 [] snd_disconnect_release+0xd0/0xe0 [] __fput+0x97/0x1d0 [] ____fput+0x9/0x10 [] task_work_run+0x72/0x90 [] do_exit+0x280/0xa80 [] do_group_exit+0x3a/0xa0 [] get_signal+0x1df/0x540 [] do_signal+0x23/0x620 [] ? do_readv_writev+0x128/0x200 [] prepare_exit_to_usermode+0x91/0xd0 [] syscall_return_slowpath+0x9a/0x120 [] ? __sys_recvmsg+0x5d/0x70 [] ? ktime_get_ts64+0x45/0xe0 [] ? SyS_poll+0x60/0xf0 [] int_ret_from_sys_call+0x25/0x8f We have already a check of disconnection in snd_usb_autoresume(), but the check is missing its counterpart. The fix is just to put the same check in snd_usb_autosuspend(), too. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 30e821e1c1f3a6a2d11616a7bb65da28da388f78 Author: Takashi Iwai Date: Tue Aug 25 16:09:00 2015 +0200 ALSA: usb-audio: Avoid nested autoresume calls [ Upstream commit 47ab154593827b1a8f0713a2b9dd445753d551d8 ] After the recent fix of runtime PM for USB-audio driver, we got a lockdep warning like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc8+ #61 Not tainted --------------------------------------------- pulseaudio/980 is trying to acquire lock: (&chip->shutdown_rwsem){.+.+.+}, at: [] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] but task is already holding lock: (&chip->shutdown_rwsem){.+.+.+}, at: [] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] This comes from snd_usb_autoresume() invoking down_read() and it's used in a nested way. Although it's basically safe, per se (as these are read locks), it's better to reduce such spurious warnings. The read lock is needed to guarantee the execution of "shutdown" (cleanup at disconnection) task after all concurrent tasks are finished. This can be implemented in another better way. Also, the current check of chip->in_pm isn't good enough for protecting the racy execution of multiple auto-resumes. This patch rewrites the logic of snd_usb_autoresume() & co; namely, - The recursive call of autopm is avoided by the new refcount, chip->active. The chip->in_pm flag is removed accordingly. - Instead of rwsem, another refcount, chip->usage_count, is introduced for tracking the period to delay the shutdown procedure. At the last clear of this refcount, wake_up() to the shutdown waiter is called. - The shutdown flag is replaced with shutdown atomic count; this is for reducing the lock. - Two new helpers are introduced to simplify the management of these refcounts; snd_usb_lock_shutdown() increases the usage_count, checks the shutdown state, and does autoresume. snd_usb_unlock_shutdown() does the opposite. Most of mixer and other codes just need this, and simply returns an error if it receives an error from lock. Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance') Reported-and-tested-by: Alexnader Kuleshov Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8d34309045f7d29641305cb2340df008b22c4c5c Author: Julian Scheel Date: Fri Aug 14 16:14:45 2015 +0200 ALSA: usb-audio: Fix parameter block size for UAC2 control requests [ Upstream commit bc18e31c3042f14fa5f2ff5c21136e2fdf4140f8 ] USB Audio Class version 2.0 supports three different parameter block sizes for CUR requests, which are 1 byte (5.2.3.1 Layout 1 Parameter Block), 2 bytes (5.2.3.2 Layout 2 Parameter Block) and 4 bytes (5.2.3.3 Layout 3 Parameter Block). Use the correct size according to the specific control as it was already done for UACv1. The allocated block size for control requests is increased to support the 4 byte worst case. Signed-off-by: Julian Scheel Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 97828b710a99325ef8ffeeac7f9f3e356419ed51 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 6abe3345f34c113503a5b3f66bd8eb65d980c27f 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