commit c9cab799319d1b2b947610ef580aeff2d6f06dae Author: Ben Hutchings Date: Wed Jun 15 21:29:36 2016 +0100 Linux 3.16.36 commit 20b8c4901d51a70bbc7d553ebea61473beecd26c Author: Peter Zijlstra Date: Thu Jun 11 14:46:43 2015 +0200 sched, dl: Convert switched_{from, to}_dl() / prio_changed_dl() to balance callbacks commit 9916e214998a4a363b152b637245e5c958067350 upstream. Remove the direct {push,pull} balancing operations from switched_{from,to}_dl() / prio_changed_dl() and use the balance callback queue. Again, err on the side of too many reschedules; since too few is a hard bug while too many is just annoying. Signed-off-by: Peter Zijlstra (Intel) Cc: ktkhai@parallels.com Cc: rostedt@goodmis.org Cc: juri.lelli@gmail.com Cc: pang.xunlei@linaro.org Cc: oleg@redhat.com Cc: wanpeng.li@linux.intel.com Cc: umgwanakikbuti@gmail.com Link: http://lkml.kernel.org/r/20150611124742.968262663@infradead.org Signed-off-by: Thomas Gleixner [Conflicts: kernel/sched/deadline.c] Signed-off-by: Byungchul Park [bwh: Backported to 3.16: - The check_resched / !CONFIG_SMP case in switched_to_dl() is different - Adjust context] Signed-off-by: Ben Hutchings commit 7890f43f6310e44ffaced396dd352551ab1ee195 Author: Peter Zijlstra Date: Thu Jun 11 14:46:42 2015 +0200 sched,dl: Remove return value from pull_dl_task() commit 0ea60c2054fc3b0c3eb68ac4f6884f3ee78d9925 upstream. In order to be able to use pull_dl_task() from a callback, we need to do away with the return value. Since the return value indicates if we should reschedule, do this inside the function. Since not all callers currently do this, this can increase the number of reschedules due rt balancing. Too many reschedules is not a correctness issues, too few are. Signed-off-by: Peter Zijlstra (Intel) Cc: ktkhai@parallels.com Cc: rostedt@goodmis.org Cc: juri.lelli@gmail.com Cc: pang.xunlei@linaro.org Cc: oleg@redhat.com Cc: wanpeng.li@linux.intel.com Cc: umgwanakikbuti@gmail.com Link: http://lkml.kernel.org/r/20150611124742.859398977@infradead.org Signed-off-by: Thomas Gleixner [Conflicts: kernel/sched/deadline.c] Signed-off-by: Byungchul Park [bwh: Backported to 3.16: use resched_task() instead of resched_curr()] Signed-off-by: Ben Hutchings commit 34beda1752a86f8fd3a6480b3d4b4531fef029d2 Author: Peter Zijlstra Date: Thu Jun 11 14:46:43 2015 +0200 sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks commit 9916e214998a4a363b152b637245e5c958067350 upstream. Remove the direct {push,pull} balancing operations from switched_{from,to}_rt() / prio_changed_rt() and use the balance callback queue. Again, err on the side of too many reschedules; since too few is a hard bug while too many is just annoying. Signed-off-by: Peter Zijlstra (Intel) Cc: ktkhai@parallels.com Cc: rostedt@goodmis.org Cc: juri.lelli@gmail.com Cc: pang.xunlei@linaro.org Cc: oleg@redhat.com Cc: wanpeng.li@linux.intel.com Cc: umgwanakikbuti@gmail.com Link: http://lkml.kernel.org/r/20150611124742.766832367@infradead.org Signed-off-by: Thomas Gleixner [Conflicts: kernel/sched/rt.c] Signed-off-by: Byungchul Park [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 3fc871f3a24db903be27d14c1c67525aefd02d92 Author: Peter Zijlstra Date: Thu Jun 11 14:46:40 2015 +0200 sched,rt: Remove return value from pull_rt_task() commit 8046d6806247088de5725eaf8a2580b29e50ac5a upstream. In order to be able to use pull_rt_task() from a callback, we need to do away with the return value. Since the return value indicates if we should reschedule, do this inside the function. Since not all callers currently do this, this can increase the number of reschedules due rt balancing. Too many reschedules is not a correctness issues, too few are. Signed-off-by: Peter Zijlstra (Intel) Cc: ktkhai@parallels.com Cc: rostedt@goodmis.org Cc: juri.lelli@gmail.com Cc: pang.xunlei@linaro.org Cc: oleg@redhat.com Cc: wanpeng.li@linux.intel.com Cc: umgwanakikbuti@gmail.com Link: http://lkml.kernel.org/r/20150611124742.679002000@infradead.org Signed-off-by: Thomas Gleixner [Conflicts: kernel/sched/rt.c] Signed-off-by: Byungchul Park [bwh: Backported to 3.16: use resched_task() instead of resched_curr()] Signed-off-by: Ben Hutchings commit 070654cc0f0defaf236f986014591dcc87ff9f87 Author: Peter Zijlstra Date: Thu Jun 11 14:46:39 2015 +0200 sched: Allow balance callbacks for check_class_changed() commit 4c9a4bc89a9cca8128bce67d6bc8870d6b7ee0b2 upstream. In order to remove dropping rq->lock from the switched_{to,from}()/prio_changed() sched_class methods, run the balance callbacks after it. We need to remove dropping rq->lock because its buggy, suppose using sched_setattr()/sched_setscheduler() to change a running task from FIFO to OTHER. By the time we get to switched_from_rt() the task is already enqueued on the cfs runqueues. If switched_from_rt() does pull_rt_task() and drops rq->lock, load-balancing can come in and move our task @p to another rq. The subsequent switched_to_fair() still assumes @p is on @rq and bad things will happen. By using balance callbacks we delay the load-balancing operations {rt,dl}x{push,pull} until we've done all the important work and the task is fully set up. Furthermore, the balance callbacks do not know about @p, therefore they cannot get confused like this. Reported-by: Mike Galbraith Signed-off-by: Peter Zijlstra (Intel) Cc: ktkhai@parallels.com Cc: rostedt@goodmis.org Cc: juri.lelli@gmail.com Cc: pang.xunlei@linaro.org Cc: oleg@redhat.com Cc: wanpeng.li@linux.intel.com Link: http://lkml.kernel.org/r/20150611124742.615343911@infradead.org Signed-off-by: Thomas Gleixner [Conflicts: kernel/sched/core.c] Signed-off-by: Byungchul Park Signed-off-by: Ben Hutchings commit 0589c0247b67e62208ecfbc7ceea4502e5b780cb Author: Peter Zijlstra Date: Thu Jun 11 14:46:37 2015 +0200 sched: Replace post_schedule with a balance callback list commit e3fca9e7cbfb72694a21c886fcdf9f059cfded9c upstream. Generalize the post_schedule() stuff into a balance callback list. This allows us to more easily use it outside of schedule() and cross sched_class. Signed-off-by: Peter Zijlstra (Intel) Cc: ktkhai@parallels.com Cc: rostedt@goodmis.org Cc: juri.lelli@gmail.com Cc: pang.xunlei@linaro.org Cc: oleg@redhat.com Cc: wanpeng.li@linux.intel.com Cc: umgwanakikbuti@gmail.com Link: http://lkml.kernel.org/r/20150611124742.424032725@infradead.org Signed-off-by: Thomas Gleixner [Conflicts: kernel/sched/core.c] Signed-off-by: Byungchul Park Signed-off-by: Ben Hutchings commit df929b25c8f7519a3e30eb8948d1e6e933c762d4 Author: Vineet Gupta Date: Sun May 10 12:04:01 2015 +0530 ARC: unbork !LLSC build commit daaf40e53b5dbdf75255d58a45ce8ac65ca511a8 upstream. Fixes: f7d11e93ee97a locking,arch,arc: Fold atomic_ops Signed-off-by: Vineet Gupta Signed-off-by: Ben Hutchings Cc: Guenter Roeck commit d02167c499d03de2c94a38a565ca106dbeb423ff Author: Will Deacon Date: Wed Feb 25 12:10:35 2015 +0000 arm64: psci: move psci firmware calls out of line commit f5e0a12ca2d939e47995f73428d9bf1ad372b289 upstream. An arm64 allmodconfig fails to build with GCC 5 due to __asmeq assertions in the PSCI firmware calling code firing due to mcount preambles breaking our assumptions about register allocation of function arguments: /tmp/ccDqJsJ6.s: Assembler messages: /tmp/ccDqJsJ6.s:60: Error: .err encountered /tmp/ccDqJsJ6.s:61: Error: .err encountered /tmp/ccDqJsJ6.s:62: Error: .err encountered /tmp/ccDqJsJ6.s:99: Error: .err encountered /tmp/ccDqJsJ6.s:100: Error: .err encountered /tmp/ccDqJsJ6.s:101: Error: .err encountered This patch fixes the issue by moving the PSCI calls out-of-line into their own assembly files, which are safe from the compiler's meddling fingers. Reported-by: Andy Whitcroft Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings Cc: Guenter Roeck commit dbb9e9ff783267fd6552b0f2729f78fe76f835ae Author: Konstantin Khlebnikov Date: Wed Oct 29 14:51:02 2014 -0700 mm/balloon_compaction: fix deflation when compaction is disabled commit 4d88e6f7d5ffc84e6094a47925870f4a130555c2 upstream. If CONFIG_BALLOON_COMPACTION=n balloon_page_insert() does not link pages with balloon and doesn't set PagePrivate flag, as a result balloon_page_dequeue() cannot get any pages because it thinks that all of them are isolated. Without balloon compaction nobody can isolate ballooned pages. It's safe to remove this check. Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management"). Signed-off-by: Konstantin Khlebnikov Reported-by: Matt Mullins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings Cc: Jiri Kosina Cc: jian wang commit 514488e2bdbb11da02735f1b864adcfdd7bae0da Author: Konstantin Khlebnikov Date: Thu Oct 9 15:29:27 2014 -0700 mm/balloon_compaction: redesign ballooned pages management commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 upstream. Sasha Levin reported KASAN splash inside isolate_migratepages_range(). Problem is in the function __is_movable_balloon_page() which tests AS_BALLOON_MAP in page->mapping->flags. This function has no protection against anonymous pages. As result it tried to check address space flags inside struct anon_vma. Further investigation shows more problems in current implementation: * Special branch in __unmap_and_move() never works: balloon_page_movable() checks page flags and page_count. In __unmap_and_move() page is locked, reference counter is elevated, thus balloon_page_movable() always fails. As a result execution goes to the normal migration path. virtballoon_migratepage() returns MIGRATEPAGE_BALLOON_SUCCESS instead of MIGRATEPAGE_SUCCESS, move_to_new_page() thinks this is an error code and assigns newpage->mapping to NULL. Newly migrated page lose connectivity with balloon an all ability for further migration. * lru_lock erroneously required in isolate_migratepages_range() for isolation ballooned page. This function releases lru_lock periodically, this makes migration mostly impossible for some pages. * balloon_page_dequeue have a tight race with balloon_page_isolate: balloon_page_isolate could be executed in parallel with dequeue between picking page from list and locking page_lock. Race is rare because they use trylock_page() for locking. This patch fixes all of them. Instead of fake mapping with special flag this patch uses special state of page->_mapcount: PAGE_BALLOON_MAPCOUNT_VALUE = -256. Buddy allocator uses PAGE_BUDDY_MAPCOUNT_VALUE = -128 for similar purpose. Storing mark directly in struct page makes everything safer and easier. PagePrivate is used to mark pages present in page list (i.e. not isolated, like PageLRU for normal pages). It replaces special rules for reference counter and makes balloon migration similar to migration of normal pages. This flag is protected by page_lock together with link to the balloon device. Signed-off-by: Konstantin Khlebnikov Reported-by: Sasha Levin Link: http://lkml.kernel.org/p/53E6CEAA.9020105@oracle.com Cc: Rafael Aquini Cc: Andrey Ryabinin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: - Remove an additional check for MIGRATEPAGE_BALLOON_SUCCESS in __unmap_and_move() - Adjust context] Signed-off-by: Ben Hutchings Cc: Jiri Kosina Cc: jian wang commit d0c534747e0d4fd2fb1fcf0a685aeded8b0f6c47 Author: Lorenzo Pieralisi Date: Wed Jan 13 14:50:03 2016 +0000 arm64: kernel: fix architected PMU registers unconditional access commit f436b2ac90a095746beb6729b8ee8ed87c9eaede upstream. The Performance Monitors extension is an optional feature of the AArch64 architecture, therefore, in order to access Performance Monitors registers safely, the kernel should detect the architected PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field before accessing them. This patch implements a guard by reading the ID_AA64DFR0_EL1 register PMUVer field to detect the architected PMU presence and prevent accessing PMU system registers if the Performance Monitors extension is not implemented in the core. Cc: Peter Maydell Cc: Mark Rutland Fixes: 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore") Signed-off-by: Lorenzo Pieralisi Reported-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: Will Deacon Signed-off-by: Ben Hutchings commit 66a315418f82f9d97f4233cd71e3b54105ffefd1 Author: Kangjie Lu Date: Sun May 8 12:10:14 2016 -0400 net: fix a kernel infoleak in x25 module commit 79e48650320e6fba48369fccf13fd045315b19b8 upstream. Stack object "dte_facilities" is allocated in x25_rx_call_request(), which is supposed to be initialized in x25_negotiate_facilities. However, 5 fields (8 bytes in total) are not initialized. This object is then copied to userland via copy_to_user, thus infoleak occurs. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 935f8a3274efedc93d5e6c8183915ac4fad81924 Author: Kangjie Lu Date: Tue May 3 16:46:24 2016 -0400 net: fix infoleak in rtnetlink commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 upstream. The stack object “map” has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via “nla_put”. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit c922f1c07ac330685d6603c619239bdb645d7bdd Author: Kangjie Lu Date: Tue May 3 16:35:05 2016 -0400 net: fix infoleak in llc commit b8670c09f37bdf2847cc44f36511a53afc6161fd upstream. The stack object “info” has a total size of 12 bytes. Its last byte is padding which is not initialized and leaked via “put_cmsg”. Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 77f7f67dbd37ab3eebd98e2764bd1e0900028a33 Author: Hugh Dickins Date: Thu Nov 5 18:50:05 2015 -0800 mm: migrate dirty page without clear_page_dirty_for_io etc commit 42cb14b110a5698ccf26ce59c4441722605a3743 upstream. clear_page_dirty_for_io() has accumulated writeback and memcg subtleties since v2.6.16 first introduced page migration; and the set_page_dirty() which completed its migration of PageDirty, later had to be moderated to __set_page_dirty_nobuffers(); then PageSwapBacked had to skip that too. No actual problems seen with this procedure recently, but if you look into what the clear_page_dirty_for_io(page)+set_page_dirty(newpage) is actually achieving, it turns out to be nothing more than moving the PageDirty flag, and its NR_FILE_DIRTY stat from one zone to another. It would be good to avoid a pile of irrelevant decrementations and incrementations, and improper event counting, and unnecessary descent of the radix_tree under tree_lock (to set the PAGECACHE_TAG_DIRTY which radix_tree_replace_slot() left in place anyway). Do the NR_FILE_DIRTY movement, like the other stats movements, while interrupts still disabled in migrate_page_move_mapping(); and don't even bother if the zone is the same. Do the PageDirty movement there under tree_lock too, where old page is frozen and newpage not yet visible: bearing in mind that as soon as newpage becomes visible in radix_tree, an un-page-locked set_page_dirty() might interfere (or perhaps that's just not possible: anything doing so should already hold an additional reference to the old page, preventing its migration; but play safe). But we do still need to transfer PageDirty in migrate_page_copy(), for those who don't go the mapping route through migrate_page_move_mapping(). Signed-off-by: Hugh Dickins Cc: Christoph Lameter Cc: "Kirill A. Shutemov" Cc: Rik van Riel Cc: Vlastimil Babka Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Sasha Levin Cc: Dmitry Vyukov Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context. This is not just an optimisation, but turned out to fix a possible oops (CVE-2016-3070).] Signed-off-by: Ben Hutchings commit af00ae6ef5a2c73f21ba215c476570b7772a14fb Author: David Howells Date: Tue Feb 23 11:03:12 2016 +0000 KEYS: Fix ASN.1 indefinite length object parsing commit 23c8a812dc3c621009e4f0e5342aa4e2ede1ceaa upstream. This fixes CVE-2016-0758. In the ASN.1 decoder, when the length field of an ASN.1 value is extracted, it isn't validated against the remaining amount of data before being added to the cursor. With a sufficiently large size indicated, the check: datalen - dp < 2 may then fail due to integer overflow. Fix this by checking the length indicated against the amount of remaining data in both places a definite length is determined. Whilst we're at it, make the following changes: (1) Check the maximum size of extended length does not exceed the capacity of the variable it's being stored in (len) rather than the type that variable is assumed to be (size_t). (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the integer 0. (3) To reduce confusion, move the initialisation of len outside of: for (len = 0; n > 0; n--) { since it doesn't have anything to do with the loop counter n. Signed-off-by: David Howells Reviewed-by: Mimi Zohar Acked-by: David Woodhouse Acked-by: Peter Jones Signed-off-by: Ben Hutchings commit e6482139083f44e7f09601ae27dda1a37f4bf9e2 Author: Joe Perches Date: Thu Jun 25 15:01:02 2015 -0700 compiler-gcc: integrate the various compiler-gcc[345].h files commit cb984d101b30eb7478d32df56a0023e4603cba7f upstream. As gcc major version numbers are going to advance rather rapidly in the future, there's no real value in separate files for each compiler version. Deduplicate some of the macros #defined in each file too. Neaten comments using normal kernel commenting style. Signed-off-by: Joe Perches Cc: Andi Kleen Cc: Michal Marek Cc: Segher Boessenkool Cc: Sasha Levin Cc: Anton Blanchard Cc: Alan Modra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [ philm: backport to 3.16-stable ] Signed-off-by: Philip Müller Signed-off-by: Ben Hutchings commit a80de2c9dd4c7c129813f9c70853bf97c0372ea0 Author: Dave Chinner Date: Thu Jun 4 09:18:18 2015 +1000 xfs: mmap lock needs to be inside freeze protection commit ec56b1f1fdc69599963574ce94cc5693d535dd64 upstream. Lock ordering for the new mmap lock needs to be: mmap_sem sb_start_pagefault i_mmap_lock page lock Right now xfs_vm_page_mkwrite gets this the wrong way around, While technically it cannot deadlock due to the current freeze ordering, it's still a landmine that might explode if we change anything in future. Hence we need to nest the locks correctly. Signed-off-by: Dave Chinner Reviewed-by: Jan Kara Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Ben Hutchings Cc: Jan Kara Cc: xfs@oss.sgi.com commit 7cafecfabbd7119ca94bd5583411ff245bcbbaec Author: Dave Chinner Date: Mon Feb 23 21:47:29 2015 +1100 xfs: lock out page faults from extent swap operations commit 723cac48473358939759885a18e8df113ea96138 upstream. Extent swap operations are another extent manipulation operation that we need to ensure does not race against mmap page faults. The current code returns if the file is mapped prior to the swap being done, but it could potentially race against new page faults while the swap is in progress. Hence we should use the XFS_MMAPLOCK_EXCL for this operation, too. While there, fix the error path handling that can result in double unlocks of the inodes when cancelling the swapext transaction. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner [bwh: Backported to 3.16: - The obsoleted check for mmap'd files was directly in xfs_swap_extents() and used VN_MAPPED - Adjust context] Signed-off-by: Ben Hutchings commit 9949c4cad4dd3fbb36e68d84116f58c007571c04 Author: Dave Chinner Date: Mon Feb 23 21:46:58 2015 +1100 xfs: xfs_setattr_size no longer races with page faults commit 0f9160b444e4de33b65dfcd3b901358a3129461a upstream. Now that truncate locks out new page faults, we no longer need to do special writeback hacks in truncate to work around potential races between page faults, page cache truncation and file size updates to ensure we get write page faults for extending truncates on sub-page block size filesystems. Hence we can remove the code in xfs_setattr_size() that handles this and update the comments around the code tha thandles page cache truncate and size updates to reflect the new reality. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner [bwh: Backported to 3.16: we never had the previous hack, so just update the comment] Signed-off-by: Ben Hutchings commit 1c2ed3952e66315720f5753fe57465d9426ef332 Author: Dave Chinner Date: Mon Feb 23 21:45:32 2015 +1100 xfs: take i_mmap_lock on extent manipulation operations commit e8e9ad42c1f1e1bfbe0e8c32c8cac02e9ebfb7ef upstream. Now we have the i_mmap_lock being held across the page fault IO path, we now add extent manipulation operation exclusion by adding the lock to the paths that directly modify extent maps. This includes truncate, hole punching and other fallocate based operations. The operations will now take both the i_iolock and the i_mmaplock in exclusive mode, thereby ensuring that all IO and page faults block without holding any page locks while the extent manipulation is in progress. This gives us the lock order during truncate of i_iolock -> i_mmaplock -> page_lock -> i_lock, hence providing the same lock order as the iolock provides the normal IO path without involving the mmap_sem. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner [bwh: Backported to 3.16: - We never need to break layouts, so take both i_iolock and i_mmaplock at the same time - Adjust context] Signed-off-by: Ben Hutchings Cc: Jan Kara Cc: xfs@oss.sgi.com commit fc5321c3570a2854c74180922ef5549517201699 Author: Dave Chinner Date: Mon Feb 23 21:44:54 2015 +1100 xfs: use i_mmaplock on write faults commit 075a924d45cc69c75a35f20b4912b85aa98b180a upstream. Take the i_mmaplock over write page faults. These come through the ->page_mkwrite callout, so we need to wrap that calls with the i_mmaplock. This gives us a lock order of mmap_sem -> i_mmaplock -> page_lock -> i_lock. Also, move the page_mkwrite wrapper to the same region of xfs_file.c as the read fault wrappers and add a tracepoint. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings Cc: Jan Kara Cc: xfs@oss.sgi.com commit b248005489f8007dcd65a8159a03ed471f8eccd7 Author: Dave Chinner Date: Mon Feb 23 21:44:19 2015 +1100 xfs: use i_mmaplock on read faults commit de0e8c20ba3a65b0f15040aabbefdc1999876e6b upstream. Take the i_mmaplock over read page faults. These come through the ->fault callout, so we need to wrap the generic implementation with the i_mmaplock. While there, add tracepoints for the read fault as it passes through XFS. This gives us a lock order of mmap_sem -> i_mmaplock -> page_lock -> i_lock. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Ben Hutchings Cc: Jan Kara Cc: xfs@oss.sgi.com commit e34915e9a957d6e33a5b4df04d5131c1c0622acb Author: Dave Chinner Date: Mon Feb 23 21:43:37 2015 +1100 xfs: introduce mmap/truncate lock commit 653c60b633a9019a54a80d64b5ed33ecb214823c upstream. Right now we cannot serialise mmap against truncate or hole punch sanely. ->page_mkwrite is not able to take locks that the read IO path normally takes (i.e. the inode iolock) because that could result in lock inversions (read - iolock - page fault - page_mkwrite - iolock) and so we cannot use an IO path lock to serialise page write faults against truncate operations. Instead, introduce a new lock that is used *only* in the ->page_mkwrite path that is the equivalent of the iolock. The lock ordering in a page fault is i_mmaplock -> page lock -> i_ilock, and so in truncate we can i_iolock -> i_mmaplock and so lock out new write faults during the process of truncation. Because i_mmap_lock is outside the page lock, we can hold it across all the same operations we hold the i_iolock for. The only difference is that we never hold the i_mmaplock in the normal IO path and so do not ever have the possibility that we can page fault inside it. Hence there are no recursion issues on the i_mmap_lock and so we can use it to serialise page fault IO against inode modification operations that affect the IO path. This patch introduces the i_mmaplock infrastructure, lockdep annotations and initialisation/destruction code. Use of the new lock will be in subsequent patches. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Ben Hutchings Cc: Jan Kara Cc: xfs@oss.sgi.com commit 9c457aeadcd3379f06da88647e294cfb5f3ec1da Author: Dave Chinner Date: Mon Aug 4 13:29:32 2014 +1000 xfs: fix swapext ilock deadlock commit 812176832169c77b4bacddd01edc3e55340263fd upstream. xfs_swap_extents() holds the ilock over a call to filemap_write_and_wait(), which can then try to write data and take the ilock. That causes a self-deadlock. Fix the deadlock and clean up the code by separating the locking appropriately. Add a lockflags variable to track what locks we are holding as we gain and drop them and cleanup the error handling to always use "out_unlock" with the lockflags variable. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Ben Hutchings commit 11e2f8dc61c5efca6eb37dfb40ede38c35c0d5be Author: Linus Torvalds Date: Sat May 14 11:11:44 2016 -0700 nf_conntrack: avoid kernel pointer value leak in slab name commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 upstream. The slab name ends up being visible in the directory structure under /sys, and even if you don't have access rights to the file you can see the filenames. Just use a 64-bit counter instead of the pointer to the 'net' structure to generate a unique name. This code will go away in 4.7 when the conntrack code moves to a single kmemcache, but this is the backportable simple solution to avoiding leaking kernel pointers to user space. Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep") Signed-off-by: Linus Torvalds Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 43f7ff720e239759b9c73a8c5368ef30fd78a3c1 Author: Junxiao Bi Date: Thu May 12 15:42:18 2016 -0700 ocfs2: fix posix_acl_create deadlock commit c25a1e0671fbca7b2c0d0757d533bd2650d6dc0c upstream. Commit 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure") refactored code to use posix_acl_create. The problem with this function is that it is not mindful of the cluster wide inode lock making it unsuitable for use with ocfs2 inode creation with ACLs. For example, when used in ocfs2_mknod, this function can cause deadlock as follows. The parent dir inode lock is taken when calling posix_acl_create -> get_acl -> ocfs2_iop_get_acl which takes the inode lock again. This can cause deadlock if there is a blocked remote lock request waiting for the lock to be downconverted. And same deadlock happened in ocfs2_reflink. This fix is to revert back using ocfs2_init_acl. Fixes: 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure") Signed-off-by: Tariq Saeed Signed-off-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 26f872d163a7a9135978146ed401bfb2bd1f762f Author: Dan Carpenter Date: Tue Apr 14 15:43:19 2015 -0700 ocfs2: dereferencing freed pointers in ocfs2_reflink() commit e073fc58dfe6a4c9b614320c1d56bb71cb213ec4 upstream. The code at the "out" label assumes that "default_acl" and "acl" are NULL, but actually the pointers can be NULL, unitialized, or freed. Signed-off-by: Dan Carpenter Reviewed-by: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e46e5c256cc4a770c16013af216a231c63becdfa Author: Steven Rostedt Date: Wed May 11 15:09:36 2016 -0400 tools lib traceevent: Do not reassign parg after collapse_tree() commit 106b816cb46ebd87408b4ed99a2e16203114daa6 upstream. At the end of process_filter(), collapse_tree() was changed to update the parg parameter, but the reassignment after the call wasn't removed. What happens is that the "current_op" gets modified and freed and parg is assigned to the new allocated argument. But after the call to collapse_tree(), parg is assigned again to the just freed "current_op", and this causes the tool to crash. The current_op variable must also be assigned to NULL in case of error, otherwise it will cause it to be free()ed twice. Signed-off-by: Steven Rostedt Acked-by: Namhyung Kim Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()") Link: http://lkml.kernel.org/r/20160511150936.678c18a1@gandalf.local.home Signed-off-by: Arnaldo Carvalho de Melo [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 261d48a9cc431d0a36eb954929cd9a869f53ddc5 Author: Yura Pakhuchiy Date: Sat May 7 23:53:36 2016 +0700 ALSA: hda - Fix subwoofer pin on ASUS N751 and N551 commit 3231e2053eaeee70bdfb216a78a30f11e88e2243 upstream. Subwoofer does not work out of the box on ASUS N751/N551 laptops. This patch fixes it. Patch tested on N751 laptop. N551 part is not tested, but according to [1] and [2] this laptop requires similar changes, so I included them in the patch. 1. https://github.com/honsiorovskyi/asus-n551-hda-fix 2. https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/1405691 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117781 Signed-off-by: Yura Pakhuchiy Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 873af5d88842c7aecb7c5ae1ea8541cf8b59f2e3 Author: Daniel Vetter Date: Tue May 3 10:33:01 2016 +0200 drm/i915: Bail out of pipe config compute loop on LPT commit 2700818ac9f935d8590715eecd7e8cadbca552b6 upstream. LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this. Cc: Chris Wilson Cc: Maarten Lankhorst References: https://bugs.freedesktop.org/show_bug.cgi?id=93477 Signed-off-by: Daniel Vetter Tested-by: Chris Wilson Signed-off-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch (cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f) Signed-off-by: Jani Nikula Signed-off-by: Ben Hutchings commit f62d33f1f799b9bf0bfaae6303c5be237ebf8d84 Author: Kaho Ng Date: Mon May 9 00:27:49 2016 +0800 ALSA: hda - Fix white noise on Asus UX501VW headset commit 2da2dc9ead232f25601404335cca13c0f722d41b upstream. For reducing the noise from the headset output on ASUS UX501VW, call the existing fixup, alc_fixup_headset_mode_alc668(), additionally. Thread: https://bbs.archlinux.org/viewtopic.php?id=209554 Signed-off-by: Kaho Ng Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 9b534eea9820cb5b3e444ec72ed7ad410508f5c0 Author: Eric Dumazet Date: Fri May 6 05:58:21 2016 -0700 macvtap: segmented packet is consumed commit be0bd3160165e42783d8215f426e41c07179c08a upstream. If GSO packet is segmented and its segments are properly queued, we call consume_skb() instead of kfree_skb() to be drop monitor friendly. Fixes: 3e4f8b7873709 ("macvtap: Perform GSO on forwarding path.") Signed-off-by: Eric Dumazet Cc: Vlad Yasevich Reviewed-by: Shmulik Ladkani Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 122352cc76bf0018b094a3051ca47f3d63cf5668 Author: Al Viro Date: Thu May 5 16:25:35 2016 -0400 get_rock_ridge_filename(): handle malformed NM entries commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream. Payloads of NM entries are not supposed to contain NUL. When we run into such, only the part prior to the first NUL goes into the concatenation (i.e. the directory entry name being encoded by a bunch of NM entries). We do stop when the amount collected so far + the claimed amount in the current NM entry exceed 254. So far, so good, but what we return as the total length is the sum of *claimed* sizes, not the actual amount collected. And that can grow pretty large - not unlimited, since you'd need to put CE entries in between to be able to get more than the maximum that could be contained in one isofs directory entry / continuation chunk and we are stop once we'd encountered 32 CEs, but you can get about 8Kb easily. And that's what will be passed to readdir callback as the name length. 8Kb __copy_to_user() from a buffer allocated by __get_free_page() Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit b1a2e529e9b98b800ad54c1f846ea0e0dbc36adf Author: Dmitry V. Levin Date: Wed Apr 27 04:56:11 2016 +0300 parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls commit f0b22d1bb2a37a665a969e95785c75a4f49d1499 upstream. Do not load one entry beyond the end of the syscall table when the syscall number of a traced process equals to __NR_Linux_syscalls. Similar bug with regular processes was fixed by commit 3bb457af4fa8 ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls"). This bug was found by strace test suite. Signed-off-by: Dmitry V. Levin Acked-by: Helge Deller Signed-off-by: Helge Deller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a45fa868e0738049b1265cd4238ea744944da87e Author: Chen Yu Date: Fri May 6 11:33:39 2016 +0800 x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO commit 886123fb3a8656699dff40afa0573df359abeb18 upstream. Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f; Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM (35.5), the ratio bits are bit 8-15. Ignoring the upper bits can result in an incorrect tsc ratio, which causes the TSC calibration and the Local APIC timer frequency to be incorrect. Fix this problem by masking 0xff instead. [ tglx: Massaged changelog ] Fixes: 7da7c1561366 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs" Signed-off-by: Chen Yu Cc: "Rafael J. Wysocki" Cc: Bin Gao Cc: Len Brown Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Ben Hutchings commit eee69c92529e82e48e088f21137220c516c4b8ed Author: Mathias Krause Date: Thu May 5 16:22:26 2016 -0700 proc: prevent accessing /proc//environ until it's ready commit 8148a73c9901a8794a50f950083c00ccf97d43b3 upstream. If /proc//environ gets read before the envp[] array is fully set up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to read more bytes than are actually written, as env_start will already be set but env_end will still be zero, making the range calculation underflow, allowing to read beyond the end of what has been written. Fix this as it is done for /proc//cmdline by testing env_end for zero. It is, apparently, intentionally set last in create_*_tables(). This bug was found by the PaX size_overflow plugin that detected the arithmetic underflow of 'this_len = env_end - (env_start + src)' when env_end is still zero. The expected consequence is that userland trying to access /proc//environ of a not yet fully set up process may get inconsistent data as we're in the middle of copying in the environment variables. Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363 Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461 Signed-off-by: Mathias Krause Cc: Emese Revfy Cc: Pax Team Cc: Al Viro Cc: Mateusz Guzik Cc: Alexey Dobriyan Cc: Cyrill Gorcunov Cc: Jarod Wilson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit a9098f8e8a9736db4587e38c926ffae29fddaf17 Author: Lucas Stach Date: Thu May 5 10:16:44 2016 -0400 drm/radeon: fix PLL sharing on DCE6.1 (v2) commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 upstream. On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not be taken into consideration when looking for an already enabled PLL to be shared with other outputs. This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland based laptop, where the internal display is connected to UNIPHYA through a TRAVIS DP->LVDS bridge. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78987 v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop extra parameter. Signed-off-by: Lucas Stach Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 816d889b22613b946de7ab6458d7c7cc250fcdca Author: Eric W. Biederman Date: Thu May 5 09:29:29 2016 -0500 propogate_mnt: Handle the first propogated copy being a slave commit 5ec0811d30378ae104f250bfc9b3640242d81e3f upstream. When the first propgated copy was a slave the following oops would result: > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 > IP: [] propagate_one+0xbe/0x1c0 > PGD bacd4067 PUD bac66067 PMD 0 > Oops: 0000 [#1] SMP > Modules linked in: > CPU: 1 PID: 824 Comm: mount Not tainted 4.6.0-rc5userns+ #1523 > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 > task: ffff8800bb0a8000 ti: ffff8800bac3c000 task.ti: ffff8800bac3c000 > RIP: 0010:[] [] propagate_one+0xbe/0x1c0 > RSP: 0018:ffff8800bac3fd38 EFLAGS: 00010283 > RAX: 0000000000000000 RBX: ffff8800bb77ec00 RCX: 0000000000000010 > RDX: 0000000000000000 RSI: ffff8800bb58c000 RDI: ffff8800bb58c480 > RBP: ffff8800bac3fd48 R08: 0000000000000001 R09: 0000000000000000 > R10: 0000000000001ca1 R11: 0000000000001c9d R12: 0000000000000000 > R13: ffff8800ba713800 R14: ffff8800bac3fda0 R15: ffff8800bb77ec00 > FS: 00007f3c0cd9b7e0(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000010 CR3: 00000000bb79d000 CR4: 00000000000006e0 > Stack: > ffff8800bb77ec00 0000000000000000 ffff8800bac3fd88 ffffffff811fbf85 > ffff8800bac3fd98 ffff8800bb77f080 ffff8800ba713800 ffff8800bb262b40 > 0000000000000000 0000000000000000 ffff8800bac3fdd8 ffffffff811f1da0 > Call Trace: > [] propagate_mnt+0x105/0x140 > [] attach_recursive_mnt+0x120/0x1e0 > [] graft_tree+0x63/0x70 > [] do_add_mount+0x9b/0x100 > [] do_mount+0x2aa/0xdf0 > [] ? strndup_user+0x4e/0x70 > [] SyS_mount+0x75/0xc0 > [] do_syscall_64+0x4b/0xa0 > [] entry_SYSCALL64_slow_path+0x25/0x25 > Code: 00 00 75 ec 48 89 0d 02 22 22 01 8b 89 10 01 00 00 48 89 05 fd 21 22 01 39 8e 10 01 00 00 0f 84 e0 00 00 00 48 8b 80 d8 00 00 00 <48> 8b 50 10 48 89 05 df 21 22 01 48 89 15 d0 21 22 01 8b 53 30 > RIP [] propagate_one+0xbe/0x1c0 > RSP > CR2: 0000000000000010 > ---[ end trace 2725ecd95164f217 ]--- This oops happens with the namespace_sem held and can be triggered by non-root users. An all around not pleasant experience. To avoid this scenario when finding the appropriate source mount to copy stop the walk up the mnt_master chain when the first source mount is encountered. Further rewrite the walk up the last_source mnt_master chain so that it is clear what is going on. The reason why the first source mount is special is that it it's mnt_parent is not a mount in the dest_mnt propagation tree, and as such termination conditions based up on the dest_mnt mount propgation tree do not make sense. To avoid other kinds of confusion last_dest is not changed when computing last_source. last_dest is only used once in propagate_one and that is above the point of the code being modified, so changing the global variable is meaningless and confusing. fixes: f2ebb3a921c1ca1e2ddd9242e95a1989a50c4c68 ("smarter propagate_mnt()") Reported-by: Tycho Andersen Reviewed-by: Seth Forshee Tested-by: Seth Forshee Signed-off-by: "Eric W. Biederman" Signed-off-by: Ben Hutchings commit f4e8208ded69610c574d8de9f3cf8d6986457c21 Author: Maxim Patlasov Date: Tue Feb 16 11:45:33 2016 -0800 fs/pnode.c: treat zero mnt_group_id-s as unequal commit 7ae8fd0351f912b075149a1e03a017be8b903b9a upstream. propagate_one(m) calculates "type" argument for copy_tree() like this: > if (m->mnt_group_id == last_dest->mnt_group_id) { > type = CL_MAKE_SHARED; > } else { > type = CL_SLAVE; > if (IS_MNT_SHARED(m)) > type |= CL_MAKE_SHARED; > } The "type" argument then governs clone_mnt() behavior with respect to flags and mnt_master of new mount. When we iterate through a slave group, it is possible that both current "m" and "last_dest" are not shared (although, both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison above erroneously makes new mount shared and sets its mnt_master to last_source->mnt_master. The patch fixes the problem by handling zero mnt_group_id-s as though they are unequal. The similar problem exists in the implementation of "else" clause above when we have to ascend upward in the master/slave tree by calling: > last_source = last_source->mnt_master; > last_dest = last_source->mnt_parent; proper number of times. The last step is governed by "n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if both are zero. The patch fixes this case in the same way as the former one. [AV: don't open-code an obvious helper...] Signed-off-by: Maxim Patlasov Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit c5948e3b269a134bb67ac0cf922b9524d9cdaa53 Author: Wang YanQing Date: Thu May 5 14:14:21 2016 +0100 x86/sysfb_efi: Fix valid BAR address range check commit c10fcb14c7afd6688c7b197a814358fecf244222 upstream. The code for checking whether a BAR address range is valid will break out of the loop when a start address of 0x0 is encountered. This behaviour is wrong since by breaking out of the loop we may miss the BAR that describes the EFI frame buffer in a later iteration. Because of this bug I can't use video=efifb: boot parameter to get efifb on my new ThinkPad E550 for my old linux system hard disk with 3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not supporting the GPU. This patch also add a trivial optimization to break out after we find the frame buffer address range without testing later BARs. Signed-off-by: Wang YanQing [ Rewrote changelog. ] Signed-off-by: Matt Fleming Reviewed-by: Peter Jones Cc: Ard Biesheuvel Cc: David Herrmann Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tomi Valkeinen Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit b986834b2c37dbb9340adc8527734d9ec81e045e Author: Herbert Xu Date: Wed May 4 17:52:56 2016 +0800 crypto: hash - Fix page length clamping in hash walk commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 upstream. The crypto hash walk code is broken when supplied with an offset greater than or equal to PAGE_SIZE. This patch fixes it by adjusting walk->pg and walk->offset when this happens. Reported-by: Steffen Klassert Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit eee71883e448e3546abf8a3dd88d692095a85150 Author: Prarit Bhargava Date: Wed May 4 13:48:56 2016 +0800 ACPICA: Dispatcher: Update thread ID for recursive method calls commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da upstream. ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25 Set the mutex owner thread ID. Original patch from: Prarit Bhargava Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121 Link: https://github.com/acpica/acpica/commit/7a3bd2d9 Signed-off-by: Prarit Bhargava Tested-by: Andy Lutomirski # On a Dell XPS 13 9350 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 9d639520393a94080ec441bcc17555dc3c72a391 Author: Matt Fleming Date: Tue May 3 20:29:39 2016 +0100 MAINTAINERS: Remove asterisk from EFI directory names commit e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 upstream. Mark reported that having asterisks on the end of directory names confuses get_maintainer.pl when it encounters subdirectories, and that my name does not appear when run on drivers/firmware/efi/libstub. Reported-by: Mark Rutland Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1462303781-8686-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 8ad468c4cc4b1014604b9f8a440610aea53ba544 Author: Alex Deucher Date: Mon May 2 18:53:27 2016 -0400 drm/radeon: make sure vertical front porch is at least 1 commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b upstream. hw doesn't like a 0 value. Signed-off-by: Alex Deucher [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 543320c210c85697272ed34d8e1b2b910521d26e Author: Chunyu Hu Date: Tue May 3 19:34:34 2016 +0800 tracing: Don't display trigger file for events that can't be enabled commit 854145e0a8e9a05f7366d240e2f99d9c1ca6d6dd upstream. Currently register functions for events will be called through the 'reg' field of event class directly without any check when seting up triggers. Triggers for events that don't support register through debug fs (events under events/ftrace are for trace-cmd to read event format, and most of them don't have a register function except events/ftrace/functionx) can't be enabled at all, and an oops will be hit when setting up trigger for those events, so just not creating them is an easy way to avoid the oops. Link: http://lkml.kernel.org/r/1462275274-3911-1-git-send-email-chuhu@redhat.com Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework") Signed-off-by: Chunyu Hu Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit 475d831dbd86b89657c3a9d93b9a8e9912ce6d7e Author: Linus Torvalds Date: Mon May 2 12:46:42 2016 -0700 Minimal fix-up of bad hashing behavior of hash_64() commit 689de1d6ca95b3b5bd8ee446863bf81a4883ea25 upstream. This is a fairly minimal fixup to the horribly bad behavior of hash_64() with certain input patterns. In particular, because the multiplicative value used for the 64-bit hash was intentionally bit-sparse (so that the multiply could be done with shifts and adds on architectures without hardware multipliers), some bits did not get spread out very much. In particular, certain fairly common bit ranges in the input (roughly bits 12-20: commonly with the most information in them when you hash things like byte offsets in files or memory that have block factors that mean that the low bits are often zero) would not necessarily show up much in the result. There's a bigger patch-series brewing to fix up things more completely, but this is the fairly minimal fix for the 64-bit hashing problem. It simply picks a much better constant multiplier, spreading the bits out a lot better. NOTE! For 32-bit architectures, the bad old hash_64() remains the same for now, since 64-bit multiplies are expensive. The bigger hashing cleanup will replace the 32-bit case with something better. The new constants were picked by George Spelvin who wrote that bigger cleanup series. I just picked out the constants and part of the comment from that series. Cc: George Spelvin Cc: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 4fc1eb4fbcb1314f28ef4af284e78e3cd0b5dca5 Author: Linus Torvalds Date: Sat Sep 13 11:24:03 2014 -0700 Make hash_64() use a 64-bit multiply when appropriate commit 23d0db76ffa13ffb95229946e4648568c3c29db5 upstream. The hash_64() function historically does the multiply by the GOLDEN_RATIO_PRIME_64 number with explicit shifts and adds, because unlike the 32-bit case, gcc seems unable to turn the constant multiply into the more appropriate shift and adds when required. However, that means that we generate those shifts and adds even when the architecture has a fast multiplier, and could just do it better in hardware. Use the now-cleaned-up CONFIG_ARCH_HAS_FAST_MULTIPLIER (together with "is it a 64-bit architecture") to decide whether to use an integer multiply or the explicit sequence of shift/add instructions. Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings [bwh: This has no immediate effect in 3.16 because nothing defines CONFIG_ARCH_HAS_FAST_MULTIPLIER. However the following fix removes that condition.] commit 17cabcb4ab60c2bb30fce5ae8f94fd9d3755bbf8 Author: Anton Blanchard Date: Sat Apr 30 08:29:27 2016 +1000 powerpc: Fix bad inline asm constraint in create_zero_mask() commit b4c112114aab9aff5ed4568ca5e662bb02cdfe74 upstream. In create_zero_mask() we have: addi %1,%2,-1 andc %1,%1,%2 popcntd %0,%1 using the "r" constraint for %2. r0 is a valid register in the "r" set, but addi X,r0,X turns it into an li: li r7,-1 andc r7,r7,r0 popcntd r4,r7 Fix this by using the "b" constraint, for which r0 is not a valid register. This was found with a kernel build using gcc trunk, narrowed down to when -frename-registers was enabled at -O2. It is just luck however that we aren't seeing this on older toolchains. Thanks to Segher for working with me to find this issue. Fixes: d0cebfa650a0 ("powerpc: word-at-a-time optimization for 64-bit Little Endian") Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: same issue exists with a different variable in find_zero()] Signed-off-by: Ben Hutchings commit dfc39542206c060e008f36060f13ea29a8e2783b Author: K. Y. Srinivasan Date: Sat Apr 2 16:17:38 2016 -0700 Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read() commit 1db488d12894f1936360779d6ab2aede3dd7f06a upstream. On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signaling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signaling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signaling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko for pointing out this issue. Also, issue a full memory barrier before making the signaling descision to correctly deal with potential reordering of the write (read index) followed by the read of pending_sz. Signed-off-by: K. Y. Srinivasan Tested-by: Dexuan Cui Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c84f51d79ae6ce03ad37966819a0b128cbf8649d Author: Christopher Oo Date: Wed Aug 5 00:52:40 2015 -0700 Drivers: hv_vmbus: Fix signal to host condition commit a5cca686ce0ef4909deaee4ed46dd991e3a9ece4 upstream. Fixes a bug where previously hv_ringbuffer_read would pass in the old number of bytes available to read instead of the expected old read index when calculating when to signal to the host that the ringbuffer is empty. Since the previous write size is already saved, also changes the hv_need_to_signal_on_read to use the previously read value rather than recalculating it. Signed-off-by: Christopher Oo Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 6f8d26fded55fd29df8008b61ec4195f1009b9b3 Author: Al Viro Date: Wed Apr 27 01:11:55 2016 -0400 atomic_open(): fix the handling of create_error commit 10c64cea04d3c75c306b3f990586ffb343b63287 upstream. * if we have a hashed negative dentry and either CREAT|EXCL on r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL with failing may_o_create(), we should fail with EROFS or the error may_o_create() has returned, but not ENOENT. Which is what the current code ends up returning. * if we have CREAT|TRUNC hitting a regular file on a read-only filesystem, we can't fail with EROFS here. At the very least, not until we'd done follow_managed() - we might have a writable file (or a device, for that matter) bound on top of that one. Moreover, the code downstream will see that O_TRUNC and attempt to grab the write access (*after* following possible mount), so if we really should fail with EROFS, it will happen. No need to do that inside atomic_open(). The real logics is much simpler than what the current code is trying to do - if we decided to go for simple lookup, ended up with a negative dentry *and* had create_error set, fail with create_error. No matter whether we'd got that negative dentry from lookup_real() or had found it in dcache. Acked-by: Miklos Szeredi Signed-off-by: Al Viro [bwh: Backported to 3.16: deleted code was slightly different] Signed-off-by: Ben Hutchings commit ff6845cfc68f6be7acc44bde3ba50f35ada1c937 Author: Tony Luck Date: Fri Apr 29 15:42:25 2016 +0200 EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream. Both of these drivers can return NOTIFY_BAD, but this terminates processing other callbacks that were registered later on the chain. Since the driver did nothing to log the error it seems wrong to prevent other interested parties from seeing it. E.g. neither of them had even bothered to check the type of the error to see if it was a memory error before the return NOTIFY_BAD. Signed-off-by: Tony Luck Acked-by: Aristeu Rozanski Acked-by: Mauro Carvalho Chehab Cc: linux-edac Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings commit 40575df76d417e666347e8ca99bd3877269bffed Author: Sven Eckelmann Date: Fri Mar 11 16:44:05 2016 +0100 batman-adv: Fix reference counting of vlan object for tt_local_entry commit a33d970d0b54b09746d5540af8271fad4eb10229 upstream. The batadv_tt_local_entry was specific to a batadv_softif_vlan and held an implicit reference to it. But this reference was never stored in form of a pointer in the tt_local_entry itself. Instead batadv_tt_local_remove, batadv_tt_local_table_free and batadv_tt_local_purge_pending_clients depend on a consistent state of bat_priv->softif_vlan_list and that batadv_softif_vlan_get always returns the batadv_softif_vlan object which it has a reference for. But batadv_softif_vlan_get cannot guarantee that because it is working only with rcu_read_lock on this list. It can therefore happen that an vid is in this list twice or that batadv_softif_vlan_get cannot find the batadv_softif_vlan for an vid due to some other list operations taking place at the same time. Instead add a batadv_softif_vlan pointer directly in batadv_tt_local_entry which will be used for the reference counter decremented on release of batadv_tt_local_entry. Fixes: 35df3b298fc8 ("batman-adv: fix TT VLAN inconsistency on VLAN re-add") Signed-off-by: Sven Eckelmann Acked-by: Antonio Quartulli Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli [bwh: Backported to 3.16: - s/_put/_free_ref/ in various function names - Adjust context] Signed-off-by: Ben Hutchings commit 29a565506bab8e2ca01dec9c9b3fce55e72b1e97 Author: Antonio Quartulli Date: Sat Mar 12 11:12:59 2016 +0100 batman-adv: fix DAT candidate selection (must use vid) commit 2871734e85e920503d49b3a8bc0afbe0773b6036 upstream. Now that DAT is VLAN aware, it must use the VID when computing the DHT address of the candidate nodes where an entry is going to be stored/retrieved. Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware") Signed-off-by: Antonio Quartulli [sven@narfation.org: fix conflicts with current version] Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Ben Hutchings commit 19d8176d7293700f5f98eb0de5187950d486383e Author: Sven Eckelmann Date: Tue Nov 3 10:05:44 2015 +0100 batman-adv: Fix invalid stack access in batadv_dat_select_candidates commit b7fe3d4f4a65bc675e737d88071300ea9c4bcddd upstream. batadv_dat_select_candidates provides an u32 to batadv_hash_dat but it needs a batadv_dat_entry with at least ip and vid filled in. Fixes: 3e26722bc9f2 ("batman-adv: make the Distributed ARP Table vlan aware") Signed-off-by: Sven Eckelmann Acked-by: Antonio Quartulli Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Ben Hutchings commit 1ec1d7466f9f21b243e0f96c47a3bcace44b993d Author: Konstantin Khlebnikov Date: Thu Apr 28 16:18:32 2016 -0700 mm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check commit 3486b85a29c1741db99d0c522211c82d2b7a56d0 upstream. Khugepaged detects own VMAs by checking vm_file and vm_ops but this way it cannot distinguish private /dev/zero mappings from other special mappings like /dev/hpet which has no vm_ops and popultes PTEs in mmap. This fixes false-positive VM_BUG_ON and prevents installing THP where they are not expected. Link: http://lkml.kernel.org/r/CACT4Y+ZmuZMV5CjSFOeXviwQdABAgT7T+StKfTqan9YDtgEi5g@mail.gmail.com Fixes: 78f11a255749 ("mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups") Signed-off-by: Konstantin Khlebnikov Reported-by: Dmitry Vyukov Acked-by: Vlastimil Babka Acked-by: Kirill A. Shutemov Cc: Dmitry Vyukov Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: deleted assertions used VM_BUG_ON()] Signed-off-by: Ben Hutchings commit f4b592cb05dce29cd4c6778400ece68a45a1a223 Author: Jason Gunthorpe Date: Sun Apr 10 19:13:13 2016 -0600 IB/security: Restrict use of the write() interface commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 upstream. The drivers/infiniband stack uses write() as a replacement for bi-directional ioctl(). This is not safe. There are ways to trigger write calls that result in the return structure that is normally written to user space being shunted off to user specified kernel memory instead. For the immediate repair, detect and deny suspicious accesses to the write API. For long term, update the user space libraries and the kernel API to something that doesn't present the same security vulnerabilities (likely a structured ioctl() interface). The impacted uAPI interfaces are generally only available if hardware from drivers/infiniband is installed in the system. Reported-by: Jann Horn Signed-off-by: Linus Torvalds Signed-off-by: Jason Gunthorpe [ Expanded check to all known write() entry points ] Signed-off-by: Doug Ledford [bwh: Backported to 3.2: - Drop changes to hfi1 - ipath_write() has the same problem, so add the same restriction there] Signed-off-by: Ben Hutchings commit 80e4da2500457c054fd4ed8243b183bdec6bc6d6 Author: Ilya Dryomov Date: Fri Apr 15 16:22:16 2016 +0200 rbd: fix rbd map vs notify races commit 811c6688774613a78bfa020f64b570b73f6974c8 upstream. A while ago, commit 9875201e1049 ("rbd: fix use-after free of rbd_dev->disk") fixed rbd unmap vs notify race by introducing an exported wrapper for flushing notifies and sticking it into do_rbd_remove(). A similar problem exists on the rbd map path, though: the watch is registered in rbd_dev_image_probe(), while the disk is set up quite a few steps later, in rbd_dev_device_setup(). Nothing prevents a notify from coming in and crashing on a NULL rbd_dev->disk: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 Call Trace: [] rbd_watch_cb+0x34/0x180 [rbd] [] do_event_work+0x40/0xb0 [libceph] [] process_one_work+0x17b/0x470 [] worker_thread+0x11b/0x400 [] ? rescuer_thread+0x400/0x400 [] kthread+0xcf/0xe0 [] ? finish_task_switch+0x53/0x170 [] ? kthread_create_on_node+0x140/0x140 [] ret_from_fork+0x58/0x90 [] ? kthread_create_on_node+0x140/0x140 RIP [] rbd_dev_refresh+0xfa/0x180 [rbd] If an error occurs during rbd map, we have to error out, potentially tearing down a watch. Just like on rbd unmap, notifies have to be flushed, otherwise rbd_watch_cb() may end up trying to read in the image header after rbd_dev_image_release() has run: Assertion failure in rbd_dev_header_info() at line 4722: rbd_assert(rbd_image_format_valid(rbd_dev->image_format)); Call Trace: [] ? rbd_parent_request_create+0x150/0x150 [] rbd_dev_refresh+0x59/0x390 [] rbd_watch_cb+0x69/0x290 [] do_event_work+0x10f/0x1c0 [] process_one_work+0x689/0x1a80 [] ? process_one_work+0x5e7/0x1a80 [] ? finish_task_switch+0x225/0x640 [] ? pwq_dec_nr_in_flight+0x2b0/0x2b0 [] worker_thread+0xd9/0x1320 [] ? process_one_work+0x1a80/0x1a80 [] kthread+0x21d/0x2e0 [] ? kthread_stop+0x550/0x550 [] ret_from_fork+0x22/0x40 [] ? kthread_stop+0x550/0x550 RIP [] rbd_dev_header_info+0xa19/0x1e30 To fix this, a) check if RBD_DEV_FLAG_EXISTS is set before calling revalidate_disk(), b) move ceph_osdc_flush_notifies() call into rbd_dev_header_unwatch_sync() to cover rbd map error paths and c) turn header read-in into a critical section. The latter also happens to take care of rbd map foo@bar vs rbd snap rm foo@bar race. Fixes: http://tracker.ceph.com/issues/15490 Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit b5752ee2fab8340a7544c11635b227a2865f2933 Author: Sascha Hauer Date: Wed Apr 20 13:34:31 2016 +0000 ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel commit 5616f36713ea77f57ae908bf2fef641364403c9f upstream. The secondary CPU starts up in ARM mode. When the kernel is compiled in thumb2 mode we have to explicitly compile the secondary startup trampoline in ARM mode, otherwise the CPU will go to Nirvana. Signed-off-by: Sascha Hauer Reported-by: Steffen Trumtrar Suggested-by: Ard Biesheuvel Signed-off-by: Dinh Nguyen Signed-off-by: Kevin Hilman Signed-off-by: Ben Hutchings commit 94488e8c61f5e76713c8cb59638134c7bb839916 Author: Imre Deak Date: Mon Apr 18 14:45:54 2016 +0300 drm/i915: Fix system resume if PCI device remained enabled commit dab9a2663f4e688106c041f7cd2797a721382f0a upstream. During system resume we depended on pci_enable_device() also putting the device into PCI D0 state. This won't work if the PCI device was already enabled but still in D3 state. This is because pci_enable_device() is refcounted and will not change the HW state if called with a non-zero refcount. Leaving the device in D3 will make all subsequent device accesses fail. This didn't cause a problem most of the time, since we resumed with an enable refcount of 0. But it fails at least after module reload because after that we also happen to leak a PCI device enable reference: During probing we call drm_get_pci_dev() which will enable the PCI device, but during device removal drm_put_dev() won't disable it. This is a bug of its own in DRM core, but without much harm as it only leaves the PCI device enabled. Fixing it is also a bit more involved, due to DRM mid-layering and because it affects non-i915 drivers too. The fix in this patch is valid regardless of the problem in DRM core. v2: - Add a code comment about the relation of this fix to the freeze/thaw vs. the suspend/resume phases. (Ville) - Add a code comment about the inconsistent ordering of set power state and device enable calls. (Chris) CC: Ville Syrjälä CC: Chris Wilson Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com (cherry picked from commit 44410cd0bfb26bde9288da34c190cc9267d42a20) Signed-off-by: Jani Nikula [bwh: Backported to 3.16: - Return error code directly - Adjust context] Signed-off-by: Ben Hutchings commit 6971777782ba593105cee306b598e6075bbddb1d Author: Roman Pen Date: Tue Apr 26 13:15:35 2016 +0200 workqueue: fix ghost PENDING flag while doing MQ IO commit 346c09f80459a3ad97df1816d6d606169a51001a upstream. The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list with the following backtrace: [ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds. [ 601.347574] Tainted: G O 4.4.5-1-storage+ #6 [ 601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 601.348142] kworker/u129:5 D ffff880803077988 0 1636 2 0x00000000 [ 601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server] [ 601.348999] ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000 [ 601.349662] ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0 [ 601.350333] ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38 [ 601.350965] Call Trace: [ 601.351203] [] ? bit_wait+0x60/0x60 [ 601.351444] [] schedule+0x35/0x80 [ 601.351709] [] schedule_timeout+0x192/0x230 [ 601.351958] [] ? blk_flush_plug_list+0xc7/0x220 [ 601.352208] [] ? ktime_get+0x37/0xa0 [ 601.352446] [] ? bit_wait+0x60/0x60 [ 601.352688] [] io_schedule_timeout+0xa4/0x110 [ 601.352951] [] ? _raw_spin_unlock_irqrestore+0xe/0x10 [ 601.353196] [] bit_wait_io+0x1b/0x70 [ 601.353440] [] __wait_on_bit+0x5d/0x90 [ 601.353689] [] wait_on_page_bit+0xc0/0xd0 [ 601.353958] [] ? autoremove_wake_function+0x40/0x40 [ 601.354200] [] __filemap_fdatawait_range+0xe4/0x140 [ 601.354441] [] filemap_fdatawait_range+0x14/0x30 [ 601.354688] [] filemap_write_and_wait_range+0x3f/0x70 [ 601.354932] [] blkdev_fsync+0x1b/0x50 [ 601.355193] [] vfs_fsync_range+0x49/0xa0 [ 601.355432] [] blkdev_write_iter+0xca/0x100 [ 601.355679] [] __vfs_write+0xaa/0xe0 [ 601.355925] [] vfs_write+0xa9/0x1a0 [ 601.356164] [] kernel_write+0x38/0x50 The underlying device is a null_blk, with default parameters: queue_mode = MQ submit_queues = 1 Verification that nullb0 has something inflight: root@pserver8:~# cat /sys/block/nullb0/inflight 0 1 root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \; ... /sys/block/nullb0/mq/0/cpu2/rq_list CTX pending: ffff8838038e2400 ... During debug it became clear that stalled request is always inserted in the rq_list from the following path: save_stack_trace_tsk + 34 blk_mq_insert_requests + 231 blk_mq_flush_plug_list + 281 blk_flush_plug_list + 199 wait_on_page_bit + 192 __filemap_fdatawait_range + 228 filemap_fdatawait_range + 20 filemap_write_and_wait_range + 63 blkdev_fsync + 27 vfs_fsync_range + 73 blkdev_write_iter + 202 __vfs_write + 170 vfs_write + 169 kernel_write + 56 So blk_flush_plug_list() was called with from_schedule == true. If from_schedule is true, that means that finally blk_mq_insert_requests() offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue, i.e. it calls kblockd_schedule_delayed_work_on(). That means, that we race with another CPU, which is about to execute __blk_mq_run_hw_queue() work. Further debugging shows the following traces from different CPUs: CPU#0 CPU#1 ---------------------------------- ------------------------------- reqeust A inserted STORE hctx->ctx_map[0] bit marked kblockd_schedule...() returns 1 request B inserted STORE hctx->ctx_map[1] bit marked kblockd_schedule...() returns 0 *** WORK PENDING bit is cleared *** flush_busy_ctxs() is executed, but bit 1, set by CPU#1, is not observed As a result request B pended forever. This behaviour can be explained by speculative LOAD of hctx->ctx_map on CPU#0, which is reordered with clear of PENDING bit and executed _before_ actual STORE of bit 1 on CPU#1. The proper fix is an explicit full barrier , which guarantees that clear of PENDING bit is to be executed before all possible speculative LOADS or STORES inside actual work function. Signed-off-by: Roman Pen Cc: Gioh Kim Cc: Michael Wang Cc: Tejun Heo Cc: Jens Axboe Cc: linux-block@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit ea229beda0be9a0283135d911a7e40b6bfc9da7b Author: Conrad Kostecki Date: Tue Apr 26 10:08:10 2016 +0200 ALSA: hda - Add dock support for ThinkPad X260 commit 037e119738120c1cdc460c6ae33871c3000531f3 upstream. Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 8e0c1edde630eceee431eba300e05431990f6b19 Author: Eric Dumazet Date: Sat Apr 23 11:35:46 2016 -0700 net/mlx4_en: fix spurious timestamping callbacks commit fc96256c906362e845d848d0f6a6354450059e81 upstream. When multiple skb are TX-completed in a row, we might incorrectly keep a timestamp of a prior skb and cause extra work. Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Reviewed-by: Eran Ben Elisha Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 5d740c28a3dc8ffb877d7ebcf2f07dd716aa47da Author: Ilya Dryomov Date: Mon Apr 11 19:34:49 2016 +0200 libceph: make authorizer destruction independent of ceph_auth_client commit 6c1ea260f89709e0021d2c59f8fd2a104b5b1123 upstream. Starting the kernel client with cephx disabled and then enabling cephx and restarting userspace daemons can result in a crash: [262671.478162] BUG: unable to handle kernel paging request at ffffebe000000000 [262671.531460] IP: [] kfree+0x5a/0x130 [262671.584334] PGD 0 [262671.635847] Oops: 0000 [#1] SMP [262672.055841] CPU: 22 PID: 2961272 Comm: kworker/22:2 Not tainted 4.2.0-34-generic #39~14.04.1-Ubuntu [262672.162338] Hardware name: Dell Inc. PowerEdge R720/068CDY, BIOS 2.4.3 07/09/2014 [262672.268937] Workqueue: ceph-msgr con_work [libceph] [262672.322290] task: ffff88081c2d0dc0 ti: ffff880149ae8000 task.ti: ffff880149ae8000 [262672.428330] RIP: 0010:[] [] kfree+0x5a/0x130 [262672.535880] RSP: 0018:ffff880149aeba58 EFLAGS: 00010286 [262672.589486] RAX: 000001e000000000 RBX: 0000000000000012 RCX: ffff8807e7461018 [262672.695980] RDX: 000077ff80000000 RSI: ffff88081af2be04 RDI: 0000000000000012 [262672.803668] RBP: ffff880149aeba78 R08: 0000000000000000 R09: 0000000000000000 [262672.912299] R10: ffffebe000000000 R11: ffff880819a60e78 R12: ffff8800aec8df40 [262673.021769] R13: ffffffffc035f70f R14: ffff8807e5b138e0 R15: ffff880da9785840 [262673.131722] FS: 0000000000000000(0000) GS:ffff88081fac0000(0000) knlGS:0000000000000000 [262673.245377] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [262673.303281] CR2: ffffebe000000000 CR3: 0000000001c0d000 CR4: 00000000001406e0 [262673.417556] Stack: [262673.472943] ffff880149aeba88 ffff88081af2be04 ffff8800aec8df40 ffff88081af2be04 [262673.583767] ffff880149aeba98 ffffffffc035f70f ffff880149aebac8 ffff8800aec8df00 [262673.694546] ffff880149aebac8 ffffffffc035c89e ffff8807e5b138e0 ffff8805b047f800 [262673.805230] Call Trace: [262673.859116] [] ceph_x_destroy_authorizer+0x1f/0x50 [libceph] [262673.968705] [] ceph_auth_destroy_authorizer+0x3e/0x60 [libceph] [262674.078852] [] put_osd+0x45/0x80 [libceph] [262674.134249] [] remove_osd+0xae/0x140 [libceph] [262674.189124] [] __reset_osd+0x103/0x150 [libceph] [262674.243749] [] kick_requests+0x223/0x460 [libceph] [262674.297485] [] ceph_osdc_handle_map+0x282/0x5e0 [libceph] [262674.350813] [] dispatch+0x4e/0x720 [libceph] [262674.403312] [] try_read+0x3d1/0x1090 [libceph] [262674.454712] [] ? dequeue_entity+0x152/0x690 [262674.505096] [] con_work+0xcb/0x1300 [libceph] [262674.555104] [] process_one_work+0x14e/0x3d0 [262674.604072] [] worker_thread+0x11a/0x470 [262674.652187] [] ? rescuer_thread+0x310/0x310 [262674.699022] [] kthread+0xd2/0xf0 [262674.744494] [] ? kthread_create_on_node+0x1c0/0x1c0 [262674.789543] [] ret_from_fork+0x3f/0x70 [262674.834094] [] ? kthread_create_on_node+0x1c0/0x1c0 What happens is the following: (1) new MON session is established (2) old "none" ac is destroyed (3) new "cephx" ac is constructed ... (4) old OSD session (w/ "none" authorizer) is put ceph_auth_destroy_authorizer(ac, osd->o_auth.authorizer) osd->o_auth.authorizer in the "none" case is just a bare pointer into ac, which contains a single static copy for all services. By the time we get to (4), "none" ac, freed in (2), is long gone. On top of that, a new vtable installed in (3) points us at ceph_x_destroy_authorizer(), so we end up trying to destroy a "none" authorizer with a "cephx" destructor operating on invalid memory! To fix this, decouple authorizer destruction from ac and do away with a single static "none" authorizer by making a copy for each OSD or MDS session. Authorizers themselves are independent of ac and so there is no reason for destroy_authorizer() to be an ac op. Make it an op on the authorizer itself by turning ceph_authorizer into a real struct. Fixes: http://tracker.ceph.com/issues/15447 Reported-by: Alan Zhang Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil [bwh: Backported to 3.16: - Implementation of ceph_x_destroy_authorizer() is different - Adjust context] Signed-off-by: Ben Hutchings commit 20b8129105b2e2d6288dd274f2528b19aaa888c4 Author: Ilya Dryomov Date: Mon Feb 16 11:49:42 2015 +0300 libceph: kfree() in put_osd() shouldn't depend on authorizer commit b28ec2f37e6a2bbd0bdf74b39cb89c74e4ad17f3 upstream. a255651d4cad ("ceph: ensure auth ops are defined before use") made kfree() in put_osd() conditional on the authorizer. A mechanical mistake most likely - fix it. Cc: Alex Elder Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Reviewed-by: Alex Elder Signed-off-by: Ben Hutchings commit 9e395dbd9d92966a2a7d199f12cb386ad523cf40 Author: Jasem Mutlaq Date: Tue Apr 19 10:38:27 2016 +0300 USB: serial: cp210x: add Straizona Focusers device ids commit 613ac23a46e10d4d4339febdd534fafadd68e059 upstream. Adding VID:PID for Straizona Focusers to cp210x driver. Signed-off-by: Jasem Mutlaq Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 414ccda02d091a19968fb70a2c6f0140e2f1cfe1 Author: Mike Manning Date: Mon Apr 18 12:13:23 2016 +0000 USB: serial: cp210x: add ID for Link ECU commit 1d377f4d690637a0121eac8701f84a0aa1e69a69 upstream. The Link ECU is an aftermarket ECU computer for vehicles that provides full tuning abilities as well as datalogging and displaying capabilities via the USB to Serial adapter built into the device. Signed-off-by: Mike Manning Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit e93055ed099bfe01a4668d58e2c6f8296857c792 Author: Linus Lüssing Date: Fri Mar 11 14:04:49 2016 +0100 batman-adv: Fix broadcast/ogm queue limit on a removed interface commit c4fdb6cff2aa0ae740c5f19b6f745cbbe786d42f upstream. When removing a single interface while a broadcast or ogm packet is still pending then we will free the forward packet without releasing the queue slots again. This patch is supposed to fix this issue. Fixes: 6d5808d4ae1b ("batman-adv: Add missing hardif_free_ref in forw_packet_free") Signed-off-by: Linus Lüssing [sven@narfation.org: fix conflicts with current version] Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Ben Hutchings commit c8238563b3ffc232e68a88b11e693bcd1d165710 Author: Sven Eckelmann Date: Sun Mar 20 12:27:53 2016 +0100 batman-adv: Reduce refcnt of removed router when updating route commit d1a65f1741bfd9c69f9e4e2ad447a89b6810427d upstream. _batadv_update_route rcu_derefences orig_ifinfo->router outside of a spinlock protected region to print some information messages to the debug log. But this pointer is not checked again when the new pointer is assigned in the spinlock protected region. Thus is can happen that the value of orig_ifinfo->router changed in the meantime and thus the reference counter of the wrong router gets reduced after the spinlock protected region. Just rcu_dereferencing the value of orig_ifinfo->router inside the spinlock protected region (which also set the new pointer) is enough to get the correct old router object. Fixes: e1a5382f978b ("batman-adv: Make orig_node->router an rcu protected pointer") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Ben Hutchings commit e7ad6820bf4053f51b4167638fe29327d26fc9ac Author: Sven Eckelmann Date: Fri Feb 26 17:56:13 2016 +0100 batman-adv: Check skb size before using encapsulated ETH+VLAN header commit c78296665c3d81f040117432ab9e1cb125521b0c upstream. The encapsulated ethernet and VLAN header may be outside the received ethernet frame. Thus the skb buffer size has to be checked before it can be parsed to find out if it encapsulates another batman-adv packet. Fixes: 420193573f11 ("batman-adv: softif bridge loop avoidance") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Ben Hutchings commit 87f1822d8eaa3d7e6e871df63192417be43a5767 Author: Laszlo Ersek Date: Thu Apr 21 18:21:11 2016 +0200 efi: Fix out-of-bounds read in variable_matches() commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 upstream. The variable_matches() function can currently read "var_name[len]", for example when: - var_name[0] == 'a', - len == 1 - match_name points to the NUL-terminated string "ab". This function is supposed to accept "var_name" inputs that are not NUL-terminated (hence the "len" parameter"). Document the function, and access "var_name[*match]" only if "*match" is smaller than "len". Reported-by: Chris Wilson Signed-off-by: Laszlo Ersek Cc: Peter Jones Cc: Matthew Garrett Cc: Jason Andryuk Cc: Jani Nikula Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906 Signed-off-by: Matt Fleming Signed-off-by: Ben Hutchings commit a3db726d7e5fd52663bf7c9d7133b22d325469d9 Author: Javier Martinez Canillas Date: Sat Apr 16 21:14:52 2016 -0400 i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream. The exynos5 I2C controller driver always prepares and enables a clock before using it and then disables unprepares it when the clock is not used anymore. But this can cause a possible ABBA deadlock in some scenarios since a driver that uses regmap to access its I2C registers, will first grab the regmap lock and then the I2C xfer function will grab the prepare lock when preparing the I2C clock. But since the clock driver also uses regmap for I2C accesses, preparing a clock will first grab the prepare lock and then the regmap lock when using the regmap API. An example of this happens on the Exynos5422 Odroid XU4 board where a s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers share the same I2C regmap. The possible deadlock is reported by the kernel lockdep: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sec_core:428:(regmap)->lock); lock(prepare_lock); lock(sec_core:428:(regmap)->lock); lock(prepare_lock); *** DEADLOCK *** Fix it by leaving the code prepared on probe and use {en,dis}able in the I2C transfer function. This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA deadlock by keeping clock prepared") that fixes the same bug in other driver for an I2C controller found in Samsung SoCs. Reported-by: Anand Moon Signed-off-by: Javier Martinez Canillas Reviewed-by: Anand Moon Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Ben Hutchings commit 27c03f880236b5e3c48af4d8848916bea8a5d88a Author: Jan Beulich Date: Thu Apr 21 00:27:04 2016 -0600 x86/mm/xen: Suppress hugetlbfs in PV guests commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream. Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use results in an endless loop of page faults when user mode code tries to access a hugetlbfs mapped area (since the hypervisor denies such PTEs to be created, but error indications can't be propagated out of xen_set_pte_at(), just like for various of its siblings), and - once killed in an oops like this: kernel BUG at .../fs/hugetlbfs/inode.c:428! invalid opcode: 0000 [#1] SMP ... RIP: e030:[] [] remove_inode_hugepages+0x25b/0x320 ... Call Trace: [] hugetlbfs_evict_inode+0x15/0x40 [] evict+0xbd/0x1b0 [] __dentry_kill+0x19a/0x1f0 [] dput+0x1fe/0x220 [] __fput+0x155/0x200 [] task_work_run+0x60/0xa0 [] do_exit+0x160/0x400 [] do_group_exit+0x3b/0xa0 [] get_signal+0x1ed/0x470 [] do_signal+0x14/0x110 [] prepare_exit_to_usermode+0xe9/0xf0 [] retint_user+0x8/0x13 This is CVE-2016-3961 / XSA-174. Reported-by: Vitaly Kuznetsov Signed-off-by: Jan Beulich Cc: Andrew Morton Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Juergen Gross Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: xen-devel Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 732ca9988ecc917d42ad43d4ff976e6106d61a0a Author: Dominik Dingel Date: Fri Jul 17 16:23:39 2015 -0700 s390/hugetlb: add hugepages_supported define commit 7f9be77555bb2e52de84e9dddf7b4eb20cc6e171 upstream. On s390 we only can enable hugepages if the underlying hardware/hypervisor also does support this. Common code now would assume this to be signaled by setting HPAGE_SHIFT to 0. But on s390, where we only support one hugepage size, there is a link between HPAGE_SHIFT and pageblock_order. So instead of setting HPAGE_SHIFT to 0, we will implement the check for the hardware capability. Signed-off-by: Dominik Dingel Acked-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Michael Holzheu Cc: Gerald Schaefer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 609aa4083b727e464fe510d6fa65e6e5bfd73bc8 Author: Dominik Dingel Date: Fri Jul 17 16:23:37 2015 -0700 mm: hugetlb: allow hugepages_supported to be architecture specific commit 2531c8cf56a640cd7d17057df8484e570716a450 upstream. s390 has a constant hugepage size, by setting HPAGE_SHIFT we also change e.g. the pageblock_order, which should be independent in respect to hugepage support. With this patch every architecture is free to define how to check for hugepage support. Signed-off-by: Dominik Dingel Acked-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Michael Holzheu Cc: Gerald Schaefer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 801b07f4e84bcbc59118e582e861e34f404e0c15 Author: Ben Hutchings Date: Wed Apr 20 23:23:08 2016 +0100 atl2: Disable unimplemented scatter/gather feature commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 upstream. atl2 includes NETIF_F_SG in hw_features even though it has no support for non-linear skbs. This bug was originally harmless since the driver does not claim to implement checksum offload and that used to be a requirement for SG. Now that SG and checksum offload are independent features, if you explicitly enable SG *and* use one of the rare protocols that can use SG without checkusm offload, this potentially leaks sensitive information (before you notice that it just isn't working). Therefore this obscure bug has been designated CVE-2016-2117. Reported-by: Justin Yackoski Signed-off-by: Ben Hutchings Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.") Signed-off-by: David S. Miller commit 98be598882d15c0552e9ea373861ac9fb8f8fa88 Author: Neil Armstrong Date: Wed Apr 20 10:56:45 2016 +0200 net: ethernet: davinci_emac: Fix platform_data overwrite commit 210990b05a1247886539078e857cd038881bb2d6 upstream. When the DaVinci emac driver is removed and re-probed, the actual pdev->dev.platform_data is populated with an unwanted valid pointer saved by the previous davinci_emac_of_get_pdata() call, causing a kernel crash when calling priv->int_disable() in emac_int_disable(). Unable to handle kernel paging request at virtual address c8622a80 ... [] (emac_int_disable) from [] (emac_dev_open+0x290/0x5f8) [] (emac_dev_open) from [] (__dev_open+0xb8/0x120) [] (__dev_open) from [] (__dev_change_flags+0x88/0x14c) [] (__dev_change_flags) from [] (dev_change_flags+0x18/0x48) [] (dev_change_flags) from [] (devinet_ioctl+0x6b4/0x7ac) [] (devinet_ioctl) from [] (sock_ioctl+0x1d8/0x2c0) [] (sock_ioctl) from [] (do_vfs_ioctl+0x41c/0x600) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x1c) Fixes: 42f59967a091 ("net: ethernet: davinci_emac: add OF support") Cc: Brian Hutchinson Signed-off-by: Neil Armstrong Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit edc15924341e34bdd81b18299e625a31a4047d58 Author: Neil Armstrong Date: Wed Apr 20 10:56:13 2016 +0200 net: ethernet: davinci_emac: Fix Unbalanced pm_runtime_enable commit 99164f9e62a391b5f4b7923b624d182b5d2859e0 upstream. In order to avoid an Unbalanced pm_runtime_enable in the DaVinci emac driver when the device is removed and re-probed, and a pm_runtime_disable() call in davinci_emac_remove(). Actually, using unbind/bind on a TI DM8168 SoC gives : $ echo 4a120000.ethernet > /sys/bus/platform/drivers/davinci_emac/unbind net eth1: DaVinci EMAC: davinci_emac_remove() $ echo 4a120000.ethernet > /sys/bus/platform/drivers/davinci_emac/bind davinci_emac 4a120000.ethernet: Unbalanced pm_runtime_enable Cc: Brian Hutchinson Fixes: 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support") Signed-off-by: Neil Armstrong Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 0fbf8e134424c79ef448ba3c06d9b7df4fcf2340 Author: Davidlohr Bueso Date: Wed Apr 20 20:09:24 2016 -0700 futex: Acknowledge a new waiter in counter before plist commit fe1bce9e2107ba3a8faffe572483b6974201a0e6 upstream. Otherwise an incoming waker on the dest hash bucket can miss the waiter adding itself to the plist during the lockless check optimization (small window but still the correct way of doing this); similarly to the decrement counterpart. Suggested-by: Peter Zijlstra Signed-off-by: Davidlohr Bueso Cc: Davidlohr Bueso Cc: bigeasy@linutronix.de Cc: dvhart@infradead.org Link: http://lkml.kernel.org/r/1461208164-29150-1-git-send-email-dave@stgolabs.net Signed-off-by: Thomas Gleixner Signed-off-by: Ben Hutchings commit 377ba31b3c60d658f19861c5866a8fe96f3bb0af Author: Alex Deucher Date: Thu Apr 14 14:15:16 2016 -0400 drm/radeon: add a quirk for a XFX R9 270X commit bcb31eba4a4ea356fd61cbd5dec5511c3883f57e upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit ac932b36ac38ffb8344ec1fbc5bbbb21e008f119 Author: Anton Blanchard Date: Fri Apr 15 12:06:13 2016 +1000 powerpc: scan_features() updates incorrect bits for REAL_LE commit 6997e57d693b07289694239e52a10d2f02c3a46f upstream. The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by: Anton Blanchard [mpe: Flesh out changelog, add comment reserving 0x4] Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 646178dc82215c0314d7da4c7b60defdc9a9199a Author: Chris Wilson Date: Tue Apr 5 15:00:00 2016 +0100 drm/i915/userptr: Hold mmref whilst calling get-user-pages commit db9f9203e27495b2d151b695504e286eec026e9b upstream. Holding a reference to the containing task_struct is not sufficient to prevent the mm_struct from being reaped under memory pressure. If this happens whilst we are calling get_user_pages(), explosions erupt - sometimes an immediate GPF, sometimes page flag corruption. To prevent the target mm from being reaped as we are reading from it, acquire a reference before we begin. Testcase: igt/gem_shrink/*userptr Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Michał Winiarski Reviewed-by: Michał Winiarski Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-2-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 40313f0cd0b711a7a5905e5182422799e157d8aa) Signed-off-by: Jani Nikula [bwh: Backported to 3.16: - s/get_user_pages_remote/get_user_pages/ - s/npages/num_pages/] Signed-off-by: Ben Hutchings commit f5546371f95f5837ad300c3cafdb891814dee316 Author: Stephen Boyd Date: Sun Apr 17 05:21:42 2016 -0700 Input: pmic8xxx-pwrkey - fix algorithm for converting trigger delay commit eda5ecc0a6b865561997e177c393f0b0136fe3b7 upstream. The trigger delay algorithm that converts from microseconds to the register value looks incorrect. According to most of the PMIC documentation, the equation is delay (Seconds) = (1 / 1024) * 2 ^ (x + 4) except for one case where the documentation looks to have a formatting issue and the equation looks like delay (Seconds) = (1 / 1024) * 2 x + 4 Most likely this driver was written with the improper documentation to begin with. According to the downstream sources the valid delays are from 2 seconds to 1/64 second, and the latter equation just doesn't make sense for that. Let's fix the algorithm and the range check to match the documentation and the downstream sources. Reported-by: Bjorn Andersson Fixes: 92d57a73e410 ("input: Add support for Qualcomm PMIC8XXX power key") Signed-off-by: Stephen Boyd Tested-by: John Stultz Acked-by: Bjorn Andersson Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 8fa9fb82895e8e7bff3ebaba3565ff8c5ebe46cf Author: Krzysztof Kozlowski Date: Mon Apr 4 14:54:59 2016 +0900 iio: ak8975: Fix NULL pointer exception on early interrupt commit 07d2390e36ee5b3265e9cc8305f2a106c8721e16 upstream. In certain probe conditions the interrupt came right after registering the handler causing a NULL pointer exception because of uninitialized waitqueue: $ udevadm trigger i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL) i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL) Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = e8b38000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (...) (__wake_up_common) from [] (__wake_up+0x38/0x4c) (__wake_up) from [] (ak8975_irq_handler+0x28/0x30) (ak8975_irq_handler) from [] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [] (handle_irq_event+0x44/0x68) (handle_irq_event) from [] (handle_edge_irq+0xf0/0x19c) (handle_edge_irq) from [] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [] (exynos_eint_gpio_irq+0x50/0x68) (exynos_eint_gpio_irq) from [] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [] (handle_irq_event+0x44/0x68) (handle_irq_event) from [] (handle_fasteoi_irq+0xb4/0x194) (handle_fasteoi_irq) from [] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4) (__handle_domain_irq) from [] (gic_handle_irq+0x54/0x94) (gic_handle_irq) from [] (__irq_usr+0x50/0x80) The bug was reproduced on exynos4412-trats2 (with a max77693 device also using i2c-gpio) after building max77693 as a module. Fixes: 94a6d5cf7caa ("iio:ak8975 Implement data ready interrupt handling") Signed-off-by: Krzysztof Kozlowski Tested-by: Gregor Boirie Signed-off-by: Jonathan Cameron Signed-off-by: Ben Hutchings commit dc5e14b09298c1262336be133fa9febad4036b43 Author: Eric Dumazet Date: Fri Apr 15 10:47:52 2016 -0700 net: bcmgenet: device stats are unsigned long commit 6517eb59b03965689e6bb16bb2d480096b3ef95d upstream. On 64bit kernels, device stats are 64bit wide, not 32bit. Fixes: 1c1008c793fa4 ("net: bcmgenet: add main driver file") Signed-off-by: Eric Dumazet Cc: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2ba121ced91f140760640675ae47e64ec4e552ec Author: Heiko Carstens Date: Wed Apr 13 11:05:20 2016 +0200 s390/spinlock: avoid yield to non existent cpu commit 8497695243f70fd19ed6cf28b63584f1b608b5f9 upstream. arch_spin_lock_wait_flags() checks if a spinlock is not held before trying a compare and swap instruction. If the lock is unlocked it tries the compare and swap instruction, however if a different cpu grabbed the lock in the meantime the instruction will fail as expected. Subsequently the arch_spin_lock_wait_flags() incorrectly tries to figure out if the cpu that holds the lock is running. However it is using the wrong cpu number for this (-1) and then will also yield the current cpu to the wrong cpu. Fix this by adding a missing continue statement. Fixes: 470ada6b1a1d ("s390/spinlock: refactor arch_spin_lock_wait[_flags]") Signed-off-by: Heiko Carstens Acked-by: Martin Schwidefsky Signed-off-by: Ben Hutchings commit d8b40ad2f49f447f2ed7386366acae007f52ea2a Author: Tom Lendacky Date: Wed Apr 13 10:52:25 2016 -0500 crypto: ccp - Prevent information leakage on export commit f709b45ec461b548c41a00044dba1f1b572783bf upstream. Prevent information from leaking to userspace by doing a memset to 0 of the export state structure before setting the structure values and copying it. This prevents un-initialized padding areas from being copied into the export area. Reported-by: Ben Hutchings Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit e6bfaf526363c5990f02b2ce86dd6fa797d9c8ce Author: Keerthy Date: Thu Apr 14 10:29:16 2016 +0530 pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe upstream. pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices ranging from 1 to MAX. This leads to a corner case where we try to request the pin number = MAX and fails. bit_pos value is being calculted using ffs. pin_num_from_lsb uses bit_pos value. pins array is populated with: pin + pin_num_from_lsb. The above is 1 more than usual bit indices as bit_pos uses ffs to compute first set bit. Hence the last of the pins array is populated with the MAX value and not MAX - 1 which causes error when we call pin_request. mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1)) Consequently val_pos and submask are correct. Hence use __ffs which gives (ffs(x) - 1) as the first bit set. fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Signed-off-by: Keerthy Acked-by: Tony Lindgren Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings commit 4c6ecde080ae0f1ff6d8ac3e6745ea72e54d5b8f Author: Jack Pham Date: Thu Apr 14 23:37:26 2016 -0700 regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 upstream. Specifically for the case of reads that use the Extended Register Read Long command, a multi-byte read operation is broken up into 8-byte chunks. However the call to spmi_ext_register_readl() is incorrectly passing 'val_size', which if greater than 8 will always fail. The argument should instead be 'len'. Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces") Signed-off-by: Jack Pham Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit d6db3a73d106fdb0eacdecec6be98cb15f1e07bc Author: Mathias Krause Date: Sun Apr 10 12:52:28 2016 +0200 packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface commit 309cf37fe2a781279b7675d4bb7173198e532867 upstream. Because we miss to wipe the remainder of i->addr[] in packet_mc_add(), pdiag_put_mclist() leaks uninitialized heap bytes via the PACKET_DIAG_MCLIST netlink attribute. Fix this by explicitly memset(0)ing the remaining bytes in i->addr[]. Fixes: eea68e2f1a00 ("packet: Report socket mclist info via diag module") Signed-off-by: Mathias Krause Cc: Eric W. Biederman Cc: Pavel Emelyanov Acked-by: Pavel Emelyanov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 85411d5615fcef2eaf230ec66c541e217428756f Author: Robert Dobrowolski Date: Thu Mar 24 03:30:07 2016 -0700 usb: hcd: out of bounds access in for_each_companion commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream. On BXT platform Host Controller and Device Controller figure as same PCI device but with different device function. HCD should not pass data to Device Controller but only to Host Controllers. Checking if companion device is Host Controller, otherwise skip. Signed-off-by: Robert Dobrowolski Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4bba2ce7c1e18eef89b24f98b47375cb1e80ebe8 Author: Hans de Goede Date: Tue Apr 12 12:27:09 2016 +0200 USB: uas: Add a new NO_REPORT_LUNS quirk commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa upstream. Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with an usb-id of: 0bc2:331a, as these will fail to respond to a REPORT_LUNS command. Reported-and-tested-by: David Webb Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c42510b613d786536a7a0681407871dd212e290d Author: Lu Baolu Date: Fri Apr 8 16:25:09 2016 +0300 usb: xhci: fix wild pointers in xhci_mem_cleanup commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream. This patch fixes some wild pointers produced by xhci_mem_cleanup. These wild pointers will cause system crash if xhci_mem_cleanup() is called twice. Reported-and-tested-by: Pengcheng Li Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9d9b8ea53f680226a0f14b462e553d7471cc3fec Author: Rafal Redzimski Date: Fri Apr 8 16:25:05 2016 +0300 usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream. Broxton B0 also requires XHCI_PME_STUCK_QUIRK. Adding PCI device ID for Broxton B and adding to quirk. Signed-off-by: Rafal Redzimski Signed-off-by: Robert Dobrowolski Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b6128b21bd6ce80a200cd1fbc437eda02686273a Author: Rui Salvaterra Date: Sat Apr 9 22:05:34 2016 +0100 lib: lz4: fixed zram with lz4 on big endian machines commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 upstream. Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Note that the 64-bit preprocessor test is not a cleanup, it's part of the fix, since those identifiers are bogus (for example, __ppc64__ isn't defined anywhere else in the kernel, which means we'd fall into the 32-bit definitions on ppc64). Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4 Suggested-by: Sergey Senozhatsky Signed-off-by: Rui Salvaterra Reviewed-by: Sergey Senozhatsky Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e5bb0548c1ddab65ed675df65be6632f83374ec3 Author: Ben Hutchings Date: Tue Apr 12 12:58:14 2016 +0100 spi: spi-ti-qspi: Handle truncated frames properly commit 1ff7760ff66b98ef244bf0e5e2bd5310651205ad upstream. We clamp frame_len_words to a maximum of 4096, but do not actually limit the number of words written or read through the DATA registers or the length added to spi_message::actual_length. This results in silent data corruption for commands longer than this maximum. Recalculate the length of each transfer, taking frame_len_words into account. Use this length in qspi_{read,write}_msg(), and to increment spi_message::actual_length. Signed-off-by: Ben Hutchings Signed-off-by: Mark Brown [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit cfb3474f6849b53d0b68e8e3b22ea2ce392b9fd8 Author: Ben Hutchings Date: Tue Apr 12 12:56:25 2016 +0100 spi: spi-ti-qspi: Fix FLEN and WLEN settings if bits_per_word is overridden commit ea1b60fb085839a9544cb3a0069992991beabb7f upstream. Each transfer can specify 8, 16 or 32 bits per word independently of the default for the device being addressed. However, currently we calculate the number of words in the frame assuming that the word size is the device default. If multiple transfers in the same message have differing bits_per_word, we bitwise-or the different values in the WLEN register field. Fix both of these. Also rename 'frame_length' to 'frame_len_words' to make clear that it's not a byte count like spi_message::frame_length. Signed-off-by: Ben Hutchings Signed-off-by: Mark Brown [bwh: Backported to 3.16: - QSPI_WLEN_MAX_BITS is not defined so use the literal value 128 - Adjust context] Signed-off-by: Ben Hutchings commit 9e27e42146211654c8d7a6d4c3fdba72da741759 Author: Dmitry Ivanov Date: Wed Apr 6 17:23:18 2016 +0300 nl80211: check netlink protocol in socket release notification commit 8f815cdde3e550e10c2736990d791f60c2ce43eb upstream. A non-privileged user can create a netlink socket with the same port_id as used by an existing open nl80211 netlink socket (e.g. as used by a hostapd process) with a different protocol number. Closing this socket will then lead to the notification going to nl80211's socket release notification handler, and possibly cause an action such as removing a virtual interface. Fix this issue by checking that the netlink protocol is NETLINK_GENERIC. Since generic netlink has no notifier chain of its own, we can't fix the problem more generically. Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames") Signed-off-by: Dmitry Ivanov [rewrite commit message] Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 0589641bc4f88c232566a3eaa0f27f789cb30fb5 Author: Kailang Yang Date: Tue Apr 12 10:55:03 2016 +0800 ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock commit adcdd0d5a1cb779f6d455ae70882c19c527627a8 upstream. This is Dell usb dock audio workaround. It was fixed the master volume keep lower. [Some background: the patch essentially skips the controls of a couple of FU volumes. Although the firmware exposes the dB and the value information via the usb descriptor, changing the values (we set the min volume as default) screws up the device. Although this has been fixed in the newer firmware, the devices are shipped with the old firmware, thus we need the workaround in the driver side. -- tiwai] Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 65ed9de4d97f555c1c88b65df799f73c2d8f7122 Author: David Matlack Date: Wed Mar 30 12:24:47 2016 -0700 kvm: x86: do not leak guest xcr0 into host interrupt handlers commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 upstream. An interrupt handler that uses the fpu can kill a KVM VM, if it runs under the following conditions: - the guest's xcr0 register is loaded on the cpu - the guest's fpu context is not loaded - the host is using eagerfpu Note that the guest's xcr0 register and fpu context are not loaded as part of the atomic world switch into "guest mode". They are loaded by KVM while the cpu is still in "host mode". Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The interrupt handler will look something like this: if (irq_fpu_usable()) { kernel_fpu_begin(); [... code that uses the fpu ...] kernel_fpu_end(); } As long as the guest's fpu is not loaded and the host is using eager fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle() returns true). The interrupt handler proceeds to use the fpu with the guest's xcr0 live. kernel_fpu_begin() saves the current fpu context. If this uses XSAVE[OPT], it may leave the xsave area in an undesirable state. According to the SDM, during XSAVE bit i of XSTATE_BV is not modified if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and xcr0[i] == 0 following an XSAVE. kernel_fpu_end() restores the fpu context. Now if any bit i in XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The fault is trapped and SIGSEGV is delivered to the current process. Only pre-4.2 kernels appear to be vulnerable to this sequence of events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly") from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts. This patch fixes the bug by keeping the host's xcr0 loaded outside of the interrupts-disabled region where KVM switches into guest mode. Suggested-by: Andy Lutomirski Signed-off-by: David Matlack [Move load after goto cancel_injection. - Paolo] Signed-off-by: Paolo Bonzini [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit d513fcfdc14b44cc22f85bd1a5206fc6cd68d354 Author: Jerome Marchand Date: Wed Apr 6 14:06:48 2016 +0100 assoc_array: don't call compare_object() on a node commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream. Changes since V1: fixed the description and added KASan warning. In assoc_array_insert_into_terminal_node(), we call the compare_object() method on all non-empty slots, even when they're not leaves, passing a pointer to an unexpected structure to compare_object(). Currently it causes an out-of-bound read access in keyring_compare_object detected by KASan (see below). The issue is easily reproduced with keyutils testsuite. Only call compare_object() when the slot is a leave. KASan warning: ================================================================== BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838 Read of size 8 by task keyctl/1655 ============================================================================= BUG kmalloc-192 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647 ___slab_alloc+0x563/0x5c0 __slab_alloc+0x51/0x90 kmem_cache_alloc_trace+0x263/0x300 assoc_array_insert+0xfd0/0x3a60 __key_link_begin+0xfc/0x270 key_create_or_update+0x459/0xaf0 SyS_add_key+0x1ba/0x350 entry_SYSCALL_64_fastpath+0x12/0x76 INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080 INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1 Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00 ...`............ Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff ...`.......`.... Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 0 PID: 1655 Comm: keyctl Tainted: G B 4.5.0-rc4-kasan+ #291 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491 ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969 ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650 Call Trace: [] dump_stack+0x85/0xc4 [] print_trailer+0xf9/0x150 [] object_err+0x34/0x40 [] kasan_report_error+0x230/0x550 [] ? keyring_get_key_chunk+0x13e/0x210 [] __asan_report_load_n_noabort+0x5d/0x70 [] ? keyring_compare_object+0x213/0x240 [] keyring_compare_object+0x213/0x240 [] assoc_array_insert+0x86c/0x3a60 [] ? assoc_array_cancel_edit+0x70/0x70 [] ? __key_link_begin+0x20d/0x270 [] __key_link_begin+0xfc/0x270 [] key_create_or_update+0x459/0xaf0 [] ? trace_hardirqs_on+0xd/0x10 [] ? key_type_lookup+0xc0/0xc0 [] ? lookup_user_key+0x13d/0xcd0 [] ? memdup_user+0x53/0x80 [] SyS_add_key+0x1ba/0x350 [] ? key_get_type_from_user.constprop.6+0xa0/0xa0 [] ? retint_user+0x18/0x23 [] ? trace_hardirqs_on_caller+0x3fe/0x580 [] ? trace_hardirqs_on_thunk+0x17/0x19 [] entry_SYSCALL_64_fastpath+0x12/0x76 Memory state around the buggy address: ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc >ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00 ================================================================== Signed-off-by: Jerome Marchand Signed-off-by: David Howells Signed-off-by: Ben Hutchings commit 74599272b052bf13a9520d634224b862deaf4d24 Author: Sebastian Ott Date: Tue Mar 22 19:00:55 2016 +0100 s390/scm_blk: fix deadlock for requests != REQ_TYPE_FS commit b707c65ae70e24c47a0ce4a7279224ce8f0ffb7f upstream. When we refuse a non REQ_TYPE_FS request in the build request function we already hold the queue lock. Thus we must not call blk_end_request_all but __blk_end_request_all. Reported-by: Peter Oberparleiter Fixes: de9587a ('s390/scm_blk: fix endless loop for requests != REQ_TYPE_FS') Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Ben Hutchings commit 8eb71f12aad899a8e182c2c459112dafb72b82e2 Author: Srinivas Kandagatla Date: Fri Apr 1 08:52:56 2016 +0100 libahci: save port map for forced port map commit 2fd0f46cb1b82587c7ae4a616d69057fb9bd0af7 upstream. In usecases where force_port_map is used saved_port_map is never set, resulting in not programming the PORTS_IMPL register as part of initial config. This patch fixes this by setting it to port_map even in case where force_port_map is used, making it more inline with other parts of the code. Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3") Signed-off-by: Srinivas Kandagatla Acked-by: Tejun Heo Reviewed-by: Andy Gross Signed-off-by: Tejun Heo [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 772703cadb1bf378bcd5ae87db4c150da37351b6 Author: Vladis Dronov Date: Thu Mar 31 10:53:42 2016 -0700 Input: gtco - fix crash on detecting device without endpoints commit 162f98dea487206d9ab79fc12ed64700667a894d upstream. The gtco 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. Also let's fix a minor coding style issue. The full correct report of this issue can be found in the public Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283385 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit f8d5d740ed82bf1aa98948ed3c9dd444519e187b Author: John Keeping Date: Wed Nov 18 11:17:25 2015 +0000 drm/qxl: fix cursor position with non-zero hotspot commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 upstream. The SPICE protocol considers the position of a cursor to be the location of its active pixel on the display, so the cursor is drawn with its top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor position gives the location where the top-left corner should be drawn, with the hotspot being a hint for drivers that need it. This fixes the location of the window resize cursors when using Fluxbox with the QXL DRM driver and both the QXL and modesetting X drivers. Signed-off-by: John Keeping Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com Signed-off-by: Jani Nikula Signed-off-by: Ben Hutchings commit 18ac9c5e35117aaf515cc32a799ee97443b58a59 Author: Krzysztof Kozlowski Date: Mon Mar 28 13:09:56 2016 +0900 regulator: s2mps11: Fix invalid selector mask and voltages for buck9 commit 3b672623079bb3e5685b8549e514f2dfaa564406 upstream. The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff instead of 0x1f) thus reading entire register as buck9's voltage. This effectively caused regulator core to interpret values as higher voltages than they were and then to set real voltage much lower than intended. The buck9 provides power to other regulators, including LDO13 and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower voltage caused SD card detection errors on Odroid XU3/XU4: mmc1: card never left busy state mmc1: error -110 whilst initialising SD card During driver probe the regulator core was checking whether initial voltage matches the constraints. With incorrect vsel_mask of 0xff and default value of 0x50, the core interpreted this as 5 V which is outside of constraints (3-3.775 V). Then the regulator core was adjusting the voltage to match the constraints. With incorrect vsel_mask this new voltage mapped to a vere low voltage in the driver. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Mark Brown [bwh: Backported to 3.16: s2mps11_buck9_ops was never combined with other macros here, so just change the n_voltages and vsel_mask fields] Signed-off-by: Ben Hutchings commit 08cd7e84d77707cc3e3a35324474007ac5885840 Author: Lokesh Vutla Date: Sat Mar 26 23:08:55 2016 -0600 ARM: OMAP2+: hwmod: Fix updating of sysconfig register commit 3ca4a238106dedc285193ee47f494a6584b6fd2f upstream. Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle when necessary") talks about verification of sysconfig cache value before updating it, only during idle path. But the patch is adding the verification in the enable path. So, adding the check in a proper place as per the commit description. Not keeping this check during enable path as there is a chance of losing context and it is safe to do on idle as the context of the register will never be lost while the device is active. Signed-off-by: Lokesh Vutla Acked-by: Tero Kristo Cc: Jon Hunter Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary" [paul@pwsan.com: appears to have been caused by my own mismerge of the originally posted patch] Signed-off-by: Paul Walmsley Signed-off-by: Ben Hutchings commit 176122b7509a61cb9267cac3306e564c40c80627 Author: Jon Hunter Date: Fri Aug 23 04:40:23 2013 -0600 ARM: OMAP2+: Only write the sysconfig on idle when necessary commit 127500ccb766f0e963436e25ddd57be8f1695498 upstream. Currently, whenever we idle a device _idle_sysc() is called and writes to the devices SYSCONFIG register to set the idle mode. A lot devices are using the smart-idle mode and so the write to the SYSCONFIG register is programming the same value that is already stored in the register. Writes to the devices SYSCONFIG register can be slow, for example, writing to the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can take ~100us. Furthermore, during boot on an OMAP4430 panda board, I see that there are 100 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write the SYSCONFIG register with a new value. Therefore, to avoid unnecessary writes to device SYSCONFIG registers when idling the device, only write the value if the value has changed. It should be safe to do this on idle as the context of the register will never be lost while the device is active. Verified that suspend, CORE off and retention states are working with this change on OMAP3430 Beagle board. Signed-off-by: Jon Hunter [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley Signed-off-by: Ben Hutchings commit c57950a15adaead0446021e6619572c8fc15dc5b Author: Alan Stern Date: Wed Mar 23 12:17:09 2016 -0400 HID: usbhid: fix inconsistent reset/resume/reset-resume behavior commit 972e6a993f278b416a8ee3ec65475724fc36feb2 upstream. The usbhid driver has inconsistently duplicated code in its post-reset, resume, and reset-resume pathways. reset-resume doesn't check HID_STARTED before trying to restart the I/O queues. resume fails to clear the HID_SUSPENDED flag if HID_STARTED isn't set. resume calls usbhid_restart_queues() with usbhid->lock held and the others call it without holding the lock. The first item in particular causes a problem following a reset-resume if the driver hasn't started up its I/O. URB submission fails because usbhid->urbin is NULL, and this triggers an unending reset-retry loop. This patch fixes the problem by creating a new subroutine, hid_restart_io(), to carry out all the common activities. It also adds some checks that were missing in the original code: After a reset, there's no need to clear any halted endpoints. After a resume, if a reset is pending there's no need to restart any I/O until the reset is finished. After a resume, if the interrupt-IN endpoint is halted there's no need to submit the input URB until the halt has been cleared. Signed-off-by: Alan Stern Reported-by: Daniel Fraga Tested-by: Daniel Fraga Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit 77e4dd2c8f1216c08d4cfc1c1e746a2200f383a1 Author: Sugar Zhang Date: Fri Mar 18 14:54:22 2016 +0800 ASoC: rt5640: Correct the digital interface data select commit 653aa4645244042826f105aab1be3d01b3d493ca upstream. this patch corrects the interface adc/dac control register definition according to datasheet. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit f58a6c08ebdfa978178bbca78c2ba744a2665912 Author: Ben Hutchings Date: Sun May 1 18:00:43 2016 +0200 Revert "net: validate variable length ll headers" This reverts commit 2793a23aacbd754dbbb5cb75093deb7e4103bace, which was commit 2793a23aacbd754dbbb5cb75093deb7e4103bace upstream. It is pointless unless af_packet calls the new function. Signed-off-by: Ben Hutchings commit 8547d08f56fb267be3a7e07d029d1db920073811 Author: Ben Hutchings Date: Sun May 1 17:59:44 2016 +0200 Revert "ax25: add link layer header validation function" This reverts commit ea47781c26510e5d97f80f9aceafe9065bd5e3aa, which was commit ea47781c26510e5d97f80f9aceafe9065bd5e3aa upstream. It is pointless unless af_packet calls the new function. Signed-off-by: Ben Hutchings