commit 22ccf8f1a5450ac5a6bc2bb519699838017ce1ea Author: Jiri Slaby Date: Mon Feb 16 16:15:42 2015 +0100 Linux 3.12.38 commit d2d5ce5c2a6d667203a1fc8726925e67d871c92f Author: Vikas Chaudhary Date: Tue May 13 07:41:32 2014 -0400 iscsi_ibft: Fix finding Broadcom specific ibft sign commit 629c27aa0c930b9c67188cfc625bf6cdd2af6764 upstream. Search for Broadcom specific ibft sign "BIFT" along with other possible values on UEFI This patch is fix for regression introduced in “935a9fee51c945b8942be2d7b4bae069167b4886”. https://lkml.org/lkml/2011/12/16/353 This impacts Broadcom CNA for iSCSI Boot on UEFI platform. Signed-off-by: Vikas Chaudhary Signed-off-by: Konrad Rzeszutek Wilk Acked-by: Mike Christie Signed-off-by: Jiri Slaby commit 526d09dfa647cacd71d7271bb30bf058f6cf72a2 Author: Randy Wright Date: Wed Jun 4 08:55:59 2014 -0700 ACPI: Fix bug when ACPI reset register is implemented in system memory commit a4714a898e85205e1118ec923cde43d88eb105f6 upstream. Use acpi_os_map_generic_address to pre-map the reset register if it is memory mapped, thereby preventing the BUG_ON() in line 1319 of mm/vmalloc.c from triggering during panic-triggered reboots. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77131 Signed-off-by: Randy Wright Signed-off-by: David E. Box [rjw: Changelog, simplified code] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 18f12cbe86a5d6d4afc710cd3e3e064898808738 Author: James Custer Date: Sun Nov 2 12:16:39 2014 -0600 x86: UV BAU: Avoid NULL pointer reference in ptc_seq_show commit fa2a79ce6aef5de35a4d50487da35deb6b634944 upstream. In init_per_cpu(), when get_cpu_topology() fails, init_per_cpu_tunables() is not called afterwards. This means that bau_control->statp is NULL. If a user then reads /proc/sgi_uv/ptc_statistics ptc_seq_show() references a NULL pointer. Therefore, since uv_bau_init calls set_bau_off when init_per_cpu() fails, we add code that detects when the bau is off in ptc_seq_show() to avoid referencing a NULL pointer. Signed-off-by: James Custer Cc: Russ Anderson Link: http://lkml.kernel.org/r/1414952199-185319-2-git-send-email-jcuster@sgi.com Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit ebf1059f4bc4e12a6878c44137f95fafc1fe55b3 Author: Eric Paris Date: Tue Jul 23 17:38:42 2013 -0400 SELinux: fix selinuxfs policy file on big endian systems commit b138004ea0382bdc6d02599c39392651b4f63889 upstream. The /sys/fs/selinux/policy file is not valid on big endian systems like ppc64 or s390. Let's see why: static int hashtab_cnt(void *key, void *data, void *ptr) { int *cnt = ptr; *cnt = *cnt + 1; return 0; } static int range_write(struct policydb *p, void *fp) { size_t nel; [...] /* count the number of entries in the hashtab */ nel = 0; rc = hashtab_map(p->range_tr, hashtab_cnt, &nel); if (rc) return rc; buf[0] = cpu_to_le32(nel); rc = put_entry(buf, sizeof(u32), 1, fp); So size_t is 64 bits. But then we pass a pointer to it as we do to hashtab_cnt. hashtab_cnt thinks it is a 32 bit int and only deals with the first 4 bytes. On x86_64 which is little endian, those first 4 bytes and the least significant, so this works out fine. On ppc64/s390 those first 4 bytes of memory are the high order bits. So at the end of the call to hashtab_map nel has a HUGE number. But the least significant 32 bits are all 0's. We then pass that 64 bit number to cpu_to_le32() which happily truncates it to a 32 bit number and does endian swapping. But the low 32 bits are all 0's. So no matter how many entries are in the hashtab, big endian systems always say there are 0 entries because I screwed up the counting. The fix is easy. Use a 32 bit int, as the hashtab_cnt expects, for nel. Signed-off-by: Eric Paris Signed-off-by: Paul Moore Signed-off-by: Jiri Slaby commit dac05cc7cc144635946cdc6ed38a6734424c2683 Author: Hannes Reinecke Date: Wed Nov 5 14:35:50 2014 +0100 dm: do not call dm_sync_table() when creating new devices commit 41abc4e1af369bb5438eaee398e3beee690cc8ca upstream. When creating new devices dm_sync_table() calls synchronize_rcu_expedited(), causing _all_ pending RCU pointers to be flushed. This causes a latency overhead that is especially noticeable when creating lots of devices. And all of this is pointless as there are no old maps to be disconnected, and hence no stale pointers which would need to be cleared up. Signed-off-by: Hannes Reinecke Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit 677984600a8de443ca9596998e96d70dfc8f5525 Author: Jiri Slaby Date: Fri Nov 21 10:05:09 2014 +0100 parport: parport_pc, do not remove parent devices early commit 91905b6f4afe51e23a3f58df93e4cdc5e49cf40c upstream. When the parport_pc module is removed from the system, all parport devices are iterated in parport_pc_exit and removed by a call to parport_pc_unregister_port. Note that some parport devices have its 'struct device' parent, known as port->dev. And when port->dev is a platform device, it is destroyed in parport_pc_exit too. Now, when parport_pc_unregister_port is called for a going port, drv->detach(port) is called for every parport driver in the system. ppdev can be one of them. ppdev's detach() tears down its per-port sysfs directory, which established port->dev as a parent earlier. But since parport_pc_exit kills port->dev parents before unregisters ports proper, ppdev's sysfs directory has no living parent anymore. This results in the following warning: WARNING: CPU: 1 PID: 785 at fs/sysfs/group.c:219 sysfs_remove_group+0x9b/0xa0 sysfs group ffffffff81c69e20 not found for kobject 'parport1' Modules linked in: parport_pc(E-) ppdev(E) [last unloaded: ppdev] CPU: 1 PID: 785 Comm: rmmod Tainted: G W E 3.18.0-rc5-next-20141120+ #824 ... Call Trace: ... [] warn_slowpath_fmt+0x46/0x50 [] sysfs_remove_group+0x9b/0xa0 [] dpm_sysfs_remove+0x57/0x60 [] device_del+0x49/0x240 [] device_unregister+0x22/0x70 [] device_destroy+0x3c/0x50 [] pp_detach+0x4a/0x60 [ppdev] [] parport_remove_port+0x11d/0x150 [] parport_pc_unregister_port+0x28/0xf0 [parport_pc] [] parport_pc_exit+0x76/0x468 [parport_pc] [] SyS_delete_module+0x18c/0x230 It is also easily reproducible on qemu with two dummy ports '-parallel /dev/null -parallel /dev/null'. So switch the order of killing the two structures. But since port is freed by parport_pc_unregister_port, we have to remember port->dev in a local variable. Perhaps nothing worse than the warning happens thanks to the device refcounting. We *should* be on the safe side. Signed-off-by: Jiri Slaby Reviewed-by: Takashi Iwai Tested-by: Martin Pluskal Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 6b5b362832201d2629202506896d45bced67657a Author: Jesse Barnes Date: Tue Nov 12 10:17:39 2013 -0800 x86/early quirk: use gen6 stolen detection for VLV commit 7bd40c16ccb2cb6877dd00b0e66249c171e6fa43 upstream. We've always been able to use either method on VLV, but it appears more recent BIOSes only support the gen6 method, so switch over to that. References: https://bugs.freedesktop.org/show_bug.cgi?id=71370 Signed-off-by: Jesse Barnes Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Jiri Slaby commit c94011ac6ae0bbfc8966ec256ad7b1bf30feaeec Author: Jan Kara Date: Fri Dec 19 14:27:55 2014 +0100 udf: Check component length before reading it commit e237ec37ec154564f8690c5bd1795339955eeef9 upstream. Check that length specified in a component of a symlink fits in the input buffer we are reading. Also properly ignore component length for component types that do not use it. Otherwise we read memory after end of buffer for corrupted udf image. Reported-by: Carl Henrik Lunde CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit ebfce5ccba81292a5e34710a602117769118fa9a Author: Jan Kara Date: Thu Dec 18 22:37:50 2014 +0100 udf: Check path length when reading symlink commit 0e5cc9a40ada6046e6bc3bdfcd0c0d7e4b706b14 upstream. Symlink reading code does not check whether the resulting path fits into the page provided by the generic code. This isn't as easy as just checking the symlink size because of various encoding conversions we perform on path. So we have to check whether there is still enough space in the buffer on the fly. CC: stable@vger.kernel.org Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit 4ff6c40be897225cf818c5202871cfb91ed064f6 Author: Jan Kara Date: Fri Dec 19 12:03:53 2014 +0100 udf: Verify i_size when loading inode commit e159332b9af4b04d882dbcfe1bb0117f0a6d4b58 upstream. Verify that inode size is sane when loading inode with data stored in ICB. Otherwise we may get confused later when working with the inode and inode size is too big. CC: stable@vger.kernel.org Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit c75789fb19feb86b64d60387f0e6525f05d95b64 Author: Goldwyn Rodrigues Date: Wed Dec 10 15:41:53 2014 -0800 ocfs2: remove filesize checks for sync I/O journal commit commit 86b9c6f3f891019b26f8e5bb11a6faa96bba54a8 upstream. Filesize is not a good indication that the file needs to be synced. An example where this breaks is: 1. Open the file in O_SYNC|O_RDWR 2. Read a small portion of the file (say 64 bytes) 3. Lseek to starting of the file 4. Write 64 bytes If the node crashes, it is not written out to disk because this was not committed in the journal and the other node which reads the file after recovery reads stale data (even if the write on the other node was successful) Signed-off-by: Goldwyn Rodrigues Reviewed-by: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 0deb7f8cc68902c58b1c735d933f69994709d7e6 Author: Trond Myklebust Date: Thu Jul 3 00:02:57 2014 -0400 SUNRPC: Handle EPIPE in xprt_connect_status commit 2fc193cf924ea6eb74f6a0cf73b94b2e62938ae5 upstream. The callback handler xs_error_report() can end up propagating an EPIPE error by means of the call to xprt_wake_pending_tasks(). Ensure that xprt_connect_status() does not automatically convert this into an EIO error. Reported-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 27219fc0724390534b5c462fa14b9dc353334410 Author: Trond Myklebust Date: Mon Jun 30 13:42:19 2014 -0400 SUNRPC: Ensure that we handle ENOBUFS errors correctly. commit 3601c4a91ebbbf1cf69f66a2abeffc6c64a4fe64 upstream. Currently, an ENOBUFS error will result in a fatal error for the RPC call. Normally, we will just want to wait and then retry. Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 94feca620813d8e56911a839d3b60ac42a950b64 Author: Steve Dickson Date: Thu Mar 20 11:23:03 2014 -0400 SUNRPC: Ensure call_connect_status() deals correctly with SOFTCONN tasks commit 1fa3e2eb9db07f30a605c66d1a2fdde4b24e74d5 upstream. Don't schedule an rpc_delay before checking to see if the task is a SOFTCONN because the tk_callback from the delay (__rpc_atrun) clears the task status before the rpc_exit_task can be run. Signed-off-by: Steve Dickson Fixes: 561ec1603171c (SUNRPC: call_connect_status should recheck...) Link: http://lkml.kernel.org/r/5329CF7C.7090308@RedHat.com Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 97034d21e60e27ff15f8caad7c101fdd29103651 Author: Trond Myklebust Date: Mon Mar 17 12:51:44 2014 -0400 SUNRPC: Ensure that call_connect times out correctly commit 485f2251782f7c44299c491d4676a8a01428d191 upstream. When the server is unavailable due to a networking error, etc, we want the RPC client to respect the timeout delays when attempting to reconnect. Reported-by: Neil Brown Fixes: 561ec1603171 (SUNRPC: call_connect_status should recheck bind..) Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 51fedbbb1a7838732e8de08bec078c2e0066974a Author: Trond Myklebust Date: Tue Dec 31 13:11:43 2013 -0500 SUNRPC: Handle connect errors ECONNABORTED and EHOSTUNREACH commit df2772700c6ee706be7b2fd16c6bf2c1bf63cda0 upstream. Ensure that call_bind_status, call_connect_status, call_transmit_status and call_status all are capable of handling ECONNABORTED and EHOSTUNREACH. Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 6686e9091ed571d4a616d2e655c22e34ded49fcb Author: Trond Myklebust Date: Tue Dec 31 13:13:30 2013 -0500 SUNRPC: Ensure xprt_connect_status handles all potential connection errors commit 0fe8d04e8c3a1eb49089793e38b60a17cee564e3 upstream. Currently, xprt_connect_status will convert connection error values such as ECONNREFUSED, ECONNRESET, ... into EIO, which means that they never get handled. Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 5a88b3915463423b14e19d50e96f35fa2a6f96d1 Author: Trond Myklebust Date: Thu Sep 26 15:22:45 2013 -0400 SUNRPC: call_connect_status should recheck bind and connect status on error commit 561ec1603171cd9b38dcf6cac53e8710f437a48d upstream. Currently, we go directly to call_transmit which sends us to call_status on error. If we know that the connect attempt failed, we should rather just jump straight back to call_bind and call_connect. Ditto for EAGAIN, except do not delay. Signed-off-by: Trond Myklebust Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit e204d37abbe3f0de038c750ba75c39250a061cb2 Author: David Rientjes Date: Wed May 7 13:03:41 2014 -0700 net, sunrpc: suppress allocation warning in rpc_malloc() commit c6c8fe79a83e1a03e5dd83d0bac178d6ba5ef30a upstream. rpc_malloc() allocates with GFP_NOWAIT without making any attempt at reclaim so it easily fails when low on memory. This ends up spamming the kernel log: SLAB: Unable to allocate memory on node 0 (gfp=0x4000) cache: kmalloc-8192, object size: 8192, order: 1 node 0: slabs: 207/207, objs: 207/207, free: 0 rekonq: page allocation failure: order:1, mode:0x204000 CPU: 2 PID: 14321 Comm: rekonq Tainted: G O 3.15.0-rc3-12.gfc9498b-desktop+ #6 Hardware name: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 2105 07/23/2010 0000000000000000 ffff880010ff17d0 ffffffff815e693c 0000000000204000 ffff880010ff1858 ffffffff81137bd2 0000000000000000 0000001000000000 ffff88011ffebc38 0000000000000001 0000000000204000 ffff88011ffea000 Call Trace: [] dump_stack+0x4d/0x6f [] warn_alloc_failed+0xd2/0x140 [] __alloc_pages_nodemask+0x7e9/0xa30 [] kmem_getpages+0x58/0x140 [] fallback_alloc+0x1d6/0x210 [] ____cache_alloc_node+0x123/0x150 [] __kmalloc+0x203/0x490 [] rpc_malloc+0x32/0xa0 [sunrpc] [] call_allocate+0xb9/0x170 [sunrpc] [] __rpc_execute+0x88/0x460 [sunrpc] [] rpc_execute+0x59/0xc0 [sunrpc] [] rpc_run_task+0x6b/0x90 [sunrpc] [] nfs4_call_sync_sequence+0x51/0x80 [nfsv4] [] _nfs4_do_setattr+0x1ed/0x280 [nfsv4] [] nfs4_do_setattr+0x72/0x180 [nfsv4] [] nfs4_proc_setattr+0xbc/0x140 [nfsv4] [] nfs_setattr+0xd8/0x240 [nfs] [] notify_change+0x231/0x380 [] chmod_common+0xfc/0x120 [] SyS_chmod+0x40/0x90 [] system_call_fastpath+0x1a/0x1f ... If the allocation fails, simply return NULL and avoid spamming the kernel log. Reported-by: Marc Dietrich Signed-off-by: David Rientjes Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 414a72c0854c450ceff6d82ce3267ae328b32707 Author: Len Brown Date: Fri Feb 14 01:14:13 2014 -0500 ACPI idle: permit sparse C-state sub-state numbers commit 2194324d8bbbad1b179c08b6095649b06abd62d5 upstream. Linux uses CPUID.MWAIT.EDX to validate the C-states reported by ACPI, silently discarding states which are not supported by the HW. This test is too restrictive, as some HW now uses sparse sub-state numbering, so the sub-state number may be higher than the number of sub-states... Also, rather than silently ignoring an invalid state, we should complain about a firmware bug. In practice... Bay Trail systems originally supported C6-no-shrink as MWAIT sub-state 0x58, and in CPUID.MWAIT.EDX 0x03000000 indicated that there were 3 MWAIT-C6 sub-states. So acpi_idle would discard that C-state because 8 >= 3. Upon discovering this issue, the ucode was updated so that C6-no-shrink was also exported as 0x51, and the BIOS was updated to match. However, systems shipped with 0x58, will never get a BIOS update, and this patch allows Linux to see C6-no-shrink on early Bay Trail. Signed-off-by: Len Brown Signed-off-by: Jiri Slaby commit b116a0436c29bd83196d1988d75521044dc36e5d Author: Manfred Spraul Date: Fri Dec 12 16:58:11 2014 -0800 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb() commit 2e094abfd1f29a08a60523b42d4508281b8dee0e upstream. When I fixed bugs in the sem_lock() logic, I was more conservative than necessary. Therefore it is safe to replace the smp_mb() with smp_rmb(). And: With smp_rmb(), semop() syscalls are up to 10% faster. The race we must protect against is: sem->lock is free sma->complex_count = 0 sma->sem_perm.lock held by thread B thread A: A: spin_lock(&sem->lock) B: sma->complex_count++; (now 1) B: spin_unlock(&sma->sem_perm.lock); A: spin_is_locked(&sma->sem_perm.lock); A: XXXXX memory barrier A: if (sma->complex_count == 0) Thread A must read the increased complex_count value, i.e. the read must not be reordered with the read of sem_perm.lock done by spin_is_locked(). Since it's about ordering of reads, smp_rmb() is sufficient. [akpm@linux-foundation.org: update sem_lock() comment, from Davidlohr] Signed-off-by: Manfred Spraul Reviewed-by: Davidlohr Bueso Acked-by: Rafael Aquini Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 23b4103455d52e2ffdc4758aea29ba6d70d246ca Author: Nadav Amit Date: Thu Sep 18 22:39:45 2014 +0300 KVM: x86: Sysexit emulation does not mask RIP/RSP commit bf0b682c9b6a6d6d54adf439bfe953feef7be2e8 upstream. If the operand size is not 64-bit, then the sysexit instruction should assign ECX to RSP and EDX to RIP. The current code assigns the full 64-bits. Fix it by masking. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 9a4288057afa92094ebc782475a4edba07d0f26e Author: Nadav Amit Date: Thu Sep 18 22:39:44 2014 +0300 KVM: vmx: Inject #GP on invalid PAT CR commit 4566654bb9be9e8864df417bb72ceee5136b6a6a upstream. Guest which sets the PAT CR to invalid value should get a #GP. Currently, if vmx supports loading PAT CR during entry, then the value is not checked. This patch makes the required check in that case. Signed-off-by: Nadav Amit Signed-off-by: Bruce Rogers Signed-off-by: Jiri Slaby commit a9638450cced05855cbb366fc6dd0792375a6611 Author: Nadav Amit Date: Thu Sep 18 22:39:43 2014 +0300 KVM: x86: emulating descriptor load misses long-mode case commit 040c8dc8a5afa7364bb8bb5b1b76c30007d6be14 upstream. In 64-bit mode a #GP should be delivered to the guest "if the code segment descriptor pointed to by the selector in the 64-bit gate doesn't have the L-bit set and the D-bit clear." - Intel SDM "Interrupt 13—General Protection Exception (#GP)". This patch fixes the behavior of CS loading emulation code. Although the comment says that segment loading is not supported in long mode, this function is executed in long mode, so the fix is necassary. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 067eafed0e6d973ee173fe1b7c2e1b29bfbfdafe Author: Nadav Amit Date: Thu Sep 18 22:39:42 2014 +0300 KVM: x86: Distinguish between stack operation and near branches commit 58b7075d059f7d37ca86c76fb1446fa3447b9f4f upstream. In 64-bit, stack operations default to 64-bits, but can be overriden (to 16-bit) using opsize override prefix. In contrast, near-branches are always 64-bit. This patch distinguish between the different behaviors. Signed-off-by: Nadav Amit Signed-off-by: Bruce Rogers Signed-off-by: Jiri Slaby commit 154832bf8bb0c22cd1b2a70c3e4491548f8d158a Author: Nadav Amit Date: Thu Sep 18 22:39:41 2014 +0300 KVM: x86: Getting rid of grp45 in emulator commit f7784046ab7cfc1645f4110b6ed14fbdffc2abee upstream. Breaking grp45 to the relevant functions to speed up the emulation and simplify the code. In addition, it is necassary the next patch will distinguish between far and near branches according to the flags. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 74b0a4b9b2a2e38b9459aa8f606503ff8c61e100 Author: Nadav Amit Date: Thu Sep 18 22:39:39 2014 +0300 KVM: x86: Handle errors when RIP is set during far jumps commit d1442d85cc30ea75f7d399474ca738e0bc96f715 upstream. Far jmp/call/ret may fault while loading a new RIP. Currently KVM does not handle this case, and may result in failed vm-entry once the assignment is done. The tricky part of doing so is that loading the new CS affects the VMCS/VMCB state, so if we fail during loading the new RIP, we are left in unconsistent state. Therefore, this patch saves on 64-bit the old CS descriptor and restores it if loading RIP failed. Signed-off-by: Nadav Amit Signed-off-by: Bruce Rogers Signed-off-by: Jiri Slaby commit 293e0568a4320cec3d5226fbb3ed14abac3b05d1 Author: Nadav Amit Date: Thu Sep 18 22:39:35 2014 +0300 KVM: x86: Warn if guest virtual address space is not 48-bits commit dd598091de4aabbc8bd7290a04f364e443c03455 upstream. The KVM emulator code assumes that the guest virtual address space (in 64-bit) is 48-bits wide. Since we are about to add more code that makes the same assumption, this patch adds an assertion to make sure guest virtual address space is indeed 48-bits wide. Signed-off-by: Nadav Amit Signed-off-by: Bruce Rogers Signed-off-by: Jiri Slaby commit 297b900186075ead7d08bccb2d46137f1838b220 Author: Adam Lee Date: Thu Feb 12 13:42:31 2015 +0800 Bluetooth: ath3k: workaround the compatibility issue with xHCI controller commit c561a5753dd631920c4459a067d22679b3d110d6 upstream. BugLink: https://bugs.launchpad.net/bugs/1400215 ath3k devices fail to load firmwares on xHCI buses, but work well on EHCI, this might be a compatibility issue between xHCI and ath3k chips. As my testing result, those chips will work on xHCI buses again with this patch. This workaround is from Qualcomm, they also did some workarounds in Windows driver. Signed-off-by: Adam Lee Signed-off-by: Marcel Holtmann Signed-off-by: Jiri Slaby commit 1d8d26c764494f5c2e44829fac384be819cee180 Author: Austin Lund Date: Thu Jul 24 07:40:20 2014 -0300 [media] media/rc: Send sync space information on the lirc device commit a8f29e89f2b54fbf2c52be341f149bc195b63a8b upstream. Userspace expects to see a long space before the first pulse is sent on the lirc device. Currently, if a long time has passed and a new packet is started, the lirc codec just returns and doesn't send anything. This makes lircd ignore many perfectly valid signals unless they are sent in quick sucession. When a reset event is delivered, we cannot know anything about the duration of the space. But it should be safe to assume it has been a long time and we just set the duration to maximum. Signed-off-by: Austin Lund Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 15c029a998d463691fc36b55826d136b2b6b67f5 Author: Alex Elder Date: Tue Mar 25 15:36:02 2014 +0200 rbd: drop an unsafe assertion commit 638c323c4d1f8eaf25224946e21ce8818f1bcee1 upstream. Olivier Bonvalet reported having repeated crashes due to a failed assertion he was hitting in rbd_img_obj_callback(): Assertion failure in rbd_img_obj_callback() at line 2165: rbd_assert(which >= img_request->next_completion); With a lot of help from Olivier with reproducing the problem we were able to determine the object and image requests had already been completed (and often freed) at the point the assertion failed. There was a great deal of discussion on the ceph-devel mailing list about this. The problem only arose when there were two (or more) object requests in an image request, and the problem was always seen when the second request was being completed. The problem is due to a race in the window between setting the "done" flag on an object request and checking the image request's next completion value. When the first object request completes, it checks to see if its successor request is marked "done", and if so, that request is also completed. In the process, the image request's next_completion value is updated to reflect that both the first and second requests are completed. By the time the second request is able to check the next_completion value, it has been set to a value *greater* than its own "which" value, which caused an assertion to fail. Fix this problem by skipping over any completion processing unless the completing object request is the next one expected. Test only for inequality (not >=), and eliminate the bad assertion. Tested-by: Olivier Bonvalet Signed-off-by: Alex Elder Reviewed-by: Sage Weil Reviewed-by: Ilya Dryomov Signed-off-by: Jiri Slaby commit 7b7685e37bc001fc53b96f7aaf5894eddf914ca4 Author: Saran Maruti Ramanara Date: Thu Jan 29 11:05:58 2015 +0100 net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param [ Upstream commit cfbf654efc6d78dc9812e030673b86f235bf677d ] When making use of RFC5061, section 4.2.4. for setting the primary IP address, we're passing a wrong parameter header to param_type2af(), resulting always in NULL being returned. At this point, param.p points to a sctp_addip_param struct, containing a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation id. Followed by that, as also presented in RFC5061 section 4.2.4., comes the actual sctp_addr_param, which also contains a sctp_paramhdr, but this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that param_type2af() can make use of. Since we already hold a pointer to addr_param from previous line, just reuse it for param_type2af(). Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT") Signed-off-by: Saran Maruti Ramanara Signed-off-by: Daniel Borkmann Acked-by: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 030892ea1af3f4ff26a9474690e75f211b9b592a Author: Florian Westphal Date: Wed Jan 28 10:56:04 2015 +0100 ppp: deflate: never return len larger than output buffer [ Upstream commit e2a4800e75780ccf4e6c2487f82b688ba736eb18 ] When we've run out of space in the output buffer to store more data, we will call zlib_deflate with a NULL output buffer until we've consumed remaining input. When this happens, olen contains the size the output buffer would have consumed iff we'd have had enough room. This can later cause skb_over_panic when ppp_generic skb_put()s the returned length. Reported-by: Iain Douglas Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1a95b47aa41d11726cf0634034b80d28f0521832 Author: Eric Dumazet Date: Thu Jan 29 21:35:05 2015 -0800 ipv4: tcp: get rid of ugly unicast_sock [ Upstream commit bdbbb8527b6f6a358dbcb70dac247034d665b8e4 ] In commit be9f4a44e7d41 ("ipv4: tcp: remove per net tcp_sock") I tried to address contention on a socket lock, but the solution I chose was horrible : commit 3a7c384ffd57e ("ipv4: tcp: unicast_sock should not land outside of TCP stack") addressed a selinux regression. commit 0980e56e506b ("ipv4: tcp: set unicast_sock uc_ttl to -1") took care of another regression. commit b5ec8eeac46 ("ipv4: fix ip_send_skb()") fixed another regression. commit 811230cd85 ("tcp: ipv4: initialize unicast_sock sk_pacing_rate") was another shot in the dark. Really, just use a proper socket per cpu, and remove the skb_orphan() call, to re-enable flow control. This solves a serious problem with FQ packet scheduler when used in hostile environments, as we do not want to allocate a flow structure for every RST packet sent in response to a spoofed packet. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5e1ab4d77a27e1c6f17101261f8aa759720a203e Author: Eric Dumazet Date: Wed Jan 28 05:47:11 2015 -0800 tcp: ipv4: initialize unicast_sock sk_pacing_rate [ Upstream commit 811230cd853d62f09ed0addd0ce9a1b9b0e13fb5 ] When I added sk_pacing_rate field, I forgot to initialize its value in the per cpu unicast_sock used in ip_send_unicast_reply() This means that for sch_fq users, RST packets, or ACK packets sent on behalf of TIME_WAIT sockets might be sent to slowly or even dropped once we reach the per flow limit. Signed-off-by: Eric Dumazet Fixes: 95bd09eb2750 ("tcp: TSO packets automatic sizing") Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit efa4b71b378f2fadd4c99b05da033009b9ec349a Author: Roopa Prabhu Date: Wed Jan 28 16:23:11 2015 -0800 bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify [ Upstream commit 59ccaaaa49b5b096cdc1f16706a9f931416b2332 ] Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081 This patch avoids calling rtnl_notify if the device ndo_bridge_getlink handler does not return any bytes in the skb. Alternately, the skb->len check can be moved inside rtnl_notify. For the bridge vlan case described in 92081, there is also a fix needed in bridge driver to generate a proper notification. Will fix that in subsequent patch. v2: rebase patch on net tree Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit d7a5ebfe21c15d1a871587be0006f3fc31e54296 Author: Christoph Hellwig Date: Tue Jan 27 12:25:33 2015 -0800 net: don't OOPS on socket aio [ Upstream commit 06539d3071067ff146a9bffd1c801fa56d290909 ] Signed-off-by: Christoph Hellwig Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7b254cb1d121f8a1def63aad8d9104114b0b0e53 Author: Govindarajulu Varadarajan <_govind@gmx.com> Date: Sun Jan 25 16:09:23 2015 +0530 bnx2x: fix napi poll return value for repoll [ Upstream commit 24e579c8898aa641ede3149234906982290934e5 ] With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi repoll is done only when work_done == budget. When in busy_poll is we return 0 in napi_poll. We should return budget. Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c196ece7d43ba9597ea7fefa8a12c454858e4d6c Author: Hannes Frederic Sowa Date: Mon Jan 26 15:11:17 2015 +0100 ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too [ Upstream commit 6e9e16e6143b725662e47026a1d0f270721cdd24 ] Lubomir Rintel reported that during replacing a route the interface reference counter isn't correctly decremented. To quote bug : | [root@rhel7-5 lkundrak]# sh -x lal | + ip link add dev0 type dummy | + ip link set dev0 up | + ip link add dev1 type dummy | + ip link set dev1 up | + ip addr add 2001:db8:8086::2/64 dev dev0 | + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20 | + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10 | + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20 | + ip link del dev0 type dummy | Message from syslogd@rhel7-5 at Jan 23 10:54:41 ... | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2 | | Message from syslogd@rhel7-5 at Jan 23 10:54:51 ... | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2 During replacement of a rt6_info we must walk all parent nodes and check if the to be replaced rt6_info got propagated. If so, replace it with an alive one. Fixes: 4a287eba2de3957 ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag") Reported-by: Lubomir Rintel Signed-off-by: Hannes Frederic Sowa Tested-by: Lubomir Rintel Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 757651a70148d9e1695daa6709988e09fd940cec Author: subashab@codeaurora.org Date: Fri Jan 23 22:26:02 2015 +0000 ping: Fix race in free in receive path [ Upstream commit fc752f1f43c1c038a2c6ae58cc739ebb5953ccb0 ] An exception is seen in ICMP ping receive path where the skb destructor sock_rfree() tries to access a freed socket. This happens because ping_rcv() releases socket reference with sock_put() and this internally frees up the socket. Later icmp_rcv() will try to free the skb and as part of this, skb destructor is called and which leads to a kernel panic as the socket is freed already in ping_rcv(). -->|exception -007|sk_mem_uncharge -007|sock_rfree -008|skb_release_head_state -009|skb_release_all -009|__kfree_skb -010|kfree_skb -011|icmp_rcv -012|ip_local_deliver_finish Fix this incorrect free by cloning this skb and processing this cloned skb instead. This patch was suggested by Eric Dumazet Signed-off-by: Subash Abhinov Kasiviswanathan Cc: Eric Dumazet Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fd09a4de42024767c0fb9ea797e96454b0054130 Author: Herbert Xu Date: Sat Jan 24 08:02:40 2015 +1100 udp_diag: Fix socket skipping within chain [ Upstream commit 86f3cddbc3037882414c7308973530167906b7e9 ] While working on rhashtable walking I noticed that the UDP diag dumping code is buggy. In particular, the socket skipping within a chain never happens, even though we record the number of sockets that should be skipped. As this code was supposedly copied from TCP, this patch does what TCP does and resets num before we walk a chain. Signed-off-by: Herbert Xu Acked-by: Pavel Emelyanov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 8277cc54f4245d71a00acba3672616c1e3b4dc65 Author: Hannes Frederic Sowa Date: Fri Jan 23 12:01:26 2015 +0100 ipv4: try to cache dst_entries which would cause a redirect [ Upstream commit df4d92549f23e1c037e83323aff58a21b3de7fe0 ] Not caching dst_entries which cause redirects could be exploited by hosts on the same subnet, causing a severe DoS attack. This effect aggravated since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()"). Lookups causing redirects will be allocated with DST_NOCACHE set which will force dst_release to free them via RCU. Unfortunately waiting for RCU grace period just takes too long, we can end up with >1M dst_entries waiting to be released and the system will run OOM. rcuos threads cannot catch up under high softirq load. Attaching the flag to emit a redirect later on to the specific skb allows us to cache those dst_entries thus reducing the pressure on allocation and deallocation. This issue was discovered by Marcelo Leitner. Cc: Julian Anastasov Signed-off-by: Marcelo Leitner Signed-off-by: Florian Westphal Signed-off-by: Hannes Frederic Sowa Signed-off-by: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 43e39c2f63240f67a67b4060882f67dac1a6f339 Author: Daniel Borkmann Date: Thu Jan 22 18:26:54 2015 +0100 net: sctp: fix slab corruption from use after free on INIT collisions [ Upstream commit 600ddd6825543962fb807884169e57b580dba208 ] When hitting an INIT collision case during the 4WHS with AUTH enabled, as already described in detail in commit 1be9a950c646 ("net: sctp: inherit auth_capable on INIT collisions"), it can happen that we occasionally still remotely trigger the following panic on server side which seems to have been uncovered after the fix from commit 1be9a950c646 ... [ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff [ 533.913657] IP: [] __kmalloc+0x95/0x230 [ 533.940559] PGD 5030f2067 PUD 0 [ 533.957104] Oops: 0000 [#1] SMP [ 533.974283] Modules linked in: sctp mlx4_en [...] [ 534.939704] Call Trace: [ 534.951833] [] ? crypto_init_shash_ops+0x60/0xf0 [ 534.984213] [] crypto_init_shash_ops+0x60/0xf0 [ 535.015025] [] __crypto_alloc_tfm+0x6d/0x170 [ 535.045661] [] crypto_alloc_base+0x4c/0xb0 [ 535.074593] [] ? _raw_spin_lock_bh+0x12/0x50 [ 535.105239] [] sctp_inet_listen+0x161/0x1e0 [sctp] [ 535.138606] [] SyS_listen+0x9d/0xb0 [ 535.166848] [] system_call_fastpath+0x16/0x1b ... or depending on the the application, for example this one: [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff [ 1370.026506] IP: [] kmem_cache_alloc+0x75/0x1d0 [ 1370.054568] PGD 633c94067 PUD 0 [ 1370.070446] Oops: 0000 [#1] SMP [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...] [ 1370.963431] Call Trace: [ 1370.974632] [] ? SyS_epoll_ctl+0x53f/0x960 [ 1371.000863] [] SyS_epoll_ctl+0x53f/0x960 [ 1371.027154] [] ? anon_inode_getfile+0xd3/0x170 [ 1371.054679] [] ? __alloc_fd+0xa7/0x130 [ 1371.080183] [] system_call_fastpath+0x16/0x1b With slab debugging enabled, we can see that the poison has been overwritten: [ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten [ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b [ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494 [ 669.826424] __slab_alloc+0x4bf/0x566 [ 669.826433] __kmalloc+0x280/0x310 [ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp] [ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp] [ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp] [ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...] [ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494 [ 669.826635] __slab_free+0x39/0x2a8 [ 669.826643] kfree+0x1d6/0x230 [ 669.826650] kzfree+0x31/0x40 [ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp] [ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp] [ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp] Since this only triggers in some collision-cases with AUTH, the problem at heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice when having refcnt 1, once directly in sctp_assoc_update() and yet again from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on the already kzfree'd memory, which is also consistent with the observation of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected at a later point in time when poison is checked on new allocation). Reference counting of auth keys revisited: Shared keys for AUTH chunks are being stored in endpoints and associations in endpoint_shared_keys list. On endpoint creation, a null key is being added; on association creation, all endpoint shared keys are being cached and thus cloned over to the association. struct sctp_shared_key only holds a pointer to the actual key bytes, that is, struct sctp_auth_bytes which keeps track of users internally through refcounting. Naturally, on assoc or enpoint destruction, sctp_shared_key are being destroyed directly and the reference on sctp_auth_bytes dropped. User space can add keys to either list via setsockopt(2) through struct sctp_authkey and by passing that to sctp_auth_set_key() which replaces or adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes with refcount 1 and in case of replacement drops the reference on the old sctp_auth_bytes. A key can be set active from user space through setsockopt() on the id via sctp_auth_set_active_key(), which iterates through either endpoint_shared_keys and in case of an assoc, invokes (one of various places) sctp_auth_asoc_init_active_key(). sctp_auth_asoc_init_active_key() computes the actual secret from local's and peer's random, hmac and shared key parameters and returns a new key directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops the reference if there was a previous one. The secret, which where we eventually double drop the ref comes from sctp_auth_asoc_set_secret() with intitial refcount of 1, which also stays unchanged eventually in sctp_assoc_update(). This key is later being used for crypto layer to set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac(). To close the loop: asoc->asoc_shared_key is freshly allocated secret material and independant of the sctp_shared_key management keeping track of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76 ("net: sctp: fix memory leak in auth key management") is independant of this bug here since it concerns a different layer (though same structures being used eventually). asoc->asoc_shared_key is reference dropped correctly on assoc destruction in sctp_association_free() and when active keys are being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is to remove that sctp_auth_key_put() from there which fixes these panics. Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing") Signed-off-by: Daniel Borkmann Acked-by: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 795c55d8ad906db83c2997fe16bd2e319fa4df01 Author: Eric Dumazet Date: Thu Jan 22 07:56:18 2015 -0800 netxen: fix netxen_nic_poll() logic [ Upstream commit 6088beef3f7517717bd21d90b379714dd0837079 ] NAPI poll logic now enforces that a poller returns exactly the budget when it wants to be called again. If a driver limits TX completion, it has to return budget as well when the limit is hit, not the number of received packets. Reported-and-tested-by: Mike Galbraith Signed-off-by: Eric Dumazet Fixes: d75b1ade567f ("net: less interrupt masking in NAPI") Cc: Manish Chopra Acked-by: Manish Chopra Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit a20ac4fd85a5c37db9603f451abbe7834e5ae6cb Author: Hagen Paul Pfeifer Date: Thu Jan 15 22:34:25 2015 +0100 ipv6: stop sending PTB packets for MTU < 1280 [ Upstream commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2 ] Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments. See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused. [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00 Signed-off-by: Fernando Gont Signed-off-by: Hagen Paul Pfeifer Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 488070c6dbd92ba5431f54fabb2101d09e3a018c Author: Eric Dumazet Date: Thu Jan 15 17:04:22 2015 -0800 net: rps: fix cpu unplug [ Upstream commit ac64da0b83d82abe62f78b3d0e21cca31aea24fa ] softnet_data.input_pkt_queue is protected by a spinlock that we must hold when transferring packets from victim queue to an active one. This is because other cpus could still be trying to enqueue packets into victim queue. A second problem is that when we transfert the NAPI poll_list from victim to current cpu, we absolutely need to special case the percpu backlog, because we do not want to add complex locking to protect process_queue : Only owner cpu is allowed to manipulate it, unless cpu is offline. Based on initial patch from Prasad Sodagudi & Subash Abhinov Kasiviswanathan. This version is better because we do not slow down packet processing, only make migration safer. Reported-by: Prasad Sodagudi Reported-by: Subash Abhinov Kasiviswanathan Signed-off-by: Eric Dumazet Cc: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7c82148b3715206c5ffea1ffde27e5f44fa30363 Author: Willem de Bruijn Date: Thu Jan 15 13:18:40 2015 -0500 ip: zero sockaddr returned on error queue [ Upstream commit f812116b174e59a350acc8e4856213a166a91222 ] The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That structure is defined and allocated on the stack as struct { struct sock_extended_err ee; struct sockaddr_in(6) offender; } errhdr; The second part is only initialized for certain SO_EE_ORIGIN values. Always initialize it completely. An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that would return uninitialized bytes. Signed-off-by: Willem de Bruijn ---- Also verified that there is no padding between errhdr.ee and errhdr.offender that could leak additional kernel data. Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 21c29e8e5abd84bc15fa05d4b1fce0f8ccb9856f Author: Mathias Krause Date: Tue Feb 10 01:14:07 2015 +0100 crypto: crc32c - add missing crypto module alias The backport of commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"") lost the MODULE_ALIAS_CRYPTO() annotation of crc32c.c. Add it to fix the reported filesystem related regressions. Signed-off-by: Mathias Krause Reported-by: Philip Müller Cc: Kees Cook Cc: Rob McCathie Cc: Luis Henriques Cc: Kamal Mostafa Cc: Jiri Slaby Signed-off-by: Jiri Slaby commit 2e70fb5dcbaec195febf1eee3b96e8b47e432c35 Author: Andy Lutomirski Date: Wed Oct 8 09:02:13 2014 -0700 x86,kvm,vmx: Preserve CR4 across VM entry commit d974baa398f34393db76be45f7d4d04fbdbb4a0a upstream. CR4 isn't constant; at least the TSD and PCE bits can vary. TBH, treating CR0 and CR3 as constant scares me a bit, too, but it looks like it's correct. This adds a branch and a read from cr4 to each vm entry. Because it is extremely likely that consecutive entries into the same vcpu will have the same host cr4 value, this fixes up the vmcs instead of restoring cr4 after the fact. A subsequent patch will add a kernel-wide cr4 shadow, reducing the overhead in the common case to just two memory reads and a branch. Signed-off-by: Andy Lutomirski Acked-by: Paolo Bonzini Cc: Petr Matousek Cc: Gleb Natapov Signed-off-by: Linus Torvalds [wangkai: Backport to 3.10: adjust context] Signed-off-by: Wang Kai Signed-off-by: Jiri Slaby commit d51ecc125de8d526f79106d169ab9f6353eab96f Author: Lai Jiangshan Date: Thu Jul 31 11:30:17 2014 +0800 smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread() commit 4bee96860a65c3a62d332edac331b3cf936ba3ad upstream. The following race exists in the smpboot percpu threads management: CPU0 CPU1 cpu_up(2) get_online_cpus(); smpboot_create_threads(2); smpboot_register_percpu_thread(); for_each_online_cpu(); __smpboot_create_thread(); __cpu_up(2); This results in a missing per cpu thread for the newly onlined cpu2 and in a NULL pointer dereference on a consecutive offline of that cpu. Proctect smpboot_register_percpu_thread() with get_online_cpus() to prevent that. [ tglx: Massaged changelog and removed the change in smpboot_unregister_percpu_thread() because that's an optimization and therefor not stable material. ] Signed-off-by: Lai Jiangshan Cc: Thomas Gleixner Cc: Rusty Russell Cc: Peter Zijlstra Cc: Srivatsa S. Bhat Cc: David Rientjes Link: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.com Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit acccc0891b814bb82566dbbf76e96f47497c3dd8 Author: Takashi Iwai Date: Tue Jan 13 10:53:20 2015 +0100 ALSA: ak411x: Fix stall in work callback commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream. When ak4114 work calls its callback and the callback invokes ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding this, control the reentrance by introducing a refcount. Also flush_delayed_work() is replaced with cancel_delayed_work_sync(). The exactly same bug is present in ak4113.c and fixed as well. Reported-by: Pavel Hofman Acked-by: Jaroslav Kysela Tested-by: Pavel Hofman Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b8de3b8efb36fbac23f80ba980858777ff0c4034 Author: Eric Nelson Date: Fri Jan 30 14:07:55 2015 -0700 ASoC: sgtl5000: add delay before first I2C access commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream. To quote from section 1.3.1 of the data sheet: The SGTL5000 has an internal reset that is deasserted 8 SYS_MCLK cycles after all power rails have been brought up. After this time, communication can start ... 1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK. Signed-off-by: Eric Nelson Reviewed-by: Fabio Estevam Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 118ccf9d5bd49b33ad27fa821ef0ab1c3839ec77 Author: Bo Shen Date: Tue Jan 20 15:43:16 2015 +0800 ASoC: atmel_ssc_dai: fix start event for I2S mode commit a43bd7e125143b875caae6d4f9938855b440faaf upstream. According to the I2S specification information as following: - WS = 0, channel 1 (left) - WS = 1, channel 2 (right) So, the start event should be TF/RF falling edge. Reported-by: Songjun Wu Signed-off-by: Bo Shen Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit d7cd6f80ee9c79db2078b049e45cda10308ec2fa Author: karl beldan Date: Thu Jan 29 11:10:22 2015 +0100 lib/checksum.c: fix build for generic csum_tcpudp_nofold commit 9ce357795ef208faa0d59894d9d119a7434e37f3 upstream. Fixed commit added from64to32 under _#ifndef do_csum_ but used it under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's robot reported TILEGX's). Move from64to32 under the latter. Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold") Reported-by: kbuild test robot Signed-off-by: Karl Beldan Cc: Eric Dumazet Cc: David S. Miller Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Jiri Slaby commit 1be17527706edd39569a79470eee572301566725 Author: Dmitry Monakhov Date: Thu Oct 30 10:53:16 2014 -0400 ext4: prevent bugon on race between write/fcntl commit a41537e69b4aa43f0fea02498c2595a81267383b upstream. O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked twice inside ext4_file_write_iter() and __generic_file_write() which result in BUG_ON inside ext4_direct_IO. Let's initialize iocb->private unconditionally. TESTCASE: xfstest:generic/036 https://patchwork.ozlabs.org/patch/402445/ #TYPICAL STACK TRACE: kernel BUG at fs/ext4/inode.c:2960! invalid opcode: 0000 [#1] SMP Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 #161 Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011 task: ffff88080e95a7c0 ti: ffff88080f908000 task.ti: ffff88080f908000 RIP: 0010:[] [] ext4_direct_IO+0x162/0x3d0 RSP: 0018:ffff88080f90bb58 EFLAGS: 00010246 RAX: 0000000000000400 RBX: ffff88080fdb2a28 RCX: 00000000a802c818 RDX: 0000040000080000 RSI: ffff88080d8aeb80 RDI: 0000000000000001 RBP: ffff88080f90bbc8 R08: 0000000000000000 R09: 0000000000001581 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88080d8aeb80 R13: ffff88080f90bbf8 R14: ffff88080fdb28c8 R15: ffff88080fdb2a28 FS: 00007f23b2055700(0000) GS:ffff880818400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f23b2045000 CR3: 000000080cedf000 CR4: 00000000000407e0 Stack: ffff88080f90bb98 0000000000000000 7ffffffffffffffe ffff88080fdb2c30 0000000000000200 0000000000000200 0000000000000001 0000000000000200 ffff88080f90bbc8 ffff88080fdb2c30 ffff88080f90be08 0000000000000200 Call Trace: [] generic_file_direct_write+0xed/0x180 [] __generic_file_write_iter+0x222/0x370 [] ext4_file_write_iter+0x34b/0x400 [] ? aio_run_iocb+0x239/0x410 [] ? aio_run_iocb+0x239/0x410 [] ? local_clock+0x25/0x30 [] ? __lock_acquire+0x274/0x700 [] ? ext4_unwritten_wait+0xb0/0xb0 [] aio_run_iocb+0x286/0x410 [] ? local_clock+0x25/0x30 [] ? lock_release_holdtime+0x29/0x190 [] ? lookup_ioctx+0x4b/0xf0 [] do_io_submit+0x55b/0x740 [] ? do_io_submit+0x3ca/0x740 [] SyS_io_submit+0x10/0x20 [] system_call_fastpath+0x16/0x1b Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c 24 18 00 75 04 <0f> 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89 RIP [] ext4_direct_IO+0x162/0x3d0 RSP Reported-by: Sasha Levin Signed-off-by: Theodore Ts'o Signed-off-by: Dmitry Monakhov [hujianyang: Backported to 3.10 - Move initialization of iocb->private to ext4_file_write() as we don't have ext4_file_write_iter(), which is introduced by commit 9b884164. - Adjust context to make 'overwrite' changes apply to ext4_file_dio_write() as ext4_file_dio_write() is not move into ext4_file_write()] Signed-off-by: hujianyang Signed-off-by: Jiri Slaby commit 737a342fa7217fadd2e3c52ecfbfe1e9d307fa60 Author: Peter Kümmel Date: Tue Nov 4 12:01:59 2014 +0100 kconfig: Fix warning "‘jump’ may be used uninitialized" commit 2d560306096739e2251329ab5c16059311a151b0 upstream. Warning: In file included from scripts/kconfig/zconf.tab.c:2537:0: scripts/kconfig/menu.c: In function ‘get_symbol_str’: scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] jump->offset = strlen(r->s); Simplifies the test logic because (head && local) means (jump != 0) and makes GCC happy when checking if the jump pointer was initialized. Signed-off-by: Peter Kümmel Signed-off-by: Michal Marek Cc: Sedat Dilek Signed-off-by: Jiri Slaby commit d26f2dfa556323787ee1ebd5d03aeaa8650c7404 Author: Ryusuke Konishi Date: Thu Feb 5 12:25:20 2015 -0800 nilfs2: fix deadlock of segment constructor over I_SYNC flag commit 7ef3ff2fea8bf5e4a21cef47ad87710a3d0fdb52 upstream. Nilfs2 eventually hangs in a stress test with fsstress program. This issue was caused by the following deadlock over I_SYNC flag between nilfs_segctor_thread() and writeback_sb_inodes(): nilfs_segctor_thread() nilfs_segctor_thread_construct() nilfs_segctor_unlock() nilfs_dispose_list() iput() iput_final() evict() inode_wait_for_writeback() * wait for I_SYNC flag writeback_sb_inodes() * set I_SYNC flag on inode->i_state __writeback_single_inode() do_writepages() nilfs_writepages() nilfs_construct_dsync_segment() nilfs_segctor_sync() * wait for completion of segment constructor inode_sync_complete() * clear I_SYNC flag after __writeback_single_inode() completed writeback_sb_inodes() calls do_writepages() for dirty inodes after setting I_SYNC flag on inode->i_state. do_writepages() in turn calls nilfs_writepages(), which can run segment constructor and wait for its completion. On the other hand, segment constructor calls iput(), which can call evict() and wait for the I_SYNC flag on inode_wait_for_writeback(). Since segment constructor doesn't know when I_SYNC will be set, it cannot know whether iput() will block or not unless inode->i_nlink has a non-zero count. We can prevent evict() from being called in iput() by implementing sop->drop_inode(), but it's not preferable to leave inodes with i_nlink == 0 for long periods because it even defers file truncation and inode deallocation. So, this instead resolves the deadlock by calling iput() asynchronously with a workqueue for inodes with i_nlink == 0. Signed-off-by: Ryusuke Konishi Cc: Al Viro Tested-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 07707a797d6c3cd0bfe86f037d3d1eb329acbc86 Author: karl beldan Date: Wed Jan 28 10:58:11 2015 +0100 lib/checksum.c: fix carry in csum_tcpudp_nofold commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream. The carry from the 64->32bits folding was dropped, e.g with: saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1, csum_tcpudp_nofold returned 0 instead of 1. Signed-off-by: Karl Beldan Cc: Al Viro Cc: Eric Dumazet Cc: Arnd Bergmann Cc: Mike Frysinger Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit aa223666b397e1d8318100693b7bb4230e836321 Author: Shiraz Hashim Date: Thu Feb 5 12:25:06 2015 -0800 mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range commit 23aaed6659df9adfabe9c583e67a36b54e21df46 upstream. walk_page_range() silently skips vma having VM_PFNMAP set, which leads to undesirable behaviour at client end (who called walk_page_range). Userspace applications get the wrong data, so the effect is like just confusing users (if the applications just display the data) or sometimes killing the processes (if the applications do something with misunderstanding virtual addresses due to the wrong data.) For example for pagemap_read, when no callbacks are called against VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual address range at wrong index. Eventually userspace may get wrong pagemap data for a task. Corresponding to a VM_PFNMAP marked vma region, kernel may report mappings from subsequent vma regions. User space in turn may account more pages (than really are) to the task. In my case I was using procmem, procrack (Android utility) which uses pagemap interface to account RSS pages of a task. Due to this bug it was giving a wrong picture for vmas (with VM_PFNMAP set). Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas") Signed-off-by: Shiraz Hashim Acked-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit b1518aca8a2bf43c8b0fa0099d33be75846c65c3 Author: Sachin Prabhu Date: Thu Jan 15 12:22:04 2015 +0000 Complete oplock break jobs before closing file handle commit ca7df8e0bb2a5ec79691de8a1a4c0e611fe04e60 upstream. Commit c11f1df5003d534fd067f0168bfad7befffb3b5c requires writers to wait for any pending oplock break handler to complete before proceeding to write. This is done by waiting on bit CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is cleared by the oplock break handler job queued on the workqueue once it has completed handling the oplock break allowing writers to proceed with writing to the file. While testing, it was noticed that the filehandle could be closed while there is a pending oplock break which results in the oplock break handler on the cifsiod workqueue being cancelled before it has had a chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit. Any subsequent attempt to write to this file hangs waiting for the CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared. We fix this by ensuring that we also clear the bit CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler from the workqueue. The bug was found by Red Hat QA while testing using ltp's fsstress command. Signed-off-by: Sachin Prabhu Acked-by: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Jiri Slaby commit 3b92dcea2b0907fa77662d4f97751d502a4d90d9 Author: Hemmo Nieminen Date: Thu Jan 15 23:01:59 2015 +0200 MIPS: Fix kernel lockup or crash after CPU offline/online commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream. As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by: Hemmo Nieminen Signed-off-by: Aaro Koskinen Cc: David Daney Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8953/ Signed-off-by: Ralf Baechle Signed-off-by: Jiri Slaby commit 3b69bb3195ae82511e6ee383713baf87f9a08711 Author: Felix Fietkau Date: Thu Jan 15 19:05:28 2015 +0100 MIPS: IRQ: Fix disable_irq on CPU IRQs commit a3e6c1eff54878506b2dddcc202df9cc8180facb upstream. If the irq_chip does not define .irq_disable, any call to disable_irq will defer disabling the IRQ until it fires while marked as disabled. This assumes that the handler function checks for this condition, which handle_percpu_irq does not. In this case, calling disable_irq leads to an IRQ storm, if the interrupt fires while disabled. This optimization is only useful when disabling the IRQ is slow, which is not true for the MIPS CPU IRQ. Disable this optimization by implementing .irq_disable and .irq_enable Signed-off-by: Felix Fietkau Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8949/ Signed-off-by: Ralf Baechle Signed-off-by: Jiri Slaby commit 2d4b4e6e40b05e17ff1a1510a8a41ba0fed83ad1 Author: Charlotte Richardson Date: Mon Feb 2 09:36:23 2015 -0600 PCI: Add NEC variants to Stratus ftServer PCIe DMI check commit 51ac3d2f0c505ca36ffc9715ffd518d756589ef8 upstream. NEC OEMs the same platforms as Stratus does, which have multiple devices on some PCIe buses under downstream ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Fixes: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)") Signed-off-by: Charlotte Richardson Signed-off-by: Bjorn Helgaas CC: Myron Stowe Signed-off-by: Jiri Slaby commit 6daef1d0b40c6f79d1b94b44f8b65429c7623589 Author: Johan Hovold Date: Mon Jan 26 12:02:46 2015 +0100 gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when setting the gpio-line polarity. Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in sysfs") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit ad55af958b2349ffafbb145166322b83fa8fed9d Author: Johan Hovold Date: Mon Jan 26 12:02:45 2015 +0100 gpio: sysfs: fix memory leak in gpiod_export_link commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when creating a link. Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using sysfs links") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit 1c2c26279c864adb131e0978556b2cfdc9ecabac Author: Martin Walch Date: Thu Oct 3 18:35:16 2013 +0200 kconfig: fix bug in search results string: use strlen(gstr->s), not gstr->len commit 503c823048e81cc85c0e9d8c297cc70203e335e5 upstream. The struct gstr has a capacity that may differ from the actual string length. However, a string manipulation in the function search_conf made the assumption that it is the same, which led to messing up some search results, especially when the content of the gstr in use had not yet reached at least 63 chars. Signed-off-by: Martin Walch Acked-by: Wang YanQing Acked-by: Benjamin Poirier Reviewed-by: "Yann E. MORIN" Signed-off-by: "Yann E. MORIN" Signed-off-by: Jiri Slaby commit c6662b96d3b81695d2eafa518e0dce7fa35ba30f Author: Tejun Heo Date: Fri Jan 16 14:21:16 2015 -0500 workqueue: fix subtle pool management issue which can stall whole worker_pool commit 29187a9eeaf362d8422e62e17a22a6e115277a49 upstream. A worker_pool's forward progress is guaranteed by the fact that the last idle worker assumes the manager role to create more workers and summon the rescuers if creating workers doesn't succeed in timely manner before proceeding to execute work items. This manager role is implemented in manage_workers(), which indicates whether the worker may proceed to work item execution with its return value. This is necessary because multiple workers may contend for the manager role, and, if there already is a manager, others should proceed to work item execution. Unfortunately, the function also indicates that the worker may proceed to work item execution if need_to_create_worker() is false at the head of the function. need_to_create_worker() tests the following conditions. pending work items && !nr_running && !nr_idle The first and third conditions are protected by pool->lock and thus won't change while holding pool->lock; however, nr_running can change asynchronously as other workers block and resume and while it's likely to be zero, as someone woke this worker up in the first place, some other workers could have become runnable inbetween making it non-zero. If this happens, manage_worker() could return false even with zero nr_idle making the worker, the last idle one, proceed to execute work items. If then all workers of the pool end up blocking on a resource which can only be released by a work item which is pending on that pool, the whole pool can deadlock as there's no one to create more workers or summon the rescuers. This patch fixes the problem by removing the early exit condition from maybe_create_worker() and making manage_workers() return false iff there's already another manager, which ensures that the last worker doesn't start executing work items. We can leave the early exit condition alone and just ignore the return value but the only reason it was put there is because the manage_workers() used to perform both creations and destructions of workers and thus the function may be invoked while the pool is trying to reduce the number of workers. Now that manage_workers() is called only when more workers are needed, the only case this early exit condition is triggered is rare race conditions rendering it pointless. Tested with simulated workload and modified workqueue code which trigger the pool deadlock reliably without this patch. tj: Updated to v3.14 where manage_workers() is responsible not only for creating more workers but also destroying surplus ones. maybe_create_worker() needs to keep its early exit condition to avoid creating a new worker when manage_workers() is called to destroy surplus ones. Other than that, the adaptabion is straight-forward. Both maybe_{create|destroy}_worker() functions are converted to return void and manage_workers() returns %false iff it lost manager arbitration. Signed-off-by: Tejun Heo Reported-by: Eric Sandeen Link: http://lkml.kernel.org/g/54B019F4.8030009@sandeen.net Cc: Dave Chinner Cc: Lai Jiangshan Signed-off-by: Jiri Slaby commit 926e01a576ca7630f4f52fa03127fb3276ac7e3e Author: Ilya Dryomov Date: Mon Jan 19 18:13:43 2015 +0300 rbd: fix rbd_dev_parent_get() when parent_overlap == 0 commit ae43e9d05eb4bd324155292f889fbd001c4faea8 upstream. The comment for rbd_dev_parent_get() said * We must get the reference before checking for the overlap to * coordinate properly with zeroing the parent overlap in * rbd_dev_v2_parent_info() when an image gets flattened. We * drop it again if there is no overlap. but the "drop it again if there is no overlap" part was missing from the implementation. This lead to absurd parent_ref values for images with parent_overlap == 0, as parent_ref was incremented for each img_request and virtually never decremented. Fix this by leveraging the fact that refresh path calls rbd_dev_v2_parent_info() under header_rwsem and use it for read in rbd_dev_parent_get(), instead of messing around with atomics. Get rid of barriers in rbd_dev_v2_parent_info() while at it - I don't see what they'd pair with now and I suspect we are in a pretty miserable situation as far as proper locking goes regardless. Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Reviewed-by: Alex Elder [idryomov@redhat.com: backport to 3.14: context] Signed-off-by: Jiri Slaby commit ed64a543fa0eb24125468b3c845b7cc05c848b34 Author: Liu ShuoX Date: Mon Mar 17 13:57:49 2014 -0700 pstore: Fix NULL pointer fault if get NULL prz in ramoops_get_next_prz commit b0aa931fb84431394d995472d0af2a6c2b61064d upstream. ramoops_get_next_prz get the prz according the paramters. If it get a uninitialized prz, access its members by following persistent_ram_old_size(prz) will cause a NULL pointer crash. Ex: if ftrace_size is 0, fprz will be NULL. Fix it by return NULL in advance. Signed-off-by: Liu ShuoX Acked-by: Kees Cook Signed-off-by: Tony Luck Cc: HuKeping Signed-off-by: Jiri Slaby commit 013d52e2500f66563ff14c74f43b68ab16cef9f1 Author: Liu ShuoX Date: Mon Mar 17 11:24:49 2014 +1100 pstore: skip zero size persistent ram buffer in traverse commit aa9a4a1edfbd3d223af01db833da2f07850bc655 upstream. In ramoops_pstore_read, a valid prz pointer with zero size buffer will break traverse of all persistent ram buffers. The latter buffer might be lost. Signed-off-by: Liu ShuoX Cc: "Zhang, Yanmin" Cc: Colin Cross Reviewed-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Tony Luck Cc: HuKeping Signed-off-by: Jiri Slaby commit 42ecc20bee44d55eb266116e9101bca9f7d6637a Author: Liu ShuoX Date: Mon Mar 17 11:24:49 2014 +1100 pstore: clarify clearing of _read_cnt in ramoops_context commit 57fd835385a043577457a385f28c08be693991bf upstream. *_read_cnt in ramoops_context need to be cleared during pstore ->open to support mutli times getting the records. The patch added missed ftrace_read_cnt clearing and removed duplicate clearing in ramoops_probe. Signed-off-by: Liu ShuoX Cc: "Zhang, Yanmin" Cc: Colin Cross Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Tony Luck Cc: HuKeping Signed-off-by: Jiri Slaby commit 51173bf8141d0dc740689b99ce88721e568eec39 Author: Russell King Date: Thu Jul 17 12:17:45 2014 +0100 ARM: DMA: ensure that old section mappings are flushed from the TLB commit 6b076991dca9817e75c37e2f0db6d52611ea42fa upstream. When setting up the CMA region, we must ensure that the old section mappings are flushed from the TLB before replacing them with page tables, otherwise we can suffer from mismatched aliases if the CPU speculatively prefetches from these mappings at an inopportune time. A mismatched alias can occur when the TLB contains a section mapping, but a subsequent prefetch causes it to load a page table mapping, resulting in the possibility of the TLB containing two matching mappings for the same virtual address region. Acked-by: Will Deacon Signed-off-by: Russell King Cc: Hou Pengyang Signed-off-by: Jiri Slaby commit d5ce89479359ee5ad97c40947ee71123b136db26 Author: Bob Paauwe Date: Thu Dec 18 09:51:26 2014 -0800 drm/i915: Only fence tiled region of object. commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream. When creating a fence for a tiled object, only fence the area that makes up the actual tiles. The object may be larger than the tiled area and if we allow those extra addresses to be fenced, they'll get converted to addresses beyond where the object is mapped. This opens up the possiblity of writes beyond the end of object. To prevent this, we adjust the size of the fence to only encompass the area that makes up the actual tiles. The extra space is considered un-tiled and now behaves as if it was a linear object. Testcase: igt/gem_tiled_fence_overflow Reported-by: Dan Hettena Signed-off-by: Bob Paauwe Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Jiri Slaby commit 92e66e18371b807e46da49c27b0b58dbf027c650 Author: Mugunthan V N Date: Thu Jan 22 15:19:22 2015 +0530 drivers: net: cpsw: discard dual emac default vlan configuration commit 02a54164c52ed6eca3089a0d402170fbf34d6cf5 upstream. In Dual EMAC, the default VLANs are used to segregate Rx packets between the ports, so adding the same default VLAN to the switch will affect the normal packet transfers. So returning error on addition of dual EMAC default VLANs. Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to break dual EMAC port separations. Fixes: d9ba8f9e6298 (driver: net: ethernet: cpsw: dual emac interface implementation) Reported-by: Felipe Balbi Signed-off-by: Mugunthan V N Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 28140574e151bbdbd34f28be4e656ea6b1b5ae9d Author: Ashay Jaiswal Date: Thu Jan 8 18:54:25 2015 +0530 regulator: core: fix race condition in regulator_put() commit 83b0302d347a49f951e904184afe57ac3723476e upstream. The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by: Ashay Jaiswal Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 7d2e24600d926215b262b4de111c298c14b9c3cd Author: Mika Westerberg Date: Mon Dec 29 10:33:36 2014 +0200 spi/pxa2xx: Clear cur_chip pointer before starting next message commit c957e8f084e0d21febcd6b8a0ea9631eccc92f36 upstream. Once the current message is finished, the driver notifies SPI core about this by calling spi_finalize_current_message(). This function queues next message to be transferred. If there are more messages in the queue, it is possible that the driver is asked to transfer the next message at this point. When spi_finalize_current_message() returns the driver clears the drv_data->cur_chip pointer to NULL. The problem is that if the driver already started the next message clearing drv_data->cur_chip will cause NULL pointer dereference which crashes the kernel like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] PGD 78bb8067 PUD 37712067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014 task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000 RIP: 0010:[] [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] RSP: 0018:ffff88007a823d08 EFLAGS: 00010202 RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430 RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98 R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000 FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0 Stack: ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89 0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006 ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204 Call Trace: [] giveback+0x69/0xa0 [spi_pxa2xx_platform] [] pump_transfers+0x710/0x740 [spi_pxa2xx_platform] [] ? pick_next_task_fair+0x744/0x830 [] tasklet_action+0xa9/0xe0 [] __do_softirq+0xee/0x280 [] run_ksoftirqd+0x20/0x40 [] smpboot_thread_fn+0xff/0x1b0 [] ? SyS_setgroups+0x150/0x150 [] kthread+0xcd/0xf0 [] ? kthread_create_on_node+0x180/0x180 [] ret_from_fork+0x7c/0xb0 Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message(). Reported-by: Martin Oldfield Signed-off-by: Mika Westerberg Acked-by: Robert Jarzmik Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 4aaf18dbeca6b5519645e1e9dd34adf101410c4f Author: Joe Thornber Date: Wed Jan 28 12:07:46 2015 +0000 dm cache: fix missing ERR_PTR returns and handling commit 766a78882ddf79b162243649d7dfdbac1fb6fb88 upstream. Commit 9b1cc9f251 ("dm cache: share cache-metadata object across inactive and active DM tables") mistakenly ignored the use of ERR_PTR returns. Restore missing IS_ERR checks and ERR_PTR returns where appropriate. Reported-by: Dan Carpenter Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit 5702185d1032c7d34adf38eb40e82dd0a474cdfc Author: Joe Thornber Date: Mon Jan 26 11:38:21 2015 +0000 dm thin: don't allow messages to be sent to a pool target in READ_ONLY or FAIL mode commit 2a7eaea02b99b6e267b1e89c79acc6e9a51cee3b upstream. You can't modify the metadata in these modes. It's better to fail these messages immediately than let the block-manager deny write locks on metadata blocks. Otherwise these failed metadata changes will trigger 'needs_check' to get set in the metadata superblock -- requiring repair using the thin_check utility. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit 708dddc00d67f6e37261b4e9a6d5b7cf2853c63a Author: Johannes Berg Date: Fri Jan 23 11:10:12 2015 +0100 nl80211: fix per-station group key get/del and memory leak commit 0fa7b39131576dd1baa6ca17fca53c65d7f62249 upstream. In case userspace attempts to obtain key information for or delete a unicast key, this is currently erroneously rejected unless the driver sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it was never noticed. Fix that, and while at it fix a potential memory leak: the error path in the get_key() function was placed after allocating a message but didn't free it - move it to a better place. Luckily admin permissions are needed to call this operation. Fixes: e31b82136d1ad ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit 2c6dcd87815a2c582df99557fa5422038cd384c2 Author: Mathy Vanhoef Date: Tue Jan 20 15:05:08 2015 +0100 mac80211: properly set CCK flag in radiotap commit 3a5c5e81d8128a9e43abc52b75dd21d3da7a0cfc upstream. Fix a regression introduced by commit a5e70697d0c4 ("mac80211: add radiotap flag and handling for 5/10 MHz") where the IEEE80211_CHAN_CCK channel type flag was incorrectly replaced by the IEEE80211_CHAN_OFDM flag. This commit fixes that by using the CCK flag again. Fixes: a5e70697d0c4 ("mac80211: add radiotap flag and handling for 5/10 MHz") Signed-off-by: Mathy Vanhoef Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit ca2c498b6d896b730bcf5b9a87033703d506bbdd Author: Trond Myklebust Date: Wed Jan 21 14:37:44 2015 -0500 NFSv4.1: Fix an Oops in nfs41_walk_client_list commit 3175e1dcec40fab1a444c010087f2068b6b04732 upstream. If we start state recovery on a client that failed to initialise correctly, then we are very likely to Oops. Reported-by: "Mkrtchyan, Tigran" Link: http://lkml.kernel.org/r/130621862.279655.1421851650684.JavaMail.zimbra@desy.de Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 88bc02271ea706c54abf4237744436c5982d09bf Author: Peng Tao Date: Tue Jan 20 07:44:29 2015 +0800 nfs: fix dio deadlock when O_DIRECT flag is flipped commit ee8a1a8b160a87dc3a9c81a86796aa4db85ea815 upstream. We only support swap file calling nfs_direct_IO. However, application might be able to get to nfs_direct_IO if it toggles O_DIRECT flag during IO and it can deadlock because we grab inode->i_mutex in nfs_file_direct_write(). So return 0 for such case. Then the generic layer will fall back to buffer IO. Signed-off-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 6633edfec196ef3a3f0a5cd4bbcdb1c65c532694 Author: Jochen Hein Date: Thu Jan 22 12:03:15 2015 -0800 Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857) commit 1d90d6d5522befa8efa1a7ea406be65cf865ded4 upstream. Without this the aux port does not get detected, and consequently the touchpad will not work. With this patch the touchpad is detected: $ dmesg | grep -E "(SYN|i8042|serio)" pnp 00:03: Plug and Play ACPI device, IDs SYN1d22 PNP0f13 (active) i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126800, board id: 2863, fw id: 1473085 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6 dmidecode excerpt for this laptop is: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Medion Product Name: Akoya E7225 Version: 1.0 Signed-off-by: Jochen Hein Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby commit cc356228c40a7d3979f6047fff9cf71ff40dad71 Author: Peter Hutterer Date: Mon Jan 19 16:29:25 2015 -0800 Input: synaptics - adjust min/max for Lenovo ThinkPad X1 Carbon 2nd commit 8543cf1c247909ce85850ca6e2714adba351d6aa upstream. LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model) Reported-and-tested-by: Bjoern Olausson Signed-off-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby commit db51cc3742a90d7eb94c4d5290445ade7895f8e7 Author: Paul Osmialowski Date: Mon Jan 19 17:03:33 2015 +0100 i2c: s3c2410: fix ABBA deadlock by keeping clock prepared commit 34e81ad5f0b60007c95995eb7803da7e00c6c611 upstream. This patch solves deadlock between clock prepare mutex and regmap mutex reported by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock of the i2c controller in a prepared state". [1] https://lkml.org/lkml/2014/7/2/171 [2] https://lkml.org/lkml/2014/7/2/207 On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was called, which calls clk_prepare() then clk_enable(). clk_prepare() takes prepare_lock mutex before proceeding. Note that i2c transfer functions are invoked from many places in kernel, typically with some other additional lock held. It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to proceed (so it needs to obtain clock related prepare_lock mutex during transfer preparation stage due to clk_prepare() call). At the same time other task on CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason) so it has taken prepare_lock mutex. CPU0: CPU1: clk_disable_unused() regulator_disable() clk_prepare_lock() map->lock(map->lock_arg) regmap_read() s3c24xx_i2c_xfer() map->lock(map->lock_arg) clk_prepare_lock() Implemented solution from [2] leaves i2c clock prepared. Preparation is done in s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared by clk_disable_unprepare() call. I've replaced this call with clk_disable() and I've added clk_unprepare() call in s3c24xx_i2c_remove(). The s3c24xx_i2c_xfer() function now uses clk_enable() instead of clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()). Signed-off-by: Paul Osmialowski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Jiri Slaby commit 848ca9fd5f0effcfbaa42487babd57d08ee5a7fd Author: Ilya Dryomov Date: Mon Jan 19 12:06:14 2015 +0300 rbd: drop parent_ref in rbd_dev_unprobe() unconditionally commit e69b8d414f948c242ad9f3eb2b7e24fba783dbbd upstream. This effectively reverts the last hunk of 392a9dad7e77 ("rbd: detect when clone image is flattened"). The problem with parent_overlap != 0 condition is that it's possible and completely valid to have an image with parent_overlap == 0 whose parent state needs to be cleaned up on unmap. The next commit, which drops the "clone image now standalone" logic, opens up another window of opportunity to hit this, but even without it # cat parent-ref.sh #!/bin/bash rbd create --image-format 2 --size 1 foo rbd snap create foo@snap rbd snap protect foo@snap rbd clone foo@snap bar rbd resize --allow-shrink --size 0 bar rbd resize --size 1 bar DEV=$(rbd map bar) rbd unmap $DEV leaves rbd_device/rbd_spec/etc and rbd_client along with ceph_client hanging around. My thinking behind calling rbd_dev_parent_put() unconditionally is that there shouldn't be any requests in flight at that point in time as we are deep into unmap sequence. Hence, even if rbd_dev_unparent() caused by flatten is delayed by in-flight requests, it will have finished by the time we reach rbd_dev_unprobe() caused by unmap, thus turning unconditional rbd_dev_parent_put() into a no-op. Fixes: http://tracker.ceph.com/issues/10352 Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Reviewed-by: Alex Elder Signed-off-by: Jiri Slaby commit 8b61ee53d39bddab0900485fdca2f0e644f7ccaf Author: Clemens Ladisch Date: Sun Jan 25 14:34:29 2015 +0100 ALSA: seq-dummy: remove deadlock-causing events on close commit 0767e95bb96d7fdddcd590fb809e6975d93aebc5 upstream. When the last subscriber to a "Through" port has been removed, the subscribed destination ports might still be active, so it would be wrong to send "all sounds off" and "reset controller" events to them. The proper place for such a shutdown would be the closing of the actual MIDI port (and close_substream() in rawmidi.c already can do this). This also fixes a deadlock when dummy_unuse() tries to send events to its own port that is already locked because it is being freed. Reported-by: Peter Billam Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b294d7b152e5580fdc6be48292cb365b6d1a0bbc Author: Laurent Dufour Date: Thu Jan 15 18:23:47 2015 +0100 powerpc/xmon: Fix another endiannes issue in RTAS call from xmon commit e6eb2eba494d6f99e69ca3c3748cd37a2544ab38 upstream. The commit 3b8a3c010969 ("powerpc/pseries: Fix endiannes issue in RTAS call from xmon") was fixing an endianness issue in the call made from xmon to RTAS. However, as Michael Ellerman noticed, this fix was not complete, the token value was not byte swapped. This lead to call an unexpected and most of the time unexisting RTAS function, which is silently ignored by RTAS. This fix addresses this hole. Reported-by: Michael Ellerman Signed-off-by: Laurent Dufour Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit a38a9696988b01a496af60ca7494068865bb2217 Author: Ahmed S. Darwish Date: Mon Jan 26 07:25:43 2015 +0200 can: kvaser_usb: Fix state handling upon BUS_ERROR events commit e638642b08c170d2021b706f0b1c4f4ae93d8cbd upstream. While being in an ERROR_WARNING state, and receiving further bus error events with error counters still in the ERROR_WARNING range of 97-127 inclusive, the state handling code erroneously reverts back to ERROR_ACTIVE. Per the CAN standard, only revert to ERROR_ACTIVE when the error counters are less than 96. Moreover, in certain Kvaser models, the BUS_ERROR flag is always set along with undefined bits in the M16C status register. Thus use bitwise operators instead of full equality for checking that register against bus errors. Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 3d6365501fe636c82771ee41727f96d0e281a70f Author: Ahmed S. Darwish Date: Mon Jan 26 07:24:06 2015 +0200 can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT commit 14c10c2a1dd8eb8e00b750b521753260befa2789 upstream. On some x86 laptops, plugging a Kvaser device again after an unplug makes the firmware always ignore the very first command. For such a case, provide some room for retries instead of completely exiting the driver init code. Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 5738a8422143d469b2b274f3ea2540cd18cd7d76 Author: Ahmed S. Darwish Date: Mon Jan 26 07:22:54 2015 +0200 can: kvaser_usb: Send correct context to URB completion commit 3803fa6977f1de15fda4e8646c8fec97c8045cae upstream. Send expected argument to the URB completion hander: a CAN netdevice instead of the network interface private context `kvaser_usb_net_priv'. This was discovered by having some garbage in the kernel log in place of the netdevice names: can0 and can1. Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 59383099795ffbf2fcedba21df919c8d662c3f42 Author: Ahmed S. Darwish Date: Mon Jan 26 07:20:39 2015 +0200 can: kvaser_usb: Do not sleep in atomic context commit ded5006667318c06df875609535176bd33f243a1 upstream. Upon receiving a hardware event with the BUS_RESET flag set, the driver kills all of its anchored URBs and resets all of its transmit URB contexts. Unfortunately it does so under the context of URB completion handler `kvaser_usb_read_bulk_callback()', which is often called in an atomic context. While the device is flooded with many received error packets, usb_kill_urb() typically sleeps/reschedules till the transfer request of each killed URB in question completes, leading to the sleep in atomic bug. [3] In v2 submission of the original driver patch [1], it was stated that the URBs kill and tx contexts reset was needed since we don't receive any tx acknowledgments later and thus such resources will be locked down forever. Fortunately this is no longer needed since an earlier bugfix in this patch series is now applied: all tx URB contexts are reset upon CAN channel close. [2] Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF event, which is the recommended handling method advised by the device manufacturer. [1] http://article.gmane.org/gmane.linux.network/239442 http://www.webcitation.org/6Vr2yagAQ [2] can: kvaser_usb: Reset all URB tx contexts upon channel close 889b77f7fd2bcc922493d73a4c51d8a851505815 [3] Stacktrace: [] dump_stack+0x45/0x57 [] __schedule_bug+0x41/0x4f [] __schedule+0x5f1/0x700 [] ? _raw_spin_unlock_irqrestore+0xa/0x10 [] schedule+0x24/0x70 [] usb_kill_urb+0x65/0xa0 [] ? prepare_to_wait_event+0x110/0x110 [] usb_kill_anchored_urbs+0x48/0x80 [] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb] [] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb] [] ? vprintk_default+0x1a/0x20 [] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb] [] __usb_hcd_giveback_urb+0x5e/0xc0 [] usb_hcd_giveback_urb+0x41/0x110 [] finish_urb+0x98/0x180 [ohci_hcd] [] ? acct_account_cputime+0x17/0x20 [] ? local_clock+0x15/0x30 [] ohci_work+0x1fb/0x5a0 [ohci_hcd] [] ? process_backlog+0xb1/0x130 [] ohci_irq+0xeb/0x270 [ohci_hcd] [] usb_hcd_irq+0x21/0x30 [] handle_irq_event_percpu+0x43/0x120 [] handle_irq_event+0x3d/0x60 [] handle_fasteoi_irq+0x74/0x110 [] handle_irq+0x1d/0x30 [] do_IRQ+0x57/0x100 [] common_interrupt+0x6a/0x6a Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 93eb4395013ad79585dad5cb10b5cbb0122956c9 Author: Peter Ujfalusi Date: Fri Jan 16 11:20:25 2015 +0200 ASoC: omap-mcbsp: Correct CBM_CFS dai format configuration commit 20602e34cd33dd452bc1836fa7c9b59978f75db0 upstream. We should select FSR also to be driven by McBSP, not only FSX. Signed-off-by: Peter Ujfalusi Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit bba2b7bbec42c63c86ab459c784319cce192860e Author: Zidan Wang Date: Wed Dec 31 11:39:14 2014 +0800 ASoC: wm8960: Fix capture sample rate from 11250 to 11025 commit 22ee76daddb87f88d2336d1b4737ef27c4f307ac upstream. wm8960 codec can't support sample rate 11250, it must be 11025. Signed-off-by: Zidan Wang Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit dbaf59afa7fffbb523a32c7bf28d5a507a0896e6 Author: Andy Shevchenko Date: Fri Jan 2 17:48:51 2015 +0200 spi: dw-mid: fix FIFO size commit 67bf9cda4b498b8cea4a40be67a470afe57d2e88 upstream. The FIFO size is 40 accordingly to the specifications, but this means 0x40, i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection for Intel MID devices. Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support) Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 27152be6083112b94ce6ff5186d01ec4d702ddcf Author: Adrian Hunter Date: Mon Jan 5 14:47:58 2015 +0200 mmc: sdhci-pci: Add support for Intel SPT commit 1f7f26528fb159e71f081df1d1050c218ff1d74d upstream. Add PCI IDs for SPT eMMC, SDIO and SD card. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit e29366fda793d8d423e0a476b62c2a3a703d4dc6 Author: Adrian Hunter Date: Wed Sep 24 10:27:33 2014 +0300 mmc: sdhci-pci: Fix Braswell eMMC timeout clock frequency commit a06586b62db5c63752e2e68daffec4baa275d594 upstream. Braswell eMMC host controller specifies an incorrect timeout clock frequncy in the capabilities registers. The correct value is 1 MHz. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit a17e1c8da5772d176e6c2dcb209f4164cd7dc4b6 Author: Alan Cox Date: Wed Aug 20 13:27:44 2014 +0300 mmc: sdhci: Add PCI IDs for Intel Braswell commit 066173b6436dfc57a96b2d940f4e727fe8131261 upstream. The hardware is the same as used in Baytrail. Add these new PCI IDs to the driver's list of supported IDs. Signed-off-by: Alan Cox Signed-off-by: Mika Westerberg Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 34385e13d73ba4e6cef1a2f74bf9996a68fb32a3 Author: Adam Lee Date: Wed Dec 18 22:23:38 2013 +0800 mmc: sdhci-pci: break out definitions to header file commit 522624f97ee22684cf1b169b5a490cc3ad87b22c upstream. Break out definitions in sdhci-pci.c to sdhci-pci.h, for introducing module files like sdhci-pci-xxx.c Signed-off-by: Adam Lee Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit a007ffbfdf0abc5e8072905f51e283b473d2a06c Author: Micky Ching Date: Fri Feb 21 18:40:35 2014 +0800 mmc: sdhci: add support for realtek rts5250 commit 9107ebbf9652c033eb5dd10a6ea34a132db3cde1 upstream. Add support for realtek rts5250 pci card reader. The card reader has some problems with DDR50 mode, so add a new quirks2 for broken ddr50. Signed-off-by: Micky Ching Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit dbf219a4e3adede455b4b81a76665569d99c3b22 Author: David Cohen Date: Tue Oct 29 10:58:26 2013 -0700 mmc: sdhci: add quirk for broken HS200 support commit 13868bf20f2f2c305f96e23620b024e167d6f9cb upstream. This patch defines a quirk for platforms unable to enable HS200 support. Signed-off-by: David Cohen Reviewed-by: Chuanxiao Dong Acked-by: Dong Aisheng Cc: stable # [3.13] Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit 568d963f10c4b1b757a156df81502af1b305253e Author: David Cohen Date: Tue Oct 29 10:58:27 2013 -0700 mmc: sdhci-pci: add broken HS200 quirk for Intel Merrifield commit 390145f9adcf2730fcee81c8a51fd7c6c08f705f upstream. Due to unknown hw issue so far, Merrifield is unable to enable HS200 support. This patch adds quirk to avoid SDHCI to initialize with error below: [ 53.850132] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.12.0-rc6-00037-g3d7c8d9-dirty #36 [ 53.850150] Hardware name: Intel Corporation Merrifield/SALT BAY, BIOS 397 2013.09.12:11.51.40 [ 53.850167] 00000000 00000000 ee409e48 c18816d2 00000000 ee409e78 c123e254 c1acc9b0 [ 53.850227] 00000000 00000000 c1b14148 000003de c16c03bf c16c03bf ee75b480 ed97c54c [ 53.850282] ee75b480 ee409e88 c123e292 00000009 00000000 ee409ef8 c16c03bf c1207fac [ 53.850339] Call Trace: [ 53.850376] [] dump_stack+0x4b/0x79 [ 53.850408] [] warn_slowpath_common+0x84/0xa0 [ 53.850436] [] ? sdhci_send_command+0xb4f/0xc50 [ 53.850462] [] ? sdhci_send_command+0xb4f/0xc50 [ 53.850490] [] warn_slowpath_null+0x22/0x30 [ 53.850516] [] sdhci_send_command+0xb4f/0xc50 [ 53.850545] [] ? native_sched_clock+0x2c/0xb0 [ 53.850575] [] ? delay_tsc+0x73/0xb0 [ 53.850601] [] ? __const_udelay+0x1e/0x20 [ 53.850626] [] ? sdhci_reset+0x93/0x190 [ 53.850654] [] sdhci_finish_data+0xf0/0x2e0 [ 53.850683] [] sdhci_irq+0x31f/0x930 [ 53.850713] [] ? __buffer_unlock_commit+0x10/0x20 [ 53.850740] [] ? trace_buffer_unlock_commit+0x37/0x50 [ 53.850773] [] handle_irq_event_percpu+0x5c/0x220 [ 53.850800] [] ? handle_fasteoi_irq+0x16/0xd0 [ 53.850827] [] handle_irq_event+0x3a/0x60 [ 53.850852] [] ? unmask_irq+0x30/0x30 [ 53.850878] [] handle_fasteoi_irq+0x4e/0xd0 [ 53.850895] [] ? do_IRQ+0x42/0xb0 [ 53.850943] [] ? common_interrupt+0x31/0x38 [ 53.850973] [] ? cgroup_mkdir+0x4e8/0x580 [ 53.851001] [] ? default_idle+0x22/0xf0 [ 53.851029] [] ? arch_cpu_idle+0x26/0x30 [ 53.851054] [] ? cpu_startup_entry+0x65/0x240 [ 53.851082] [] ? rest_init+0xb5/0xc0 [ 53.851108] [] ? __read_lock_failed+0x18/0x18 [ 53.851138] [] ? start_kernel+0x31b/0x321 [ 53.851164] [] ? repair_env_string+0x51/0x51 [ 53.851190] [] ? i386_start_kernel+0x139/0x13c [ 53.851209] ---[ end trace 92777f5fe48d33f2 ]--- [ 53.853449] mmcblk0: error -84 transferring data, sector 11142162, nr 304, cmd response 0x0, card status 0x0 [ 53.853476] mmcblk0: retrying using single block read [ 55.937863] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 56.207951] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 66.228785] mmc0: Timeout waiting for hardware interrupt. [ 66.230855] ------------[ cut here ]------------ Signed-off-by: David Cohen Reviewed-by: Chuanxiao Dong Acked-by: Dong Aisheng Cc: stable # [3.13] Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit a27ad256a42fae347acaec06ff8e53ba1db20162 Author: Adrian Hunter Date: Mon Jan 5 14:47:57 2015 +0200 mmc: sdhci-acpi: Add ACPI HID INT344D commit d0ed8e6b0ab149421cd1532e7c5ebb0992ad25d0 upstream. Add ACPI HID INT344D for an Intel SDIO host controller. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 43a93a13b5067027d122ca3b3a79f3ba0d684322 Author: Adrian Hunter Date: Wed Sep 24 10:27:29 2014 +0300 mmc: sdhci-acpi: Add a HID and UID for a SD Card host controller commit 7147eaf3a4fe7e7dbb6e1f89e328ea0507e0c32c upstream. Add a HID (INT33BB) and UID (3) for a SD Card host controller. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 536f9653b9557fececdc769837294efbb27ecafa Author: Maurice Petallo Date: Tue Jul 8 19:11:00 2014 +0800 mmc: sdhci: Preset value not supported in Baytrail eMMC commit d61b59461b0cd0106f03e566d537b9072029e059 upstream. "SDHCI_QUIRK2_PRESET_VALUE_BROKEN" quirk is added to prohibit preset value enabling for Baytrail eMMC controller. Signed-off-by: Maurice Petallo Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 6f55614e95472493acb155c99ffbb76319e3bbb6 Author: Adrian Hunter Date: Thu Apr 3 14:58:39 2014 +0300 mmc: sdhci-acpi: Intel SDIO has broken card detect commit c67480173f72e883235dd0ad09d90156c8f87600 upstream. Intel SDIO has broken card detect so add a quirk to reflect that. Signed-off-by: Adrian Hunter Acked-by: Ulf Hansson Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit d40b840deecf9e058c8edf3e8459fd6524bac99b Author: Adrian Hunter Date: Mon Mar 10 15:02:43 2014 +0200 mmc: sdhci-acpi: Add device id 80860F16 commit aad95dc49c6dad19b49af7cd90c53473ec0536d1 upstream. Add ACPI HID 80860F16 as a host controller for a SD card. Signed-off-by: Adrian Hunter Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit bb5f415484d7fbf3a0a5c55134ca0a99892544a3 Author: Mika Westerberg Date: Tue Nov 12 12:01:33 2013 +0200 mmc: sdhci-acpi: add new ACPI ID commit 07c001c119c7de92be9c8ad1f1a3e5af459cb3d4 upstream. Newer Intel PCHs with LPSS have the same SDHCI controller than Haswell but ACPI ID is different. Add this ID to the driver list. Signed-off-by: Mika Westerberg Acked-by: Adrian Hunter Signed-off-by: Chris Ball Signed-off-by: Jiri Slaby commit 9606e430dc79200193b15df6997c7981e19216c1 Author: Mark Rutland Date: Fri Feb 6 17:59:27 2015 +0000 arm64: Fix up /proc/cpuinfo commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream. [backport to 3.12.x: fold in missing MIDR_EL1 recording] Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs) attempted to clean up /proc/cpuinfo, but due to concerns regarding further changes was reverted in commit 5e39977edf6500fd (Revert "arm64: cpuinfo: print info for all CPUs"). There are two major issues with the arm64 /proc/cpuinfo format currently: * The "Features" line describes (only) the 64-bit hwcaps, which is problematic for some 32-bit applications which attempt to parse it. As the same names are used for analogous ISA features (e.g. aes) despite these generally being architecturally unrelated, it is not possible to simply append the 64-bit and 32-bit hwcaps in a manner that might not be misleading to some applications. Various potential solutions have appeared in vendor kernels. Typically the format of the Features line varies depending on whether the task is 32-bit. * Information is only printed regarding a single CPU. This does not match the ARM format, and does not provide sufficient information in big.LITTLE systems where CPUs are heterogeneous. The CPU information printed is queried from the current CPU's registers, which is racy w.r.t. cross-cpu migration. This patch attempts to solve these issues. The following changes are made: * When a task with a LINUX32 personality attempts to read /proc/cpuinfo, the "Features" line contains the decoded 32-bit hwcaps, as with the arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In the absense of compat support, the Features line is empty. The set of hwcaps injected into a task's auxval are unaffected. * Properties are printed per-cpu, as with the ARM port. The per-cpu information is queried from pre-recorded cpu information (as used by the sanity checks). * As with the previous attempt at fixing up /proc/cpuinfo, the hardware field is removed. The only users so far are 32-bit applications tied to particular boards, so no portable applications should be affected, and this should prevent future tying to particular boards. The following differences remain: * No model_name is printed, as this cannot be queried from the hardware and cannot be provided in a stable fashion. Use of the CPU {implementor,variant,part,revision} fields is sufficient to identify a CPU and is portable across arm and arm64. * The following system-wide properties are not provided, as they are not possible to provide generally. Programs relying on these are already tied to particular (32-bit only) boards: - Hardware - Revision - Serial No software has yet been identified for which these remaining differences are problematic. Cc: Catalin Marinas Cc: Will Deacon Cc: stable@vger.kernel.org # 3.12.x Signed-off-by: Mark Rutland [Mark: backport to v3.12.x] Signed-off-by: Jiri Slaby commit d99060df01b027501e55b8ce92c072aa60f87ee3 Author: Nicholas Bellinger Date: Fri Jan 30 22:17:31 2015 +0000 target: Drop arbitrary maximum I/O size limit commit 046ba64285a4389ae5e9a7dfa253c6bff3d7c341 upstream. This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(), which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512 byte sector devices), and for hw_max_sectors is a backend driver dependent value. This limit is problematic because Linux initiators have only recently started to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux based initiators (eg: MSFT Fibre Channel) can also generate I/Os larger than 4 MB in size. Currently when this happens, the following message will appear on the target resulting in I/Os being returned with non recoverable status: SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192 Instead, drop both [fabric,hw]_max_sector checks in sbc_parse_cdb(), and convert the existing hw_max_sectors into a purely informational attribute used to represent the granuality that backend driver and/or subsystem code is splitting I/Os upon. Also, update FILEIO with an explicit FD_MAX_BYTES check in fd_execute_rw() to deal with the one special iovec limitiation case. v2 changes: - Drop hw_max_sectors check in sbc_parse_cdb() Reported-by: Lance Gropper Reported-by: Stefan Priebe Cc: Christoph Hellwig Cc: Martin K. Petersen Cc: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit dddbc77e40b3af8bb32f49f1b4dc424bba45e59c Author: Hannes Reinecke Date: Fri Jan 30 22:17:23 2015 +0000 tcm_loop: Fix wrong I_T nexus association commit 506787a2c7daed45f0a213674ca706cbc83a9089 upstream. tcm_loop has the I_T nexus associated with the HBA. This causes commands to become misdirected if the HBA has more than one target portal group; any command is then being sent to the first target portal group instead of the correct one. The nexus needs to be associated with the target portal group instead. Signed-off-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit 4602761bac19ae3373f003bc3cabc4546c8e5207 Author: Heiko Carstens Date: Tue Mar 4 12:39:03 2014 +0100 ipc/compat_sys_msgrcv: change msgtyp type from long to compat_long_t commit 291fdb0bcebd5e8db6af767c1fdc522167dad73d upstream. Change the type of compat_sys_msgrcv's msgtyp parameter from long to compat_long_t, since compat user space passes only a 32 bit signed value. Let the compat wrapper do proper sign extension to 64 bit of this parameter. Signed-off-by: Heiko Carstens Signed-off-by: Jiri Slaby commit 910f9e7dbee0aef348cecd53d54fb70f77e8321b Author: Mateusz Guzik Date: Mon Jan 27 17:07:11 2014 -0800 ipc: fix compat msgrcv with negative msgtyp commit e7ca2552369c1dfe0216c626baf82c3d83ec36bb upstream. Compat function takes msgtyp argument as u32 and passes it down to do_msgrcv which results in casting to long, thus the sign is lost and we get a big positive number instead. Cast the argument to signed type before passing it down. Signed-off-by: Mateusz Guzik Reported-by: Gabriellla Schmidt Cc: Al Viro Cc: Davidlohr Bueso Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit aa99e32532c37c8fb56465fe5609a343a17a2354 Author: Hans de Goede Date: Mon Nov 24 11:26:32 2014 +0100 asus-nb-wmi: Add another wapf=4 quirk commit 841e11ccdf90c29a7778a5d5d553bc716c3d477a upstream. Wifi on this laptop does not work unless asus-nb-wmi.wapf=4 is specified on the kerne commandline, add a quirk for this. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1173681 Signed-off-by: Hans de Goede Signed-off-by: Darren Hart Signed-off-by: Jiri Slaby commit ecd9be6a40adaa8ff7edf041ca5e4feeeea98bc6 Author: Stanislaw Gruszka Date: Sun Oct 26 11:23:55 2014 +0100 asus-nb-wmi: Add wapf4 quirk for the X550VB commit 4ec7a45b51a32ee513898e2f1e42bb681b340fcf upstream. X550VB as many others Asus laptops need wapf4 quirk to make RFKILL switch be functional. Otherwise system boots with wireless card disabled and is only possible to enable it by suspend/resume. Bug report: http://bugzilla.redhat.com/show_bug.cgi?id=1089731#c23 Reported-and-tested-by: Vratislav Podzimek Signed-off-by: Stanislaw Gruszka Signed-off-by: Darren Hart Signed-off-by: Jiri Slaby commit 39d8ae26e5524a07da55b2104a1bde9fcac55868 Author: Hans de Goede Date: Tue Jul 29 11:59:57 2014 +0200 asus-nb-wmi: Add wapf4 quirk for the U32U commit 831a444ea6f8f25fd1a9cc9d7651bc18b5a1f755 upstream. As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681 the U32U needs wapf=4 too. Signed-off-by: Hans de Goede Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby commit 367366c29e48a1ca124817154ff7d175d0e07cc8 Author: Hans de Goede Date: Mon Jul 14 09:14:34 2014 +0200 asus-nb-wmi.c: Rename x401u quirk to wapf4 commit 378008dfc72baed2d9c0f0a40dababc0e8901207 upstream. The actual x401u does not use the so named x401u quirk but the x55u quirk. All that the x401u quirk does it setting wapf to 4, so rename it to wapf4 to stop the confusion. Signed-off-by: Hans de Goede Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby commit 533e6f122022f63b6cfd87a397312fdc9fb4f4af Author: Hans de Goede Date: Fri Jul 18 12:15:09 2014 +0200 asus-nb-wmi: Add wapf4 quirk for the X550CC commit 6d6ded3bdb0ed6f65d1f58d5d84971f6b3a39b70 upstream. As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681 the X550CC needs wapf=4 too. Signed-off-by: Hans de Goede Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby commit 0c3e519354daafedfbdd399218e1e19c04f2fdd3 Author: Hans de Goede Date: Mon Jul 14 09:14:35 2014 +0200 asus-nb-wmi: Add wapf4 quirk for the X550CL commit 22ba58c8abea9e948d406776b9252024a30bd45c upstream. As reported here: https://bugs.launchpad.net/bugs/1277959 the X550CL needs wapf=4 too. Signed-off-by: Hans de Goede Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby commit 3265f861718dc0912e6c42b47ad591cccc178152 Author: AceLan Kao Date: Wed Jul 9 16:18:19 2014 +0800 asus-nb-wmi: Add ASUSTeK COMPUTER INC. X200CA commit c66263a368490a200a65639ff826f633090936a9 upstream. BIOS won't light on the wifi-led after S3, so asus-wmi driver needs to control the wifi and wifi-led status. But, it'll lead to bt status error if asus-wmi driver controls bt as well. So, for X200CA, asus-wmi driver controls wifi status only and have to set wapf to 1. Signed-off-by: AceLan Kao Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby commit 8365e101d9dc837354a4c7f399575f481232dcd4 Author: poma Date: Tue May 6 22:03:38 2014 +0200 WAPF 4 for ASUSTeK COMPUTER INC. X75VBP WLAN ON. commit 7216e10227c90a388db1ee29b7b89820b81aa8eb upstream. The 'asus-nb-wmi' WAPF parameter must be set to 4, so the internal Wireless LAN device is operational. Signed-off-by: poma Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby commit 09e6fe32192a77f6e2e60cc0f4103e630c7ecf20 Author: Andreas Utterberg Date: Tue May 6 22:27:45 2014 +0200 asus-wmi: Set WAPF to 4 for Asus X550CA commit c08db55fe1455202e4bcda416e88bbbc20700dc4 upstream. The 'asus-nb-wmi' WAPF parameter must be set to 4, so the internal Wireless LAN device is operational. Signed-off-by: Andreas Utterberg Signed-off-by: Matthew Garrett Signed-off-by: Jiri Slaby