Android hikey linaro 4.4 #19

commit a44323e upstream. The current code goes through a lot of indirection just to call a known handler. Simplify it: just call the handlers directly. Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f840ab1 upstream. The freq_table array is not populated before calling thermal_of_cooling_register. The code which populates the freq table was introduced in commit f685901. This should be done before registering new thermal cooling device. The log shows effects of this wrong decision. [ 2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34 [ 2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34 Fixes: f685901 ("thermal: cpu_cooling: Store frequencies in descending order") Signed-off-by: Lukasz Luba <[email protected]> Acked-by: Javi Merino <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Zhang Rui <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 62a584f upstream. As vm.dirty_[background_]bytes can't be applied verbatim to multiple cgroup writeback domains, they get converted to percentages in domain_dirty_limits() and applied the same way as vm.dirty_[background]ratio. However, if the specified bytes is lower than 1% of available memory, the calculated ratios become zero and the writeback domain gets throttled constantly. Fix it by using per-PAGE_SIZE instead of percentage for ratio calculations. Also, the updated DIV_ROUND_UP() usages now should yield 1/4096 (0.0244%) as the minimum ratio as long as the specified bytes are above zero. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Miao Xie <[email protected]> Link: http://lkml.kernel.org/g/[email protected] Fixes: 9fc3a43 ("writeback: separate out domain_dirty_limits()") Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Adjusted comment based on Jan's suggestion. Signed-off-by: Jens Axboe <[email protected]>

commit d50039e upstream. Also simplify the logic a bit. Signed-off-by: J. Bruce Fields <[email protected]> Acked-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit feb9dad upstream. It used to be the case that state had an rwlock that was locked for write by downgrades, but for read for upgrades (opens). Well, the problem is if there are two competing opens for the same state, they step on each other toes potentially leading to leaking file descriptors from the state structure, since access mode is a bitmap only set once. Signed-off-by: Oleg Drokin <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5cc1fb2 upstream. To avoid racing entry into nfs4_get_vfs_file(). Make init_open_stateid() return with locked stateid to be unlocked by the caller. Signed-off-by: Oleg Drokin <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 485e71e upstream. Factor out part of posix_acl_xattr_set into a common function that takes a posix_acl, which nfsd can also call. The prototype already exists in include/linux/posix_acl.h. Signed-off-by: Andreas Gruenbacher <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9996537 upstream. Use set_posix_acl, which includes proper permission checks, instead of calling ->set_acl directly. Without this anyone may be able to grant themselves permissions to a file by setting the ACL. Lock the inode to make the new checks atomic with respect to set_acl. (Also, nfsd was the only caller of set_acl not locking the inode, so I suspect this may fix other races.) This also simplifies the code, and ensures our ACLs are checked by posix_acl_valid. The permission checks and the inode locking were lost with commit 4ac7249, which changed nfsd to use the set_acl inode operation directly instead of going through xattr handlers. Reported-by: David Sinquin <[email protected]> [[email protected]: use set_posix_acl] Fixes: 4ac7249 Cc: Christoph Hellwig <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d20cb71 upstream. In "NFSv4: Move dentry instantiation into the NFSv4-specific atomic open code" unconditional d_drop() after the ->open_context() had been removed. It had been correct for success cases (there ->open_context() itself had been doing dcache manipulations), but not for error ones. Only one of those (ENOENT) got a compensatory d_drop() added in that commit, but in fact it should've been done for all errors. As it is, the case of O_CREAT non-exclusive open on a hashed negative dentry racing with e.g. symlink creation from another client ended up with ->open_context() getting an error and proceeding to call nfs_lookup(). On a hashed dentry, which would've instantly triggered BUG_ON() in d_materialise_unique() (or, these days, its equivalent in d_splice_alias()). Tested-by: Oleg Drokin <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e547f26 upstream. Olga Kornievskaia reports that the following test fails to trigger an OPEN_DOWNGRADE on the wire, and only triggers the final CLOSE. fd0 = open(foo, RDRW) -- should be open on the wire for "both" fd1 = open(foo, RDONLY) -- should be open on the wire for "read" close(fd0) -- should trigger an open_downgrade read(fd1) close(fd1) The issue is that we're missing a check for whether or not the current state transitioned from an O_RDWR state as opposed to having transitioned from a combination of O_RDONLY and O_WRONLY. Reported-by: Olga Kornievskaia <[email protected]> Fixes: cd9288f ("NFSv4: Fix another bug in the close/open_downgrade code") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 20c1522 upstream. The value used for Micrel PHY mask is not correct. Use the MICREL_PHY_ID_MASK definition instead. Thanks to Jiri Luznicky for proposing the fix at https://community.freescale.com/thread/387739 Fixes: 709bc06 ("ARM: imx6ul: add fec MAC refrence clock and phy fixup init") Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6245318 upstream. In a subsequent patch, pmd_mknotpresent will clear the valid bit of the pmd entry, resulting in a not-present entry from the hardware's perspective. Unfortunately, pmd_present simply checks for a non-zero pmd value and will therefore continue to return true even after a pmd_mknotpresent operation. Since pmd_mknotpresent is only used for managing huge entries, this is only an issue for the 3-level case. This patch fixes the 3-level pmd_present implementation to take into account the valid bit. For bisectability, the change is made before the fix to pmd_mknotpresent. [[email protected]: comment update regarding pmd_mknotpresent patch] Fixes: 8d96250 ("ARM: mm: Transparent huge page support for LPAE systems.") Cc: Russell King <[email protected]> Cc: Steve Capper <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 56530f5 upstream. Currently pmd_mknotpresent will use a zero entry to respresent an invalidated pmd. Unfortunately this definition clashes with pmd_none, thus it is possible for a race condition to occur if zap_pmd_range sees pmd_none whilst __split_huge_pmd_locked is running too with pmdp_invalidate just called. This patch fixes the race condition by modifying pmd_mknotpresent to create non-zero faulting entries (as is done in other architectures), removing the ambiguity with pmd_none. [[email protected]: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT] Fixes: 8d96250 ("ARM: mm: Transparent huge page support for LPAE systems.") Reported-by: Kirill A. Shutemov <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Steve Capper <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 797179b upstream. Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never get a TLB refill exception in it when KVM is built as a module. This was observed to happen with the host MIPS kernel running under QEMU, due to a not entirely transparent optimisation in the QEMU TLB handling where TLB entries replaced with TLBWR are copied to a separate part of the TLB array. Code in those pages continue to be executable, but those mappings persist only until the next ASID switch, even if they are marked global. An ASID switch happens in __kvm_mips_vcpu_run() at exception level after switching to the guest exception base. Subsequent TLB mapped kernel instructions just prior to switching to the guest trigger a TLB refill exception, which enters the guest exception handlers without updating EPC. This appears as a guest triggered TLB refill on a host kernel mapped (host KSeg2) address, which is not handled correctly as user (guest) mode accesses to kernel (host) segments always generate address error exceptions. Signed-off-by: James Hogan <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Radim Krčmář <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1118dce upstream. Export these symbols such that UBIFS can implement ->migratepage. Signed-off-by: Richard Weinberger <[email protected]> Acked-by: Christoph Hellwig <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4ac1c17 upstream. During page migrations UBIFS might get confused and the following assert triggers: [ 213.480000] UBIFS assert failed in ubifs_set_page_dirty at 1451 (pid 436) [ 213.490000] CPU: 0 PID: 436 Comm: drm-stress-test Not tainted 4.4.4-00176-geaa802524636-dirty #1008 [ 213.490000] Hardware name: Allwinner sun4i/sun5i Families [ 213.490000] [<c0015e70>] (unwind_backtrace) from [<c0012cdc>] (show_stack+0x10/0x14) [ 213.490000] [<c0012cdc>] (show_stack) from [<c02ad834>] (dump_stack+0x8c/0xa0) [ 213.490000] [<c02ad834>] (dump_stack) from [<c0236ee8>] (ubifs_set_page_dirty+0x44/0x50) [ 213.490000] [<c0236ee8>] (ubifs_set_page_dirty) from [<c00fa0bc>] (try_to_unmap_one+0x10c/0x3a8) [ 213.490000] [<c00fa0bc>] (try_to_unmap_one) from [<c00fadb4>] (rmap_walk+0xb4/0x290) [ 213.490000] [<c00fadb4>] (rmap_walk) from [<c00fb1bc>] (try_to_unmap+0x64/0x80) [ 213.490000] [<c00fb1bc>] (try_to_unmap) from [<c010dc28>] (migrate_pages+0x328/0x7a0) [ 213.490000] [<c010dc28>] (migrate_pages) from [<c00d0cb0>] (alloc_contig_range+0x168/0x2f4) [ 213.490000] [<c00d0cb0>] (alloc_contig_range) from [<c010ec00>] (cma_alloc+0x170/0x2c0) [ 213.490000] [<c010ec00>] (cma_alloc) from [<c001a958>] (__alloc_from_contiguous+0x38/0xd8) [ 213.490000] [<c001a958>] (__alloc_from_contiguous) from [<c001ad44>] (__dma_alloc+0x23c/0x274) [ 213.490000] [<c001ad44>] (__dma_alloc) from [<c001ae08>] (arm_dma_alloc+0x54/0x5c) [ 213.490000] [<c001ae08>] (arm_dma_alloc) from [<c035cecc>] (drm_gem_cma_create+0xb8/0xf0) [ 213.490000] [<c035cecc>] (drm_gem_cma_create) from [<c035cf20>] (drm_gem_cma_create_with_handle+0x1c/0xe8) [ 213.490000] [<c035cf20>] (drm_gem_cma_create_with_handle) from [<c035d088>] (drm_gem_cma_dumb_create+0x3c/0x48) [ 213.490000] [<c035d088>] (drm_gem_cma_dumb_create) from [<c0341ed8>] (drm_ioctl+0x12c/0x444) [ 213.490000] [<c0341ed8>] (drm_ioctl) from [<c0121adc>] (do_vfs_ioctl+0x3f4/0x614) [ 213.490000] [<c0121adc>] (do_vfs_ioctl) from [<c0121d30>] (SyS_ioctl+0x34/0x5c) [ 213.490000] [<c0121d30>] (SyS_ioctl) from [<c000f2c0>] (ret_fast_syscall+0x0/0x34) UBIFS is using PagePrivate() which can have different meanings across filesystems. Therefore the generic page migration code cannot handle this case correctly. We have to implement our own migration function which basically does a plain copy but also duplicates the page private flag. UBIFS is not a block device filesystem and cannot use buffer_migrate_page(). Signed-off-by: Kirill A. Shutemov <[email protected]> [rw: Massaged changelog, build fixes, etc...] Signed-off-by: Richard Weinberger <[email protected]> Acked-by: Christoph Hellwig <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8974189 upstream. As per commit: b7fa30c ("sched/fair: Fix post_init_entity_util_avg() serialization") > the code generated from update_cfs_rq_load_avg(): > > if (atomic_long_read(&cfs_rq->removed_load_avg)) { > s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0); > sa->load_avg = max_t(long, sa->load_avg - r, 0); > sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0); > removed_load = 1; > } > > turns into: > > ffffffff81087064: 49 8b 85 98 00 00 00 mov 0x98(%r13),%rax > ffffffff8108706b: 48 85 c0 test %rax,%rax > ffffffff8108706e: 74 40 je ffffffff810870b0 <update_blocked_averages+0xc0> > ffffffff81087070: 4c 89 f8 mov %r15,%rax > ffffffff81087073: 49 87 85 98 00 00 00 xchg %rax,0x98(%r13) > ffffffff8108707a: 49 29 45 70 sub %rax,0x70(%r13) > ffffffff8108707e: 4c 89 f9 mov %r15,%rcx > ffffffff81087081: bb 01 00 00 00 mov $0x1,%ebx > ffffffff81087086: 49 83 7d 70 00 cmpq $0x0,0x70(%r13) > ffffffff8108708b: 49 0f 49 4d 70 cmovns 0x70(%r13),%rcx > > Which you'll note ends up with sa->load_avg -= r in memory at > ffffffff8108707a. So I _should_ have looked at other unserialized users of ->load_avg, but alas. Luckily nikbor reported a similar /0 from task_h_load() which instantly triggered recollection of this here problem. Aside from the intermediate value hitting memory and causing problems, there's another problem: the underflow detection relies on the signed bit. This reduces the effective width of the variables, IOW its effectively the same as having these variables be of signed type. This patch changes to a different means of unsigned underflow detection to not rely on the signed bit. This allows the variables to use the 'full' unsigned range. And it does so with explicit LOAD - STORE to ensure any intermediate value will never be visible in memory, allowing these unserialized loads. Note: GCC generates crap code for this, might warrant a look later. Note2: I say 'full' above, if we end up at U*_MAX we'll still explode; maybe we should do clamping on add too. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yuyang Du <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Fixes: 9d89c25 ("sched/fair: Rewrite runnable load and utilization average tracking") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit eb70db8 ] People who use PACKET_FANOUT_HASH want a symmetric hash, meaning that they want packets going in both directions on a flow to hash to the same bucket. The core kernel SKB hash became non-symmetric when the ipv6 flow label and other entities were incorporated into the standard flow hash order to increase entropy. But there are no users of PACKET_FANOUT_HASH who want an assymetric hash, they all want a symmetric one. Therefore, use the flow dissector to compute a flat symmetric hash over only the protocol, addresses and ports. This hash does not get installed into and override the normal skb hash, so this change has no effect whatsoever on the rest of the stack. Reported-by: Eric Leblond <[email protected]> Tested-by: Eric Leblond <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 82a31b9 ] Similar to commit 9b36881 ("net: fix bridge multicast packet checksum validation") we need to fixup the checksum for CHECKSUM_COMPLETE when pushing skb on RX path. Otherwise we get similar splats. Cc: Jamal Hadi Salim <[email protected]> Cc: Tom Herbert <[email protected]> Signed-off-by: Cong Wang <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit c086e70 ] Several Lenovo users have reported problems with their Sierra Wireless EM7455 modem. The driver has loaded successfully and the MBIM management channel has appeared to work, including establishing a connection to the mobile network. But no frames have been received over the data interface. The problem affects all EM7455 and MC7455, and is assumed to affect other modems based on the same Qualcomm chipset and baseband firmware. Testing narrowed the problem down to what seems to be a firmware timing bug during initialization. Adding a short sleep while probing is sufficient to make the problem disappear. Experiments have shown that 1-2 ms is too little to have any effect, while 10-20 ms is enough to reliably succeed. Reported-by: Stefan Armbruster <[email protected]> Reported-by: Ralph Plawetzki <[email protected]> Reported-by: Andreas Fett <[email protected]> Reported-by: Rasmus Lerdorf <[email protected]> Reported-by: Samo Ratnik <[email protected]> Reported-and-tested-by: Aleksander Morgado <[email protected]> Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 903ce4a ] It was first reported and reproduced by Petr (thanks!) in https://bugzilla.kernel.org/show_bug.cgi?id=119581 free_percpu(rt->rt6i_pcpu) used to always happen in ip6_dst_destroy(). However, after fixing a deadlock bug in commit 9c7370a ("ipv6: Fix a potential deadlock when creating pcpu rt"), free_percpu() is not called before setting non_pcpu_rt->rt6i_pcpu to NULL. It is worth to note that rt6i_pcpu is protected by table->tb6_lock. kmemleak somehow did not report it. We nailed it down by observing the pcpu entries in /proc/vmallocinfo (first suggested by Hannes, thanks!). Signed-off-by: Martin KaFai Lau <[email protected]> Fixes: 9c7370a ("ipv6: Fix a potential deadlock when creating pcpu rt") Reported-by: Petr Novopashenniy <[email protected]> Tested-by: Petr Novopashenniy <[email protected]> Acked-by: Hannes Frederic Sowa <[email protected]> Cc: Hannes Frederic Sowa <[email protected]> Cc: Petr Novopashenniy <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4d0cb15 upstream. Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b31ac42 upstream. Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

@t

commit 3832742 upstream. If __key_link_begin() failed then "edit" would be uninitialized. I've added a check to fix that. This allows a random user to crash the kernel, though it's quite difficult to achieve. There are three ways it can be done as the user would have to cause an error to occur in __key_link(): (1) Cause the kernel to run out of memory. In practice, this is difficult to achieve without ENOMEM cropping up elsewhere and aborting the attempt. (2) Revoke the destination keyring between the keyring ID being looked up and it being tested for revocation. In practice, this is difficult to time correctly because the KEYCTL_REJECT function can only be used from the request-key upcall process. Further, users can only make use of what's in /sbin/request-key.conf, though this does including a rejection debugging test - which means that the destination keyring has to be the caller's session keyring in practice. (3) Have just enough key quota available to create a key, a new session keyring for the upcall and a link in the session keyring, but not then sufficient quota to create a link in the nominated destination keyring so that it fails with EDQUOT. The bug can be triggered using option (3) above using something like the following: echo 80 >/proc/sys/kernel/keys/root_maxbytes keyctl request2 user debug:fred negate @t The above sets the quota to something much lower (80) to make the bug easier to trigger, but this is dependent on the system. Note also that the name of the keyring created contains a random number that may be between 1 and 10 characters in size, so may throw the test off by changing the amount of quota used. Assuming the failure occurs, something like the following will be seen: kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h ------------[ cut here ]------------ kernel BUG at ../mm/slab.c:2821! ... RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25 RSP: 0018:ffff8804014a7de8 EFLAGS: 00010092 RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000 RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300 RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202 R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001 ... Call Trace: kfree+0xde/0x1bc assoc_array_cancel_edit+0x1f/0x36 __key_link_end+0x55/0x63 key_reject_and_link+0x124/0x155 keyctl_reject_key+0xb6/0xe0 keyctl_negate_key+0x10/0x12 SyS_keyctl+0x9f/0xe7 do_syscall_64+0x63/0x13a entry_SYSCALL64_slow_path+0x25/0x25 Fixes: f70e2e0 ('KEYS: Do preallocation for __key_link()') Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit caf1ff2 upstream. These days, we experienced one guest crash with 8 cores and 3 disks, with qemu error logs as bellow: qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. And then we found one patch(bdf0263) in qemu tree, which said could fix this bug. Execute the following script will reproduce the BUG quickly: irq_affinity.sh ======================================================================== vda_irq_num=25 vdb_irq_num=27 while [ 1 ] do for irq in {1,2,4,8,10,20,40,80} do echo $irq > /proc/irq/$vda_irq_num/smp_affinity echo $irq > /proc/irq/$vdb_irq_num/smp_affinity dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct done done ======================================================================== The following qemu log is added in the qemu code and is displayed when this bug reproduced: kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024, irq_routes->nr: 1024, gsi_count: 1024. That's to say when irq_routes->nr == 1024, there are 1024 routing entries, but in the kernel code when routes->nr >= 1024, will just return -EINVAL; The nr is the number of the routing entries which is in of [1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1]. This patch fix the BUG above. Signed-off-by: Xiubo Li <[email protected]> Signed-off-by: Wei Tang <[email protected]> Signed-off-by: Zhang Zhuoyu <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ff30ef4 upstream. I couldn't get Xen to boot a L2 HVM when it was nested under KVM - it was getting a GP(0) on a rather unspecial vmread from Xen: (XEN) ----[ Xen-4.7.0-rc x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: e008:[<ffff82d0801e629e>] vmx_get_segment_register+0x14e/0x450 (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor (d1v0) (XEN) rax: ffff82d0801e6288 rbx: ffff83003ffbfb7c rcx: fffffffffffab928 (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff83000bdd0000 (XEN) rbp: ffff83000bdd0000 rsp: ffff83003ffbfab0 r8: ffff830038813910 (XEN) r9: ffff83003faf3958 r10: 0000000a3b9f7640 r11: ffff83003f82d418 (XEN) r12: 0000000000000000 r13: ffff83003ffbffff r14: 0000000000004802 (XEN) r15: 0000000000000008 cr0: 0000000080050033 cr4: 00000000001526e0 (XEN) cr3: 000000003fc79000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen code around <ffff82d0801e629e> (vmx_get_segment_register+0x14e/0x450): (XEN) 00 00 41 be 02 48 00 00 <44> 0f 78 74 24 08 0f 86 38 56 00 00 b8 08 68 00 (XEN) Xen stack trace from rsp=ffff83003ffbfab0: ... (XEN) Xen call trace: (XEN) [<ffff82d0801e629e>] vmx_get_segment_register+0x14e/0x450 (XEN) [<ffff82d0801f3695>] get_page_from_gfn_p2m+0x165/0x300 (XEN) [<ffff82d0801bfe32>] hvmemul_get_seg_reg+0x52/0x60 (XEN) [<ffff82d0801bfe93>] hvm_emulate_prepare+0x53/0x70 (XEN) [<ffff82d0801ccacb>] handle_mmio+0x2b/0xd0 (XEN) [<ffff82d0801be591>] emulate.c#_hvm_emulate_one+0x111/0x2c0 (XEN) [<ffff82d0801cd6a4>] handle_hvm_io_completion+0x274/0x2a0 (XEN) [<ffff82d0801f334a>] __get_gfn_type_access+0xfa/0x270 (XEN) [<ffff82d08012f3bb>] timer.c#add_entry+0x4b/0xb0 (XEN) [<ffff82d08012f80c>] timer.c#remove_entry+0x7c/0x90 (XEN) [<ffff82d0801c8433>] hvm_do_resume+0x23/0x140 (XEN) [<ffff82d0801e4fe7>] vmx_do_resume+0xa7/0x140 (XEN) [<ffff82d080164aeb>] context_switch+0x13b/0xe40 (XEN) [<ffff82d080128e6e>] schedule.c#schedule+0x22e/0x570 (XEN) [<ffff82d08012c0cc>] softirq.c#__do_softirq+0x5c/0x90 (XEN) [<ffff82d0801602c5>] domain.c#idle_loop+0x25/0x50 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=0000] (XEN) **************************************** Tracing my host KVM showed it was the one injecting the GP(0) when emulating the VMREAD and checking the destination segment permissions in get_vmx_mem_address(): 3) | vmx_handle_exit() { 3) | handle_vmread() { 3) | nested_vmx_check_permission() { 3) | vmx_get_segment() { 3) 0.074 us | vmx_read_guest_seg_base(); 3) 0.065 us | vmx_read_guest_seg_selector(); 3) 0.066 us | vmx_read_guest_seg_ar(); 3) 1.636 us | } 3) 0.058 us | vmx_get_rflags(); 3) 0.062 us | vmx_read_guest_seg_ar(); 3) 3.469 us | } 3) | vmx_get_cs_db_l_bits() { 3) 0.058 us | vmx_read_guest_seg_ar(); 3) 0.662 us | } 3) | get_vmx_mem_address() { 3) 0.068 us | vmx_cache_reg(); 3) | vmx_get_segment() { 3) 0.074 us | vmx_read_guest_seg_base(); 3) 0.068 us | vmx_read_guest_seg_selector(); 3) 0.071 us | vmx_read_guest_seg_ar(); 3) 1.756 us | } 3) | kvm_queue_exception_e() { 3) 0.066 us | kvm_multiple_exception(); 3) 0.684 us | } 3) 4.085 us | } 3) 9.833 us | } 3) + 10.366 us | } Cross-checking the KVM/VMX VMREAD emulation code with the Intel Software Developper Manual Volume 3C - "VMREAD - Read Field from Virtual-Machine Control Structure", I found that we're enforcing that the destination operand is NOT located in a read-only data segment or any code segment when the L1 is in long mode - BUT that check should only happen when it is in protected mode. Shuffling the code a bit to make our emulation follow the specification allows me to boot a Xen dom0 in a nested KVM and start HVM L2 guests without problems. Fixes: f9eb4af ("KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions") Signed-off-by: Quentin Casasnovas <[email protected]> Cc: Eugene Korenevsky <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Radim Krčmář <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: H. Peter Anvin <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ed596a4 upstream. Flushing a work that reschedules itself is not a sensible operation. It needs to be killed. Failure to do so leads to a kernel panic in the timer code. Signed-off-by: Oliver Neukum <[email protected]> Reviewed-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…mands commit 93a2001 upstream. This patch validates the num_values parameter from userland during the HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter leading to a heap overflow. Signed-off-by: Scott Bauer <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6dd2e27 upstream. The usage Confidence is mandary to Windows Precision Touchpad devices. If it is examined in input_mapping on a WIndows Precision Touchpad, a new add quirk MT_QUIRK_CONFIDENCE desgned for such devices will be applied to the device. A touch with the confidence bit is not set is determined as invalid. Tested on Dell XPS13 9343 Reviewed-by: Benjamin Tissoires <[email protected]> Tested-by: Andy Lutomirski <[email protected]> # XPS 13 9350, BIOS 1.4.3 Signed-off-by: Allen Hung <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 70c8217 upstream. If a task uses a non constant string for the format parameter in trace_printk(), then the trace_printk_fmt variable is set to NULL. This variable is then saved in the __trace_printk_fmt section. The function hold_module_trace_bprintk_format() checks to see if duplicate formats are used by modules, and reuses them if so (saves them to the list if it is new). But this function calls lookup_format() that does a strcmp() to the value (which is now NULL) and can cause a kernel oops. This wasn't an issue till 3debb0a ("tracing: Fix trace_printk() to print when not using bprintk()") which added "__used" to the trace_printk_fmt variable, and before that, the kernel simply optimized it out (no NULL value was saved). The fix is simply to handle the NULL pointer in lookup_format() and have the caller ignore the value if it was NULL. Link: http://lkml.kernel.org/r/[email protected] Reported-by: xingzhen <[email protected]> Acked-by: Namhyung Kim <[email protected]> Fixes: 3debb0a ("tracing: Fix trace_printk() to print when not using bprintk()") Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7e1b1fc upstream. Modules which register drivers via standard path (driver_register) in parallel can cause a warning: WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/module/saa7146/drivers' Modules linked in: hexium_gemini(+) mxb(+) ... ... Call Trace: ... [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80 [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90 [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340 [<ffffffff8140f5b8>] kobject_add+0x68/0xb0 [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70 [<ffffffff8157a703>] module_add_driver+0xc3/0xd0 [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280 [<ffffffff815604c0>] driver_register+0x60/0xe0 [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70 [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146] [<ffffffffa0033011>] hexium_init_module+0x11/0x1000 [hexium_gemini] ... As can be (mostly) seen, driver_register causes this call sequence: -> bus_add_driver -> module_add_driver -> module_create_drivers_dir The last one creates "drivers" directory in /sys/module/<...>. When this is done in parallel, the directory is attempted to be created twice at the same time. This can be easily reproduced by loading mxb and hexium_gemini in parallel: while :; do modprobe mxb & modprobe hexium_gemini wait rmmod mxb hexium_gemini saa7146_vv saa7146 done saa7146 calls pci_register_driver for both mxb and hexium_gemini, which means /sys/module/saa7146/drivers is to be created for both of them. Fix this by a new mutex in module_create_drivers_dir which makes the test-and-create "drivers" dir atomic. I inverted the condition and removed 'return' to avoid multiple unlocks or a goto. Signed-off-by: Jiri Slaby <[email protected]> Fixes: fe480a2 (Modules: only add drivers/ direcory if needed) Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9aeb26c upstream. The map_sg callback is missing from arm_smmu_ops, but is required by iommu.h. Similarly to most other IOMMU drivers, connect it to default_iommu_map_sg. Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a4c34ff upstream. This seems to be required on some X58 chipsets on systems with more than one IOMMU. QI does not work until it is enabled on all IOMMUs in the system. Reported-by: Dheeraj CVR <[email protected]> Tested-by: Dheeraj CVR <[email protected]> Fixes: 5f0a7f7 ('iommu/vt-d: Make root entry visible for hardware right after allocation') Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 522e5cb upstream. There is a race condition in the AMD IOMMU init code that causes requested unity mappings to be blocked by the IOMMU for a short period of time. This results on boot failures and IO_PAGE_FAULTs on some machines. Fix this by making sure the unity mappings are installed before all other DMA is blocked. Fixes: aafd8ba ('iommu/amd: Implement add_device and remove_device') Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d3922b6 upstream. - Fixed black screen for some resolutions of G200e rev4 - Fixed testm & testn which had predetermined value. Reported-by: Jan Beulich <[email protected]> Signed-off-by: Mathieu Larouche <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…v_msg() commit ae4ea9a upstream. Commit 7ea0ed2 ("ipmi: Make the message handler easier to use for SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg() for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list. That could lead to following list corruption problems: 1) low-level function treats smi_msg as not connected to list handle_one_recv_msg() could end up calling smi_send(), which assumes the msg is not connected to list. For example, the following sequence could corrupt list by doing list_add_tail() for the entry still connected to other list. handle_new_recv_msgs() msg = list_entry(waiting_rcv_msgs) handle_one_recv_msg(msg) handle_ipmb_get_msg_cmd(msg) smi_send(msg) spin_lock(xmit_msgs_lock) list_add_tail(msg) spin_unlock(xmit_msgs_lock) 2) race between multiple handle_new_recv_msgs() instances handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling handle_one_recv_msg() then retakes the lock and list_del() it. If others call handle_new_recv_msgs() during the window shown below list_del() will be done twice for the same smi_msg. handle_new_recv_msgs() spin_lock(waiting_rcv_msgs_lock) msg = list_entry(waiting_rcv_msgs) spin_unlock(waiting_rcv_msgs_lock) | | handle_one_recv_msg(msg) | spin_lock(waiting_rcv_msgs_lock) list_del(msg) spin_unlock(waiting_rcv_msgs_lock) Fixes: 7ea0ed2 ("ipmi: Make the message handler easier to use for SMI interfaces") Signed-off-by: Jun'ichi Nomura <[email protected]> [Added a comment to describe why this works.] Signed-off-by: Corey Minyard <[email protected]> Tested-by: Ye Feng <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dbd4d7c upstream. We validate pstate using PSR_MODE32_BIT, which is part of the user-provided pstate (and cannot be trusted). Also, we conflate validation of AArch32 and AArch64 pstate values, making the code difficult to reason about. Instead, validate the pstate value based on the associated task. The task may or may not be current (e.g. when using ptrace), so this must be passed explicitly by callers. To avoid circular header dependencies via sched.h, is_compat_task is pulled out of asm/ptrace.h. To make the code possible to reason about, the AArch64 and AArch32 validation is split into separate functions. Software must respect the RES0 policy for SPSR bits, and thus the kernel mirrors the hardware policy (RAZ/WI) for bits as-yet unallocated. When these acquire an architected meaning writes may be permitted (potentially with additional validation). Signed-off-by: Mark Rutland <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Dave Martin <[email protected]> Cc: James Morse <[email protected]> Cc: Peter Maydell <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> [ rebased for v4.1+ This avoids a user-triggerable Oops() if a task is switched to a mode not supported by the kernel (e.g. switching a 64-bit task to AArch32). ] Signed-off-by: James Morse <[email protected]> Reviewed-by: Mark Rutland <[email protected]> [backport] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a118084 upstream. Needed by the following fix. Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit eb0a4a4 upstream. Overlayfs uses separate inodes even in the case of hard links on the underlying filesystems. This is a problem for AF_UNIX socket implementation which indexes sockets based on the inode. This resulted in hard linked sockets not working. The fix is to use the real, underlying inode. Test case follows: -- ovl-sock-test.c -- #include <unistd.h> #include <err.h> #include <sys/socket.h> #include <sys/un.h> #define SOCK "test-sock" #define SOCK2 "test-sock2" int main(void) { int fd, fd2; struct sockaddr_un addr = { .sun_family = AF_UNIX, .sun_path = SOCK, }; struct sockaddr_un addr2 = { .sun_family = AF_UNIX, .sun_path = SOCK2, }; unlink(SOCK); unlink(SOCK2); if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) err(1, "socket"); if (bind(fd, (struct sockaddr *) &addr, sizeof(addr)) == -1) err(1, "bind"); if (listen(fd, 0) == -1) err(1, "listen"); if (link(SOCK, SOCK2) == -1) err(1, "link"); if ((fd2 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) err(1, "socket"); if (connect(fd2, (struct sockaddr *) &addr2, sizeof(addr2)) == -1) err (1, "connect"); return 0; } ---- Reported-by: Alexander Morozov <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…destruction commit 4f996e2 upstream. Atomic allocations can trigger async map extensions which is serviced by chunk->map_extend_work. pcpu_balance_work which is responsible for destroying idle chunks wasn't synchronizing properly against chunk->map_extend_work and may end up freeing the chunk while the work item is still in flight. This patch fixes the bug by rolling async map extension operations into pcpu_balance_work. Signed-off-by: Tejun Heo <[email protected]> Reported-and-tested-by: Alexei Starovoitov <[email protected]> Reported-by: Vlastimil Babka <[email protected]> Reported-by: Sasha Levin <[email protected]> Fixes: 9c824b6 ("percpu: make sure chunk->map array has available space") Signed-off-by: Greg Kroah-Hartman <[email protected]>

…nk destruction commit 6710e59 upstream. For non-atomic allocations, pcpu_alloc() can try to extend the area map synchronously after dropping pcpu_lock; however, the extension wasn't synchronized against chunk destruction and the chunk might get freed while extension is in progress. This patch fixes the bug by putting most of non-atomic allocations under pcpu_alloc_mutex to synchronize against pcpu_balance_work which is responsible for async chunk management including destruction. Signed-off-by: Tejun Heo <[email protected]> Reported-and-tested-by: Alexei Starovoitov <[email protected]> Reported-by: Vlastimil Babka <[email protected]> Reported-by: Sasha Levin <[email protected]> Fixes: 1a4d760 ("percpu: implement asynchronous chunk population") Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 64c1292 upstream. The test for !trans->blocks_used in btrfs_abort_transaction is insufficient to determine whether it's safe to drop the transaction handle on the floor. btrfs_cow_block, informed by should_cow_block, can return blocks that have already been CoW'd in the current transaction. trans->blocks_used is only incremented for new block allocations. If an operation overlaps the blocks in the current transaction entirely and must abort the transaction, we'll happily let it clean up the trans handle even though it may have modified the blocks and will commit an incomplete operation. In the long-term, I'd like to do closer tracking of when the fs is actually modified so we can still recover as gracefully as possible, but that approach will need some discussion. In the short term, since this is the only code using trans->blocks_used, let's just switch it to a bool indicating whether any blocks were used and set it when should_cow_block returns false. Signed-off-by: Jeff Mahoney <[email protected]> Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 05082b8 upstream. When executing in a PCI passthrough based virtuzliation environment, the hypervisor will usually attempt to send a PCIe bus reset signal to the ASIC when the VM reboots. In this scenario, the card is not correctly initialized, but we still consider it to be posted. Therefore, in a passthrough based environemnt we should always post the card to guarantee it is in a good state for driver initialization. Ported from amdgpu commit: amdgpu: fix asic initialization for virtualized environments Cc: Andres Rodriguez <[email protected]> Cc: Alex Williamson <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8b18300 upstream. Wrong operator. Reported-by: David Binderman <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 972228d upstream. recover_peb() was never power cut aware, if a power cut happened right after writing the VID header upon next attach UBI would blindly use the new partial written PEB and all data from the old PEB is lost. In order to make recover_peb() power cut aware, write the new VID with a proper crc and copy_flag set such that the UBI attach process will detect whether the new PEB is completely written or not. We cannot directly use ubi_eba_atomic_leb_change() since we'd have to unlock the LEB which is facing a write error. Reported-by: Jörg Pfähler <[email protected]> Reviewed-by: Jörg Pfähler <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 121b78e upstream. When unbinding a process from a device (initiated by amd_iommu_v2), the driver needs to make sure that process still exists in the process table. There is a possibility that amdkfd's own notifier handler - kfd_process_notifier_release() - was called before the unbind function and it already removed the process from the process table. v2: Because there can be only one process with the specified pasid, and because *p can't be NULL inside the hash_for_each_rcu macro, it is more reasonable to just put the whole code inside the if statement that compares the pasid value. That way, when we exit hash_for_each_rcu, we simply exit the function as well. Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bc4755a upstream. amdkfd need to destroy the debug manager in case amdkfd's notifier function is called before the unbind function, because in that case, the unbind function will exit without destroying debug manager. Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fd2d2ba upstream. Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch. Fixes: 91a25e4 ("drm/dp/mst: deallocate payload on port destruction") Signed-off-by: Andrey Grodzovsky <[email protected]> Reviewed-by: Lyude <[email protected]> Cc: Mykola Lysenko <[email protected]> Cc: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 87c9403 upstream. Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Reported-by: Cornelia Huck <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Tested-by: Cornelia Huck <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a8953c5 upstream. It appears that, for whatever reason, both link A and B use the same register to control the training pattern. It's a little odd, as the GPUs before this (Tesla/Fermi1) have per-link registers, as do newer GPUs (Maxwell). Fixes the third DP output on NVS 510 (GK107). Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 383d0a4 upstream. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f045f45 upstream. Reported by KASAN. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 52dfcc5 upstream. Hello, after this commit: commit f045f45 Author: Ben Skeggs <[email protected]> Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses kernel started to oops when loading nouveau module when using GTX 780 Ti video adapter. This patch fixes the problem. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591 Signed-off-by: Dmitrii Tcvetkov <[email protected]> Suggested-by: Ilia Mirkin <[email protected]> Fixes: f045f45 ("nouveau_fbcon_init()") Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…attern commit 2172150 upstream. Fixes a regression caused by a stupid thinko from "disp/sor/gf119: both links use the same training register". Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 476490a upstream. Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL configurations. This causes issues on the first modeset, since we don't expect SSC to be left on and as a result, can't successfully power down the pipes or the transcoders using it. Here's an example from this Dell OptiPlex 990: [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled [drm:intel_modeset_init] 2 display pipes available. [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm:intel_crt_reset] crt adpa set to 0xf40000 [drm:intel_dp_init_connector] Adding DP connector on port C [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1 [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0 [drm:ironlake_init_pch_refclk] Disabling SSC entirely … later we try committing the first modeset … [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A [drm:intel_dump_pipe_config] cpu_transcoder: A … [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07 [drm:intel_dump_pipe_config] planes on this crtc [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258 [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600 [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0 [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0 [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A [drm:intel_disable_pipe] disabling pipe A ------------[ cut here ]------------ WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915] pipe_off wait timed out … ---[ end trace 94fc8aa03ae139e8 ]--- [drm:intel_dp_link_down] [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A Later modesets succeed since they reset the DPLL's configuration anyway, but this is enough to get stuck with a big fat warning in dmesg. A better solution would be to add refcounts for the SSC source, but for now leaving the source clock on should suffice. Changes since v4: - Fix calculation of final for systems with LVDS panels (fixes BUG() on CI test suite) Changes since v3: - Move temp variable into loop - Move checks for using_ssc_source to after we've figured out has_ck505 - Add using_ssc_source to debug output Changes since v2: - Fix debug output for when we disable the CPU source Changes since v1: - Leave the SSC source clock on instead of just shutting it off on all of the DPLL configurations. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Lyude <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 664a84d upstream. During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there is no guarantee that the value in the actual register will match the cached value. If i915 isn't loaded in the kernel that loads the hibernation image, the port may well be on (eg. left on by the BIOS). The encoder state readout does the right thing in this case and updates our encoder state to reflect the actual hardware state. However the post-resume modeset will then use the stale cached port register value in intel_dp_link_down() and potentially confuse the hardware. This was caught by the following assert WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915] eDP PLL state assertion failure (expected on, current off) on account of the eDP PLL getting prematurely turned off when shutting down the port, since the DP_PLL_ENABLE bit wasn't set in the cached register value. Presumably I introduced this problem in commit 6fec766 ("drm/i915: Use intel_dp->DP in eDP PLL setup") as before that we didn't update the cached value after shuttting the port down. That's assuming the port got enabled at least once prior to hibernating. If that didn't happen then the cached value would still have been totally out of sync with reality (eg. first boot w/o eDP on, then hibernate, and then resume with eDP on). So, let's fix this properly and refresh the cached register value from the hardware register during resume. DDI platforms shouldn't use the cached value during port disable at least, so shouldn't have this particular issue. They might still have issues if we skip the initial modeset and then try to retrain the link or something. But untangling this DP vs. DDI mess is a bigger topic, so let's jut punt on DDI for now. Cc: Jani Nikula <[email protected]> Fixes: 6fec766 ("drm/i915: Use intel_dp->DP in eDP PLL setup") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 64989ca) Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b192400 upstream. In commit 7608a43 ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate") the owner field in the mutex was updated from being dependent upon CONFIG_SMP to using optimistic spin. Update our peek function to suite. Fixes:7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...") Reported-by: Hong Liu <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit 4f074a5) Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…uency commit a04e23d upstream. Update CDCLK_FREQ on BDW after changing the cdclk frequency. Not sure if this is a late addition to the spec, or if I simply overlooked this step when writing the original code. This is what Bspec has to say about CDCLK_FREQ: "Program this field to the CD clock frequency minus one. This is used to generate a divided down clock for miscellaneous timers in display." And the "Broadwell Sequences for Changing CD Clock Frequency" section clarifies this further: "For CD clock 337.5 MHz, program 337 decimal. For CD clock 450 MHz, program 449 decimal. For CD clock 540 MHz, program 539 decimal. For CD clock 675 MHz, program 674 decimal." Cc: [email protected] Cc: Mika Kahola <[email protected]> Fixes: b432e5c ("drm/i915: BDW clock change support") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]> (cherry picked from commit 7f1052a) Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b201e74 upstream. When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data in state->mode, as state->mode is not cleared when setting new mode. This patch adds drm_mode_set_crtcinfo() call to drm_mode_convert_umode(), which is called in both legacy and atomic paths. This should be fine as there's no reason to call drm_mode_convert_umode() without also setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6709887 upstream. drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so old data may be left there when a new mode is set, possibly causing odd issues. This patch improves the situation by always clearing the state->mode first. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1b7e38b upstream. The driver is only enabling scaling, but never disabling it, thus, if you enable the scaling feature once it stays enabled forever. Signed-off-by: Boris Brezillon <[email protected]> Reported-by: Alex Vazquez <[email protected]> Reviewed-by: Nicolas Ferre <[email protected]> Fixes: 1a39678 ("drm: add Atmel HLCDC Display Controller support") Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 94477bf upstream. There are cases where it is desired to see if a proposed placement is compatible with a buffer object before calling ttm_bo_validate(). Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 04319d8 upstream. Offer an option for advanced users who want larger modes at 16bpp. This becomes necessary after the fix: "Work around mode set failure in 2D VMs." Without this patch, there would be no way for existing advanced users to get to a high res mode, and the regression is they will likely get a black screen after a software update on their current VM. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7c20d21 upstream. In a low-memory 2D VM, fbdev can take up a large percentage of available memory, making them unavailable for other DRM clients. Since we do not take fbdev into account when filtering modes, we end up claiming to support more modes than we actually do. As a result, users get a black screen when setting a mode too large for current available memory. In a low-memory VM configuration, users can get a black screen for a mode as low as 1024x768. The current mode filtering mechanism keys off of SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount of surface memory we have. Since this value is a performance suggestion, not a hard limit, and since there should not be much of a performance impact for a 2D VM, rather than filtering out more modes, we will just allow ourselves to exceed the SVGA's performance suggestion. Also changed assumed bpp to 32 from 16 to make sure we can actually support all the modes listed. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4ed7e22 upstream. In certain scenarios, e.g. when fbdev is enabled, we can get into a situation where a vmw_framebuffer_pin() is called on a buffer that is already pinned. When this happens, ttm_bo_validate() will unintentially remove the TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way to actually pin the buffer again. To prevent this, if a buffer is already pinned, then instead of calling ttm_bo_validate(), just make sure the proposed placement is compatible with the existing placement. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d5f1a29 upstream. For the Screen Object display unit, we need to reserve a guest-invisible region equal to the size of the framebuffer for the host. This region can only be reserved in VRAM, whereas the guest-visible framebuffer can be reserved in either VRAM or GMR. As such priority should be given to the guest-invisible region otherwise in a limited VRAM situation, we can fail to allocate this region. This patch makes it so that vmw_sou_backing_alloc() is called before the framebuffer is pinned. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 58541f7 upstream. Rather than returning immediately, make sure to unlock the mutexes first. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Charmaine Lee <[email protected]> Reported-by: Emil Velikov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8f50b8e upstream. In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY is overwritten by the WEEXTRADELAY value from the device tree and GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device tree. As a consequence, the memory accesses cannot be configured properly when the extra delay are needed for OE and WE. Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the device tree file and prevents GPMC_CONFIG4_OEXTRADELAY being overwritten by the WEXTRADELAY value from the device tree. Signed-off-by: Ocquidant, Sebastien <[email protected]> Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6d6f283 upstream. Jim reported: UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12 shift exponent 35 is too large for 32-bit type 'long unsigned int' The use of 'unsigned long' type obviously is not correct here, make it 'unsigned long long' instead. Reported-by: Jim Cromie <[email protected]> Signed-off-by: Andrey Ryabinin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Imre Palik <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Fixes: 2c33645 ("perf/x86: Honor the architectural performance monitoring version") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Cc: Kevin Christopher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 842775f upstream. Fix a declared-but-not-defined warning when building with XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by commit dfd74a1 ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE"). Signed-off-by: Ross Lagerwall <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9954382 upstream. When attaching a pollfunc iio_trigger_attach_poll_func will allocate a virtual irq and call the driver's set_trigger_state function. Fix error handling to undo previous steps if any fails. In particular this fixes handling errors from a driver's set_trigger_state function. When using triggered buffers a failure to enable the trigger used to make the buffer unusable. Signed-off-by: Crestez Dan Leonard <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d43a411 upstream. Temperature channels report scaled samples in Celsius although expected as milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio. Gains are not implemented at all for LPS001WP pressure and temperature channels. This patch ensures that proper offsets and scales are exposed to userpace for both pressure and temperature channels. Also fix a NULL pointer exception when userspace reads content of sysfs scale attribute when gains are not defined. Signed-off-by: Gregor Boirie <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 590b92a upstream. Without this, the iio:deviceX is missing in the /sys/bus/i2c/devices/0-0039 Some userspace tools use this path to identify a specific instance of the device. Signed-off-by: Yong Li <[email protected]> Reviewed-By: Matt Ranostay <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5138806 upstream. IIO_CHAN_INFO_RAW was returning processed data which was incorrect. This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value. Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7d06436 upstream. Triggered buffers shouldn't return processed data, and the respective conversion was overflowing the defined .realbits for the channel. Cc: [email protected] Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 37b1ba2 upstream. Buffer wasn't of a valid size to allow the timestamp, and correct padding. This patchset also moves the buffer off the stack, and onto the heap. Cc: [email protected] Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0e35cf5 upstream. Apply the correct mask to enable all available humidity integration times. Currently, the driver defaults to 6500 and all is okay with that. However, if 3850 is selected we get a stuck bit and can't change back to 6500 or select 2500. (Verified with HDC1008) Signed-off-by: Alison Schofield <[email protected]> Cc: Daniel Baluta <[email protected]> Reviewed-by: Matt Ranostay <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 09bc0dd upstream. IIO_TEMP channel was being incorrectly reported back as Celsius when it should have been milliCelsius. This is via an incorrect scale value being returned to userspace. Signed-off-by: Matt Ranostay <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 94bef00 upstream. Shifting sensor data to the right 2 bits was incorrect and caused the scaling values + offsets to be invalid. Reported-by: Alison Schofield <[email protected]> Signed-off-by: Matt Ranostay <[email protected]> Tested-by: Alison Schofield <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ef3149e upstream. sca3000_read_ctrl_reg() returns a negative number on failure, check for this instead of zero. Signed-off-by: Luis de Bethencourt <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0c1f91b upstream. These two spi_w8r8() calls return a value with is used by the code following the error check. The dubious use was caused by a cleanup patch. Fixes: d34dbee ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.") Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6b7f4e2 upstream. All regulator_get() variants return either a pointer to a regulator or an ERR_PTR() so testing for NULL makes no sense and may lead to bugs if we use NULL as a valid regulator. Fix this by using IS_ERR() as expected. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e5511c8 upstream. The ad7266 driver attempts to support deciding between the use of internal and external power supplies by checking to see if an error is returned when requesting the regulator. This doesn't work with the current code since the driver uses a normal regulator_get() which is for non-optional supplies and so assumes that if a regulator is not provided by the platform then this is a bug in the platform integration and so substitutes a dummy regulator. Use regulator_get_optional() instead which indicates to the framework that the regulator may be absent and provides a dummy regulator instead. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 68b356e upstream. Currently the ad7266 driver treats any failure to get vref as though the regulator were not present but this means that if probe deferral is triggered the driver will act as though the regulator were not present. Instead only use the internal reference if we explicitly got -ENODEV which is what is returned for absent regulators. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1b45996 upstream. We are getting somewhat random soft lockups with this signature: [ 86.992215] [<fffffc00080935e0>] el1_irq+0xa0/0x10c [ 86.997082] [<fffffc000841822c>] cursor_timer_handler+0x30/0x54 [ 87.002991] [<fffffc000810ec44>] call_timer_fn+0x54/0x1a8 [ 87.008378] [<fffffc000810ef88>] run_timer_softirq+0x1c4/0x2bc [ 87.014200] [<fffffc000809077c>] __do_softirq+0x114/0x344 [ 87.019590] [<fffffc00080af45c>] irq_exit+0x74/0x98 [ 87.024458] [<fffffc00080fac20>] __handle_domain_irq+0x98/0xfc [ 87.030278] [<fffffc000809056c>] gic_handle_irq+0x94/0x190 This is caused by the vt visual_init() function calling into fbcon_init() with a vc_cur_blink_ms value of zero. This is a transient condition, as it is later set to a non-zero value. But, if the timer happens to expire while the blink rate is zero, it goes into an endless loop, and we get soft lockup. The fix is to initialize vc_cur_blink_ms before calling the con_init() function. Signed-off-by: David Daney <[email protected]> Acked-by: Pavel Machek <[email protected]> Tested-by: Ming Lei <[email protected]> Acked-by: Scot Doyle <[email protected]> Tested-by: Henrique de Moraes Holschuh <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 510cccb upstream. The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS, which is currently 256, whereas number of keys/buttons in input device (and therefor in key_down) is much larger - KEY_CNT - 768, and that can cause out-of-bound access when we do sym = U(key_maps[0][k]); with large 'k'. To fix it we should not attempt iterating beyond smaller of NR_KEYS and KEY_CNT. Also while at it let's switch to for_each_set_bit() instead of open-coding it. Reported-by: Sasha Levin <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…DMIN by default commit 7613663 upstream. For security reasons ordinary user must not be able to control fan speed via /proc/i8k by default. Some malicious software running under "nobody" user could be able to turn fan off and cause HW problems. So this patch changes default value of "restricted" parameter to 1. Also restrict reading of DMI_PRODUCT_SERIAL from /proc/i8k via "restricted" parameter. It is because non root user cannot read DMI_PRODUCT_SERIAL from sysfs file /sys/class/dmi/id/product_serial. Old non secure behaviour of file /proc/i8k can be achieved by loading this module with "restricted" parameter set to 0. Note that this patch has effects only for kernels compiled with CONFIG_I8K and only for file /proc/i8k. Hwmon interface provided by this driver was not changed and root access for setting fan speed was needed also before. Reported-by: Mario Limonciello <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2744d2f upstream. Some Dell machines have especially broken SMM or BIOS which cause that once fan_type() is called then CPU fan speed going randomly up and down. And for fixing this behaviour reboot is required. So this patch creates fan_type blacklist of affected Dell machines and disallow fan_type() call on them to prevent that erratic behaviour. Old blacklist which disabled loading driver on some machines added in commits a4b45b2 ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8100") and 6220f4e ("hwmon: (dell-smm) Blacklist Dell Studio XPS 8000") were moved to FAN_TYPE blacklist. Reported-by: Jan C Peters <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121 Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5ce9171 upstream. On more Dell machines (e.g. Dell Precision M3800) fan_type() call is too expensive (CPU is too long in SMM mode) and cause kernel to hang. This is bug in Dell SMM or BIOS. This patch caches type for each fan (as it should not change) and changes the way how fan presense is detected. First it try function fan_status() as was before commit f989e55 ("i8k: Add support for fan labels"). And if that fails fallback to fan_type(). *_status() functions can fail in case fan is not currently accessible (e.g. present on GPU which is currently turned off). Reported-by: Tolga Cakir <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=112021 Tested-by: Tolga Cakir <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d5dbbe6 upstream. syzkaller fuzzer spotted a potential use-after-free case in snd-dummy driver when hrtimer is used as backend: > ================================================================== > BUG: KASAN: use-after-free in rb_erase+0x1b17/0x2010 at addr ffff88005e5b6f68 > Read of size 8 by task syz-executor/8984 > ============================================================================= > BUG kmalloc-192 (Not tainted): kasan: bad access detected > ----------------------------------------------------------------------------- > > Disabling lock debugging due to kernel taint > INFO: Allocated in 0xbbbbbbbbbbbbbbbb age=18446705582212484632 > .... > [< none >] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:464 > .... > INFO: Freed in 0xfffd8e09 age=18446705496313138713 cpu=2164287125 pid=-1 > [< none >] dummy_hrtimer_free+0x68/0x80 sound/drivers/dummy.c:481 > .... > Call Trace: > [<ffffffff8179e59e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:333 > [< inline >] rb_set_parent include/linux/rbtree_augmented.h:111 > [< inline >] __rb_erase_augmented include/linux/rbtree_augmented.h:218 > [<ffffffff82ca5787>] rb_erase+0x1b17/0x2010 lib/rbtree.c:427 > [<ffffffff82cb02e8>] timerqueue_del+0x78/0x170 lib/timerqueue.c:86 > [<ffffffff814d0c80>] __remove_hrtimer+0x90/0x220 kernel/time/hrtimer.c:903 > [< inline >] remove_hrtimer kernel/time/hrtimer.c:945 > [<ffffffff814d23da>] hrtimer_try_to_cancel+0x22a/0x570 kernel/time/hrtimer.c:1046 > [<ffffffff814d2742>] hrtimer_cancel+0x22/0x40 kernel/time/hrtimer.c:1066 > [<ffffffff85420531>] dummy_hrtimer_stop+0x91/0xb0 sound/drivers/dummy.c:417 > [<ffffffff854228bf>] dummy_pcm_trigger+0x17f/0x1e0 sound/drivers/dummy.c:507 > [<ffffffff85392170>] snd_pcm_do_stop+0x160/0x1b0 sound/core/pcm_native.c:1106 > [<ffffffff85391b26>] snd_pcm_action_single+0x76/0x120 sound/core/pcm_native.c:956 > [<ffffffff85391e01>] snd_pcm_action+0x231/0x290 sound/core/pcm_native.c:974 > [< inline >] snd_pcm_stop sound/core/pcm_native.c:1139 > [<ffffffff8539754d>] snd_pcm_drop+0x12d/0x1d0 sound/core/pcm_native.c:1784 > [<ffffffff8539d3be>] snd_pcm_common_ioctl1+0xfae/0x2150 sound/core/pcm_native.c:2805 > [<ffffffff8539ee91>] snd_pcm_capture_ioctl1+0x2a1/0x5e0 sound/core/pcm_native.c:2976 > [<ffffffff8539f2ec>] snd_pcm_kernel_ioctl+0x11c/0x160 sound/core/pcm_native.c:3020 > [<ffffffff853d9a44>] snd_pcm_oss_sync+0x3a4/0xa30 sound/core/oss/pcm_oss.c:1693 > [<ffffffff853da27d>] snd_pcm_oss_release+0x1ad/0x280 sound/core/oss/pcm_oss.c:2483 > ..... A workaround is to call hrtimer_cancel() in dummy_hrtimer_sync() which is called certainly before other blocking ops. Reported-by: Dmitry Vyukov <[email protected]> Tested-by: Dmitry Vyukov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f83c329 upstream. The new Dell laptop with codec 3246 can't detect headset mic when headset was inserted on the machine. So adding pin configurations into quirk table makes headset mic work correctly. Codec: Realtek ALC3246 Vendor Id: 0x10ec0256 Subsystem Id: 0x10280781 Signed-off-by: Woodrow Shen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…0 fixup commit 0f087ee upstream. See: https://bugzilla.redhat.com/show_bug.cgi?id=1349539 See: https://bugzilla.kernel.org/show_bug.cgi?id=120961 Signed-off-by: Jaroslav Kysela <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 62db715 upstream. vortex_wtdma_bufshift() function does calculate the page index wrongly, first masking then shift, which always results in zero. The proper computation is to first shift, then mask. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9c6795a upstream. 'commpage_bak' is allocated with 'sizeof(struct echoaudio)' bytes. We then copy 'sizeof(struct comm_page)' bytes in it. On my system, smatch complains because one is 2960 and the other is 3072. This would result in memory corruption or a oops. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3fa6993 upstream. The user timer tu->qused counter may go to a negative value when multiple concurrent reads are performed since both the check and the decrement of tu->qused are done in two individual locked contexts. This results in bogus read outs, and the endless loop in the user-space side. The fix is to move the decrement of the tu->qused counter into the same spinlock context as the zero-check of the counter. Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9cd2574 upstream. This solves the issue that a headphone is not working on the docking unit. Signed-off-by: Torsten Hilbrich <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6858107 upstream. Kabylake-H shows up as PCI ID 0xa2f0. We missed adding this earlier with other KBL IDs. Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81e4396 upstream. UBSAN reports the following warning from accessing path->path[-1] in set_path_power(): [ 16.078040] ================================================================================ [ 16.078124] UBSAN: Undefined behaviour in sound/pci/hda/hda_generic.c:3981:17 [ 16.078198] index -1 is out of range for type 'hda_nid_t [10]' [ 16.078270] CPU: 2 PID: 1738 Comm: modprobe Not tainted 4.7.0-rc1-wt+ torvalds#47 [ 16.078274] Hardware name: LENOVO 3443CTO/3443CTO, BIOS G6ET23WW (1.02 ) 08/14/2012 [ 16.078278] ffff8800cb246000 ffff8800cb3638b8 ffffffff815c4fe3 0000000000000032 [ 16.078286] ffff8800cb3638e0 ffffffffffffffff ffff8800cb3638d0 ffffffff8162443d [ 16.078294] ffffffffa0894200 ffff8800cb363920 ffffffff81624af7 0000000000000292 [ 16.078302] Call Trace: [ 16.078311] [<ffffffff815c4fe3>] dump_stack+0x86/0xd3 [ 16.078317] [<ffffffff8162443d>] ubsan_epilogue+0xd/0x40 [ 16.078324] [<ffffffff81624af7>] __ubsan_handle_out_of_bounds+0x67/0x70 [ 16.078335] [<ffffffffa087665f>] set_path_power+0x1bf/0x230 [snd_hda_codec_generic] [ 16.078344] [<ffffffffa087880d>] add_pin_power_ctls+0x8d/0xc0 [snd_hda_codec_generic] [ 16.078352] [<ffffffffa087f190>] ? pin_power_down_callback+0x20/0x20 [snd_hda_codec_generic] [ 16.078360] [<ffffffffa0878947>] add_all_pin_power_ctls+0x107/0x150 [snd_hda_codec_generic] [ 16.078370] [<ffffffffa08842b3>] snd_hda_gen_parse_auto_config+0x2d73/0x49e0 [snd_hda_codec_generic] [ 16.078376] [<ffffffff81173360>] ? trace_hardirqs_on_caller+0x1b0/0x2c0 [ 16.078390] [<ffffffffa089df27>] alc_parse_auto_config+0x147/0x310 [snd_hda_codec_realtek] [ 16.078402] [<ffffffffa08a332a>] patch_alc269+0x23a/0x560 [snd_hda_codec_realtek] [ 16.078417] [<ffffffffa0838644>] hda_codec_driver_probe+0xa4/0x1a0 [snd_hda_codec] [ 16.078424] [<ffffffff817bbac1>] driver_probe_device+0x101/0x380 [ 16.078430] [<ffffffff817bbdf9>] __driver_attach+0xb9/0x100 [ 16.078438] [<ffffffff817bbd40>] ? driver_probe_device+0x380/0x380 [ 16.078444] [<ffffffff817b8d20>] bus_for_each_dev+0x70/0xc0 [ 16.078449] [<ffffffff817bb087>] driver_attach+0x27/0x50 [ 16.078454] [<ffffffff817ba956>] bus_add_driver+0x166/0x2c0 [ 16.078460] [<ffffffffa0369000>] ? 0xffffffffa0369000 [ 16.078465] [<ffffffff817bd13d>] driver_register+0x7d/0x130 [ 16.078477] [<ffffffffa083816f>] __hda_codec_driver_register+0x6f/0x90 [snd_hda_codec] [ 16.078488] [<ffffffffa036901e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek] [ 16.078493] [<ffffffff8100215e>] do_one_initcall+0x4e/0x1d0 [ 16.078499] [<ffffffff8119f54d>] ? rcu_read_lock_sched_held+0x6d/0x80 [ 16.078504] [<ffffffff813701b1>] ? kmem_cache_alloc_trace+0x391/0x560 [ 16.078510] [<ffffffff812bb314>] ? do_init_module+0x28/0x273 [ 16.078515] [<ffffffff812bb387>] do_init_module+0x9b/0x273 [ 16.078522] [<ffffffff811e3782>] load_module+0x20b2/0x3410 [ 16.078527] [<ffffffff811df140>] ? m_show+0x210/0x210 [ 16.078533] [<ffffffff813b2b26>] ? kernel_read+0x66/0xe0 [ 16.078541] [<ffffffff811e4cfa>] SYSC_finit_module+0xba/0xc0 [ 16.078547] [<ffffffff811e4d1e>] SyS_finit_module+0xe/0x10 [ 16.078552] [<ffffffff81a860fc>] entry_SYSCALL_64_fastpath+0x1f/0xbd [ 16.078556] ================================================================================ Fix by checking path->depth before use. Signed-off-by: Bob Copeland <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8a13209 upstream. We have some Dell laptops which can't detect headset mic, the machines use the codec ALC225, they have some new pin configuration values, after adding them in the alc225 pin quirk table, they work well. Signed-off-by: Hui Wang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a8ff48c upstream. The chmap ctls assigned to PCM streams are freed in the PCM disconnect callback. However, since the disconnect callback isn't called when the card gets freed before registering, the chmap ctls may still be left assigned. They are eventually freed together with other ctls, but it may cause an Oops at pcm_chmap_ctl_private_free(), as the function refers to the assigned PCM stream, while the PCM objects have been already freed beforehand. The fix is to free the chmap ctls also at PCM free callback, not only at PCM disconnect. Reported-by: Laxminath Kasam <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f388cdc upstream. snd_ctl_remove() has a notification for the removal event. It's superfluous when done during the device got disconnected. Although the notification itself is mostly harmless, it may potentially be harmful, and should be suppressed. Actually some components PCM may free ctl elements during the disconnect or free callbacks, thus it's no theoretical issue. This patch adds the check of card->shutdown flag for avoiding unnecessary notifications after (or during) the disconnect. Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ab58d8c upstream. register_vga_switcheroo() sets the PM ops from the hda structure which is freed later in azx_free. Make sure that these ops are cleared. Caught by KASAN, initially noticed due to a general protection fault. Fixes: 246efa4 ("snd/hda: add runtime suspend/resume on optimus support (v4)") Signed-off-by: Peter Wu <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d716fb0 upstream. This allows the device to correctly show up as ATI HDMI rather than a generic one and allows the driver to use the available caps. Signed-off-by: Awais Belal <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5fc39d3 upstream. The sun4i-timer driver registers its sched_clock only if the machine is compatible with "allwinner,sun5i-a13", "allwinner,sun5i-a10s" or "allwinner,sun4i-a10". Add the missing "allwinner,sun5i-a13" string to the machine compatible. Signed-off-by: Boris Brezillon <[email protected]> Fixes: 465a225 ("ARM: sun5i: Add C.H.I.P DTS") Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 929e604 upstream. When the support for the Marvell crypto engine was added in the Device Tree of the various Armada 385 Device Tree files in commit d716f2e ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards"), a typo was made in the MBus window attributes for the Armada 385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit fixes this typo, which makes the CESA engines operational on Armada 385 Linksys boards. Reported-by: Terry Stockert <[email protected]> Cc: Terry Stockert <[email protected]> Cc: Imre Kaloz <[email protected]> Cc: Boris Brezillon <[email protected]> Fixes: d716f2e ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards") Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c5379ba upstream. Until now, our understanding for HW I/O coherency to work on the Cortex-A9 based Marvell SoC was that only the PCIe regions should be mapped strongly-ordered. However, we were still encountering some deadlocks, especially when testing the CESA crypto engine. After checking with the HW designers, it was concluded that all the MMIO registers should be mapped as strongly ordered for the HW I/O coherency mechanism to work properly. This fixes some easy to reproduce deadlocks with the CESA crypto engine driver (dmcrypt on a sufficiently large disk partition). Tested-by: Terry Stockert <[email protected]> Tested-by: Romain Perier <[email protected]> Cc: Terry Stockert <[email protected]> Cc: Romain Perier <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 07a2daa upstream. Right now when a new overlay inode is created, we initialize overlay inode's ->i_mode from underlying inode ->i_mode but we retain only file type bits (S_IFMT) and discard permission bits. This patch changes it and retains permission bits too. This should allow overlay to do permission checks on overlay inode itself in task context. [SzM] It also fixes clearing suid/sgid bits on write. Signed-off-by: Vivek Goyal <[email protected]> Reported-by: Eryu Guan <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Fixes: 4bacc9c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cfc9fde upstream. The upper dentry may become stale before we call ovl_lock_rename_workdir. For example, someone could (mistakenly or maliciously) manually unlink(2) it directly from upperdir. To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir and and check if it matches the upper dentry. Essentially, it is the same problem and similar solution as in commit 11f3710 ("ovl: verify upper dentry before unlink and rename"). Signed-off-by: Maxim Patlasov <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 72d8c36 upstream. sas_ata_strategy_handler() adds the works of the ata error handler to system_unbound_wq. This workqueue asynchronously runs work items, so the ata error handler will be performed concurrently on different CPUs. In this case, ->host_failed will be decreased simultaneously in scsi_eh_finish_cmd() on different CPUs, and become abnormal. It will lead to permanently inequality between ->host_failed and ->host_busy, and scsi error handler thread won't start running. IO errors after that won't be handled. Since all scmds must have been handled in the strategy handler, just remove the decrement in scsi_eh_finish_cmd() and zero ->host_busy after the strategy handler to fix this race. Fixes: 50824d6 ("[SCSI] libsas: async ata-eh") Signed-off-by: Wei Fang <[email protected]> Reviewed-by: James Bottomley <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bcf4dd5 upstream. The test_fp_ctl function is used to test if a given value is a valid floating-point control. The inline assembly in test_fp_ctl uses an incorrect constraint for the 'orig_fpc' variable. If the compiler chooses the same register for 'fpc' and 'orig_fpc' the test_fp_ctl() function always returns true. This allows user space to trigger kernel oopses with invalid floating-point control values on the signal stack. This problem has been introduced with git commit 4725c86 "s390: fix save and restore of the floating-point-control register" Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8beb330 upstream. The untagged command case in the 53c700 driver has been broken since host wide tags were enabled because the replaced scsi_find_tag() function had a special case for the tag value SCSI_NO_TAG to retrieve sdev->current_cmnd. The replacement function scsi_host_find_tag() has no such special case and returns NULL causing untagged commands to trigger a BUG() in the driver. Inspection shows that the 53c700 is the only driver using this SCSI_NO_TAG case, so a local fix in the driver suffices to fix this problem globally. Fixes: 64d513a - "scsi: use host wide tags by default" Reported-by: Helge Deller <[email protected]> Tested-by: Helge Deller <[email protected]> Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Acked-by: Christoph Hellwig <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…econnect commit 4fcd181 upstream. Azure server blocks clients that open a socket and don't do anything on it. In our reconnect scenarios, we can reconnect the tcp session and detect the socket is available but we defer the negprot and SMB3 session setup and tree connect reconnection until the next i/o is requested, but this looks suspicous to some servers who expect SMB3 negprog and session setup soon after a socket is created. In the echo thread, reconnect SMB3 sessions and tree connections that are disconnected. A later patch will replay persistent (and resilient) handle opens. Signed-off-by: Steve French <[email protected]> Acked-by: Pavel Shilovsky <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b8da344 upstream. In sess_auth_rawntlmssp_authenticate(), the ntlmssp blob is allocated statically and its size is an "empirical" 5*sizeof(struct _AUTHENTICATE_MESSAGE) (320B on x86_64). I don't know where this value comes from or if it was ever appropriate, but it is currently insufficient: the user and domain name in UTF16 could take 1kB by themselves. Because of that, build_ntlmssp_auth_blob() might corrupt memory (out-of-bounds write). The size of ntlmssp_blob in SMB2_sess_setup() is too small too (sizeof(struct _NEGOTIATE_MESSAGE) + 500). This patch allocates the blob dynamically in build_ntlmssp_auth_blob(). Signed-off-by: Jerome Marchand <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 45e8a25 upstream. POSIX allows files with trailing spaces or a trailing period but SMB3 does not, so convert these using the normal Services For Mac mapping as we do for other reserved characters such as : < > | ? * This is similar to what Macs do for the same problem over SMB3. Signed-off-by: Steve French <[email protected]> Acked-by: Pavel Shilovsky <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6f2d9d9 upstream. As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on both Intel and AMD systems. Doing any kind of hardware capability checks in the driver as a prerequisite was wrong anyway: With the hypervisor being in charge, all such checking should be done by it. If ACPI data gets uploaded despite some missing capability, the hypervisor is free to ignore part or all of that data. Ditch the entire check_prereq() function, and do the only valid check (xen_initial_domain()) in the caller in its place. Signed-off-by: Jan Beulich <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81dc036 upstream. Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory #include "qat_rsapubkey-asn1.h" Signed-off-by: Jan Stancek <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b9b4bb2 upstream. When fallocate is interrupted it will undo a range that extends one byte past its range of allocated pages. This can corrupt an in-use page by zeroing out its first byte. Instead, undo using the inclusive byte range. Fixes: 1635f6a ("tmpfs: undo fallocation on failure") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Anthony Romano <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Brandon Philips <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7f55656 upstream. The well-spotted fallocate undo fix is good in most cases, but not when fallocate failed on the very first page. index 0 then passes lend -1 to shmem_undo_range(), and that has two bad effects: (a) that it will undo every fallocation throughout the file, unrestricted by the current range; but more importantly (b) it can cause the undo to hang, because lend -1 is treated as truncation, which makes it keep on retrying until every page has gone, but those already fully instantiated will never go away. Big thank you to xfstests generic/269 which demonstrates this. Fixes: b9b4bb2 ("tmpfs: don't undo fallocate past its last page") Signed-off-by: Hugh Dickins <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 34511dc upstream. It has been found out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms. This is a manual revert of commits 5fa836a ("drm/i915: DP link training optimization") and 4e96c97 ("drm/i915: eDP link training optimization"). Fixes: 5fa836a ("drm/i915: DP link training optimization") Fixes: 4e96c97 ("drm/i915: eDP link training optimization") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393 Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Mika Kahola <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 91df09d) Signed-off-by: Joakim Tjernlund <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 11f3710 upstream. Unlink and rename in overlayfs checked the upper dentry for staleness by verifying upper->d_parent against upperdir. However the dentry can go stale also by being unhashed, for example. Expand the verification to actually look up the name again (under parent lock) and check if it matches the upper dentry. This matches what the VFS does before passing the dentry to filesytem's unlink/rename methods, which excludes any inconsistency caused by overlayfs. Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Change-Id: I92b8f49402cfc006b17ceb26a43ed6bff8ecee1d Signed-off-by: Dmitry Shmidt <[email protected]>

HW config manager processes DT entries on demand. These entries can be chosen from kernel command line: hi6220_hw_mgr.dt_entry=hardware_cfg_0. DT contains main hw_cfg_mng entry with all possible HW config setups. And then kernel command line option will allow to choose between them. Kernel DT entry: hw_cfg_mng { compatible = "hw_cfg_manager"; hardware_cfg_0 { overlay@0 { fragment@0 { __overlay__ { }; }; }; gpio_sd_sel { /* Select SD from Quick Bus */ set-gpio = <&gpio4 4 0>; value = <1>; delay = <100>; /* Delay in ms */ }; }; }; Change-Id: Ibeba85c5d0a81aa1766d214d5afe39ec3a2b0534 Signed-off-by: Dmitry Shmidt <[email protected]>

Change-Id: Ic784f818bde419e23285d2fdc888245d1f9c340a Signed-off-by: Dmitry Shmidt <[email protected]>

hardware_cfg_innolux_panel - to enable innolux panel hardware_cfg_cs_sd_qb - to use SD signals from quick bus Change-Id: Id87de049c41e9bc602dd9a5cee8d55f88517af7f Signed-off-by: Dmitry Shmidt <[email protected]>

The sdio dpc starts processing when in SDIOD_STATE_DATA. This state was entered right after firmware download. This patch moves that transition just before enabling sdio interrupt handling thus avoiding watchdog expiry which would put the bus to sleep while probing. Change-Id: I09c60752374b8145da78000935062be08c5c8a52 Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Signed-off-by: Dmitry Shmidt <[email protected]>

The previous patch 1c9ac24 ("ARM64: hikey: Disable innolux panel") unfortunately disabled all DSI output which includes the HDMI output. This patch fixes the previous patch by re-enabling DSI and properly disabling the innolux node. Change-Id: If84b73563ecccbfa257244dfe681e86d8577e64c Signed-off-by: John Stultz <[email protected]>

Change-Id: I56e58fb3ab3d337a0f173f916087dc336a45e34d Signed-off-by: Dmitry Shmidt <[email protected]>

…linaro-4.4-aosp Change-Id: I94f38bddab6f7754d6e68865d4ba8fe8603e0dad

This is the 4.4.16 stable release

usb_ep_autoconfig is called twice for allocating bulk out endpoint. Removed the unwanted call. Fixes Issue: 67180 Change-Id: I03e87a86fbbbc85831ff7f0496adf038d1de2956 Signed-off-by: Anson Jacob <[email protected]>

This reverts commit 4e09c51. I checked for the usage of this debug helper in AOSP common kernels as well as vendor kernels (e.g exynos, msm, mediatek, omap, tegra, x86, x86_64) hosted at https://android.googlesource.com/kernel/ and I found out that other than few fairly obsolete Omap trees (for tuna & Glass) and Exynos tree (for Manta), there is no active user of this debug helper. So we can safely remove this helper code. Signed-off-by: Amit Pundir <[email protected]>

This is the 4.4.16 stable release Change-Id: Ibaf7b7e03695e1acebc654a2ca1a4bfcc48fcea4

Change-Id: I78a1bda3728d0fc9b32c28033cd40076a7a3ab06 Signed-off-by: Dmitry Shmidt <[email protected]>

New driver memory_state_time tracks time spent in different DDR frequency and bandwidth states. Memory drivers such as qcom,cpubw can post updated state to the driver after registering a callback. Processed by a workqueue Bandwidth buckets are read in from device tree in the relevant qualcomm section, can be defined in any quantity and spacing. The data is exposed at /sys/kernel/memory_state_time, able to be read by the Android framework. Functionality is behind a config option CONFIG_MEMORY_STATE_TIME Change-Id: I4fee165571cb975fb9eacbc9aada5e6d7dd748f0 Signed-off-by: James Carr <[email protected]>

(cherry picked from commit 34b88a6) The syzkaller fuzzer hit the following use-after-free: Call Trace: [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295 [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261 [< inline >] SYSC_recvmmsg net/socket.c:2281 [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270 [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 And, as Dmitry rightly assessed, that is because we can drop the reference and then touch it when the underlying recvmsg calls return some packets and then hit an error, which will make recvmmsg to set sock->sk->sk_err, oops, fix it. Reported-and-Tested-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Sasha Levin <[email protected]> Fixes: a2e2725 ("net: Introduce recvmmsg socket syscall") http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Change-Id: I2adb0faf595b7b634d9b739dfdd1a47109e20ecb Bug: 30515201

commit c66f59e upstream. Since ed_schedule begins with marking the ED as "operational", the ED may be left in such state even if scheduling actually fails. This allows future submission attempts to smuggle this ED to the hardware behind the scheduler's back and without linking it to the ohci->eds_in_use list. The former causes bandwidth saturation and data loss on isoc endpoints, the latter crashes the kernel when attempt is made to unlink such ED from this list. Fix ed_schedule to update ED state only on successful return. Signed-off-by: Michal Pecio <[email protected]> Acked-by: Alan Stern <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 447d29d upstream. Since the following commit: 8659c40 ("x86: only scan the root bus in early PCI quirks") ... early quirks are only applied to devices on the root bus. The motivation was to prevent application of the nvidia_bugs quirk on secondary buses. We're about to reintroduce scanning of secondary buses for a quirk to reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent regressions, open code the requirement to apply nvidia_bugs only on the root bus. Signed-off-by: Lukas Wunner <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yinghai Lu <[email protected]> Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.de Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 850c321 upstream. We used to scan secondary buses until the following commit that was applied in 2009: 8659c40 ("x86: only scan the root bus in early PCI quirks") which commit constrained early quirks to the root bus only. Its motivation was to prevent application of the nvidia_bugs quirk on secondary buses. We're about to add a quirk to reset the Broadcom 4331 wireless card on 2011/2012 Macs, which is located on a secondary bus behind a PCIe root port. To facilitate that, reintroduce scanning of secondary buses. The commit message of 8659c40 notes that scanning only the root bus "saves quite some unnecessary scanning work". The algorithm used prior to 8659c40 was particularly time consuming because it scanned buses 0 to 31 brute force. To avoid lengthening boot time, employ a recursive strategy which only scans buses that are actually reachable from the root bus. Yinghai Lu pointed out that the secondary bus number read from a bridge's config space may be invalid, in particular a value of 0 would cause an infinite loop. The PCI core goes beyond that and recurses to a child bus only if its bus number is greater than the parent bus number (see pci_scan_bridge()). Since the root bus is numbered 0, this implies that secondary buses may not be 0. Do the same on early scanning. If this algorithm is found to significantly impact boot time or cause infinite loops on broken hardware, it would be possible to limit its recursion depth: The Broadcom 4331 quirk applies at depth 1, all others at depth 0, so the bus need not be scanned deeper than that for now. An alternative approach would be to revert to scanning only the root bus, and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12 and 8086:1e16. Apple always positioned the card behind either of these three ports. The quirk would then check presence of the card in slot 0 below the root port and do its deed. Signed-off-by: Lukas Wunner <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/f0daa70dac1a9b2483abdb31887173eb6ab77bdf.1465690253.git.lukas@wunner.de Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit abb2baf upstream. The EFI firmware on Macs contains a full-fledged network stack for downloading OS X images from osrecovery.apple.com. Unfortunately on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331 wireless card on every boot and leaves it enabled even after ExitBootServices has been called. The card continues to assert its IRQ line, causing spurious interrupts if the IRQ is shared. It also corrupts memory by DMAing received packets, allowing for remote code execution over the air. This only stops when a driver is loaded for the wireless card, which may be never if the driver is not installed or blacklisted. The issue seems to be constrained to the Broadcom 4331. Chris Milsted has verified that the newer Broadcom 4360 built into the MacBookPro11,3 (2013/2014) does not exhibit this behaviour. The chances that Apple will ever supply a firmware fix for the older machines appear to be zero. The solution is to reset the card on boot by writing to a reset bit in its mmio space. This must be done as an early quirk and not as a plain vanilla PCI quirk to successfully combat memory corruption by DMAed packets: Matthew Garrett found out in 2012 that the packets are written to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html). This type of memory is made available to the page allocator by efi_free_boot_services(). Plain vanilla PCI quirks run much later, in subsys initcall level. In-between a time window would be open for memory corruption. Random crashes occurring in this time window and attributed to DMAed packets have indeed been observed in the wild by Chris Bainbridge. When Matthew Garrett analyzed the memory corruption issue in 2012, he sought to fix it with a grub quirk which transitions the card to D3hot: http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56 This approach does not help users with other bootloaders and while it may prevent DMAed packets, it does not cure the spurious interrupts emanating from the card. Unfortunately the card's mmio space is inaccessible in D3hot, so to reset it, we have to undo the effect of Matthew's grub patch and transition the card back to D0. Note that the quirk takes a few shortcuts to reduce the amount of code: The size of BAR 0 and the location of the PM capability is identical on all affected machines and therefore hardcoded. Only the address of BAR 0 differs between models. Also, it is assumed that the BCMA core currently mapped is the 802.11 core. The EFI driver seems to always take care of this. Michael Büsch, Bjorn Helgaas and Matt Fleming contributed feedback towards finding the best solution to this problem. The following should be a comprehensive list of affected models: iMac13,1 2012 21.5" [Root Port 00:1c.3 = 8086:1e16] iMac13,2 2012 27" [Root Port 00:1c.3 = 8086:1e16] Macmini5,1 2011 i5 2.3 GHz [Root Port 00:1c.1 = 8086:1c12] Macmini5,2 2011 i5 2.5 GHz [Root Port 00:1c.1 = 8086:1c12] Macmini5,3 2011 i7 2.0 GHz [Root Port 00:1c.1 = 8086:1c12] Macmini6,1 2012 i5 2.5 GHz [Root Port 00:1c.1 = 8086:1e12] Macmini6,2 2012 i7 2.3 GHz [Root Port 00:1c.1 = 8086:1e12] MacBookPro8,1 2011 13" [Root Port 00:1c.1 = 8086:1c12] MacBookPro8,2 2011 15" [Root Port 00:1c.1 = 8086:1c12] MacBookPro8,3 2011 17" [Root Port 00:1c.1 = 8086:1c12] MacBookPro9,1 2012 15" [Root Port 00:1c.1 = 8086:1e12] MacBookPro9,2 2012 13" [Root Port 00:1c.1 = 8086:1e12] MacBookPro10,1 2012 15" [Root Port 00:1c.1 = 8086:1e12] MacBookPro10,2 2012 13" [Root Port 00:1c.1 = 8086:1e12] For posterity, spurious interrupts caused by the Broadcom 4331 wireless card resulted in splats like this (stacktrace omitted): irq 17: nobody cared (try booting with the "irqpoll" option) handlers: [<ffffffff81374370>] pcie_isr [<ffffffffc0704550>] sdhci_irq [sdhci] threaded [<ffffffffc07013c0>] sdhci_thread_irq [sdhci] [<ffffffffc0a0b960>] azx_interrupt [snd_hda_codec] Disabling IRQ torvalds#17 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732 Tested-by: Konstantin Simanov <[email protected]> # [MacBookPro8,1] Tested-by: Lukas Wunner <[email protected]> # [MacBookPro9,1] Tested-by: Bryan Paradis <[email protected]> # [MacBookPro9,2] Tested-by: Andrew Worsley <[email protected]> # [MacBookPro10,1] Tested-by: Chris Bainbridge <[email protected]> # [MacBookPro10,2] Signed-off-by: Lukas Wunner <[email protected]> Acked-by: Rafał Miłecki <[email protected]> Acked-by: Matt Fleming <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Chris Milsted <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Michael Buesch <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de [ Did minor readability edits. ] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4a9723e upstream. Having descriptors aligned on 64 bits allows update CNDA and CUBC in an atomic way. Signed-off-by: Ludovic Desroches <[email protected]> Fixes: e1f7c9e ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Reviewed-by: Nicolas Ferre <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 53398f4 upstream. An unexpected value of CUBC can lead to a corrupted residue. A more complex sequence is needed to detect an inaccurate value for NCA or CUBC. Signed-off-by: Ludovic Desroches <[email protected]> Fixes: e1f7c9e ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Reviewed-by: Nicolas Ferre <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9295c41 upstream. Due to the way CUBC register is updated, a double flush is needed to compute an accurate residue. First flush aim is to get data from the DMA FIFO and second one ensures that we won't report data which are not in memory. Signed-off-by: Ludovic Desroches <[email protected]> Fixes: e1f7c9e ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Reviewed-by: Nicolas Ferre <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e838a45 upstream. Commit d0164ad ("mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd") modified __GFP_WAIT to explicitly identify the difference between atomic callers and those that were unwilling to sleep. Later the definition was removed entirely. The GFP_RECLAIM_MASK is the set of flags that affect watermark checking and reclaim behaviour but __GFP_ATOMIC was never added. Without it, atomic users of the slab allocator strip the __GFP_ATOMIC flag and cannot access the page allocator atomic reserves. This patch addresses the problem. The user-visible impact depends on the workload but potentially atomic allocations unnecessarily fail without this path. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Reported-by: Marcin Wojtas <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a4f04f2 upstream. If the memory compaction free scanner cannot successfully split a free page (only possible due to per-zone low watermark), terminate the free scanner rather than continuing to scan memory needlessly. If the watermark is insufficient for a free page of order <= cc->order, then terminate the scanner since all future splits will also likely fail. This prevents the compaction freeing scanner from scanning all memory on very large zones (very noticeable for zones > 128GB, for instance) when all splits will likely fail while holding zone->lock. compaction_alloc() iterating a 128GB zone has been benchmarked to take over 400ms on some systems whereas any free page isolated and ready to be split ends up failing in split_free_page() because of the low watermark check and thus the iteration continues. The next time compaction occurs, the freeing scanner will likely start at the end of the zone again since no success was made previously and we get the same lengthy iteration until the zone is brought above the low watermark. All thp page faults can take >400ms in such a state without this fix. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: David Rientjes <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Hugh Dickins <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 63d2f95 upstream. The value `bytes' comes from the filesystem which is about to be mounted. We cannot trust that the value is always in the range we expect it to be. Check its value before using it to calculate the length for the crc32_le call. It value must be larger (or equal) sumoff + 4. This fixes a kernel bug when accidentially mounting an image file which had the nilfs2 magic value 0x3434 at the right offset 0x406 by chance. The bytes 0x01 0x00 were stored at 0x408 and were interpreted as a s_bytes value of 1. This caused an underflow when substracting sumoff + 4 (20) in the call to crc32_le. BUG: unable to handle kernel paging request at ffff88021e600000 IP: crc32_le+0x36/0x100 ... Call Trace: nilfs_valid_sb.part.5+0x52/0x60 [nilfs2] nilfs_load_super_block+0x142/0x300 [nilfs2] init_nilfs+0x60/0x390 [nilfs2] nilfs_mount+0x302/0x520 [nilfs2] mount_fs+0x38/0x160 vfs_kern_mount+0x67/0x110 do_mount+0x269/0xe00 SyS_mount+0x9f/0x100 entry_SYSCALL_64_fastpath+0x16/0x71 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Torsten Hilbrich <[email protected]> Tested-by: Torsten Hilbrich <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a46cbf3 upstream. It's possible to isolate some freepages in a pageblock and then fail split_free_page() due to the low watermark check. In this case, we hit VM_BUG_ON() because the freeing scanner terminated early without a contended lock or enough freepages. This should never have been a VM_BUG_ON() since it's not a fatal condition. It should have been a VM_WARN_ON() at best, or even handled gracefully. Regardless, we need to terminate anytime the full pageblock scan was not done. The logic belongs in isolate_freepages_block(), so handle its state gracefully by terminating the pageblock loop and making a note to restart at the same pageblock next time since it was not possible to complete the scan this time. [[email protected]: don't rescan pages in a pageblock] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: David Rientjes <[email protected]> Reported-by: Minchan Kim <[email protected]> Tested-by: Minchan Kim <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e4568d3 upstream. early_pfn_to_nid can return node 0 if a PFN is invalid on machines that has no node 0. A machine with only node 1 was observed to crash with the following message: BUG: unable to handle kernel paging request at 000000000002a3c8 PGD 0 Modules linked in: Hardware name: Supermicro H8DSP-8/H8DSP-8, BIOS 080011 06/30/2006 task: ffffffff81c0d500 ti: ffffffff81c00000 task.ti: ffffffff81c00000 RIP: reserve_bootmem_region+0x6a/0xef CR2: 000000000002a3c8 CR3: 0000000001c06000 CR4: 00000000000006b0 Call Trace: free_all_bootmem+0x4b/0x12a mem_init+0x70/0xa3 start_kernel+0x25b/0x49b The problem is that early_page_uninitialised uses the early_pfn_to_nid helper which returns node 0 for invalid PFNs. No caller of early_pfn_to_nid cares except early_page_uninitialised. This patch has early_pfn_to_nid always return a valid node. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…uninitialised commit ef70b6f upstream. early_page_uninitialised looks up an arbitrary PFN. While a machine without node 0 will boot with "mm, page_alloc: Always return a valid node from early_pfn_to_nid", it works because it assumes that nodes are always in PFN order. This is not guaranteed so this patch adds robustness by always checking if the node being checked is online. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e41f501 upstream. If CONFIG_KASAN is enabled and gcc is configured with --disable-initfini-array and/or gold linker is used, gcc emits .ctors/.dtors and .text.startup/.text.exit sections instead of .init_array/.fini_array. .dtors section is not explicitly accounted in the linker script and messes vvar/percpu layout. We want: ffffffff822bfd80 D _edata ffffffff822c0000 D __vvar_beginning_hack ffffffff822c0000 A __vvar_page ffffffff822c0080 0000000000000098 D vsyscall_gtod_data ffffffff822c1000 A __init_begin ffffffff822c1000 D init_per_cpu__irq_stack_union ffffffff822c1000 A __per_cpu_load ffffffff822d3000 D init_per_cpu__gdt_page We got: ffffffff8279a600 D _edata ffffffff8279b000 A __vvar_page ffffffff8279c000 A __init_begin ffffffff8279c000 D init_per_cpu__irq_stack_union ffffffff8279c000 A __per_cpu_load ffffffff8279e000 D __vvar_beginning_hack ffffffff8279e080 0000000000000098 D vsyscall_gtod_data ffffffff827ae000 D init_per_cpu__gdt_page This happens because __vvar_page and .vvar get different addresses in arch/x86/kernel/vmlinux.lds.S: . = ALIGN(PAGE_SIZE); __vvar_page = .; .vvar : AT(ADDR(.vvar) - LOAD_OFFSET) { /* work around gold bug 13023 */ __vvar_beginning_hack = .; Discard .dtors/.fini_array/.text.exit, since we don't call dtors. Merge .text.startup into init text. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Dmitry Vyukov <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 368301f upstream. With this command sequence: modprobe plip modprobe pps_parport rmmod pps_parport the partport_pps modules causes this crash: BUG: unable to handle kernel NULL pointer dereference at (null) IP: parport_detach+0x1d/0x60 [pps_parport] Oops: 0000 [xin3liang#1] SMP ... Call Trace: parport_unregister_driver+0x65/0xc0 [parport] SyS_delete_module+0x187/0x210 The sequence that builds up to this is: 1) plip is loaded and takes the parport device for exclusive use: plip0: Parallel port at 0x378, using IRQ 7. 2) pps_parport then fails to grab the device: pps_parport: parallel port PPS client parport0: cannot grant exclusive access for device pps_parport pps_parport: couldn't register with parport0 3) rmmod of pps_parport is then killed because it tries to access pardev->name, but pardev (taken from port->cad) is NULL. So add a check for NULL in the test there too. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jiri Slaby <[email protected]> Acked-by: Rodolfo Giometti <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…processing sysrq-w commit 57675cb upstream. Lengthy output of sysrq-w may take a lot of time on slow serial console. Currently we reset NMI-watchdog on the current CPU to avoid spurious lockup messages. Sometimes this doesn't work since softlockup watchdog might trigger on another CPU which is waiting for an IPI to proceed. We reset softlockup watchdogs on all CPUs, but we do this only after listing all tasks, and this may be too late on a busy system. So, reset watchdogs CPUs earlier, in for_each_process_thread() loop. Signed-off-by: Andrey Ryabinin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9bd5451 upstream. If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core() gets called following message gets printed in debug console: ----------------->8--------------- CONFIG_ARC_DW2_UNWIND needs to be enabled ----------------->8--------------- That message makes sense if user indeed wants to see a backtrace or get nice function call-graphs in perf but what if user disabled unwinder for the purpose? Why pollute his debug console? So instead we'll warn user about possibly missing feature once and let him decide if that was what he or she really wanted. Signed-off-by: Alexey Brodkin <[email protected]> Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f52e126 upstream. With recent binutils update to support dwarf CFI pseudo-ops in gas, we now get .eh_frame vs. .debug_frame. Although the call frame info is exactly the same in both, the CIE differs, which the current kernel unwinder can't cope with. This broke both the kernel unwinder as well as loadable modules (latter because of a new unhandled relo R_ARC_32_PCREL from .rela.eh_frame in the module loader) The ideal solution would be to switch unwinder to .eh_frame. For now however we can make do by just ensureing .debug_frame is generated by removing -fasynchronous-unwind-tables .eh_frame generated with -gdwarf-2 -fasynchronous-unwind-tables .debug_frame generated with -gdwarf-2 Fixes STAR 9001058196 Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 02ef871 upstream. Current overlap check is evaluating to false a case where a filter field is fully contained (proper subset) of a r/w request. This change applies classical overlap check instead to include all the scenarios. More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver the logic is such that the entire confspace is read and written in 4 byte chunks. In this case as an example, CACHE_LINE_SIZE, LATENCY_TIMER and PCI_BIST are arriving together in one call to xen_pcibk_config_write() with offset == 0xc and size == 4. With the exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length == 1) is fully contained in the write request and hence is excluded from write, which is incorrect. Signed-off-by: Andrey Grodzovsky <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0beef63 upstream. Inability to locate a user mode specified transaction ID should not lead to a kernel crash. For other than XS_TRANSACTION_START also don't issue anything to xenbus if the specified ID doesn't match that of any active transaction. Signed-off-by: Jan Beulich <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7469be9 upstream. xenbus_dev_request_and_reply() needs to track whether a transaction is open. For XS_TRANSACTION_START messages it calls transaction_start() and for XS_TRANSACTION_END messages it calls transaction_end(). If sending an XS_TRANSACTION_START message fails or responds with an an error, the transaction is not open and transaction_end() must be called. If sending an XS_TRANSACTION_END message fails, the transaction is still open, but if an error response is returned the transaction is closed. Commit 027bd7e ("xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart") introduced a regression where failed XS_TRANSACTION_START messages were leaving the transaction open. This can cause problems with suspend (and migration) as all transactions must be closed before suspending. It appears that the problematic change was added accidentally, so just remove it. Signed-off-by: Jan Beulich <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cec8f96 upstream. The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9a47e9c upstream. The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e4ec8cc upstream. The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 60842ef upstream. The VMWare EFI BIOS will expose port 0x5658 as an ACPI resource. This causes the port to be reserved by the APCI module as the system comes up, making it unavailable to be reserved again by other drivers, thus preserving this VMWare port for special use in a VMWare guest. This port is designed to be shared among multiple VMWare services, such as the VMMOUSE. Because of this, VMMOUSE should not try to reserve this port on its own. The VMWare non-EFI BIOS does not do this to preserve compatibility with existing/legacy VMs. It is known that there is small chance a VM may be configured such that these ports get reserved by other non-VMWare devices, and if this ever happens, the result is undefined. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 226ba70 upstream. The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and according to Elan both 11 and 12 are valid IC types and should be identified as hw_version 4. Reported-by: Patrick Lessard <[email protected]> Tested-by: Patrick Lessard <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c7f1429 upstream. Xbox One controllers have multiple interfaces which all have the same class, subclass, and protocol. One of the these interfaces has only a single endpoint. When Xpad attempts to bind to this interface, it causes an oops when trying initialize the output URB by trying to access the second endpoint's descriptor. This situation was avoided for known Xbox One devices by checking the XTYPE constant associated with the VID and PID tuple. However, this breaks when new or previously unknown Xbox One controllers are attached to the system. This change addresses the problem by deriving the XTYPE for Xbox One controllers based on the interface protocol before checking the interface number. Fixes: 1a48ff8 ("Input: xpad - add support for Xbox One controllers") Signed-off-by: Cameron Gutman <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 12afb34 upstream. Somehow the patch that added two-finger touch support forgot to update W8001_MAX_LENGTH from 11 to 13. Signed-off-by: Ping Cheng <[email protected]> Reviewed-by: Peter Hutterer <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit caca925 upstream. This prevents a malicious USB device from causing an oops. Signed-off-by: Cameron Gutman <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e9003c9 upstream. Passes input_id struct to the common probe function for the tsc200x drivers instead of just the bustype. This allows for the use of the product variable to set the input_dev->name variable according to the type of touchscreen used. Note that when we introduced support for TSC2004 we started calling everything TSC200X, so let's keep this quirk. Signed-off-by: Michael Welling <[email protected]> Acked-by: Pavel Machek <[email protected]> Acked-by: Pali Rohár <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 749d088 upstream. Protocol for the "version" fields is: hypervisor raises it (making it uneven) before it starts updating the fields and raises it again (making it even) when it is done. Thus the guest can make sure the time values it got are consistent by checking the version before and after reading them. Add CPU barries after getting version value just like what function vread_pvclock does, because all of callees in this function is inline. Fixes: 502dfef Signed-off-by: Minfei Huang <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0ac3c0a upstream. With many repeated suspend resume cycles, the pin specific wakeirq may not always work on omaps. This is because the write to enable the pin interrupt may not have reached the device over the interconnect before suspend happens. Let's fix the issue with a flush of posted write with a readback. Reported-by: Nishanth Menon <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ba562d5 upstream. Some PINs do not have a MUX register, it is not an error. It is necessary to allow the continuation of the PINs configuration, otherwise the whole PIN-group will be configured incorrectly. Signed-off-by: Alexander Shiyan <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8fa3b8d upstream. If percpu_ref initialization fails during css_create(), the free path can end up trying to free css->id of zero. As ID 0 is unused, it doesn't cause a critical breakage but it does trigger a warning message. Fix it by setting css->id to -1 from init_and_link_css(). Signed-off-by: Tejun Heo <[email protected]> Cc: Wenwei Tao <[email protected]> Fixes: 01e5865 ("cgroup: release css->id after css_free") Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5bc28b9 upstream. Change power_supply_read_temp() to use power_supply_get_property() so that it will check the use_cnt and ensure it is > 0. The use_cnt will be incremented at the end of __power_supply_register, so this will block to case where get_property can be called before the supply is fully registered. This fixes the issue show in the stack below: [ 1.452598] power_supply_read_temp+0x78/0x80 [ 1.458680] thermal_zone_get_temp+0x5c/0x11c [ 1.464765] thermal_zone_device_update+0x34/0xb4 [ 1.471195] thermal_zone_device_register+0x87c/0x8cc [ 1.477974] __power_supply_register+0x364/0x424 [ 1.484317] power_supply_register_no_ws+0x10/0x18 [ 1.490833] bq27xxx_battery_setup+0x10c/0x164 [ 1.497003] bq27xxx_battery_i2c_probe+0xd0/0x1b0 [ 1.503435] i2c_device_probe+0x174/0x240 [ 1.509172] driver_probe_device+0x1fc/0x29c [ 1.515167] __driver_attach+0xa4/0xa8 [ 1.520643] bus_for_each_dev+0x58/0x98 [ 1.526204] driver_attach+0x20/0x28 [ 1.531505] bus_add_driver+0x1c8/0x22c [ 1.537067] driver_register+0x68/0x108 [ 1.542630] i2c_register_driver+0x38/0x7c [ 1.548457] bq27xxx_battery_i2c_driver_init+0x18/0x20 [ 1.555321] do_one_initcall+0x38/0x12c [ 1.560886] kernel_init_freeable+0x148/0x1ec [ 1.566972] kernel_init+0x10/0xfc [ 1.572101] ret_from_fork+0x10/0x40 Also make the same change to ps_get_max_charge_cntl_limit() and ps_get_cur_chrage_cntl_limit() to be safe. Lastly, change the return value of power_supply_get_property() to -EAGAIN from -ENODEV if use_cnt <= 0. Fixes: 297d716 ("power_supply: Change ownership from driver to core") Signed-off-by: Rhyland Klein <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6343a21 upstream. (Another one for the f_path debacle.) ltp fcntl33 testcase caused an Oops in selinux_file_send_sigiotask. The reason is that generic_add_lease() used filp->f_path.dentry->inode while all the others use file_inode(). This makes a difference for files opened on overlayfs since the former will point to the overlay inode the latter to the underlying inode. So generic_add_lease() added the lease to the overlay inode and generic_delete_lease() removed it from the underlying inode. When the file was released the lease remained on the overlay inode's lock list, resulting in use after free. Reported-by: Eryu Guan <[email protected]> Fixes: 4bacc9c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by: Miklos Szeredi <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 78c4e17 upstream. This reverts commit 2f36db7. It fixed a local root exploit but also introduced a dependency on the lower file system implementing an mmap operation just to open a file, which is a bit of a heavy hammer. The right fix is to have mmap depend on the existence of the mmap handler instead. Signed-off-by: Jeff Mahoney <[email protected]> Signed-off-by: Tyler Hicks <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f0fe970 upstream. There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap support on file systems that don't offer support natively. CVE-2016-1583 Signed-off-by: Jeff Mahoney <[email protected]> [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()] Signed-off-by: Tyler Hicks <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7bc9491 upstream. Although the extent tree depth of 5 should enough be for the worst case of 2*32 extents of length 1, the extent tree code does not currently to merge nodes which are less than half-full with a sibling node, or to shrink the tree depth if possible. So it's possible, at least in theory, for the tree depth to be greater than 5. However, even in the worst case, a tree depth of 32 is highly unlikely, and if the file system is maliciously corrupted, an insanely large eh_depth can cause memory allocation failures that will trigger kernel warnings (here, eh_depth = 65280): JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max:256 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle+0x569/0x580 CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ torvalds#508 Stack: 604a8947 625badd8 0002fd09 00000000 60078643 00000000 62623910 601bf9bc 62623970 6002fc84 626239b0 900000125 Call Trace: [<6001c2dc>] show_stack+0xdc/0x1a0 [<601bf9bc>] dump_stack+0x2a/0x2e [<6002fc84>] __warn+0x114/0x140 [<6002fdff>] warn_slowpath_null+0x1f/0x30 [<60165829>] start_this_handle+0x569/0x580 [<60165d4e>] jbd2__journal_start+0x11e/0x220 [<60146690>] __ext4_journal_start_sb+0x60/0xa0 [<60120a81>] ext4_truncate+0x131/0x3a0 [<60123677>] ext4_setattr+0x757/0x840 [<600d5d0f>] notify_change+0x16f/0x2a0 [<600b2b16>] do_truncate+0x76/0xc0 [<600c3e56>] path_openat+0x806/0x1300 [<600c55c9>] do_filp_open+0x89/0xf0 [<600b4074>] do_sys_open+0x134/0x1e0 [<600b4140>] SyS_open+0x20/0x30 [<6001ea68>] handle_syscall+0x88/0x90 [<600295fd>] userspace+0x3fd/0x500 [<6001ac55>] fork_handler+0x85/0x90 ---[ end trace 08b0b88b6387a244 ]--- [ Commit message modified and the extent tree depath check changed from 5 to 32 -- tytso ] Cc: Darrick J. Wong <[email protected]> Signed-off-by: Vegard Nossum <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b403f0e upstream. v9fs may be used as lower layer of overlayfs and accessing f_path.dentry can lead to a crash. In this case it's a NULL pointer dereference in p9_fid_create(). Fix by replacing direct access of file->f_path.dentry with the file_dentry() accessor, which will always return a native object. Reported-by: Alessio Igor Bogani <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Tested-by: Alessio Igor Bogani <[email protected]> Fixes: 4bacc9c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e06b933 upstream. - m_start() in fs/namespace.c expects that ns->event is incremented each time a mount added or removed from ns->list. - umount_tree() removes items from the list but does not increment event counter, expecting that it's done before the function is called. - There are some codepaths that call umount_tree() without updating "event" counter. e.g. from __detach_mounts(). - When this happens m_start may reuse a cached mount structure that no longer belongs to ns->list (i.e. use after free which usually leads to infinite loop). This change fixes the above problem by incrementing global event counter before invoking umount_tree(). Change-Id: I622c8e84dcb9fb63542372c5dbf0178ee86bb589 Signed-off-by: Andrey Ulanov <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 719bd65 upstream. The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over 1MHz SPI bus takes way longer than that. Calculate the timeout from the actual time the transfer is supposed to take and multiply by 2 for good measure. Signed-off-by: Michal Suchanek <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6d9fe44 upstream. When testing SPI without DMA I noticed that filling the FIFO on the spi controller causes timeout. Always leave room for one byte in the FIFO. Signed-off-by: Michal Suchanek <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 595144c upstream. The flags element of clk_init_data was never initialized for mmc- phase-clocks resulting in the element containing a random value and thus possibly enabling unwanted clock flags. Fixes: 89bf26c ("clk: rockchip: Add support for the mmc clock phases using the framework") Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 096cdc6 upstream. We verify "u_cmd.outsize" and "u_cmd.insize" but we need to make sure that those values have not changed between the two copy_from_user() calls. Otherwise it could lead to a buffer overflow. Additionally, cros_ec_cmd_xfer() can set s_cmd->insize to a lower value. We should use the new smaller value so we don't copy too much data to the user. Reported-by: Pengfei Wang <[email protected]> Fixes: a841178 ('mfd: cros_ec: Use a zero-length array for command data') Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Kees Cook <[email protected]> Tested-by: Gwendal Grignou <[email protected]> Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7831b4f upstream. A qeth_card contains a napi_struct linked to the net_device during device probing. This struct must be deleted when removing the qeth device, otherwise Panic on oops can occur when qeth devices are repeatedly removed and added. Fixes: a1c3ed4 ("qeth: NAPI support for l2 and l3 discipline") Signed-off-by: Ursula Braun <[email protected]> Tested-by: Alexander Klein <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

@offset

commit 8ba8682 upstream. get_task_ioprio() accesses the task->io_context without holding the task lock and thus can race with exit_io_context(), leading to a use-after-free. The reproducer below hits this within a few seconds on my 4-core QEMU VM: #define _GNU_SOURCE #include <assert.h> #include <unistd.h> #include <sys/syscall.h> #include <sys/wait.h> int main(int argc, char **argv) { pid_t pid, child; long nproc, i; /* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */ syscall(SYS_ioprio_set, 1, 0, 0x6000); nproc = sysconf(_SC_NPROCESSORS_ONLN); for (i = 0; i < nproc; i++) { pid = fork(); assert(pid != -1); if (pid == 0) { for (;;) { pid = fork(); assert(pid != -1); if (pid == 0) { _exit(0); } else { child = wait(NULL); assert(child == pid); } } } pid = fork(); assert(pid != -1); if (pid == 0) { for (;;) { /* ioprio_get(IOPRIO_WHO_PGRP, 0); */ syscall(SYS_ioprio_get, 2, 0); } } } for (;;) { /* ioprio_get(IOPRIO_WHO_PGRP, 0); */ syscall(SYS_ioprio_get, 2, 0); } return 0; } This gets us KASAN dumps like this: [ 35.526914] ================================================================== [ 35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c [ 35.530009] Read of size 2 by task ioprio-gpf/363 [ 35.530009] ============================================================================= [ 35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected [ 35.530009] ----------------------------------------------------------------------------- [ 35.530009] Disabling lock debugging due to kernel taint [ 35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360 [ 35.530009] ___slab_alloc+0x55d/0x5a0 [ 35.530009] __slab_alloc.isra.20+0x2b/0x40 [ 35.530009] kmem_cache_alloc_node+0x84/0x200 [ 35.530009] create_task_io_context+0x2b/0x370 [ 35.530009] get_task_io_context+0x92/0xb0 [ 35.530009] copy_process.part.8+0x5029/0x5660 [ 35.530009] _do_fork+0x155/0x7e0 [ 35.530009] SyS_clone+0x19/0x20 [ 35.530009] do_syscall_64+0x195/0x3a0 [ 35.530009] return_from_SYSCALL_64+0x0/0x6a [ 35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060 [ 35.530009] __slab_free+0x27b/0x3d0 [ 35.530009] kmem_cache_free+0x1fb/0x220 [ 35.530009] put_io_context+0xe7/0x120 [ 35.530009] put_io_context_active+0x238/0x380 [ 35.530009] exit_io_context+0x66/0x80 [ 35.530009] do_exit+0x158e/0x2b90 [ 35.530009] do_group_exit+0xe5/0x2b0 [ 35.530009] SyS_exit_group+0x1d/0x20 [ 35.530009] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080 [ 35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001 [ 35.530009] ================================================================== Fix it by grabbing the task lock while we poke at the io_context. Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Omar Sandoval <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f68381a upstream. The code that fills packed command header assumes that CPU runs in little-endian mode. Hence the header is malformed in big-endian mode and causes MMC data transfer errors: [ 563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40 [ 563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1 Convert header data to LE. Signed-off-by: Taras Kondratiuk <[email protected]> Fixes: ce39f9d ("mmc: support packed write command for eMMC4.5 devices") Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7dd4912 upstream. Starting with the following commit: fde7d22 ("sched/fair: Fix overly small weight for interactive group entities") calc_tg_weight() doesn't compute the right value as expected by effective_load(). The difference is in the 'correction' term. In order to ensure \Sum rw_j >= rw_i we cannot use tg->load_avg directly, since that might be lagging a correction on the current cfs_rq->avg.load_avg value. Therefore we use tg->load_avg - cfs_rq->tg_load_avg_contrib + cfs_rq->avg.load_avg. Now, per the referenced commit, calc_tg_weight() doesn't use cfs_rq->avg.load_avg, as is later used in @w, but uses cfs_rq->load.weight instead. So stop using calc_tg_weight() and do it explicitly. The effects of this bug are wake_affine() making randomly poor choices in cgroup-intense workloads. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: fde7d22 ("sched/fair: Fix overly small weight for interactive group entities") Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b99c2d9 upstream. Before 4bacc9c ("overlayfs: Make f_path...") file->f_path pointed to the underlying file, hence suid/sgid removal on write worked fine. After that patch file->f_path pointed to the overlay file, and the file mode bits weren't copied to overlay_inode->i_mode. So the suid/sgid removal simply stopped working. The fix is to copy the mode bits, but then ovl_setattr() needs to clear ATTR_MODE to avoid the BUG() in notify_change(). So do this first, then in the next patch copy the mode. Reported-by: Eryu Guan <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Fixes: 4bacc9c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Cc: Eric Schultz <[email protected]> Cc: Eric Hameleers <[email protected]> [backported by Eric Hameleers as seen in https://bugzilla.kernel.org/show_bug.cgi?id=150711] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1424a09 upstream. This patch fixes broken PEBS support on Intel Atom and Core2 due to wrong pointer arithmetic in intel_pmu_drain_pebs_core(). The get_next_pebs_record_by_bit() was called on PEBS format fmt0 which does not use the pebs_record_nhm layout. Signed-off-by: Stephane Eranian <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Fixes: 2150908 ("perf/x86/intel: Handle multiple records in the PEBS buffer") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 43200a4 upstream. At high bus load it could happen that "at91_poll()" enters with all RX message boxes filled up. If then at the end the "quota" is exceeded as well, "rx_next" will not be reset to the first RX mailbox and hence the interrupts remain disabled. Signed-off-by: Wolfgang Grandegger <[email protected]> Tested-by: Amr Bekhit <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…yclone access commit 427460c upstream. When testing CAN write floods on Altera's CycloneV, the first 2 bytes are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also observed bytes 4 & 5 were corrupted in some cases. The D_CAN Data registers are 32 bits and changing from 16 bit writes to 32 bit writes fixes the problem. Testing performed on Altera CycloneV (D_CAN). Requesting tests on other C_CAN & D_CAN platforms. Reported-by: Richard Andrysek <[email protected]> Signed-off-by: Thor Thayer <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bce271f upstream. With upstream commit bb208f1 (can: fix handling of unmodifiable configuration options) a new can_validate() function was introduced. When invoking 'ip link set can0 type can' without any configuration data can_validate() tries to validate the content without taking into account that there's totally no content. This patch adds a check for missing content. Reported-by: ajneu <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25e1ed6 upstream. For 'real' hardware CAN devices the netlink interface is used to set CAN specific communication parameters. Real CAN hardware can not be created nor removed with the ip tool ... This patch adds a private dellink function for the CAN device driver interface that does just nothing. It's a follow up to commit 993e6f2 ("can: fix oops caused by wrong rtnl newlink usage") but for dellink. Reported-by: ajneu <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3dad542 upstream. If register_pernet_subsys() fails, we shouldn't try to call unregister_pernet_subsys(). Fixes: 467fa15 ("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.") Cc: Sowmini Varadhan <[email protected]> Cc: David S. Miller <[email protected]> Signed-off-by: Vegard Nossum <[email protected]> Acked-by: Sowmini Varadhan <[email protected]> Acked-by: Santosh Shilimkar <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5e7ff2c upstream. Commit b704f70 ("SCSI: fix bug in scsi_dev_info_list matching") changed the way vendor- and model-string matching was carried out in the routine that looks up entries in a SCSI devinfo list. The new matching code failed to take into account the case of a maximum-length string; in such cases it could end up testing for a terminating '\0' byte beyond the end of the memory allocated to the string. This out-of-bounds bug was detected by UBSAN. I don't know if anybody has actually encountered this bug. The symptom would be that a device entry in the blacklist might not be matched properly if it contained an 8-character vendor name or a 16-character model name. Such entries certainly exist in scsi_static_device_list. This patch fixes the problem by adding a check for a maximum-length string before the '\0' test. Signed-off-by: Alan Stern <[email protected]> Fixes: b704f70 ("SCSI: fix bug in scsi_dev_info_list matching") Tested-by: Wilfried Klaebe <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 54e430b upstream. If we fall back to using LSI on the Croc or Crocodile chip we need to clear the interrupt so we don't hang the system. Tested-by: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Brian King <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aa93d1f upstream. Fix a memory leak on probe error of the airspy usb device driver. The problem is triggered when more than 64 usb devices register with v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV. The memory leak is caused by the probe function of the airspy driver mishandeling errors and not freeing the corresponding control structures when an error occours registering the device to v4l2 core. A badusb device can emulate 64 of these devices, and then through continual emulated connect/disconnect of the 65th device, cause the kernel to run out of RAM and crash the kernel, thus causing a local DOS vulnerability. Fixes CVE-2016-5400 Signed-off-by: James Patrick-Evans <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2c13ce8 upstream. Variable "now" seems to be genuinely used unintialized if branch if (CPUCLOCK_PERTHREAD(timer->it_clock)) { is not taken and branch if (unlikely(sighand == NULL)) { is taken. In this case the process has been reaped and the timer is marked as disarmed anyway. So none of the postprocessing of the sample is required. Return right away. Signed-off-by: Alexey Dobriyan <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…urn value commit 22ebf00 upstream. of_address_to_resource return 0 on successful call but devm_ioremap_resource is called only if it returns non-zero value Signed-off-by: Lukasz Gemborowski <[email protected]> Reviewed-by: Alexander Sverdlin <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1488a1e upstream. Since 34b48db ("block: remove artifical max_hw_sectors cap"), max_sectors is no longer limited to BLK_DEF_MAX_SECTORS and LITE-ON CX1-JB256-HP keeps timing out with higher max_sectors. Revert it to the previous value. Signed-off-by: Tejun Heo <[email protected]> Reported-by: [email protected] Link: https://bugzilla.kernel.org/show_bug.cgi?id=121671 Fixes: 34b48db ("block: remove artifical max_hw_sectors cap") Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 930c532 upstream. Currently, osd_weight and osd_state fields are updated in the encoding order. This is wrong, because an incremental map may look like e.g. new_up_client: { osd=6, addr=... } # set osd_state and addr new_state: { osd=6, xorstate=EXISTS } # clear osd_state Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down). After applying new_up_client, osd_state is changed to EXISTS | UP. Carrying on with the new_state update, we flip EXISTS and leave osd6 in a weird "!EXISTS but UP" state. A non-existent OSD is considered down by the mapping code 2087 for (i = 0; i < pg->pg_temp.len; i++) { 2088 if (ceph_osd_is_down(osdmap, pg->pg_temp.osds[i])) { 2089 if (ceph_can_shift_osds(pi)) 2090 continue; 2091 2092 temp->osds[temp->size++] = CRUSH_ITEM_NONE; and so requests get directed to the second OSD in the set instead of the first, resulting in OSD-side errors like: [WRN] : client.4239 192.168.122.21:0/2444980242 misdirected client.4239.1:2827 pg 2.5df899f2 to osd.4 not [1,4,6] in e680/680 and hung rbds on the client: [ 493.566367] rbd: rbd0: write 400000 at 11cc00000 (0) [ 493.566805] rbd: rbd0: result -6 xferred 400000 [ 493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688 The fix is to decouple application from the decoding and: - apply new_weight first - apply new_state before new_up_client - twiddle osd_state flags if marking in - clear out some of the state if osd is destroyed Fixes: http://tracker.ceph.com/issues/14901 Signed-off-by: Ilya Dryomov <[email protected]> Reviewed-by: Josh Durgin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 06708f8 upstream. Commit aebea2b ("net: mvneta: fix Tx interrupt delay") intended to set coalescing threshold to a value guaranteeing interrupt generation per each sent packet, so that buffers can be released with no delay. In fact setting threshold to '1' was wrong, because it causes interrupt every two packets. According to the documentation a reason behind it is following - interrupt occurs once sent buffers counter reaches a value, which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This behavior was confirmed during tests. Also when testing the SoC working as a NAS device, better performance was observed with int-per-packet, as it strongly depends on the fact that all transmitted packets are released immediately. This commit enables NETA controller work in interrupt per sent packet mode by setting coalescing threshold to 0. Signed-off-by: Dmitri Epshtein <[email protected]> Signed-off-by: Marcin Wojtas <[email protected]> Fixes aebea2b ("net: mvneta: fix Tx interrupt delay") Acked-by: Willy Tarreau <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7a1a47c upstream. This adds Intel(R) Trace Hub PCI ID for Kaby Lake PCH-H. Signed-off-by: Alexander Shishkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a36aa80 upstream. Driver initialization tries to request a hub (GTH) driver module from its probe callback, resulting in a deadlock. This patch solves the problem by adding a deferred work for requesting the hub module. Signed-off-by: Alexander Shishkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c1892c3 upstream. file_remove_privs() is called with inode lock on file_inode(), which proceeds to calling notify_change() on file->f_path.dentry. Which triggers the WARN_ON_ONCE(!inode_is_locked(inode)) in addition to deadlocking later when ovl_setattr tries to lock the underlying inode again. Fix this mess by not mixing the layers, but doing everything on underlying dentry/inode. Signed-off-by: Miklos Szeredi <[email protected]> Fixes: 07a2daa ("ovl: Copy up underlying inode's ->i_mode to overlay inode") Signed-off-by: Greg Kroah-Hartman <[email protected]>

This is a wrap-up of three patches pending upstream approval. I'm bundling them because they are interdependent, and it'll be easier to drop it on rebase later. 1. dm: allow a dm-fs-style device to be shared via dm-ioctl Integrates feedback from Alisdair, Mike, and Kiyoshi. Two main changes occur here: - One function is added which allows for a programmatically created mapped device to be inserted into the dm-ioctl hash table. This binds the device to a name and, optional, uuid which is needed by udev and allows for userspace management of the mapped device. - dm_table_complete() was extended to handle all of the final functional changes required for the table to be operational once called. 2. init: boot to device-mapper targets without an initr* Add a dm= kernel parameter modeled after the md= parameter from do_mounts_md. It allows for device-mapper targets to be configured at boot time for use early in the boot process (as the root device or otherwise). It also replaces /dev/XXX calls with major:minor opportunistically. The format is dm="name uuid ro,table line 1,table line 2,...". The parser expects the comma to be safe to use as a newline substitute but, otherwise, uses the normal separator of space. Some attempt has been made to make it forgiving of additional spaces (using skip_spaces()). A mapped device created during boot will be assigned a minor of 0 and may be access via /dev/dm-0. An example dm-linear root with no uuid may look like: root=/dev/dm-0 dm="lroot none ro, 0 4096 linear /dev/ubdb 0, 4096 4096 linear /dv/ubdc 0" Once udev is started, /dev/dm-0 will become /dev/mapper/lroot. Older upstream threads: http://marc.info/?l=dm-devel&m=127429492521964&w=2 http://marc.info/?l=dm-devel&m=127429499422096&w=2 http://marc.info/?l=dm-devel&m=127429493922000&w=2 Latest upstream threads: https://patchwork.kernel.org/patch/104859/ https://patchwork.kernel.org/patch/104860/ https://patchwork.kernel.org/patch/104861/ Bug: 27175947 Signed-off-by: Will Drewry <[email protected]> Review URL: http://codereview.chromium.org/2020011 Change-Id: I92bd53432a11241228d2e5ac89a3b20d19b05a31

1. "dm: optimize use SRCU and RCU" removes the use of dm_table_put. 2. "dm: remove request-based logic from make_request_fn wrapper" necessitates calling dm_setup_md_queue or else the request_queue's make_request_fn pointer ends being unset. [ 7.711600] Internal error: Oops - bad mode: 0 [xin3liang#1] PREEMPT SMP [ 7.717519] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.1.15-02273-gb057d16-dirty torvalds#33 [ 7.726559] Hardware name: HiKey Development Board (DT) [ 7.731779] task: ffffffc005f8acc0 ti: ffffffc005f8c000 task.ti: ffffffc005f8c000 [ 7.739257] PC is at 0x0 [ 7.741787] LR is at generic_make_request+0x8c/0x108 .... [ 9.082931] Call trace: [ 9.085372] [< (null)>] (null) [ 9.090074] [<ffffffc0003f4ac0>] submit_bio+0x98/0x1e0 [ 9.095212] [<ffffffc0001e2618>] _submit_bh+0x120/0x1f0 [ 9.096165] cfg80211: Calling CRDA to update world regulatory domain [ 9.106781] [<ffffffc0001e5450>] __bread_gfp+0x94/0x114 [ 9.112004] [<ffffffc00024a748>] ext4_fill_super+0x18c/0x2d64 [ 9.117750] [<ffffffc0001b275c>] mount_bdev+0x194/0x1c0 [ 9.122973] [<ffffffc0002450dc>] ext4_mount+0x14/0x1c [ 9.128021] [<ffffffc0001b29a0>] mount_fs+0x3c/0x194 [ 9.132985] [<ffffffc0001d059c>] vfs_kern_mount+0x4c/0x134 [ 9.138467] [<ffffffc0001d2168>] do_mount+0x204/0xbbc [ 9.143514] [<ffffffc0001d2ec4>] SyS_mount+0x94/0xe8 [ 9.148479] [<ffffffc000c54074>] mount_block_root+0x120/0x24c [ 9.154222] [<ffffffc000c543e8>] mount_root+0x110/0x12c [ 9.159443] [<ffffffc000c54574>] prepare_namespace+0x170/0x1b8 [ 9.165273] [<ffffffc000c53d98>] kernel_init_freeable+0x23c/0x260 [ 9.171365] [<ffffffc0009b1748>] kernel_init+0x10/0x118 [ 9.176589] Code: bad PC value [ 9.179807] ---[ end trace 75e1bc52ba364d13 ]--- Bug: 27175947 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: I952d86fd1475f0825f9be1386e3497b36127abd0

When candidate is the last parameter, candidate_end points to the '\0' character and not the DM_FIELD_SEP character. In such a situation, we should not move the candidate_end pointer one character backward. Signed-off-by: Jeremy Compostella <[email protected]>

This device-mapper target is virtually a VERITY target. This target is setup by reading the metadata contents piggybacked to the actual data blocks in the block device. The signature of the metadata contents are verified against the key included in the system keyring. Upon success, the underlying verity target is setup. BUG: 27175947 Change-Id: I7e99644a0960ac8279f02c0158ed20999510ea97 Signed-off-by: Badhri Jagan Sridharan <[email protected]>

Following CLs in upstream causes minor changes to dm-android-verity target. 1. keys: change asymmetric keys to use common hash definitions 2. block: Abstract out bvec iterator Rebase dm-android-verity on top of these changes. Bug: 27175947 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: Icfdc3e7b3ead5de335a059cade1aca70414db415

This CL makes android-verity target to be added as linear dm device if when bootloader is unlocked and verity is disabled. Bug: 27175947 Change-Id: Ic41ca4b8908fb2777263799cf3a3e25934d70f18 Signed-off-by: Badhri Jagan Sridharan <[email protected]>

Compacts the linear device arguments removing the unnecessary variables. Bug: 27175947 Change-Id: I157170eebe3c0f89a68ae05870a1060f188d0da0 Signed-off-by: Badhri Jagan Sridharan <[email protected]>

This keeps linear_target as static variable and just exposes the linear target methods for android-verity Cherry-picked: https://android-review.googlesource.com/#/c/212858 Change-Id: I4a377e417b00afd9ecccdb3e605fea31a7df112e Signed-off-by: Badhri Jagan Sridharan <[email protected]> (cherry picked from commit a6d1b09)

This patch makes android_verity_ctr() parse its block device string parameter with name_to_dev_t(). It allows the use of less hardware related block device reference like PARTUUID for instance. Change-Id: Idb84453e70cc11abd5ef3a0adfbb16f8b5feaf07 Signed-off-by: Jeremy Compostella <[email protected]>

The bug was that the signature verification was only happening when verity was disabled. It should always happen when verity is enabled. Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: I2d9354e240d36ea06fc68c2d18d8e87b823a4c2f (cherry picked from commit 5364b5c)

If the dm-android-verity target does not provide a default key try using the default public key from the system keyring. The defualt verity keyid is passed as a kernel command line argument veritykeyid=. The order of the dm-android-verity params have been reversed to facilitate the change. Old format example: dm="system none ro,0 1 android-verity Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f /dev/mmcblk0p43" New formats supported: dm="system none ro,0 1 android-verity /dev/mmcblk0p43 Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f" (or) dm="system none ro,0 1 android-verity /dev/mmcblk0p43" when veritykeyid= is set in the kernel command line. BUG: 28384658 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: I506c89b053d835ab579e703eef2bc1f8487250de (cherry picked from commit c5c74d0)

eng builds dont have verity enabled i.e it does even have verity metadata appended to the parition. Therefore add rootdev as linear device and map the entire partition if build variant is "eng". (Cherry-picked based on https://partner-android-review.git.corp.google.com/#/c/618690/) BUG: 29276559 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: I8f5c2289b842b820ca04f5773525e5449bb3f355

adb disable-verity was allowed when the phone is in the unlocked state. Since the driver is now aware of the build variant, honor "adb disable-verity" only in userdebug builds. (Cherry-picked from https://partner-android-review.git.corp.google.com/#/c/622117) BUG: 29276559 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: I7ce9f38d8c7a62361392c5a8ccebb288f8a3a2ea

Move header validation logic before reading the verity_table as an invalid header implies the table is invalid as well. (Cherry-picked from: https://partner-android-review.git.corp.google.com/#/c/625203) BUG: 29940612 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: Ib34d25c0854202f3e70df0a6d0ef1d96f0250c8e

The fec_header structure is generated build time and stored on disk. The fec_header might be build on a 64 bits machine while it is read per a 32 bits device or the other way around. In such situations, the fec_header fields are not aligned as expected by the device and it fails to read the fec_header structure. This patch makes the fec_header packed. Change-Id: Idb84453e70cc11abd5ef3a0adfbb16f8b5feaf06 Signed-off-by: Jeremy Compostella <[email protected]>

This is the 4.4.17 stable release

In changing from checking ptrace_may_access(p, PTRACE_MODE_ATTACH_FSCREDS) to capable(CAP_SYS_NICE), I missed that ptrace_my_access succeeds when p == current, but the CAP_SYS_NICE doesn't. Thus while the previous commit was intended to loosen the needed privledges to modify a processes timerslack, it needlessly restricted a task modifying its own timerslack via the proc/<tid>/timerslack_ns (which is permitted also via the PR_SET_TIMERSLACK method). This patch corrects this by checking if p == current before checking the CAP_SYS_NICE value. Cc: Kees Cook <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> CC: Arjan van de Ven <[email protected]> Cc: Oren Laadan <[email protected]> Cc: Ruchi Kandoi <[email protected]> Cc: Rom Lemarchand <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Colin Cross <[email protected]> Cc: Nick Kralevich <[email protected]> Cc: Dmitry Shmidt <[email protected]> Cc: Elliott Hughes <[email protected]> Cc: Android Kernel Team <[email protected]> Mailing-list-url: http://www.spinics.net/lists/kernel/msg2317488.html Change-Id: Ia3e8aff07c2d41f55b6617502d33c39b7d781aac Signed-off-by: John Stultz <[email protected]>

Remove duplicate FRA_GOTO assignment. Fixes: fd2cf79 ("net: core: Support UID-based routing.") Change-Id: I462c24b16fdef42ae2332571a0b95de3ef9d2e25 Signed-off-by: Amit Pundir <[email protected]>

Fix RTA_UID enum to match it with the Android userspace code which assumes RTA_UID=18. With this patch all Android kernel networking unit tests mentioned here https://source.android.com/devices/tech/config/kernel_network_tests.html are success. Without this patch multinetwork_test.py unit test fails. Change-Id: I3ff36670f7d4e5bf5f01dce584ae9d53deabb3ed Signed-off-by: Amit Pundir <[email protected]>

(cherry picked from commit 78c4e17) This reverts upstream commit 2f36db7. It fixed a local root exploit but also introduced a dependency on the lower file system implementing an mmap operation just to open a file, which is a bit of a heavy hammer. The right fix is to have mmap depend on the existence of the mmap handler instead. Signed-off-by: Jeff Mahoney <[email protected]> Cc: [email protected] Signed-off-by: Tyler Hicks <[email protected]> Fixes: Change-Id I0be77c7f8bd3046bc34cd87ef577529792d479bc ("UPSTREAM: ecryptfs: forbid opening files without mmap handler") Change-Id: Ib9bc87099f7f89e4e12dbc1a79e884dcadb1befb Signed-off-by: Amit Pundir <[email protected]>

…t it (cherry picked from commit f0fe970) There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap support on file systems that don't offer support natively. CVE-2016-1583 Signed-off-by: Jeff Mahoney <[email protected]> Cc: [email protected] [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()] Signed-off-by: Tyler Hicks <[email protected]> Change-Id: I66e3670771630a25b0608f10019d1584e9ce73a6 Signed-off-by: Amit Pundir <[email protected]>

(cherry picked from commit 6a480a7) First of all, trying to open them r/w is idiocy; it's guaranteed to fail. Moreover, assigning ->f_pos and assuming that everything will work is blatantly broken - try that with e.g. tmpfs as underlying layer and watch the fireworks. There may be a non-trivial amount of state associated with current IO position, well beyond the numeric offset. Using the single struct file associated with underlying inode is really not a good idea; we ought to open one for each ecryptfs directory struct file. Additionally, file_operations both for directories and non-directories are full of pointless methods; non-directories should *not* have ->iterate(), directories should not have ->flush(), ->fasync() and ->splice_read(). Signed-off-by: Al Viro <[email protected]> Change-Id: I4813ce803f270fdd364758ce1dc108b76eab226e Signed-off-by: Amit Pundir <[email protected]>

v4.4 introduced changes to the callbacks used for dm-linear and dm-verity-target targets. Move to those headers in dm-android-verity. Verified on hikey while having BOARD_USES_RECOVERY_AS_BOOT := true BOARD_BUILD_SYSTEM_ROOT_IMAGE := true BUG: 27339727 Signed-off-by: Badhri Jagan Sridharan <[email protected]> Change-Id: Ic64950c3b55f0a6eaa570bcedc2ace83bbf3005e

…y-linaro-4.4-aosp

Adds helpers to do SMC and HVC based on ARM SMC Calling Convention. CONFIG_HAVE_ARM_SMCCC is enabled for architectures that may support the SMC or HVC instruction. It's the responsibility of the caller to know if the SMC instruction is supported by the platform. This patch doesn't provide an implementation of the declared functions. Later patches will bring in implementations and set CONFIG_HAVE_ARM_SMCCC for ARM and ARM64 respectively. Change-Id: If9182cf66926f668c56ab7b5db3d5199da67395f Reviewed-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: David Brown <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Adds implementation for arm-smccc and enables CONFIG_HAVE_SMCCC for architectures that may support arm-smccc. It's the responsibility of the caller to know if the SMC instruction is supported by the platform. Change-Id: I3656cac5469dc0c8d96117ba33c53b37d92dbfab Reviewed-by: Lars Persson <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: David Brown <[email protected]>

Adds implementation for arm-smccc and enables CONFIG_HAVE_SMCCC. Change-Id: I0751001628f0c46e5eb0f0f9c253718491875591 Acked-by: Will Deacon <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: David Brown <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE implementation. Change-Id: I777c012b744c2ebdfd0b09aba08170c587d26e0a Acked-by: Rob Herring <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Initial patch for generic TEE subsystem. This subsystem provides: * Registration/un-registration of TEE drivers. * Shared memory between normal world and secure world. * Ioctl interface for interaction with user space. * Sysfs implementation_id of TEE driver A TEE (Trusted Execution Environment) driver is a driver that interfaces with a trusted OS running in some secure environment, for example, TrustZone on ARM cpus, or a separate secure co-processor etc. The TEE subsystem can serve a TEE driver for a Global Platform compliant TEE, but it's not limited to only Global Platform TEEs. This patch builds on other similar implementations trying to solve the same problem: * "optee_linuxdriver" by among others Jean-michel DELORME<[email protected]> and Emmanuel MICHEL <[email protected]> * "Generic TrustZone Driver" by Javier González <[email protected]> Change-Id: I9b859011fe6eb697fb6771724d6933df9fdfb895 Acked-by: Andreas Dannenberg <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Adds a OP-TEE driver which also can be compiled as a loadable module. * Targets ARM and ARM64 * Supports using reserved memory from OP-TEE as shared memory * Probes OP-TEE version using SMCs * Accepts requests on privileged and unprivileged device * Uses OPTEE message protocol version 2 to communicate with secure world Change-Id: I2fa86374de723602a9edd642c1a4f26c5455d79b Acked-by: Andreas Dannenberg <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Change-Id: I890b6d1c25525d149ca10cd63aba6f3954acb72f Acked-by: Andreas Dannenberg <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Adds a kernel internal TEE client interface to be used by other drivers. Change-Id: I3bd6ad0037a319ac489749f378f1714b1d017ebd Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Enables use of PSCI for foundation-v8. Change-Id: I119ea8fbf5f37527f07d0b1c20f575049ce48977 Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Uses GICv2 for foundation-v8. Change-Id: I0200801e264bee5a285a1d3490ec5699bb489c5b Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Configures foundation-v8 with OP-TEE. Change-Id: I08f6cef05cbe38b11e93a0d62ec1b32e8d74ab53 Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Adds qemu-v8 with OP-TEE and PSCI. Change-Id: I56820911f2115f60cd2fe2309e25d94af314c9b4 Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Change-Id: I0a63c65b84cc0f159b505118db9e75288baa1190 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Configures Juno with OP-TEE. Change-Id: Id38c8b2e2e25ca662c4b7df19f6a511ac5797100 Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Prevents two OP-TEE supplicant processes from running simultaneously. Change-Id: I7398c52f25b9b6828cc573356cae73430b732bf2 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Corrections based on output from tool provided by Nishanth Menon at https://github.com/nmenon/kernel_patch_verify The patch will merged into the "tee: add OP-TEE driver" commit when creating the v10 patch set. Change-Id: I29d3606e3eda784e1d70988c5ebb9483e2ae37ca Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Corrections based on output from tool provided by Nishanth Menon at https://github.com/nmenon/kernel_patch_verify The patch will merged into the "tee: generic TEE subsystem" commit when creating the v10 patch set. Change-Id: I858549d6e658e022d14d61dd3d1d1cf7228fd189 Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Prior to this patch the ARM_SMCCC_FAST_CALL constant was of an unsigned type causing unwanted sign extension. This patch explicitly selects an unsigned type for the constant. Change-Id: I2f00aac76a7b2201f4a439d40e14d352f0052fb3 Reviewed-by: Pascal Brand <[email protected]> Tested-by: Jens Wiklander <[email protected]> (QEMU Aarch64) Reported-by: Saksham Jain <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Adds a juno-r2.dts based on juno-r1.dts configured with OP-TEE. Change-Id: I4037ce8d08ef2985e3cf5c3c2fc81bc29c7da15d Signed-off-by: Miraje Gentilal <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Avoids delayed release of a shared memory object allocated by supplicant. Change-Id: I7ff3114f86b19932bc13bebe7c17a8e54ea1f474 Tested-by: Jerome Forissier <[email protected]> (HiKey) Tested-by: Jens Wiklander <[email protected]> (QEMU) Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Zoltan Kuscsik <[email protected]>

Change-Id: I3b43b1db5053654d348e4d897a907236680ead9f Signed-off-by: Zoltan Kuscsik <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Android hikey linaro 4.4 #19

Android hikey linaro 4.4 #19

Commits on Jul 27, 2016

Commits on Jul 28, 2016

Commits on Jul 29, 2016

Commits on Aug 1, 2016

Commits on Aug 3, 2016

Commits on Aug 8, 2016

Commits on Aug 10, 2016

Commits on Aug 11, 2016

Commits on Aug 12, 2016

Commits on Aug 16, 2016

Android hikey linaro 4.4 #19

Are you sure you want to change the base?

Android hikey linaro 4.4 #19

Commits on Jul 27, 2016

Commits on Jul 28, 2016

Commits on Jul 29, 2016

Commits on Aug 1, 2016

Commits on Aug 3, 2016

Commits on Aug 8, 2016

Commits on Aug 10, 2016

Commits on Aug 11, 2016

Commits on Aug 12, 2016

Commits on Aug 16, 2016