commit 072cab659c9368586d6417cfd6ec2d2c68469c67 Author: Greg Kroah-Hartman Date: Wed May 6 22:04:23 2015 +0200 Linux 4.0.2 commit cf1cab07a20abcfa17f0cf431d103471ebd7b33c Author: Florian Westphal Date: Wed Apr 1 22:36:27 2015 +0200 netfilter: bridge: really save frag_max_size between PRE and POST_ROUTING commit 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream. We also need to save/store in forward, else br_parse_ip_options call will zero frag_max_size as well. Fixes: 93fdd47e5 ('bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING') Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 4c0a56b2ee7b3a3741339e943acd2692c146fcb1 Author: Junjie Mao Date: Wed Jan 28 10:02:44 2015 +0800 driver core: bus: Goto appropriate labels on failure in bus_add_device commit 1c34203a1496d1849ba978021b878b3447d433c8 upstream. It is not necessary to call device_remove_groups() when device_add_groups() fails. The group added by device_add_groups() should be removed if sysfs_create_link() fails. Fixes: fa6fdb33b486 ("driver core: bus_type: add dev_groups") Signed-off-by: Junjie Mao Signed-off-by: Greg Kroah-Hartman commit 6361409a1274060993b246c688c24a7c863c7eeb Author: Linus Walleij Date: Wed Feb 18 17:12:18 2015 +0100 drivers: platform: parse IRQ flags from resources commit 7085a7401ba54e92bbb5aa24d6f428071e18e509 upstream. This fixes a regression from the net subsystem: After commit d52fdbb735c36a209f36a628d40ca9185b349ba7 "smc91x: retrieve IRQ and trigger flags in a modern way" a regression would appear on some legacy platforms such as the ARM PXA Zylonite that specify IRQ resources like this: static struct resource r = { .start = X, .end = X, .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE, }; The previous code would retrieve the resource and parse the high edge setting in the SMC91x driver, a use pattern that means every driver specifying an IRQ flag from a static resource need to parse resource flags and apply them at runtime. As we switched the code to use IRQ descriptors to retrieve the the trigger type like this: irqd_get_trigger_type(irq_get_irq_data(...)); the code would work for new platforms using e.g. device tree as the backing irq descriptor would have its flags properly set, whereas this kind of oldstyle static resources at no point assign the trigger flags to the corresponding IRQ descriptor. To make the behaviour identical on modern device tree and legacy static platform data platforms, modify platform_get_irq() to assign the trigger flags to the irq descriptor when a client looks up an IRQ from static resources. Fixes: d52fdbb735c3 ("smc91x: retrieve IRQ and trigger flags in a modern way") Tested-by: Robert Jarzmik Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit df0bffebd40ba332f01193e2b6694042a0a2f56c Author: Dan Carpenter Date: Thu Apr 16 12:48:35 2015 -0700 memstick: mspro_block: add missing curly braces commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream. Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly. Fixes: f1d82698029b ('memstick: use fully asynchronous request processing') Signed-off-by: Dan Carpenter Cc: Alex Dubov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 78775b31ea25fc6d25f2444c634b2eec0ed90bca Author: Nishanth Menon Date: Sat Mar 7 03:39:05 2015 -0600 C6x: time: Ensure consistency in __init commit f4831605f2dacd12730fe73961c77253cc2ea425 upstream. time_init invokes timer64_init (which is __init annotation) since all of these are invoked at init time, lets maintain consistency by ensuring time_init is marked appropriately as well. This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init() The function time_init() references the function __init timer64_init(). This is often because time_init lacks a __init annotation or the annotation of timer64_init is wrong. Fixes: 546a39546c64 ("C6X: time management") Signed-off-by: Nishanth Menon Signed-off-by: Mark Salter Signed-off-by: Greg Kroah-Hartman commit 8a7e1640e89ee191d677e2d994476ce68e2160ea Author: Vutla, Lokesh Date: Tue Mar 31 09:52:25 2015 +0530 crypto: omap-aes - Fix support for unequal lengths commit 6d7e7e02a044025237b6f62a20521170b794537f upstream. For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver. To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths. Fixes: 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned lengths") Signed-off-by: Lokesh Vutla Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1cd176dfd9e5e4d0cae0545fa8c56ecd582b2e9a Author: Nicolas Iooss Date: Fri Mar 13 15:17:14 2015 +0800 wl18xx: show rx_frames_per_rates as an array as it really is commit a3fa71c40f1853d0c27e8f5bc01a722a705d9682 upstream. In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be used to display this field in debugfs (it would display a pointer, not the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead. This bug has been found by adding a __printf attribute to wl1271_format_buffer. gcc complained about "format '%u' expects argument of type 'unsigned int', but argument 5 has type 'u32 *'". Fixes: c5d94169e818 ("wl18xx: use new fw stats structures") Signed-off-by: Nicolas Iooss Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 2649caa31cc3143b2ad3039ac581dacd7529a631 Author: mancha security Date: Wed Mar 18 18:47:25 2015 +0100 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream. OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization. For the random driver and crypto drivers, calls are emitted ... $ gdb vmlinux (gdb) disassemble memzero_explicit Dump of assembler code for function memzero_explicit: 0xffffffff813a18b0 <+0>: push %rbp 0xffffffff813a18b1 <+1>: mov %rsi,%rdx 0xffffffff813a18b4 <+4>: xor %esi,%esi 0xffffffff813a18b6 <+6>: mov %rsp,%rbp 0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 0xffffffff813a18be <+14>: pop %rbp 0xffffffff813a18bf <+15>: retq End of assembler dump. (gdb) disassemble extract_entropy [...] 0xffffffff814a5009 <+313>: mov %r12,%rdi 0xffffffff814a500c <+316>: mov $0xa,%esi 0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax [...] ... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead. Minimal test example when we assume memzero_explicit() would *not* be a call, but would have been *inlined* instead: static inline void memzero_explicit(void *s, size_t count) { memset(s, 0, count); } int main(void) { char buff[20]; snprintf(buff, sizeof(buff) - 1, "test"); printf("%s", buff); memzero_explicit(buff, sizeof(buff)); return 0; } With := OPTIMIZER_HIDE_VAR(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 0x0000000000400469 <+41>: xor %eax,%eax 0x000000000040046b <+43>: add $0x28,%rsp 0x000000000040046f <+47>: retq End of assembler dump. With := barrier(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 0x0000000000400469 <+41>: movq $0x0,(%rsp) 0x0000000000400471 <+49>: movq $0x0,0x8(%rsp) 0x000000000040047a <+58>: movl $0x0,0x10(%rsp) 0x0000000000400482 <+66>: xor %eax,%eax 0x0000000000400484 <+68>: add $0x28,%rsp 0x0000000000400488 <+72>: retq End of assembler dump. As can be seen, movq, movq, movl are being emitted inlined via memset(). Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/ Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data") Cc: Theodore Ts'o Signed-off-by: mancha security Signed-off-by: Daniel Borkmann Acked-by: Hannes Frederic Sowa Acked-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0b97a15f6fedf422d276245866319990c2c771c5 Author: David Rientjes Date: Tue Apr 14 15:46:58 2015 -0700 mm, thp: really limit transparent hugepage allocation to local node commit 5265047ac30191ea24b16503165000c225f54feb upstream. Commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node") restructured alloc_hugepage_vma() with the intent of only allocating transparent hugepages locally when there was not an effective interleave mempolicy. alloc_pages_exact_node() does not limit the allocation to the single node, however, but rather prefers it. This is because __GFP_THISNODE is not set which would cause the node-local nodemask to be passed. Without it, only a nodemask that prefers the local node is passed. Fix this by passing __GFP_THISNODE and falling back to small pages when the allocation fails. Commit 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target node") suffers from a similar problem for khugepaged, which is also fixed. Fixes: 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node") Fixes: 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target node") Signed-off-by: David Rientjes Acked-by: Vlastimil Babka Cc: Christoph Lameter Cc: Pekka Enberg Cc: Joonsoo Kim Cc: Johannes Weiner Cc: Mel Gorman Cc: Pravin Shelar Cc: Jarno Rajahalme Cc: Li Zefan Cc: Greg Thelen Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e86ecd8a7bbc590987b4046c523d8caaef8f8b5f Author: Daniel Borkmann Date: Thu Mar 12 17:21:42 2015 +0100 ebpf: verifier: check that call reg with ARG_ANYTHING is initialized commit 80f1d68ccba70b1060c9c7360ca83da430f66bed upstream. I noticed that a helper function with argument type ARG_ANYTHING does not need to have an initialized value (register). This can worst case lead to unintented stack memory leakage in future helper functions if they are not carefully designed, or unintended application behaviour in case the application developer was not careful enough to match a correct helper function signature in the API. The underlying issue is that ARG_ANYTHING should actually be split into two different semantics: 1) ARG_DONTCARE for function arguments that the helper function does not care about (in other words: the default for unused function arguments), and 2) ARG_ANYTHING that is an argument actually being used by a helper function and *guaranteed* to be an initialized register. The current risk is low: ARG_ANYTHING is only used for the 'flags' argument (r4) in bpf_map_update_elem() that internally does strict checking. Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dada7797e4595606cf730600d8c9a03955a8264b Author: Johannes Berg Date: Sat Mar 21 07:41:04 2015 +0100 mac80211: send AP probe as unicast again commit a73f8e21f3f93159bc19e154e8f50891c22c11db upstream. Louis reported that a static checker was complaining that the 'dst' variable was set (multiple times) but not used. This is due to a previous commit having removed the usage (apparently erroneously), so add it back. Fixes: a344d6778a98 ("mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR") Reported-by: Louis Langholtz Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9279e1f98b13d5e5b40805114896ec33313ad019 Author: Sabrina Dubroca Date: Thu Feb 26 05:35:41 2015 +0000 e1000: add dummy allocator to fix race condition between mtu change and netpoll commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream. There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] put_compound_page+0x7e/0x330 [...] Call Trace: [] put_page+0x55/0x60 [] e1000_clean_rx_ring+0x134/0x200 [] e1000_clean_all_rx_rings+0x45/0x60 [] e1000_down+0x1c0/0x1d0 [] ? deactivate_slab+0x7f0/0x840 [] e1000_change_mtu+0xdc/0x170 [] dev_set_mtu+0xa0/0x140 [] do_setlink+0x218/0xac0 [] ? nla_parse+0xb9/0x120 [] rtnl_newlink+0x6d0/0x890 [] ? kvm_clock_read+0x20/0x40 [] ? sched_clock_cpu+0xa8/0x100 [] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors") Signed-off-by: Sabrina Dubroca Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit a0e97e698901d058b984bcf1c13693f7a33375b3 Author: Juri Lelli Date: Tue Mar 31 09:53:36 2015 +0100 sched/deadline: Always enqueue on previous rq when dl_task_timer() fires commit 4cd57f97135840f637431c92380c8da3edbe44ed upstream. dl_task_timer() may fire on a different rq from where a task was removed after throttling. Since the call path is: dl_task_timer() -> enqueue_task_dl() -> enqueue_dl_entity() -> replenish_dl_entity() and replenish_dl_entity() uses dl_se's rq, we can't use current's rq in dl_task_timer(), but we need to lock the task's previous one. Tested-by: Wanpeng Li Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Acked-by: Kirill Tkhai Cc: Juri Lelli Fixes: 3960c8c0c789 ("sched: Make dl_task_time() use task_rq_lock()") Link: http://lkml.kernel.org/r/1427792017-7356-1-git-send-email-juri.lelli@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ecb403f5eaf05dd7a9160fae030d55e23a5a4445 Author: Anna Schumaker Date: Tue Apr 14 10:34:20 2015 -0400 NFS: Add a stub for GETDEVICELIST commit 7c61f0d3897eeeff6f3294adb9f910ddefa8035a upstream. d4b18c3e (pnfs: remove GETDEVICELIST implementation) removed the GETDEVICELIST operation from the NFS client, but left a "hole" in the nfs4_procedures array. This caused /proc/self/mountstats to report an operation named "51" where GETDEVICELIST used to be. This patch adds a stub to fix mountstats. Signed-off-by: Anna Schumaker Fixes: d4b18c3e (pnfs: remove GETDEVICELIST implementation) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 5efdfc74ab7d8ccfce9f8517012e3962939c91fc Author: Peng Tao Date: Thu Apr 9 23:02:17 2015 +0800 nfs: remove WARN_ON_ONCE from nfs_direct_good_bytes commit 05f54903d9d370a4cd302a85681304d3ec59e5c1 upstream. For flexfiles driver, we might choose to read from mirror index other than 0 while mirror_count is always 1 for read. Reported-by: Jean Spector Cc: Weston Andros Adamson Signed-off-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit dcd8d0c80e86b8821c5a453b5bf782328d8580e1 Author: Peng Tao Date: Thu Apr 9 23:02:16 2015 +0800 nfs: fix DIO good bytes calculation commit 1ccbad9f9f9bd36db26a10f0b17fbaf12b3ae93a upstream. For direct read that has IO size larger than rsize, we'll split it into several READ requests and nfs_direct_good_bytes() would count completed bytes incorrectly by eating last zero count reply. Fix it by handling mirror and non-mirror cases differently such that we only count mirrored writes differently. This fixes 5fadeb47("nfs: count DIO good bytes correctly with mirroring"). Reported-by: Jean Spector Signed-off-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c59908b7a9d4b76f72367f055559663e1da274fc Author: Jeff Layton Date: Fri Mar 20 15:15:14 2015 -0400 nfs: fix high load average due to callback thread sleeping commit 5d05e54af3cdbb13cf19c557ff2184781b91a22c upstream. Chuck pointed out a problem that crept in with commit 6ffa30d3f734 (nfs: don't call blocking operations while !TASK_RUNNING). Linux counts tasks in uninterruptible sleep against the load average, so this caused the system's load average to be pinned at at least 1 when there was a NFSv4.1+ mount active. Not a huge problem, but it's probably worth fixing before we get too many complaints about it. This patch converts the code back to use TASK_INTERRUPTIBLE sleep, simply has it flush any signals on each loop iteration. In practice no one should really be signalling this thread at all, so I think this is reasonably safe. With this change, there's also no need to game the hung task watchdog so we can also convert the schedule_timeout call back to a normal schedule. Reported-by: Chuck Lever Signed-off-by: Jeff Layton Tested-by: Chuck Lever Fixes: commit 6ffa30d3f734 (“nfs: don't call blocking . . .”) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit d5d30089c2a59d079a074eb37c8c223b81664ceb Author: Giuseppe Cantavenera Date: Mon Apr 20 18:00:08 2015 +0200 nfsd: fix nsfd startup race triggering BUG_ON commit bb7ffbf29e76b89a86ca4c3ee0d4690641f2f772 upstream. nfsd triggered a BUG_ON in net_generic(...) when rpc_pipefs_event(...) in fs/nfsd/nfs4recover.c was called before assigning ntfsd_net_id. The following was observed on a MIPS 32-core processor: kernel: Call Trace: kernel: [] rpc_pipefs_event+0x7c/0x158 [nfsd] kernel: [] notifier_call_chain+0x70/0xb8 kernel: [] __blocking_notifier_call_chain+0x4c/0x70 kernel: [] rpc_fill_super+0xf8/0x1a0 kernel: [] mount_ns+0xb4/0xf0 kernel: [] mount_fs+0x50/0x1f8 kernel: [] vfs_kern_mount+0x58/0xf0 kernel: [] do_mount+0x27c/0xa28 kernel: [] SyS_mount+0x98/0xe8 kernel: [] handle_sys64+0x44/0x68 kernel: kernel: Code: 0040f809 00000000 2e020001 <00020336> 3c12c00d 3c02801a de100000 6442eb98 0040f809 kernel: ---[ end trace 7471374335809536 ]--- Fixed this behaviour by calling register_pernet_subsys(&nfsd_net_ops) before registering rpc_pipefs_event(...) with the notifier chain. Signed-off-by: Giuseppe Cantavenera Signed-off-by: Lorenzo Restelli Reviewed-by: Kinlong Mee Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 1f8303c597803d7d7c6943708dff333dbbc009a1 Author: Mark Salter Date: Mon Apr 6 09:46:00 2015 -0400 nfsd: eliminate NFSD_DEBUG commit 135dd002c23054aaa056ea3162c1e0356905c195 upstream. Commit f895b252d4edf ("sunrpc: eliminate RPC_DEBUG") introduced use of IS_ENABLED() in a uapi header which leads to a build failure for userspace apps trying to use : linux/nfsd/debug.h:18:15: error: missing binary operator before token "(" #if IS_ENABLED(CONFIG_SUNRPC_DEBUG) ^ Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG. Fixes: f895b252d4edf "sunrpc: eliminate RPC_DEBUG" Signed-off-by: Mark Salter Reviewed-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6fd154a83b18bc81aa3f1071e74c36d9076ff4b9 Author: J. Bruce Fields Date: Tue Apr 21 15:25:39 2015 -0400 nfsd4: disallow SEEK with special stateids commit 980608fb50aea34993ba956b71cd4602aa42b14b upstream. If the client uses a special stateid then we'll pass a NULL file to vfs_llseek. Fixes: 24bab491220f " NFSD: Implement SEEK" Cc: Anna Schumaker Reported-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit e2efc21fbad9a8d055586716fad4d4baaf210b56 Author: J. Bruce Fields Date: Fri Apr 3 17:19:41 2015 -0400 nfsd4: fix READ permission checking commit 6e4891dc289cd191d46ab7ba1dcb29646644f9ca upstream. In the case we already have a struct file (derived from a stateid), we still need to do permission-checking; otherwise an unauthorized user could gain access to a file by sniffing or guessing somebody else's stateid. Fixes: dc97618ddda9 "nfsd4: separate splice and readv cases" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 2556cb4a63a559a09112aba49d0112bd7dc4d2d6 Author: J. Bruce Fields Date: Fri Apr 3 16:24:27 2015 -0400 nfsd4: disallow ALLOCATE with special stateids commit 5ba4a25ab7b13be528b23f85182f4d09cf7f71ad upstream. vfs_fallocate will hit a NULL dereference if the client tries an ALLOCATE or DEALLOCATE with a special stateid. Fix that. (We also depend on the open to have broken any conflicting leases or delegations for us.) (If it turns out we need to allow special stateid's then we could do a temporary open here in the special-stateid case, as we do for read and write. For now I'm assuming it's not necessary.) Fixes: 95d871f03cae "nfsd: Add ALLOCATE support" Cc: Anna Schumaker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 04dcce2b2b45c99fdaebd0baa19640674ea388f4 Author: Nicolas Iooss Date: Thu Apr 16 18:48:39 2015 +0800 Revert "nfs: replace nfs_add_stats with nfs_inc_stats when add one" commit 3708f842e107b9b79d54a75d152e666b693649e8 upstream. This reverts commit 5a254d08b086d80cbead2ebcee6d2a4b3a15587a. Since commit 5a254d08b086 ("nfs: replace nfs_add_stats with nfs_inc_stats when add one"), nfs_readpage and nfs_do_writepage use nfs_inc_stats to increment NFSIOS_READPAGES and NFSIOS_WRITEPAGES instead of nfs_add_stats. However nfs_inc_stats does not do the same thing as nfs_add_stats with value 1 because these functions work on distinct stats: nfs_inc_stats increments stats from "enum nfs_stat_eventcounters" (in server->io_stats->events) and nfs_add_stats those from "enum nfs_stat_bytecounters" (in server->io_stats->bytes). Signed-off-by: Nicolas Iooss Fixes: 5a254d08b086 ("nfs: replace nfs_add_stats with nfs_inc_stats...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit f5e360ea796b5833aa7ddf281ed49d72f9eba1e3 Author: Al Viro Date: Fri Apr 24 15:47:07 2015 -0400 RCU pathwalk breakage when running into a symlink overmounting something commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 upstream. Calling unlazy_walk() in walk_component() and do_last() when we find a symlink that needs to be followed doesn't acquire a reference to vfsmount. That's fine when the symlink is on the same vfsmount as the parent directory (which is almost always the case), but it's not always true - one _can_ manage to bind a symlink on top of something. And in such cases we end up with excessive mntput(). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 0f14e0aa4e606b77387e807b89a0ee8faf10accb Author: Dmitry Torokhov Date: Tue Apr 21 09:49:11 2015 -0700 drm/i915: cope with large i2c transfers commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream. The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Reviewed-by: Chris Wilson Signed-off-by: Dmitry Torokhov Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 959905cf28ee80f8830b717f4e1ac28a61732974 Author: Imre Deak Date: Wed Apr 15 16:52:30 2015 -0700 drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg commit b5f1c97f944482e98e6e39208af356630389d1ea upstream. Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Signed-off-by: Imre Deak Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi Reviewed-by: Mika Kuoppala Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 74ed38596ea50609c61bd10f048f97d6161e73b4 Author: Laurent Pinchart Date: Wed Feb 18 15:19:33 2015 +0200 drm: adv7511: Fix nested sleep when reading EDID commit a5241289c4139f0521b89e34a70f5f998463ae15 upstream. The EDID read code waits for the read completion interrupt to occur using wait_event_interruptible(). The condition passed to the macro reads I2C registers. This results in sleeping with the task state set to TASK_INTERRUPTIBLE, triggering a WARN_ON() introduced in commit 8eb23b9f35aae ("sched: Debug nested sleeps"). Fix this by reworking the EDID read code. Instead of checking whether the read is complete through I2C reads, handle the interrupt registers in the interrupt handler and update a new edid_read flag accordingly. As a side effect both the IRQ and polling code paths now process the interrupt sources through the same code path, simplifying the code. Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 244f81177e5bc0ecb2f5507ef4371dc4752fea94 Author: Laurent Pinchart Date: Wed Feb 18 15:19:33 2015 +0200 drm: adv7511: Fix DDC error interrupt handling commit 2e96206c4f952295e11c311fbb2a7aa2105024af upstream. The DDC error interrupt bit is located in REG_INT1, not REG_INT0. Update both the interrupt wait code and the interrupt sources reset code accordingly. Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 9dc473bad145b361c179c4f115ea781b8b73448d Author: Daniel Vetter Date: Wed Apr 1 13:43:46 2015 +0200 drm/i915: Dont enable CS_PARSER_ERROR interrupts at all commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901 upstream. We stopped handling them in commit aaecdf611a05cac26a94713bad25297e60225c29 Author: Daniel Vetter Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171 Tested-by: Mono Tested-by: info@gluglug.org.uk Reviewed-by: Mika Kuoppala Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 7b645d942ed7101136f35bad5f6cb225c6e2adaa Author: Krzysztof Kozlowski Date: Tue Apr 7 22:28:50 2015 +0900 drm/exynos: Enable DP clock to fix display on Exynos5250 and other commit 1c363c7cccf64128087002b0779986ad16aff6dc upstream. After adding display power domain for Exynos5250 in commit 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the display on Chromebook Snow and others stopped working after boot. The reason for this suggested Andrzej Hajda: the DP clock was disabled. This clock is required by Display Port and is enabled by bootloader. However when FIMD driver probing was deferred, the display power domain was turned off. This effectively reset the value of DP clock enable register. When exynos-dp is later probed, the clock is not enabled and display is not properly configured: exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok exynos-dp 145b0000.dp-controller: unable to config video Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") Signed-off-by: Krzysztof Kozlowski Reported-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Tested-by: Andreas Färber Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman commit 87479d71ffe1c2b63f7621fefbdc1cedd95dd49d Author: Alex Deucher Date: Tue Feb 24 11:29:21 2015 -0500 drm/radeon: fix doublescan modes (v2) commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream. Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 00b2c92fe1b560e1a984edf0671f0feb7886a7ed Author: Mark Brown Date: Wed Apr 15 19:18:39 2015 +0100 i2c: core: Export bus recovery functions commit c1c21f4e60ed4523292f1a89ff45a208bddd3849 upstream. Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported: ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined! Add exports to fix this. Fixes: 5f9296ba21b3c (i2c: Add bus recovery infrastructure) Signed-off-by: Mark Brown Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 184848b540e3c7df18a22b983319fa4f64acec15 Author: Charles Keepax Date: Thu Apr 16 13:05:19 2015 +0100 i2c: Mark adapter devices with pm_runtime_no_callbacks commit 6ada5c1e1b077ab98fc144d7ac132b4dcc0148ec upstream. Commit 523c5b89640e ("i2c: Remove support for legacy PM") removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax Acked-by: Beata Michalska Signed-off-by: Wolfram Sang Fixes: 523c5b89640e Signed-off-by: Greg Kroah-Hartman commit 7a86d818f4f71fdd0e1d16c07026e2b9a52be2d6 Author: Dmitry Torokhov Date: Mon Apr 20 15:14:47 2015 -0700 i2c: rk3x: report number of messages transmitted commit c6cbfb91b878224e78408a2e15901c79de77115a upstream. master_xfer() method should return number of i2c messages transferred, but on Rockchip we were usually returning just 1, which caused trouble with users that actually check number of transferred messages vs. checking for negative error codes. Signed-off-by: Dmitry Torokhov Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit c5bc4117a935b13fdc40db4753b9d32307d2e304 Author: Wolfram Sang Date: Thu Apr 23 10:29:09 2015 +0200 i2c: mux: use proper dev when removing "channel-X" symlinks commit 133778482ec6c8fde69406be380333963627c17a upstream. Those symlinks are created for the mux_dev, so we need to remove it from there. Currently, it breaks for muxes where the mux_dev is not the device of the parent adapter like this: [ 78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78() [ 78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0' Remove confusing comments while we are here. Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Fixes: c9449affad2ae0 Signed-off-by: Greg Kroah-Hartman commit aaeb6f4d936e550fef1f068d2e883a23f757d5f5 Author: Joonsoo Kim Date: Thu Apr 16 13:44:44 2015 +0900 tracing: Fix incorrect enabling of trace events by boot cmdline commit 84fce9db4d7eaebd6cb2ee30c15da6d4e4daf846 upstream. There is a problem that trace events are not properly enabled with boot cmdline. The problem is that if we pass "trace_event=kmem:mm_page_alloc" to the boot cmdline, it enables all kmem trace events, and not just the page_alloc event. This is caused by the parsing mechanism. When we parse the cmdline, the buffer contents is modified due to tokenization. And, if we use this buffer again, we will get the wrong result. Unfortunately, this buffer is be accessed three times to set trace events properly at boot time. So, we need to handle this situation. There is already code handling ",", but we need another for ":". This patch adds it. Link: http://lkml.kernel.org/r/1429159484-22977-1-git-send-email-iamjoonsoo.kim@lge.com Signed-off-by: Joonsoo Kim [ added missing return ret; ] Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c62b024af945d20e01c3e8c416b9e00d137e6f02 Author: Rabin Vincent Date: Mon Apr 13 22:30:12 2015 +0200 tracing: Handle ftrace_dump() atomic context in graph_trace_open() commit ef99b88b16bee753fa51207abdc58ae660453ec6 upstream. graph_trace_open() can be called in atomic context from ftrace_dump(). Use GFP_ATOMIC for the memory allocations when that's the case, in order to avoid the following splat. BUG: sleeping function called from invalid context at mm/slab.c:2849 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 Backtrace: .. [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238) r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0) r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8 r4:810d16f0 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c) r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec) r4:810d2580 r3:00000000 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20) r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a r4:808d5394 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18) [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18) r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60 r4:8454fe00 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c) r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60 r4:84f01e00 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac) r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c) r6:00000026 r5:00000000 r4:00000026 r3:8007a938 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc) r4:808c1e38 r3:0000002e [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c) r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015 r4:8880210c r3:808c7ef0 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c) Link: http://lkml.kernel.org/r/1428953721-31349-1-git-send-email-rabin@rab.in Link: http://lkml.kernel.org/r/1428957012-2319-1-git-send-email-rabin@rab.in Signed-off-by: Rabin Vincent Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 6fb5785d6c07d834567ccf3f3ba2df9c3803b28b Author: Sagi Grimberg Date: Tue Apr 14 18:08:13 2015 +0300 IB/iser: Fix wrong calculation of protection buffer length commit a065fe6aa25ba6ba93c02dc13486131bb3c64d5f upstream. This length miss-calculation may cause a silent data corruption in the DIX case and cause the device to reference unmapped area. Fixes: d77e65350f2d ('libiscsi, iser: Adjust data_length to include protection information') Signed-off-by: Sagi Grimberg Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 7fc80a4ea6d5b307470a6bb165b293e334b22c20 Author: Erez Shitrit Date: Thu Apr 2 13:39:05 2015 +0300 IB/mlx4: Fix WQE LSO segment calculation commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream. The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers. It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers. The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages. An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2*hlen (2*56) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state. Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support') Reported-by: Matthew Finlay Signed-off-by: Erez Shitrit Signed-off-by: Or Gerlitz Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit d0ddb13fc24a64a940e8050ea076e59bb04597f4 Author: Yann Droneaud Date: Mon Apr 13 14:56:23 2015 +0200 IB/core: don't disallow registering region starting at 0x0 commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream. In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit 8494057ab5e4 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0). This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages(). There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Reviewed-by: Sagi Grimberg Reviewed-by: Haggai Eran Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit d9bc10f7ccda1d662f3cd98f0949a03fe27b69e4 Author: Yann Droneaud Date: Mon Apr 13 14:56:22 2015 +0200 IB/core: disallow registering 0-sized memory region commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream. If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller. This should not be allowed: it's not expected for a memory region to have a size equal to 0. This patch adds a check to explicitly refuse to register a 0-sized region. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit ecfdbe6a56ddd74036337f651bb2bd933341faa7 Author: Ezequiel Garcia Date: Tue Mar 10 11:37:14 2015 -0300 stk1160: Make sure current buffer is released commit aeff09276748b66072f2db2e668cec955cf41959 upstream. The available (i.e. not used) buffers are returned by stk1160_clear_queue(), on the stop_streaming() path. However, this is insufficient and the current buffer must be released as well. Fix it. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 287189f739322ef2f2b7698e613c85e7be8c9b9c Author: Sifan Naeem Date: Tue Feb 10 07:41:56 2015 -0300 rc: img-ir: fix error in parameters passed to irq_free() commit 80ccf4ad06dc9d2f06a8347b2d309cdc959f72b3 upstream. img_ir_remove() passes a pointer to the ISR function as the 2nd parameter to irq_free() instead of a pointer to the device data structure. This issue causes unloading img-ir module to fail with the below warning after building and loading img-ir as a module. WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278 __free_irq+0xb4/0x214() Trying to free already-free IRQ 58 Modules linked in: img_ir(-) CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ... Call Trace: ... [<8048d420>] __free_irq+0xb4/0x214 [<8048d6b4>] free_irq+0xac/0xf4 [] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>] platform_drv_remove+0x30/0x54 ... Fixes: 160a8f8aec4d ("[media] rc: img-ir: add base driver") Signed-off-by: Sifan Naeem Acked-by: James Hogan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1f77a24829ac6dbe9a942752ee15054d403653d9 Author: James Bottomley Date: Wed Apr 15 22:16:01 2015 -0700 mvsas: fix panic on expander attached SATA devices commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream. mvsas is giving a General protection fault when it encounters an expander attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is assuming all ATA devices are locally attached and obtaining the phy mask by indexing the local phy table (in the HBA structure) with the phy id. Since expanders have many more phys than the HBA, this is causing the index into the HBA phy table to overflow and returning rubbish as the pointer. mvs_task_prep_ssp() instead does the phy mask using the port properties. Mirror this in mvs_task_prep_ata() to fix the panic. Reported-by: Adam Talbot Tested-by: Adam Talbot Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b9b4320c38bf2fadfd9299c36165c46f131200e0 Author: K. Y. Srinivasan Date: Fri Feb 27 11:26:04 2015 -0800 Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open() commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream. Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 5c87838eadeb1a63546e36f76917241d8fa6ea52 Author: Martin K. Petersen Date: Tue Apr 14 17:11:03 2015 -0400 sd: Fix missing ATO tag check commit e557990e358934fb168d30371c9c0f63e314c6b8 upstream. 3aec2f41a8bae introduced a merge error where we would end up check for sdkp instead of sdkp->ATO. Fix this so we register app tag capability correctly. Signed-off-by: Martin K. Petersen Reviewed-by: Sagi Grimberg Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 5cd06dd45f7cc5c15517266a61f8051ec16912ff Author: Martin K. Petersen Date: Tue Apr 14 16:56:23 2015 -0400 sd: Unregister integrity profile commit e727c42bd55794765c460b7ac2b6cc969f2a9698 upstream. The new integrity code did not correctly unregister the profile for SD disks. Call blk_integrity_unregister() when we release a disk. Signed-off-by: Martin K. Petersen Reported-by: Sagi Grimberg Tested-by: Sagi Grimberg Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit cc1064fc8f1d71f9c3429e6bdd8129629fc39784 Author: Peter Hurley Date: Mon Mar 9 14:05:01 2015 -0400 serial: 8250: Check UART_SCR is writable commit f01a0bd8921b9d6668d41fae3198970e6318f532 upstream. Au1x00/RT2800+ doesn't implement the 8250 scratch register (and this may be true of other h/w currently supported by the 8250 driver); read back the canary value written to the scratch register to enable the console h/w restart after resume from system suspend. Fixes: 4516d50aabedb ("serial: 8250: Use canary to restart console ...") Reported-by: Mason Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 8067aec1b07ce3f80c8209eb3589abdf38753ac1 Author: Uwe Kleine-König Date: Tue Feb 24 11:17:05 2015 +0100 serial: imx: Fix clearing of receiver overrun flag commit 91555ce9012557b2d621d7b0b6ec694218a2a9bc upstream. The writeable bits in the USR2 register are all "write 1 to clear" so only write the bits that actually should be cleared. Fixes: f1f836e4209e ("serial: imx: Add Rx Fifo overrun error message") Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 39b991a4765e2f7bd2faa383c66df5237117a8bb Author: Ken Xue Date: Mon Mar 9 17:10:13 2015 +0800 serial: 8250_dw: add support for AMD SOC Carrizo commit 5ef86b74209db33c133b5f18738dd8f3189b63a1 upstream. Add ACPI identifier for UART on AMD SOC Carrizo. Signed-off-by: Ken Xue Signed-off-by: Greg Kroah-Hartman commit b1c9b99dda6dfe49023214a772ff59debfaa6824 Author: Ben Collins Date: Fri Apr 3 16:09:46 2015 +0000 dm crypt: fix deadlock when async crypto algorithm returns -EBUSY commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream. I suspect this doesn't show up for most anyone because software algorithms typically don't have a sense of being too busy. However, when working with the Freescale CAAM driver it will return -EBUSY on occasion under heavy -- which resulted in dm-crypt deadlock. After checking the logic in some other drivers, the scheme for crypt_convert() and it's callback, kcryptd_async_done(), were not correctly laid out to properly handle -EBUSY or -EINPROGRESS. Fix this by using the completion for both -EBUSY and -EINPROGRESS. Now crypt_convert()'s use of completion is comparable to af_alg_wait_for_completion(). Similarly, kcryptd_async_done() follows the pattern used in af_alg_complete(). Before this fix dm-crypt would lockup within 1-2 minutes running with the CAAM driver. Fix was regression tested against software algorithms on PPC32 and x86_64, and things seem perfectly happy there as well. Signed-off-by: Ben Collins Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ea8ae530984cacf55cebc6a12bc43061f1dd41ed Author: Stephen Boyd Date: Thu Feb 26 19:34:35 2015 -0800 clk: qcom: Fix ipq806x LCC frequency tables commit b3261d768bcdd4b368179ed85becf38c95461848 upstream. These frequency tables list the wrong rates. Either they don't have the correct frequency at all, or they're specified in kHz instead of Hz. Fix it. Fixes: c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) driver" Tested-by: Kenneth Westfield Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 0602addf5fe488d8ced792e6a8f7da073516d33b Author: Archit Taneja Date: Wed Mar 4 15:19:35 2015 +0530 clk: qcom: fix RCG M/N counter configuration commit 0b21503dbbfa669dbd847b33578d4041513cddb2 upstream. Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N. In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1. Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division. Signed-off-by: Archit Taneja Fixes: bcd61c0f535a (clk: qcom: Add support for root clock generators (RCGs)) Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 6761ec536ade4be25c5b846e71f96c8ecdc08347 Author: Stephen Boyd Date: Fri Mar 6 15:41:53 2015 -0800 clk: qcom: Properly change rates for ahbix clock commit 9d3745d44a7faa7d24db7facb1949a1378162f3e upstream. The ahbix clock can never be turned off in practice. To change the rates we need to switch the mux off the M/N counter to an always on source (XO), reprogram the M/N counter to get the rate we want and finally switch back to the M/N counter. Add a new ops structure for this type of clock so that we can set the rate properly. Fixes: c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) driver" Tested-by: Kenneth Westfield Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 1d77b1031e7230917ed6c8fd1ac82f18a9c33c9d Author: Stephen Boyd Date: Mon Feb 23 13:30:28 2015 -0800 clk: qcom: Fix i2c frequency table commit 0bf0ff82c34da02ee5795101b328225a2d519594 upstream. PXO is 25MHz, not 27MHz. Fix the table. Fixes: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)" Signed-off-by: Stephen Boyd Reviewed-by: Andy Gross Tested-by: Andy Gross Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 7c646709786798cd41b4e2feb7f9136214169c92 Author: Thierry Reding Date: Thu Mar 26 17:53:01 2015 +0100 clk: tegra: Use the proper parent for plld_dsi commit c1d676cec572544616273d5853cb7cc38fbaa62b upstream. The current parent, plld_out0, does not exist. The proper name is pll_d_out0. While at it, rename the plld_dsi clock to pll_d_dsi_out to be more consistent with other clock names. Fixes: b270491eb9a0 ("clk: tegra: Define PLLD_DSI and remove dsia(b)_mux") Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 41761ed1e3b457699c416c4e5eea1c86aa2d307c Author: Thierry Reding Date: Mon Mar 23 10:57:46 2015 +0100 clk: tegra: Register the proper number of resets commit 5e43e259171e1eee8bc074d9c44be434e685087b upstream. The number of resets controls is 32 times the number of peripheral register banks rather than 32 times the number of clocks. This reduces (drastically) the number of reset controls registered from 10080 (315 clocks * 32) to 224 (6 peripheral register banks * 32). This also fixes a potential crash because trying to use any of the excess reset controls (224-10079) would have caused accesses beyond the array bounds of the peripheral register banks definition array. Cc: Peter De Schrijver Cc: Prashant Gaikwad Fixes: 6d5b988e7dc5 ("clk: tegra: implement a reset driver") Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit fb8e85723598714f519a827184910324690e2896 Author: Bartlomiej Zolnierkiewicz Date: Fri Mar 27 17:27:10 2015 +0100 clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC commit 3a9e9cb65be84d6c64fbe9c69a73c15d59f29454 upstream. Commit 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature") enabled ARMCLK down feature on all Exynos4 SoCs. Unfortunately on Exynos4210 SoC ARMCLK down feature causes a lockup when ondemand cpufreq governor is used. Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs. This patch was tested on: - Exynos4210 SoC based Trats board - Exynos4210 SoC based Origen board - Exynos4412 SoC based Trats2 board - Exynos4412 SoC based Odroid-U3 board Cc: Daniel Drake Cc: Tomasz Figa Cc: Kukjin Kim Fixes: 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 6d4724e609d9640755996c9dc8f3f4ee79790957 Author: Gregory CLEMENT Date: Thu Apr 2 17:11:11 2015 +0200 gpio: mvebu: Fix mask/unmask managment per irq chip type commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream. Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario: First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm. The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue. It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario. This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov: 9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there: http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012 Reported-by: Evgeniy A. Dushistov Signed-off-by: Gregory CLEMENT Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 63c94a9787fee217938e65b3e11bed2b7179481f Author: Max Filippov Date: Fri Apr 3 09:56:21 2015 +0300 xtensa: ISS: fix locking in TAP network adapter commit 24e94454c8cb6a13634f5a2f5a01da53a546a58d upstream. - don't lock lp->lock in the iss_net_timer for the call of iss_net_poll, it will lock it itself; - invert order of lp->lock and opened_lock acquisition in the iss_net_open to make it consistent with iss_net_poll; - replace spin_lock with spin_lock_bh when acquiring locks used in iss_net_timer from non-atomic context; - replace spin_lock_irqsave with spin_lock_bh in the iss_net_start_xmit as the driver doesn't use lp->lock in the hard IRQ context; - replace __SPIN_LOCK_UNLOCKED(lp.lock) with spin_lock_init, otherwise lockdep is unhappy about using non-static key. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 3d421b4703e664742e5f8b80c8f61d64d6435fa2 Author: Max Filippov Date: Fri Feb 27 11:02:38 2015 +0300 xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range commit 01e84c70fe40c8111f960987bcf7f931842e6d07 upstream. xtensa actually uses sync_file_range2 implementation, so it should define __NR_sync_file_range2 as other architectures that use that function. That fixes userspace interface (that apparently never worked) and avoids special-casing xtensa in libc implementations. See the thread ending at http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html for more details. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 042741ecc3287d365daab83a5fd287aee607ea32 Author: Max Filippov Date: Fri Feb 27 06:28:00 2015 +0300 xtensa: xtfpga: fix hardware lockup caused by LCD driver commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 upstream. LCD driver is always built for the XTFPGA platform, but its base address is not configurable, and is wrong for ML605/KC705. Its initialization locks up KC705 board hardware. Make the whole driver optional, and its base address and bus width configurable. Implement 4-bit bus access method. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 7b2f4da529f27b81d06a9c5d49803dc4b1d5eea3 Author: Rafael J. Wysocki Date: Sat Apr 18 01:25:46 2015 +0200 ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline() commit 4c533c801d1c9b5c38458a0e7516e0cf50643782 upstream. acpi_scan_is_offline() may be called under the physical_node_lock lock of the given device object's parent, so prevent lockdep from complaining about that by annotating that instance with SINGLE_DEPTH_NESTING. Fixes: caa73ea158de (ACPI / hotplug / driver core: Handle containers in a special way) Reported-and-tested-by: Xie XiuQi Reviewed-by: Toshi Kani Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit afaed716d9f945416e6f0967384714ee3b066020 Author: Rafael J. Wysocki Date: Wed Apr 15 04:00:27 2015 +0200 ACPICA: Store GPE register enable masks upfront commit 0ee0d34985ceffe4036319e1e46df8bff591b9e3 upstream. It is reported that ACPI interrupts do not work any more on Dell Latitude D600 after commit c50f13c672df (ACPICA: Save current masks of enabled GPEs after enable register writes). The problem turns out to be related to the fact that the enable_mask and enable_for_run GPE bit masks are not in sync (in the absence of any system suspend/resume events) for at least one GPE register on that machine. Address this problem by writing the enable_for_run mask into enable_mask as soon as enable_for_run is updated instead of doing that only after the subsequent register write has succeeded. For consistency, update acpi_hw_gpe_enable_write() to store the bit mask to be written into the GPE register in enable_mask unconditionally before the write. Since the ACPI_GPE_SAVE_MASK flag is not necessary any more after that, drop it along with the symbols depending on it. Reported-and-tested-by: Jim Bos Fixes: c50f13c672df (ACPICA: Save current masks of enabled GPEs after enable register writes) Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5980bf8bc5dbb8e5338a3db6e311539eeb6242da Author: Octavian Purdila Date: Mon Apr 13 11:49:05 2015 +0800 ACPICA: Tables: Don't release ACPI_MTX_TABLES in acpi_tb_install_standard_table(). commit 77ddc2fe08329e375505bc36a3df3233fe57317b upstream. ACPICA commit c70434d4da13e65b6163c79a5aa16b40193631c7 ACPI_MTX_TABLES is acquired and released by the callers of acpi_tb_install_standard_table() so releasing it in the function itself is causing the following error in Linux kernel if the table is reloaded: ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321) Call Trace: [] dump_stack+0x4f/0x7b [] acpi_ut_release_mutex+0x47/0x67 [] acpi_load_table+0x73/0xcb Link: https://github.com/acpica/acpica/commit/c70434d4 Signed-off-by: Octavian Purdila Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 650a628d5725e7eb8ed5f979fee058795cb06355 Author: Lv Zheng Date: Mon Apr 13 11:48:58 2015 +0800 ACPICA: Utilities: split IO address types from data type models. commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream. ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 Reported-and-tested-by: Paul Menzel Reported-and-tested-by: Sial Nije Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 43ebd1a85ee86416c2d45a3834e7425c396890e9 Author: Howard Mitchell Date: Fri Mar 20 21:13:45 2015 +0000 ASoC: pcm512x: Fix divide by zero issue commit f073faa73626f41db7050a69edd5074c53ce6d6c upstream. If den=1 and pllin_rate>20MHz then den and num are adjusted to 0 causing a divide by zero error a few lines further on. Therefore this patch correctly scales num and den such that pllin_rate/den < 20MHz as required in the device data sheet. Signed-off-by: Howard Mitchell Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f646e040a619bcea31a6cab378ccaccb6f4cb659 Author: Howard Mitchell Date: Thu Mar 19 12:08:30 2015 +0000 ASoC: pcm512x: Add 'Analogue' prefix to analogue volume controls commit 4d9b13c7cc803fbde59d7e998f7de2b9a2101c7e upstream. This is to ensure that 'alsactl restore' does not apply default initialisation as the chip reset defaults are preferred. Signed-off-by: Howard Mitchell Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f7a469cdb54b146db35083f167e9f844ffc31f0c Author: Manish Badarkhe Date: Thu Mar 26 15:38:25 2015 +0200 ASoC: davinci-evm: drop un-necessary remove function commit a57069e33fbc6625f39e1b09c88ea44629a35206 upstream. As davinci card gets registered using 'devm_' api there is no need to unregister the card in 'remove' function. Hence drop the 'remove' function. Fixes: ee2f615d6e59c (ASoC: davinci-evm: Add device tree binding) Signed-off-by: Manish Badarkhe Signed-off-by: Jyri Sarha Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d9493a0723e5a23b0250f43ea5e6d8ed66e1a343 Author: Sergej Sawazki Date: Tue Mar 24 21:13:22 2015 +0100 ASoC: wm8741: Fix rates constraints values commit 8787041d9bb832b9449b1eb878cedcebce42c61a upstream. The WM8741 DAC supports the following typical audio sampling rates: 44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz) 32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz) For the rates lists, we should use 82000 instead of 88235, 176400 instead of 1764000 and 192000 instead of 19200 (seems to be a typo). Signed-off-by: Sergej Sawazki Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 755b29de0d793e3915b35f35c716705d9910109f Author: Pascal Huerst Date: Thu Apr 2 10:17:40 2015 +0200 ASoC: cs4271: Increase delay time after reset commit 74ff960222d90999508b4ba0d3449f796695b6d5 upstream. The delay time after a reset in the codec probe callback was too short, and did not work on certain hw because the codec needs more time to power on. This increases the delay time from 1us to 1ms. Signed-off-by: Pascal Huerst Acked-by: Brian Austin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 94a5f3b014e7d81936ae02cc095cdf895f94fb19 Author: Michael Ellerman Date: Fri Apr 3 14:11:54 2015 +1100 powerpc/cell: Fix cell iommu after it_page_shift changes commit 7261b956b276aa97fbf60d00f1d7717d2ea6ee78 upstream. The patch to add it_page_shift incorrectly changed the increment of uaddr to use it_page_shift, rather then (1 << it_page_shift). This broke booting on at least some Cell blades, as the iommu was basically non-functional. Fixes: 3a553170d35d ("powerpc/iommu: Add it_page_shift field to determine iommu page size") Signed-off-by: Michael Ellerman Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9fb1018337f9767398e0d62e5dce8499fd0f2bf0 Author: Michael Ellerman Date: Fri Apr 3 14:11:53 2015 +1100 powerpc/cell: Fix crash in iic_setup_cpu() after per_cpu changes commit b0dd00addc5035f87ec9c5820dacc1ebc7fcb3e6 upstream. The conversion from __get_cpu_var() to this_cpu_ptr() in iic_setup_cpu() is wrong. It causes an oops at boot. We need the per-cpu address of struct cpu_iic, not cpu_iic.regs->prio. Sparse noticed this, because we pass a non-iomem pointer to out_be64(), but we obviously don't check the sparse results often enough. Fixes: 69111bac42f5 ("powerpc: Replace __get_cpu_var uses") Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 7ef1951eca49005fdbb4768574b7076cae1eeb4c Author: Dave Olson Date: Thu Apr 2 21:28:45 2015 -0700 powerpc: Fix missing L2 cache size in /sys/devices/system/cpu commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream. This problem appears to have been introduced in 2.6.29 by commit 93197a36a9c1 "Rewrite sysfs processor cache info code". This caused lscpu to error out on at least e500v2 devices, eg: error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory Some embedded powerpc systems use cache-size in DTS for the unified L2 cache size, not d-cache-size, so we need to allow for both DTS names. Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle this. Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code") Signed-off-by: Dave Olson Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit aa54f8fb00ef9c739f564672048ec0fcc08a61dc Author: Gavin Shan Date: Fri Mar 27 11:29:00 2015 +1100 powerpc/powernv: Don't map M64 segments using M32DT commit 027fa02f84e851e21daffdf8900d6117071890f8 upstream. If M64 has been supported, the prefetchable 64-bits memory resources shouldn't be mapped to the corresponding PE# via M32DT. Unfortunately, we're doing that in pnv_ioda_setup_pe_seg() wrongly. The issue was introduced by commit 262af55 ("powerpc/powernv: Enable M64 aperatus for PHB3"). The patch fixes the issue by simply skipping M64 resources when updating to M32DT. Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d56f1962494430ce86e221537a2116a8ff0dca7e Author: Will Deacon Date: Mon Mar 23 19:07:02 2015 +0000 arm64: errata: add workaround for cortex-a53 erratum #845719 commit 905e8c5dcaa147163672b06fe9dcb5abaacbc711 upstream. When running a compat (AArch32) userspace on Cortex-A53, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data. This patch works around the issue by writing to the contextidr_el1 register on the exception return path when returning to a 32-bit task. This workaround is patched in at runtime based on the MIDR value of the processor. Reviewed-by: Marc Zyngier Tested-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit f5fc6d70222ede94eb601c8f2697df1a9bcd9535 Author: Mark Rutland Date: Fri Mar 13 16:14:34 2015 +0000 arm64: apply alternatives for !SMP kernels commit 137650aad96c9594683445e41afa8ac5a2097520 upstream. Currently we only perform alternative patching for kernels built with CONFIG_SMP, as we call apply_alternatives_all() in smp.c, which is only built for CONFIG_SMP. Thus !SMP kernels may not have necessary alternatives patched in. This patch ensures that we call apply_alternatives_all() once all CPUs are booted, even for !SMP kernels, by having the smp_init_cpus() stub call this for !SMP kernels via up_late_init. A new wrapper, do_post_cpus_up_work, is added so we can hook other calls here later (e.g. boot mode logging). Cc: Andre Przywara Cc: Catalin Marinas Fixes: e039ee4ee3fcf174 ("arm64: add alternative runtime patching") Tested-by: Ard Biesheuvel Reviewed-by: Ard Biesheuvel Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3b4f68e9d08a42860dd7491e973a1ba2abcf4ea7 Author: Steve Capper Date: Mon Mar 16 09:30:39 2015 +0000 arm64: Adjust EFI libstub object include logic commit ad08fd494bf00c03ae372e0bbd9cefa37bf608d6 upstream. Commit f4f75ad5 ("efi: efistub: Convert into static library") introduced a static library for EFI stub, libstub. The EFI libstub directory is referenced by the kernel build system via a obj subdirectory rule in: drivers/firmware/efi/Makefile Unfortunately, arm64 also references the EFI libstub via: libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/ If we're unlucky, the kernel build system can enter libstub via two simultaneous threads resulting in build failures such as: fixdep: error opening depfile: drivers/firmware/efi/libstub/.efi-stub-helper.o.d: No such file or directory scripts/Makefile.build:257: recipe for target 'drivers/firmware/efi/libstub/efi-stub-helper.o' failed make[1]: *** [drivers/firmware/efi/libstub/efi-stub-helper.o] Error 2 Makefile:939: recipe for target 'drivers/firmware/efi/libstub' failed make: *** [drivers/firmware/efi/libstub] Error 2 make: *** Waiting for unfinished jobs.... This patch adjusts the arm64 Makefile to reference the compiled library explicitly (as is currently done in x86), rather than the directory. Fixes: f4f75ad5 efi: efistub: Convert into static library Signed-off-by: Steve Capper Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 28a75aebb66869d9b48970bc9ad2c50d06ca2368 Author: Mark Rutland Date: Tue Mar 24 13:50:27 2015 +0000 arm64: head.S: ensure visibility of page tables commit 91d57155dc5ab4b311624b7ee570339b6af19ad5 upstream. After writing the page tables, we use __inval_cache_range to invalidate any stale cache entries. Strongly Ordered memory accesses are not ordered w.r.t. cache maintenance instructions, and hence explicit memory barriers are required to provide this ordering. However, __inval_cache_range was written to be used on Normal Cacheable memory once the MMU and caches are on, and does not have any barriers prior to the DC instructions. This patch adds a DMB between the page tables being written and the corresponding cachelines being invalidated, ensuring that the invalidation makes the new data visible to subsequent cacheable accesses. A barrier is not required before the prior invalidate as we do not access the page table memory area prior to this, and earlier barriers in preserve_boot_args and set_cpu_boot_mode_flag ensures ordering w.r.t. any stores performed prior to entering Linux. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Fixes: c218bca74eeafa2f ("arm64: Relax the kernel cache requirements for boot") Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 929315920e42097f53f97bfc88c6da4a41e19f66 Author: Bo Yan Date: Tue Mar 31 21:30:48 2015 +0100 arm64: fix midr range for Cortex-A57 erratum 832075 commit 6d1966dfd6e0ad2f8aa4b664ae1a62e33abe1998 upstream. Register MIDR_EL1 is masked to get variant and revision fields, then compared against midr_range_min and midr_range_max when checking whether CPU is affected by any particular erratum. However, variant and revision fields in MIDR_EL1 are separated by 16 bits, so the min and max of midr range should be constructed accordingly, otherwise the patch will not be applied when variant field is non-0. Acked-by: Andre Przywara Reviewed-by: Paul Walmsley Signed-off-by: Bo Yan [will: use MIDR_VARIANT_SHIFT to construct upper bound] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 1ed449ae56cbf5db4f3ea0560a5bfbe95e30e89a Author: Alexander Ploumistos Date: Fri Feb 13 21:05:11 2015 +0200 Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card commit 2eeff0b4317a02f0e281df891d990194f0737aae upstream. Add 04f2:aff1 to ath3k.c supported devices list and btusb.c blacklist, so that the device can load the ath3k firmware and re-enumerate itself as an AR3011 device. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04f2 ProdID=aff1 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Alexander Ploumistos Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit c1398bc9478760e098fd1a36c9d67eeaf1bc5813 Author: Sagi Grimberg Date: Sun Mar 29 15:52:04 2015 +0300 iser-target: Fix possible deadlock in RDMA_CM connection error commit 4a579da2586bd3b79b025947ea24ede2bbfede62 upstream. Before we reach to connection established we may get an error event. In this case the core won't teardown this connection (never established it), so we take care of freeing it ourselves. Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 6c617001eadca79dc3c26a6e2d2844ad48c1a178 Author: Sagi Grimberg Date: Sun Mar 29 15:52:03 2015 +0300 iser-target: Fix session hang in case of an rdma read DIF error commit 364189f0ada5478e4faf8a552d6071a650d757cd upstream. This hang was a result of a missing command put when a DIF error occurred during a rdma read (and we sent an CHECK_CONDITION error without passing it to the backend). Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 53e5aa168e3ba918741417ac2177db04a84f77c1 Author: Akinobu Mita Date: Mon Apr 13 23:21:57 2015 +0900 target/file: Fix SG table for prot_buf initialization commit c836777830428372074d5129ac513e1472c99791 upstream. In fd_do_prot_rw(), it allocates prot_buf which is used to copy from se_cmd->t_prot_sg by sbc_dif_copy_prot(). The SG table for prot_buf is also initialized by allocating 'se_cmd->t_prot_nents' entries of scatterlist and setting the data length of each entry to PAGE_SIZE at most. However if se_cmd->t_prot_sg contains a clustered entry (i.e. sg->length > PAGE_SIZE), the SG table for prot_buf can't be initialized correctly and sbc_dif_copy_prot() can't copy to prot_buf. (This actually happened with TCM loopback fabric module) As prot_buf is allocated by kzalloc() and it's physically contiguous, we only need a single scatterlist entry. Signed-off-by: Akinobu Mita Cc: Sagi Grimberg Cc: "Martin K. Petersen" Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 1d6b56f309d72a9ce2be3129f41c4a1138693091 Author: Akinobu Mita Date: Mon Apr 13 23:21:58 2015 +0900 target/file: Fix UNMAP with DIF protection support commit 64d240b721b21e266ffde645ec965c3b6d1c551f upstream. When UNMAP command is issued with DIF protection support enabled, the protection info for the unmapped region is remain unchanged. So READ command for the region causes data integrity failure. This fixes it by invalidating protection info for the unmapped region by filling with 0xff pattern. This change also adds helper function fd_do_prot_fill() in order to reduce code duplication with existing fd_format_prot(). Signed-off-by: Akinobu Mita Reviewed-by: Sagi Grimberg Reviewed-by: "Martin K. Petersen" Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 54afccf4a4f42da1ef3eca9b56ed8dd25a8d7f1c Author: Akinobu Mita Date: Mon Apr 13 23:21:56 2015 +0900 target/file: Fix BUG() when CONFIG_DEBUG_SG=y and DIF protection enabled commit 38da0f49e8aa1649af397d53f88e163d0e60c058 upstream. When CONFIG_DEBUG_SG=y and DIF protection support enabled, kernel BUG()s are triggered due to the following two issues: 1) prot_sg is not initialized by sg_init_table(). When CONFIG_DEBUG_SG=y, scatterlist helpers check sg entry has a correct magic value. 2) vmalloc'ed buffer is passed to sg_set_buf(). sg_set_buf() uses virt_to_page() to convert virtual address to struct page, but it doesn't work with vmalloc address. vmalloc_to_page() should be used instead. As prot_buf isn't usually too large, so fix it by allocating prot_buf by kmalloc instead of vmalloc. Signed-off-by: Akinobu Mita Cc: Sagi Grimberg Cc: "Martin K. Petersen" Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit ca7767a3f859d6e5487ddcf7a23515e19188b922 Author: Nicholas Bellinger Date: Tue Apr 7 21:53:27 2015 +0000 target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling commit c8e639852ad720499912acedfd6b072325fd2807 upstream. This patch fixes a bug for COMPARE_AND_WRITE handling with fabrics using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC. It adds the missing allocation for cmd->t_bidi_data_sg within transport_generic_new_cmd() that is used by COMPARE_AND_WRITE for the initial READ payload, even if the fabric is already providing a pre-allocated buffer for cmd->t_data_sg. Also, fix zero-length COMPARE_AND_WRITE handling within the compare_and_write_callback() and target_complete_ok_work() to queue the response, skipping the initial READ. This fixes COMPARE_AND_WRITE emulation with loopback, vhost, and xen-backend fabric drivers using SG_TO_MEM_NOALLOC. Reported-by: Christoph Hellwig Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 7f61df07930dae7b1a94f088365362a191d2f4ec Author: Nicholas Bellinger Date: Thu Feb 26 22:19:15 2015 -0800 iscsi-target: Convert iscsi_thread_set usage to kthread.h commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca upstream. This patch converts iscsi-target code to use modern kthread.h API callers for creating RX/TX threads for each new iscsi_conn descriptor, and releasing associated RX/TX threads during connection shutdown. This is done using iscsit_start_kthreads() -> kthread_run() to start new kthreads from within iscsi_post_login_handler(), and invoking kthread_stop() from existing iscsit_close_connection() code. Also, convert iscsit_logout_post_handler_closesession() code to use cmpxchg when determing when iscsit_cause_connection_reinstatement() needs to sleep waiting for completion. Reported-by: Sagi Grimberg Tested-by: Sagi Grimberg Cc: Slava Shwartsman Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 1d05935b31efb2e398e1772b76a6513b9484574a Author: K. Y. Srinivasan Date: Fri Mar 27 00:27:18 2015 -0700 scsi: storvsc: Fix a bug in copy_from_bounce_buffer() commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream. We may exit this function without properly freeing up the maapings we may have acquired. Fix the bug. Signed-off-by: K. Y. Srinivasan Reviewed-by: Long Li Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 075831830ff0277572a93633cce3807394955358 Author: Brian Norris Date: Sat Feb 28 02:23:28 2015 -0800 UBI: fix check for "too many bytes" commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream. The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum. Coverity CID #139400 Signed-off-by: Brian Norris [rw: Fixed comparison] Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 5a156e848f96a0f0024ef94a3e19979f8f7e9dbc Author: Brian Norris Date: Sat Feb 28 02:23:27 2015 -0800 UBI: initialize LEB number variable commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream. In some of the 'out_not_moved' error paths, lnum may be used uninitialized. Don't ignore the warning; let's fix it. This uninitialized variable doesn't have much visible effect in the end, since we just schedule the PEB for erasure, and its LEB number doesn't really matter (it just gets printed in debug messages). But let's get it straight anyway. Coverity CID #113449 Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 921b47c10b2b18b3562152aa0eacc1b2e56c6996 Author: Brian Norris Date: Sat Feb 28 02:23:26 2015 -0800 UBI: fix out of bounds write commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream. If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 67e9563f2e494959696ff3128cf9d5fb1b3dbad7 Author: Brian Norris Date: Sat Feb 28 02:23:25 2015 -0800 UBI: account for bitflips in both the VID header and data commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream. We are completely discarding the earlier value of 'bitflips', which could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the bitwise OR of header and data 'bitflip' statuses instead. Coverity CID #1226856 Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit e5e82af52cd373fed10be67faba90cd2eed6fb17 Author: Thomas D Date: Mon Jan 5 21:37:23 2015 +0100 tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile commit f82263c6989c31ae9b94cecddffb29dcbec38710 upstream. Since commit ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable") turbostat's Makefile is using [...] BUILD_OUTPUT := $(PWD) [...] which obviously causes trouble when building "turbostat" with make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat because GNU make does not update nor guarantee that $PWD is set. This patch changes the Makefile to use $CURDIR instead, which GNU make guarantees to set and update (i.e. when using "make -C ...") and also adds support for the O= option (see "make help" in your root of your kernel source tree for more details). Link: https://bugs.gentoo.org/show_bug.cgi?id=533918 Fixes: ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable") Signed-off-by: Thomas D. Cc: Mark Asselstine Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f0289e90ac96271337d6d0f9c9a6ceb2aea62a05 Author: Steven Rostedt (Red Hat) Date: Tue Mar 24 09:57:55 2015 -0400 tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING commit c5e691928bf166ac03430e957038b60adba3cf6c upstream. When a event PADDING is hit (a deleted event that is still in the ring buffer), translate_data() sets the length of the padding and also updates the data pointer which is passed back to the caller. This is unneeded because the caller also updates the data pointer with the passed back length. translate_data() should not update the pointer, only set the length. Signed-off-by: Steven Rostedt Cc: Andrew Morton Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit beda5943f15926783dc6768e8f821266ae6e8fb3 Author: Anton Blanchard Date: Tue Apr 14 07:51:03 2015 +1000 powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream. We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH (currently 127), but we forgot to do the same for 64bit backtraces. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a245448568a6f791b7d4617e622adf6e7118d174 Author: Vinson Lee Date: Mon Mar 23 12:09:16 2015 -0700 perf tools: Work around lack of sched_getcpu in glibc < 2.6. commit e1e455f4f4d35850c30235747620d0d078fe9f64 upstream. This patch fixes this build error with glibc < 2.6. CC util/cloexec.o cc1: warnings being treated as errors util/cloexec.c: In function ‘perf_flag_probe’: util/cloexec.c:24: error: implicit declaration of function ‘sched_getcpu’ util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’ make: *** [util/cloexec.o] Error 1 Signed-off-by: Vinson Lee Acked-by: Jiri Olsa Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Masami Hiramatsu Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Yann Droneaud Link: http://lkml.kernel.org/r/1427137761-16119-1-git-send-email-vlee@twopensource.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit eefadbaae8af748e25d6fb903b56c6d3e38215b8 Author: H.J. Lu Date: Tue Mar 17 15:27:48 2015 -0700 perf tools: Fix perf-read-vdsox32 not building and lib64 install dir commit 76aea7731e7050c066943a1d7456ec6510702601 upstream. Commit: c6e5e9fbc3ea ("perf tools: Fix building error in x86_64 when dwarf unwind is on") removed the definition of IS_X86_64 but not all places using it, with the consequence that perf-read-vdsox32 would not be built anymore, and the default lib install directory was 'lib' instead of 'lib64'. Also needs to go to v3.19. Signed-off-by: H.J. Lu Acked-by: Adrian Hunter Acked-by: Jiri Olsa Link: http://lkml.kernel.org/r/CAMe9rOqpGVq3D88w+D15ef7sv6G6k57ZeTvxBm46=WFgzo9p1w@mail.gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit b0566aa080d2ab7f5810f5bdea53c02dfc78ff16 Author: Vinson Lee Date: Mon Feb 9 16:29:37 2015 -0800 perf symbols: Define STT_GNU_IFUNC for glibc 2.9 and older. commit 4e31050f482c02c822b150d71cf1ea5be7c9d6e4 upstream. The token STT_GNU_IFUNC is not available with glibc 2.9 and older. Define this token if it is not already defined. This patch fixes this build errors with older versions of glibc. CC util/symbol-elf.o util/symbol-elf.c: In function ‘elf_sym__is_function’: util/symbol-elf.c:75: error: ‘STT_GNU_IFUNC’ undeclared (first use in this function) util/symbol-elf.c:75: error: (Each undeclared identifier is reported only once util/symbol-elf.c:75: error: for each function it appears in.) make: *** [util/symbol-elf.o] Error 1 Signed-off-by: Vinson Lee Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Anton Blanchard Cc: Avi Kivity Cc: Jiri Olsa Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Waiman Long Link: http://lkml.kernel.org/r/1423528286-13630-1-git-send-email-vlee@twopensource.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 85c75cd8131b5aa9fe4efc6400ae1d0631497720 Author: Jarkko Sakkinen Date: Wed Mar 18 08:17:14 2015 +0200 tpm: fix: sanitized code paths in tpm_chip_register() commit 34d47b6322087665be33ca3aa81775b143a4d7ac upstream. I started to work with PPI interface so that it would be available under character device sysfs directory and realized that chip registeration was still too messy. In TPM 1.x in some rare scenarios (errors that almost never occur) wrong order in deinitialization steps was taken in teardown. I reproduced these scenarios by manually inserting error codes in the place of the corresponding function calls. The key problem is that the teardown is messy with two separate code paths (this was inherited when moving code from tpm-interface.c). Moved TPM 1.x specific register/unregister functionality to own helper functions and added single code path for teardown in tpm_chip_register(). Now the code paths have been fixed and it should be easier to review later on this part of the code. Fixes: 7a1d7e6dd76a ("tpm: TPM 2.0 baseline support") Signed-off-by: Jarkko Sakkinen Tested-by: Scot Doyle Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 84b78514033ff22c443473214ab6d0508394cf7a Author: Eric W. Biederman Date: Wed Apr 1 18:30:06 2015 -0500 mnt: Update detach_mounts to leave mounts connected commit e0c9c0afd2fc958ffa34b697972721d81df8a56f upstream. Now that it is possible to lazily unmount an entire mount tree and leave the individual mounts connected to each other add a new flag UMOUNT_CONNECTED to umount_tree to force this behavior and use this flag in detach_mounts. This closes a bug where the deletion of a file or directory could trigger an unmount and reveal data under a mount point. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit c076cbf218f3cb83dffe6982587d2b9751318962 Author: Eric W. Biederman Date: Mon Jan 19 11:48:45 2015 -0600 mnt: Fix the error check in __detach_mounts commit f53e57975151f54ad8caa1b0ac8a78091cd5700a upstream. lookup_mountpoint can return either NULL or an error value. Update the test in __detach_mounts to test for an error value to avoid pathological cases causing a NULL pointer dereferences. The callers of __detach_mounts should prevent it from ever being called on an unlinked dentry but don't take any chances. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 20e62ee6fa3da23a792ca31d4b68069060317260 Author: Eric W. Biederman Date: Tue Dec 23 21:37:03 2014 -0600 mnt: Honor MNT_LOCKED when detaching mounts commit ce07d891a0891d3c0d0c2d73d577490486b809e1 upstream. Modify umount(MNT_DETACH) to keep mounts in the hash table that are locked to their parent mounts, when the parent is lazily unmounted. In mntput_no_expire detach the children from the hash table, depending on mnt_pin_kill in cleanup_mnt to decrement the mnt_count of the children. In __detach_mounts if there are any mounts that have been unmounted but still are on the list of mounts of a mountpoint, remove their children from the mount hash table and those children to the unmounted list so they won't linger potentially indefinitely waiting for their final mntput, now that the mounts serve no purpose. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 2db706971b3f28b3d59a9af231578803da85def8 Author: Eric W. Biederman Date: Thu Jan 15 22:58:33 2015 -0600 mnt: Factor umount_mnt from umount_tree commit 6a46c5735c29175da55b2fa9d53775182422cdd7 upstream. For future use factor out a function umount_mnt from umount_tree. This function unhashes a mount and remembers where the mount was mounted so that eventually when the code makes it to a sleeping context the mountpoint can be dput. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 92e35ac5954f9f7829ad88066930a4b2b58fe4dd Author: Eric W. Biederman Date: Mon Dec 29 13:03:41 2014 -0600 mnt: Factor out unhash_mnt from detach_mnt and umount_tree commit 7bdb11de8ee4f4ae195e2fa19efd304e0b36c63b upstream. Create a function unhash_mnt that contains the common code between detach_mnt and umount_tree, and use unhash_mnt in place of the common code. This add a unncessary list_del_init(mnt->mnt_child) into umount_tree but given that mnt_child is already empty this extra line is a noop. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 928116b22b1eb446c59a0fb93857d7a6d80930af Author: Eric W. Biederman Date: Mon Jan 5 13:38:04 2015 -0600 mnt: Don't propagate unmounts to locked mounts commit 0c56fe31420ca599c90240315f7959bf1b4eb6ce upstream. If the first mount in shared subtree is locked don't unmount the shared subtree. This is ensured by walking through the mounts parents before children and marking a mount as unmountable if it is not locked or it is locked but it's parent is marked. This allows recursive mount detach to propagate through a set of mounts when unmounting them would not reveal what is under any locked mount. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 397dd1fc1225b478824134ddd5540f889b13809d Author: Eric W. Biederman Date: Sat Jan 3 05:39:35 2015 -0600 mnt: On an unmount propagate clearing of MNT_LOCKED commit 5d88457eb5b86b475422dc882f089203faaeedb5 upstream. A prerequisite of calling umount_tree is that the point where the tree is mounted at is valid to unmount. If we are propagating the effect of the unmount clear MNT_LOCKED in every instance where the same filesystem is mounted on the same mountpoint in the mount tree, as we know (by virtue of the fact that umount_tree was called) that it is safe to reveal what is at that mountpoint. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 7a9742a65c02e30a62ae42c765eb4dff26b51cc9 Author: Eric W. Biederman Date: Mon Dec 22 19:12:07 2014 -0600 mnt: Delay removal from the mount hash. commit 411a938b5abc9cb126c41cccf5975ae464fe0f3e upstream. - Modify __lookup_mnt_hash_last to ignore mounts that have MNT_UMOUNTED set. - Don't remove mounts from the mount hash table in propogate_umount - Don't remove mounts from the mount hash table in umount_tree before the entire list of mounts to be umounted is selected. - Remove mounts from the mount hash table as the last thing that happens in the case where a mount has a parent in umount_tree. Mounts without parents are not hashed (by definition). This paves the way for delaying removal from the mount hash table even farther and fixing the MNT_LOCKED vs MNT_DETACH issue. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 7052e71b2d085f76800115d4a212dcaf82b86262 Author: Eric W. Biederman Date: Mon Dec 22 18:30:08 2014 -0600 mnt: Add MNT_UMOUNT flag commit 590ce4bcbfb4e0462a720a4ad901e84416080bba upstream. In some instances it is necessary to know if the the unmounting process has begun on a mount. Add MNT_UMOUNT to make that reliably testable. This fix gets used in fixing locked mounts in MNT_DETACH Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 953bab2cb35f8f6f2a0183c1b27ff7466f72bccc Author: Eric W. Biederman Date: Thu Dec 18 13:10:48 2014 -0600 mnt: In umount_tree reuse mnt_list instead of mnt_hash commit c003b26ff98ca04a180ff34c38c007a3998d62f9 upstream. umount_tree builds a list of mounts that need to be unmounted. Utilize mnt_list for this purpose instead of mnt_hash. This begins to allow keeping a mount on the mnt_hash after it is unmounted, which is necessary for a properly functioning MNT_LOCKED implementation. The fact that mnt_list is an ordinary list makding available list_move is nice bonus. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit a15f7b5e276d1b8f71d3d64d7f3f509e77bee5e4 Author: Eric W. Biederman Date: Wed Dec 24 07:35:10 2014 -0600 mnt: Don't propagate umounts in __detach_mounts commit 8318e667f176f7ea34451a1a530634e293f216ac upstream. Invoking mount propagation from __detach_mounts is inefficient and wrong. It is inefficient because __detach_mounts already walks the list of mounts that where something needs to be done, and mount propagation walks some subset of those mounts again. It is actively wrong because if the dentry that is passed to __detach_mounts is not part of the path to a mount that mount should not be affected. change_mnt_propagation(p,MS_PRIVATE) modifies the mount propagation tree of a master mount so it's slaves are connected to another master if possible. Which means even removing a mount from the middle of a mount tree with __detach_mounts will not deprive any mount propagated mount events. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 1527fbabfa4fdb32f66b47dd48518572fb4e0eaa Author: Eric W. Biederman Date: Wed Dec 24 07:20:01 2014 -0600 mnt: Improve the umount_tree flags commit e819f152104c9f7c9fe50e1aecce6f5d4bf06d65 upstream. - Remove the unneeded declaration from pnode.h - Mark umount_tree static as it has no callers outside of namespace.c - Define an enumeration of umount_tree's flags. - Pass umount_tree's flags in by name This removes the magic numbers 0, 1 and 2 making the code a little clearer and makes it possible for there to be lazy unmounts that don't propagate. Which is what __detach_mounts actually wants for example. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 3536e283ea6797daac8054aebea238cafe9a464c Author: Lukas Czerner Date: Fri Apr 3 10:46:58 2015 -0400 ext4: make fsync to sync parent dir in no-journal for real this time commit e12fb97222fc41e8442896934f76d39ef99b590a upstream. Previously commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c added a support for for syncing parent directory of newly created inodes to make sure that the inode is not lost after a power failure in no-journal mode. However this does not work in majority of cases, namely: - if the directory has inline data - if the directory is already indexed - if the directory already has at least one block and: - the new entry fits into it - or we've successfully converted it to indexed So in those cases we might lose the inode entirely even after fsync in the no-journal mode. This also includes ext2 default mode obviously. I've noticed this while running xfstest generic/321 and even though the test should fail (we need to run fsck after a crash in no-journal mode) I could not find a newly created entries even when if it was fsynced before. Fix this by adjusting the ext4_add_entry() successful exit paths to set the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the parent directory as well. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: Frank Mayhar Signed-off-by: Greg Kroah-Hartman commit a9fe1b9caf0ea4ccada73ce243b23fd6a7e896d3 Author: Marek Vasut Date: Thu Mar 26 02:16:06 2015 +0100 rtlwifi: rtl8192cu: Add new device ID commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 upstream. Add new ID for ASUS N10 WiFi dongle. Signed-off-by: Marek Vasut Tested-by: Marek Vasut Cc: Larry Finger Cc: John W. Linville Acked-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 9e2d43e521a469a50ef03b55cef24e7d260bbdbb Author: Larry Finger Date: Mon Mar 23 18:14:10 2015 -0500 rtlwifi: rtl8192cu: Add new USB ID commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream. USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 95df5a6b8698921ca30cd55853446016a2acb891 Author: Christophe Ricard Date: Tue Mar 31 08:02:15 2015 +0200 NFC: st21nfcb: Retry i2c_master_send if it returns a negative value commit d4a41d10b2cb5890aeda6b2912973b2a754b05b1 upstream. i2c_master_send may return many negative values different than -EREMOTEIO. In case an i2c transaction is NACK'ed, on raspberry pi B+ kernel 3.18, -EIO is generated instead. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 6181a6b2238de82fed39b0568645ea6a1ff2c6fd Author: Nicolas Ferre Date: Tue Mar 31 15:02:05 2015 +0200 net/macb: fix the peripheral version test commit 361918970b7426bba97a64678ef2b2679c37199b upstream. We currently need two checks of the peripheral version in MACB_MID register. One of them got out of sync after modification by 8a013a9c71b2 (net: macb: Include multi queue support for xilinx ZynqMP ethernet version). Fix this in macb_configure_caps() so that xilinx ZynqMP will be considered as a GEM flavor. Fixes: 8a013a9c71b2 ("net: macb: Include multi queue support for xilinx ZynqMP ethernet version") Signed-off-by: Nicolas Ferre Cc: Michal Simek Cc: Punnaiah Choudary Kalluri Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 64b22d90114136c3f66fef541c844bc2deb539c5 Author: Len Brown Date: Tue Mar 24 23:23:20 2015 -0400 intel_idle: Update support for Silvermont Core in Baytrail SOC commit d7ef76717322c8e2df7d4360b33faa9466cb1a0d upstream. On some Silvermont-Core/Baytrail-SOC systems, C1E latency is higher than original specifications. Although C1E is still enumerated in CPUID.MWAIT.EDX, we delete the state from intel_idle to avoid latency impact. Under some conditions, the latency of the C6N-BYT and C6S-BYT states may exceed the specified values of 40 and 140 usec, respectively. Increase those values to 300 and 500 usec; to assure that the hardware does not violate constraints that may be set by the Linux PM_QOS sub-system. Also increase the C7-BYT target residency to 4.0 ms from 1.5 ms. Signed-off-by: Len Brown Cc: Kumar P Mahesh Cc: Alan Cox Cc: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 12ea13bf83f15c5cf59b4039295f98b0d7a83881 Author: Oleg Nesterov Date: Thu Apr 16 12:47:29 2015 -0700 ptrace: fix race between ptrace_resume() and wait_task_stopped() commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream. ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include #include #include #include #include #include int pid; void *waiter(void *arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without 9899d11f6544 "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by: Oleg Nesterov Reported-by: Pavel Labath Tested-by: Pavel Labath Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 671ea8186b4d894fef503c13745152d9827d7a1b Author: Michael Davidson Date: Tue Apr 14 15:47:38 2015 -0700 fs/binfmt_elf.c: fix bug in loading of PIE binaries commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary. Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run). Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure. Fix this by calculating the total size of the binary in the same way as load_elf_interp(). Signed-off-by: Michael Davidson Cc: Alexander Viro Cc: Jiri Kosina Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9a7fcd609f2e3eaf2d661ee26ab7601e450cd7a2 Author: Johan Hovold Date: Wed Mar 25 12:07:05 2015 +0100 mfd: core: Fix platform-device name collisions commit a77c50b44cfb663ad03faba9800fec19bdf83577 upstream. Since commit 6e3f62f0793e ("mfd: core: Fix platform-device id generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when registering mfd-devices. Unfortunately, some mfd-drivers rely on the old behaviour of generating platform-device ids by adding the cell id also to the special value of PLATFORM_DEVID_NONE. The resulting platform ids are not only used to generate device-unique names, but are also used instead of the cell id to identify cells when probing subdevices. These drivers should be updated to use PLATFORM_DEVID_AUTO, which would also allow more than one device to be registered without resorting to hacks (see for example wm831x), but lets fix the regression first by partially reverting the above mentioned commit with respect to PLATFORM_DEVID_NONE. Fixes: 6e3f62f0793e ("mfd: core: Fix platform-device id generation") Reported-by: Bartlomiej Zolnierkiewicz Signed-off-by: Johan Hovold Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 93ab611572eae4cb426cf006c70a7c7216603cfe Author: Hans de Goede Date: Wed Apr 8 09:26:42 2015 -0700 Input: alps - fix touchpad buttons getting stuck when used with trackpoint commit 6bcca19f5dcedc3a006ca0bcc3699a437cadee74 upstream. When the left touchpad button gets pressed, and then the trackpoint is moved, and then the button is released, the following happens: 1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1 2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in this packet because when the trackstick is active it communicates the combined touchpad + pointing stick buttons in the trackstick packet, since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter to alps_report_buttons the combining is not detected and the pointing stick evdev node will also report BTN_LEFT 1 3) on release of the button a pointing stick packet with BTN_LEFT 0 is received and the pointing stick evdev node will report BTN_LEFT 0 Note how because of the passing as NULL for dev2 the touchpad evdev node will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button. This is a regression in 4.0 introduced by commit 04aae283ba6a8 ("Input: ALPS - do not mix trackstick and external PS/2 mouse data") This commit fixes this by passing in the touchpad evdev as dev2 parameter when calling alps_report_buttons for the pointingstick on alps v2 devices, so that alps_report_buttons correctly detect that we're already reporting the button as pressed via the touchpad evdev node, and will also send the release event there. Reported-by: Hans de Bruin Signed-off-by: Hans de Goede Acked-by: Pali Rohár Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 53c20b74579ec9bb7b45b2208fce79df09e8bdfb Author: Ulrik De Bie Date: Mon Apr 6 15:35:38 2015 -0700 Input: elantech - fix absolute mode setting on some ASUS laptops commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream. On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ca7d80c841febeb3688d5ed57660d37b4baedad5 Author: Hui Wang Date: Fri Apr 24 13:39:59 2015 +0800 ALSA: hda - fix headset mic detection problem for one more machine commit e8191a8e475551b277d85cd76c3f0f52fdf42e86 upstream. We have two machines with alc256 codec in the pin quirk table, so moving the common pins to ALC256_STANDARD_PINS. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447909 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c7a98726965179726bbd105e5ff6465c1d09ace1 Author: Kailang Yang Date: Thu Apr 23 15:10:53 2015 +0800 ALSA: hda/realtek - Fix Headphone Mic doesn't recording for ALC256 commit d32b66668c702aed0e330dc5ca186afbadcdacf8 upstream. Switch default pcbeep path to Line in path. Signed-off-by: Kailang Yang Tested-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cb927a0ae496171966921e084eb7f6c2dc04e43b Author: David Henningsson Date: Tue Apr 21 10:48:46 2015 +0200 ALSA: hda - fix "num_steps = 0" error on ALC256 commit 7d1b6e29327428993ba568bdd8c66734070f45e0 upstream. The ALC256 does not have a mixer nid at 0x0b, and there's no loopback path (the output pins are directly connected to the DACs). This commit fixes an "num_steps = 0 for NID=0xb (ctl = Beep Playback Volume)" error (and as a result, problems with amixer/alsamixer). If there's pcbeep functionality, it certainly isn't controlled by setting an amp on 0x0b, so disable beep functionality (at least for now). BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1446517 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0933e9dd839f4d37d408d9365266940928a73a8c Author: Jo-Philipp Wich Date: Mon Apr 13 12:47:26 2015 +0200 ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T450 commit f2aa111041ce36b94e651d882458dea502e76721 upstream. The Lenovo Thinkpad T450 requires the ALC292_FIXUP_TPT440_DOCK as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T450 (20BVCTO1WW) using kernel 4.0-rc7 in conjunction with a ThinkPad Ultradock. Signed-off-by: Jo-Philipp Wich Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 15c97265c67f27eef7d92262964a43e0aff8df61 Author: Michael Gernoth Date: Thu Apr 9 23:42:15 2015 +0200 ALSA: emu10k1: don't deadlock in proc-functions commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream. The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock. Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock. [removed superfluous flags variables too -- tiwai] Signed-off-by: Michael Gernoth Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0b586ed327f10ed037bf84381cbdb16754d7bdfd Author: Adam Honse Date: Sun Apr 12 01:03:07 2015 -0500 ALSA: usb-audio: Don't attempt to get Microsoft Lifecam Cinema sample rate commit eef0342cf32689f77d78ee3302999e5caaa6a8f3 upstream. Adds Microsoft LifeCam Cinema USB ID to the snd_usb_get_sample_rate_quirk list as the Lifecam Cinema does not appear to support getting the sample rate. Fixes the issue where the LifeCam Cinema would wait for USB timeout and log the message "cannot get freq at ep 0x82" when accessed. Addresses bug report https://bugzilla.kernel.org/show_bug.cgi?id=95961. Signed-off-by: Adam Honse Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ffa5893889612e5d65e456c0b433d0160d46c4eb Author: Yves-Alexis Perez Date: Sat Apr 11 09:31:35 2015 +0200 ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226) commit c0278669fb61596cc1a10ab8686d27c37269c37b upstream. This model uses the same dock port as the previous generation. Signed-off-by: Yves-Alexis Perez Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f5a652339c3ff18b6184d0ee02f7f0eef2ebe681 Author: Boris Brezillon Date: Sun Mar 29 03:45:33 2015 +0200 clk: at91: usb: propagate rate modification to the parent clk commit 4591243102faa8de92da320edea47219901461e9 upstream. The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate modification requests to their parents. This causes a bug when the PLLB is left uninitialized by the bootloader (PLL multiplier set to 0, or in other words, PLL rate = 0 Hz). Implement the determinate_rate method and propagate the change rate request to the parent clk. Signed-off-by: Boris Brezillon Reported-by: Bo Shen Tested-by: Bo Shen Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 1eeba7304a3e8070983c3a9f757a6b51236a64de Author: Felipe Balbi Date: Fri Feb 13 15:38:33 2015 -0600 usb: core: hub: use new USB_RESUME_TIMEOUT commit bbc78c07a51f6fd29c227b1220a9016e585358ba upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit b6053a1546ea879b47c346628cf40401bcf9e27e Author: Felipe Balbi Date: Fri Feb 13 15:04:06 2015 -0600 usb: isp1760: hcd: use new USB_RESUME_TIMEOUT commit 59c9904cce77b55892e15f40791f1e66e4d3a1e6 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 8271acf33346951d281a428ae8a40f20750e789f Author: Felipe Balbi Date: Fri Feb 13 15:03:13 2015 -0600 usb: dwc2: hcd: use new USB_RESUME_TIMEOUT commit 74bd7b69801819707713b88e9d0bc074efa2f5e7 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 6a0ecbeea7d077ae4e49c3a1ef03a38bb91c5218 Author: Felipe Balbi Date: Fri Feb 13 15:00:38 2015 -0600 usb: host: sl811: use new USB_RESUME_TIMEOUT commit 08debfb13b199716da6153940c31968c556b195d upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 426c93ea979c24f4f011351af58d5f5319514493 Author: Felipe Balbi Date: Fri Feb 13 14:42:25 2015 -0600 usb: host: ehci: use new USB_RESUME_TIMEOUT commit ea16328f80ca8d74434352157f37ef60e2f55ce2 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 9a0a677ad3526bf0914aecab14423c761e5af9e7 Author: Felipe Balbi Date: Fri Feb 13 14:39:13 2015 -0600 usb: host: xhci: use new USB_RESUME_TIMEOUT commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Acked-by: Mathias Nyman Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 34f698795e94955800a8ba8acdea4a725211a20a Author: Felipe Balbi Date: Fri Feb 13 14:50:10 2015 -0600 usb: host: isp116x: use new USB_RESUME_TIMEOUT commit 8c0ae6574ccfd3d619876a65829aad74c9d22ba5 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 14c69a53b6c0640d94796b04762ed943e9cf3918 Author: Felipe Balbi Date: Fri Feb 13 14:58:53 2015 -0600 usb: host: r8a66597: use new USB_RESUME_TIMEOUT commit 7a606ac29752a3e571b83f9b3fceb1eaa1d37781 upstream. While this driver was already using a 50ms resume timeout, let's make sure everybody uses the same macro so it's easy to fix later should anything go wrong. It also gives a more "stable" expectation to Linux users. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit fb4655758ba685c5aa07b9af45b18895e3df2a26 Author: Felipe Balbi Date: Fri Feb 13 14:54:38 2015 -0600 usb: host: fotg210: use new USB_RESUME_TIMEOUT commit 7e136bb71a08e8b8be3bc492f041d9b0bea3856d upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c8d7235af46783ee3e312ea5c877ac73de8c435d Author: Felipe Balbi Date: Fri Feb 13 14:44:17 2015 -0600 usb: host: uhci: use new USB_RESUME_TIMEOUT commit b8fb6f79f76f478acbbffccc966daa878f172a0a upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 9aeb024dc65fa1c9520c655a36d52d48e4285ab1 Author: Felipe Balbi Date: Fri Feb 13 14:55:34 2015 -0600 usb: host: fusbh200: use new USB_RESUME_TIMEOUT commit 595227db1f2d98bfc33f02a55842f268e12b247d upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 0e33853a595e4947e416e86c966a2f532084b3ae Author: Felipe Balbi Date: Fri Feb 13 14:57:54 2015 -0600 usb: host: oxu210hp: use new USB_RESUME_TIMEOUT commit 84c0d178eb9f3a3ae4d63dc97a440266cf17f7f5 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 913916432e9f24d403a51dae54b905b07e509dd9 Author: Felipe Balbi Date: Fri Feb 13 14:46:27 2015 -0600 usb: musb: use new USB_RESUME_TIMEOUT commit 309be239369609929d5d3833ee043f7c5afc95d1 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Based on original work by Bin Liu > Cc: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c3f787950225dc61f2a4342601d78d1052d0f8ef Author: Felipe Balbi Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro commit 62f0342de1f012f3e90607d39e20fce811391169 upstream. Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Acked-by: Greg Kroah-Hartman Acked-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 968986cb57477f487045baa184eee0cf7a82b2e3 Author: Axel Lin Date: Thu Mar 12 09:15:28 2015 +0800 usb: phy: Find the right match in devm_usb_phy_match commit 869aee0f31429fa9d94d5aef539602b73ae0cf4b upstream. The res parameter passed to devm_usb_phy_match() is the location where the pointer to the usb_phy is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Fixes: 410219dcd2ba ("usb: otg: utils: devres: Add API's to associate a device with the phy") Signed-off-by: Axel Lin Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 55db0145ac65aec05c736cddb3a6717b83619d7e Author: Felipe Balbi Date: Mon Dec 30 12:33:53 2013 -0600 usb: musb: core: fix TX/RX endpoint order commit e3c93e1a3f35be4cf1493d3ccfb0c6d9209e4922 upstream. As per Mentor Graphics' documentation, we should always handle TX endpoints before RX endpoints. This patch fixes that error while also updating some hard-to-read comments which were scattered around musb_interrupt(). This patch should be backported as far back as possible since this error has been in the driver since it's conception. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 422be9a5e09ea7d6e84ad2c3d05dfdf01e4a7a3f Author: Andreas Faerber Date: Wed Mar 18 01:25:18 2015 +0900 ARM: dts: fix mmc node updates for exynos5250-spring commit 7e9e20b1faab02357501553d7f4e3efec1b4cfd3 upstream. Resolve a merge conflict with mmc refactoring aaa25a5a33cb ("ARM: dts: unuse the slot-node and deprecate the supports-highspeed for dw-mmc in exynos") by dropping the slot@0 nodes, moving its bus-width property to the mmc node and replacing supports-highspeed with cap-{mmc,sd}-highspeed, matching exynos5250-snow. Cc: Jaehoon Chung Fixes: 53dd4138bb0a ("ARM: dts: Add exynos5250-spring device tree") Signed-off-by: Andreas Faerber Reviewed-by: Javier Martinez Canillas Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit 5b126c3890f31b1b0e2bbfd94aace90169664e69 Author: Sebastian Hesselbarth Date: Tue Feb 17 19:52:04 2015 +0100 ARM: dts: dove: Fix uart[23] reg property commit a74cd13b807029397f7232449df929bac11fb228 upstream. Fix Dove's register addresses of uart2 and uart3 nodes that seem to be broken since ages due to a copy-and-paste error. Signed-off-by: Sebastian Hesselbarth Acked-by: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 64d90ab58af7a385a7955061e0a319f7f939ddff Author: Nicolas Ferre Date: Tue Mar 31 10:56:10 2015 +0200 ARM: at91/dt: sama5d3 xplained: add phy address for macb1 commit 98b80987c940956da48f0c703f60340128bb8521 upstream. After 57a38effa598 (net: phy: micrel: disable broadcast for KSZ8081/KSZ8091) the macb1 interface refuses to work properly because it tries to cling to address 0 which isn't able to communicate in broadcast with the mac anymore. The micrel phy on the board is actually configured to show up at address 1. Adding the phy node and its real address fixes the issue. Signed-off-by: Nicolas Ferre Cc: Johan Hovold Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 3c9d536953582615eb9054c38a5e4de6c711ccb5 Author: Charles Keepax Date: Fri Mar 27 01:58:08 2015 +0900 ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore commit 4e330ae4ab2915444f1e6dca1358a910aa259362 upstream. There are two PMICs on Cragganmore, currently one dynamically assign its IRQ base and the other uses a fixed base. It is possible for the statically assigned PMIC to fail if its IRQ is taken by the dynamically assigned one. Fix this by statically assigning both the IRQ bases. Signed-off-by: Charles Keepax Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit 6ec6b63f4e9d59f78b61944f8c533d9ff029f46f Author: Gregory CLEMENT Date: Fri Jan 30 12:34:25 2015 +0100 ARM: mvebu: Disable CPU Idle on Armada 38x commit 548ae94c1cc7fc120848757249b9a542b1080ffb upstream. On Armada 38x SoCs, under heavy I/O load, the system hangs when CPU Idle is enabled. Waiting for a solution to this issue, this patch disables the CPU Idle support for this SoC. As CPU Hot plug support also uses some of the CPU Idle functions it is also affected by the same issue. This patch disables it also for the Armada 38x SoCs. Signed-off-by: Gregory CLEMENT Tested-by: Thomas Petazzoni Signed-off-by: Greg Kroah-Hartman commit c5528d2a0edcbbc3ceba739ec70133e2594486c4 Author: Andrey Ryabinin Date: Fri Mar 20 15:42:27 2015 +0100 ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream. Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel split this is not so, because 2*TASK_SIZE overflows 32 bits, so the actual value of ELF_ET_DYN_BASE is: (2 * TASK_SIZE / 3) = 0x2a000000 When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address. On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000] for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled as it fails to map shadow memory. Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries has a high chance of loading somewhere in between [0x2a000000 - 0x40000000] even if ASLR enabled. This makes ASan with PIE absolutely incompatible. Fix overflow by dividing TASK_SIZE prior to multiplying. After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y): (TASK_SIZE / 3 * 2) = 0x7f555554 [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping Signed-off-by: Andrey Ryabinin Reported-by: Maria Guseva Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 46d09e1c86167373dcb343cfd6c901c78624ff01 Author: Russell King Date: Wed Apr 1 16:20:39 2015 +0100 ARM: fix broken hibernation commit 767bf7e7a1e82a81c59778348d156993d0a6175d upstream. Normally, when a CPU wants to clear a cache line to zero in the external L2 cache, it would generate bus cycles to write each word as it would do with any other data access. However, a Cortex A9 connected to a L2C-310 has a specific feature where the CPU can detect this operation, and signal that it wants to zero an entire cache line. This feature, known as Full Line of Zeros (FLZ), involves a non-standard AXI signalling mechanism which only the L2C-310 can properly interpret. There are separate enable bits in both the L2C-310 and the Cortex A9 - the L2C-310 needs to be enabled and have the FLZ enable bit set in the auxiliary control register before the Cortex A9 has this feature enabled. Unfortunately, the suspend code was not respecting this - it's not obvious from the code: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register */ arch_save_image() soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */ cpu_resume() /* restores the Cortex A9 registers, inc auxcr */ At this point, we end up with the L2C disabled, but the Cortex A9 with FLZ enabled - which means any memset() or zeroing of a full cache line will fail to take effect. A similar issue exists in the resume path, but it's slightly more complex: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register */ arch_save_image() /* image with A9 auxcr saved */ ... swsusp_arch_resume() call_with_stack() arch_restore_image() /* restores image with A9 auxcr saved above */ soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */ cpu_resume() /* restores the Cortex A9 registers, inc auxcr */ Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled. There's no need to turn off the L2C in either of these two paths; there are benefits from not doing so - for example, the page copies will be faster with the L2C enabled. Hence, fix this by providing a variant of soft_restart() which can be used without turning the L2 cache controller off, and use it in both of these paths to keep the L2C enabled across the respective resume transitions. Fixes: 8ef418c7178f ("ARM: l2c: trial at enabling some Cortex-A9 optimisations") Reported-by: Sean Cross Tested-by: Sean Cross Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 3bc3783ea692a04256e2cf027bfd98bf7b8d82a6 Author: Andrew Elble Date: Mon Feb 23 08:51:24 2015 -0500 NFS: fix BUG() crash in notify_change() with patch to chown_common() commit c1b8940b42bb6487b10f2267a96b486276ce9ff7 upstream. We have observed a BUG() crash in fs/attr.c:notify_change(). The crash occurs during an rsync into a filesystem that is exported via NFS. 1.) fs/attr.c:notify_change() modifies the caller's version of attr. 2.) 6de0ec00ba8d ("VFS: make notify_change pass ATTR_KILL_S*ID to setattr operations") introduced a BUG() restriction such that "no function will ever call notify_change() with both ATTR_MODE and ATTR_KILL_S*ID set". Under some circumstances though, it will have assisted in setting the caller's version of attr to this very combination. 3.) 27ac0ffeac80 ("locks: break delegations on any attribute modification") introduced code to handle breaking delegations. This can result in notify_change() being re-called. attr _must_ be explicitly reset to avoid triggering the BUG() established in #2. 4.) The path that that triggers this is via fs/open.c:chmod_common(). The combination of attr flags set here and in the first call to notify_change() along with a later failed break_deleg_wait() results in notify_change() being called again via retry_deleg without resetting attr. Solution is to move retry_deleg in chmod_common() a bit further up to ensure attr is completely reset. There are other places where this seemingly could occur, such as fs/utimes.c:utimes_common(), but the attr flags are not initially set in such a way to trigger this. Fixes: 27ac0ffeac80 ("locks: break delegations on any attribute modification") Reported-by: Eric Meddaugh Tested-by: Eric Meddaugh Signed-off-by: Andrew Elble Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 66997b1d6c47e793556da41877262f5ac92e8d4d Author: Oliver Neukum Date: Wed Mar 25 15:38:31 2015 +0100 HID: add quirk for PIXART OEM mouse used by HP commit b70b82580248b5393241c986082842ec05a2b7d7 upstream. This mouse is also known under other IDs. It needs the quirk or will disconnect in runlevel 1 or 3. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4fc2e2c56db0c05c62444ed7bc8d285704155386 Author: Oliver Neukum Date: Wed Mar 25 15:13:36 2015 +0100 HID: add HP OEM mouse to quirk ALWAYS_POLL commit 7a8e53c414c8183e8735e3b08d9a776200e6e665 upstream. This mouse needs QUIRK_ALWAYS_POLL. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 640e9bd83b3a3bc313eb0ade22effbab5c135a76 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:24 2015 +0100 power_supply: ipaq_micro_battery: Check return values in probe commit a2c1d531854c4319610f1d83351213b47a633969 upstream. The return values of create_singlethread_workqueue() and power_supply_register() calls were not checked and even on error probe() function returned 0. 1. If allocation of workqueue failed (returning NULL) then further accesses could lead to NULL pointer dereference. The queue_delayed_work() expects workqueue to be non-NULL. 2. If registration of power supply failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by: Krzysztof Kozlowski Fixes: 00a588f9d27f ("power: add driver for battery reading on iPaq h3xxx") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit a8cb866f5168eaec313528f7059b0025b859cccf Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:23 2015 +0100 power_supply: ipaq_micro_battery: Fix leaking workqueue commit f852ec461e24504690445e7d281cbe806df5ccef upstream. Driver allocates singlethread workqueue in probe but it is not destroyed during removal. Signed-off-by: Krzysztof Kozlowski Fixes: 00a588f9d27f ("power: add driver for battery reading on iPaq h3xxx") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit e7b8d14c9be1ddb14796569a636807647e30724c Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:25 2015 +0100 power_supply: lp8788-charger: Fix leaked power supply on probe fail commit a7117f81e8391e035c49b3440792f7e6cea28173 upstream. Driver forgot to unregister charger power supply if registering of battery supply failed in probe(). In such case the memory associated with power supply leaked. Signed-off-by: Krzysztof Kozlowski Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 85020c092b437aaceec966678ec5fd9f7792b547 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:22 2015 +0100 power_supply: twl4030_madc: Check return value of power_supply_register commit 68c3ed6fa7e0d69529ced772d650ab128916a81d upstream. The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by: Krzysztof Kozlowski Fixes: da0a00ebc239 ("power: Add twl4030_madc battery driver.") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 676ee802b67bf6ea0287ab5b25ae3f551cf27f74 Author: Steven Rostedt Date: Tue Mar 17 10:40:38 2015 -0400 ring-buffer: Replace this_cpu_*() with __this_cpu_*() commit 80a9b64e2c156b6523e7a01f2ba6e5d86e722814 upstream. It has come to my attention that this_cpu_read/write are horrible on architectures other than x86. Worse yet, they actually disable preemption or interrupts! This caused some unexpected tracing results on ARM. 101.356868: preempt_count_add <-ring_buffer_lock_reserve 101.356870: preempt_count_sub <-ring_buffer_lock_reserve The ring_buffer_lock_reserve has recursion protection that requires accessing a per cpu variable. But since preempt_disable() is traced, it too got traced while accessing the variable that is suppose to prevent recursion like this. The generic version of this_cpu_read() and write() are: #define this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = *this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \ }) #define this_cpu_generic_to_op(pcp, val, op) \ do { \ unsigned long flags; \ raw_local_irq_save(flags); \ *__this_cpu_ptr(&(pcp)) op val; \ raw_local_irq_restore(flags); \ } while (0) Which is unacceptable for locations that know they are within preempt disabled or interrupt disabled locations. Paul McKenney stated that __this_cpu_() versions produce much better code on other architectures than this_cpu_() does, if we know that the call is done in a preempt disabled location. I also changed the recursive_unlock() to use two local variables instead of accessing the per_cpu variable twice. Link: http://lkml.kernel.org/r/20150317114411.GE3589@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/20150317104038.312e73d1@gandalf.local.home Acked-by: Christoph Lameter Reported-by: Uwe Kleine-Koenig Tested-by: Uwe Kleine-Koenig Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7d91365ba6ce7256b1afb1197aecf3dd0dca6e65 Author: Krzysztof Kozlowski Date: Thu Mar 12 08:44:00 2015 +0100 compal-laptop: Check return value of power_supply_register commit 1915a718b1872edffcb13e5436a9f7302d3d36f0 upstream. The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Fix this by checking return status of power_supply_register() call. In case of failure, clean up sysfs entries and fail the probe. Signed-off-by: Krzysztof Kozlowski Fixes: 9be0fcb5ed46 ("compal-laptop: add JHL90, battery & hwmon interface") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 855715fa0e283d4ff8280c79ac2c531116bc3290 Author: Krzysztof Kozlowski Date: Thu Mar 12 08:43:59 2015 +0100 compal-laptop: Fix leaking hwmon device commit ad774702f1705c04e5fa492b793d8d477a504fa6 upstream. The commit c2be45f09bb0 ("compal-laptop: Use devm_hwmon_device_register_with_groups") wanted to change the registering of hwmon device to resource-managed version. It mostly did it except the main thing - it forgot to use devm-like function so the hwmon device leaked after device removal or probe failure. Signed-off-by: Krzysztof Kozlowski Fixes: c2be45f09bb0 ("compal-laptop: Use devm_hwmon_device_register_with_groups") Acked-by: Guenter Roeck Acked-by: Darren Hart Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 721669bff3eaa852476783845293dca50431ce5b Author: Ian Abbott Date: Mon Mar 23 17:50:27 2015 +0000 spi: spidev: fix possible arithmetic overflow for multi-transfer message commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream. `spidev_message()` sums the lengths of the individual SPI transfers to determine the overall SPI message length. It restricts the total length, returning an error if too long, but it does not check for arithmetic overflow. For example, if the SPI message consisted of two transfers and the first has a length of 10 and the second has a length of (__u32)(-1), the total length would be seen as 9, even though the second transfer is actually very long. If the second transfer specifies a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could overrun the spidev's pre-allocated tx buffer before it reaches an invalid user memory address. Fix it by checking that neither the total nor the individual transfer lengths exceed the maximum allowed value. Thanks to Dan Carpenter for reporting the potential integer overflow. Signed-off-by: Ian Abbott Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 662552a3bf88447e8985bdad78fc7e548487416b Author: Lucas Stach Date: Wed Apr 1 10:46:15 2015 +0200 spi: imx: read back the RX/TX watermark levels earlier commit f511ab09dfb0fe7b2335eccac51ff9f001a32e4a upstream. They are used to decide if the controller can do DMA on a buffer of a specific length and thus are needed before any transfer is attempted. This fixes a memory leak where the SPI core uses the drivers can_dma() callback to determine if a buffer needs to be mapped. As the watermark levels aren't correct at that point the driver falsely claims to be able to DMA the buffer when it fact it isn't. After the transfer has been done the core uses the same callback to determine if it needs to unmap the buffers. As the driver now correctly claims to not being able to DMA the buffer the core doesn't attempt to unmap the buffer which leaves the SGT leaking. Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support) Signed-off-by: Lucas Stach Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 85895968a9444e810f96cc951c6b5fc7dd183296 Author: Chen-Yu Tsai Date: Tue Mar 3 09:44:40 2015 +0800 mmc: sunxi: Use devm_reset_control_get_optional() for reset control commit 9e71c589e44ddf2b86f361c81e360c6b0d0354b1 upstream. The reset control for the sunxi mmc controller is optional. Some newer platforms (sun6i, sun8i, sun9i) have it, while older ones (sun4i, sun5i, sun7i) don't. Use the properly stubbed _optional version so the driver does not fail to compile when RESET_CONTROLLER=n. This patch also adds a check for deferred probing on the reset control. Signed-off-by: Chen-Yu Tsai Acked-by: David Lanzendörfer Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7df0c5a403d2e9a1698a6ebdcf6e37a0639aad85 Author: Geert Uytterhoeven Date: Wed Feb 18 17:34:59 2015 +0100 mmc: tmio: Remove bogus un-initialization in tmio_mmc_host_free() commit 13a6a2ed1f5e77ae47c2b1a8e3bf22b2fa2d56ba upstream. If CONFIG_DEBUG_SLAB=y: sh_mobile_sdhi ee100000.sd: Got CD GPIO sh_mobile_sdhi ee100000.sd: Got WP GPIO platform ee100000.sd: Driver sh_mobile_sdhi requests probe deferral ... Slab corruption (Not tainted): kmalloc-1024 start=ed8b3c00, len=1024 2d0: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk Prev obj: start=ed8b3800, len=1024 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Struct tmio_mmc_host is embedded inside struct mmc_host, and thus is freed by the call to mmc_free_host(). Hence it must not be written to afterwards, as that will corrupt freed (and perhaps already reused) memory. Fixes: 94b110aff8679b14 ("mmc: tmio: add tmio_mmc_host_alloc/free()") Signed-off-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 766f84104c3a294da5c4f1660589b3d167c5b1c6 Author: Oliver Neukum Date: Fri Mar 20 14:29:34 2015 +0100 cdc-wdm: fix endianness bug in debug statements commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 upstream. Values directly from descriptors given in debug statements must be converted to native endianness. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit e654ded279c44285d07a31fe6d6c6fb74a9b5465 Author: Sudeep Holla Date: Tue Mar 17 17:28:46 2015 +0000 drivers/base: cacheinfo: validate device node for all the caches commit 8a7d95f95c95f396decbd4cda6d4903fc4664946 upstream. On architectures that depend on DT for obtaining cache hierarcy, we need to validate the device node for all the cache indices, failing to do so might result in wrong information being exposed to the userspace. This is quite possible on initial/incomplete versions of the device trees. In such cases, it's better to bail out if all the required device nodes are not present. This patch adds checks for the validation of device node for all the caches and doesn't initialise the cacheinfo if there's any error. Reported-by: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit a3ec48fa3f64ea293bfe691a02c17c0a7d2887e1 Author: Christoph Hellwig Date: Wed Apr 15 09:44:37 2015 -0700 megaraid_sas: use raw_smp_processor_id() commit 16b8528d20607925899b1df93bfd8fbab98d267c upstream. We only want to steer the I/O completion towards a queue, but don't actually access any per-CPU data, so the raw_ version is fine to use and avoids the warnings when using smp_processor_id(). Signed-off-by: Christoph Hellwig Reported-by: Andy Lutomirski Tested-by: Andy Lutomirski Acked-by: Sumit Saxena Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a89d16cbd3a2838b54e404d7f8dd0af60667fa21 Author: NeilBrown Date: Fri Apr 10 13:19:04 2015 +1000 md/raid0: fix bug with chunksize not a power of 2. commit 47d68979cc968535cb87f3e5f2e6a3533ea48fbd upstream. Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 in v3.14-rc1 RAID0 has performed incorrect calculations when the chunksize is not a power of 2. This happens because "sector_div()" modifies its first argument, but this wasn't taken into account in the patch. So restore that first arg before re-using the variable. Reported-by: Joe Landman Reported-by: Dave Chinner Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit c373916a7434a49607ece05dbf0f60c697ad7291 Author: Malcolm Priestley Date: Wed Apr 1 22:32:52 2015 +0100 staging: vt6655: use ieee80211_tx_info to select packet type. commit a6388e68321a1e0a0f408379c2a36396807745b3 upstream. Information for packet type is in ieee80211_tx_info band IEEE80211_BAND_5GHZ for PK_TYPE_11A. IEEE80211_TX_RC_USE_CTS_PROTECT via tx_rate flags selects PK_TYPE_11GB This ensures that the packet is always the right type. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit da01c0cfb196bef048fcb16727d646138d257ce3 Author: Alistair Strachan Date: Tue Mar 24 14:51:31 2015 -0700 staging: android: sync: Fix memory corruption in sync_timeline_signal(). commit 8e43c9c75faf2902955bd2ecd7a50a8cc41cb00a upstream. The android_fence_release() function checks for active sync points by calling list_empty() on the list head embedded on the sync point. However, it is only valid to use list_empty() on nodes that have been initialized with INIT_LIST_HEAD() or list_del_init(). Because the list entry has likely been removed from the active list by sync_timeline_signal(), there is a good chance that this WARN_ON_ONCE() will be hit due to dangling pointers pointing at freed memory (even though the sync drivers did nothing wrong) and memory corruption will ensue as the list entry is removed for a second time, corrupting the active list. This problem can be reproduced quite easily with CONFIG_DEBUG_LIST=y and fences with more than one sync point. Signed-off-by: Alistair Strachan Cc: Maarten Lankhorst Cc: Greg Kroah-Hartman Cc: Colin Cross Signed-off-by: Greg Kroah-Hartman commit f0ce3bf7fa069f614101c819576cb0344076e95c Author: Sudip Mukherjee Date: Tue Mar 24 16:29:32 2015 +0530 staging: panel: fix lcd type commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream. the lcd type as defined in the Kconfig is not matching in the code. as a result the rs, rw and en pins were getting interchanged. Kconfig defines the value of PANEL_LCD to be 1 if we select custom configuration but in the code LCD_TYPE_CUSTOM is defined as 5. my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it as pins of LCD_TYPE_OLD, and it was not working. Now values are corrected with referenece to the values defined in Kconfig and it is working. checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration. Signed-off-by: Sudip Mukherjee Acked-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit 6fbe5c7cd4d50582ba22c0a979131e347ec7b132 Author: Huacai Chen Date: Sun Mar 29 10:54:05 2015 +0800 MIPS: Hibernate: flush TLB entries earlier commit a843d00d038b11267279e3b5388222320f9ddc1d upstream. We found that TLB mismatch not only happens after kernel resume, but also happens during snapshot restore. So move it to the beginning of swsusp_arch_suspend(). Signed-off-by: Huacai Chen Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/9621/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 9da8705189d48b9d74724d5ae37c5a3a486fcfef Author: Huacai Chen Date: Thu Mar 12 11:51:06 2015 +0800 MIPS: Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction commit 0add9c2f1cff9f3f1f2eb7e9babefa872a9d14b9 upstream. HPET irq is routed to i8259 and then to MIPS CPU irq (cascade). After commit a3e6c1eff5 (MIPS: IRQ: Fix disable_irq on CPU IRQs), if without IRQF_NO_SUSPEND in cascade_irqaction, HPET interrupts will lost during suspend. The result is machine cannot be waken up. Signed-off-by: Huacai Chen Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/9528/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit e239cb24f08477d187a5bb831088de60f70e3ade Author: Markos Chandras Date: Mon Mar 9 14:54:52 2015 +0000 MIPS: unaligned: Fix regular load/store instruction emulation for EVA commit 6eae35485b26f9e51ab896eb8a936bed9908fdf6 upstream. When emulating a regular lh/lw/lhu/sh/sw we need to use the appropriate instruction if we are in EVA mode. This is necessary for userspace applications which trigger alignment exceptions. In such case, the userspace load/store instruction needs to be emulated with the correct eva/non-eva instruction by the kernel emulator. Signed-off-by: Markos Chandras Fixes: c1771216ab48 ("MIPS: kernel: unaligned: Handle unaligned accesses for EVA") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9503/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit ae0a145ca5b6c135e068a08f859e3f10ad2242d9 Author: Markos Chandras Date: Mon Mar 9 14:54:51 2015 +0000 MIPS: unaligned: Surround load/store macros in do {} while statements commit 3563c32d6532ece53c9dd8905a8e41983ef9952f upstream. It's best to surround such complex macros with do {} while statements so they can appear as independent logical blocks when used within other control blocks. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9502/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 88a82d60a26013483a22b19035517fec54b7dee5 Author: Markos Chandras Date: Mon Mar 9 14:54:50 2015 +0000 MIPS: unaligned: Prevent EVA instructions on kernel unaligned accesses commit eeb538950367e3966cbf0237ab1a1dc30e059818 upstream. Commit c1771216ab48 ("MIPS: kernel: unaligned: Handle unaligned accesses for EVA") allowed unaligned accesses to be emulated for EVA. However, when emulating regular load/store unaligned accesses, we need to use the appropriate "address space" instructions for that. Previously, an unaligned load/store instruction in kernel space would have used the corresponding EVA instructions to emulate it which led to segmentation faults because of the address translation that happens with EVA instructions. This is now fixed by using the EVA instruction only when emulating EVA unaligned accesses. Signed-off-by: Markos Chandras Fixes: c1771216ab48 ("MIPS: kernel: unaligned: Handle unaligned accesses for EVA") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9501/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit e52a20fcbf2ae06dc538b953c065bd6ae0b5f4ad Author: Markos Chandras Date: Mon Mar 9 14:54:49 2015 +0000 MIPS: asm: asm-eva: Introduce kernel load/store variants commit 60cd7e08e453bc6828ac4b539f949e4acd80f143 upstream. Introduce new macros for kernel load/store variants which will be used to perform regular kernel space load/store operations in EVA mode. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9500/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 0668432d35a9e96ee500cbe1b3f7df6c4fe29b09 Author: Markos Chandras Date: Fri Feb 27 07:51:32 2015 +0000 MIPS: Malta: Detect and fix bad memsize values commit f7f8aea4b97c4d48e42f02cb37026bee445f239f upstream. memsize denotes the amount of RAM we can access from kseg{0,1} and that should be up to 256M. In case the bootloader reports a value higher than that (perhaps reporting all the available RAM) it's best if we fix it ourselves and just warn the user about that. This is usually a problem with the bootloader and/or its environment. [ralf@linux-mips.org: Remove useless parens as suggested bei Sergei. Reformat long pr_warn statement to fit into 80 column limit.] Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9362/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit facbd0f25d07e3448d472d679aafefe7580990b2 Author: James Hogan Date: Wed Feb 25 13:08:05 2015 +0000 MIPS: lose_fpu(): Disable FPU when MSA enabled commit acaf6a97d623af123314c2f8ce4cf7254f6b2fc1 upstream. The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the FPU is in use and MSA isn't enabled. This isn't necessarily a problem because KSTK_STATUS(current), the version of CP0_Status stored on the kernel stack on entry from user mode, does always get updated and gets restored when returning to user mode, but I don't think it was intended, and it is inconsistent with the case of only the FPU being in use. Sometimes leaving the FPU enabled may also mask kernel bugs where FPU operations are executed when the FPU might not be enabled. So lets disable the FPU in the MSA case too. Fixes: 33c771ba5c5d ("MIPS: save/disable MSA in lose_fpu") Signed-off-by: James Hogan Cc: Ralf Baechle Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9323/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 7e5ed3d726c9333bdb3f23c3de7ff2f9e9902508 Author: James Hogan Date: Fri Feb 6 11:11:56 2015 +0000 MIPS: KVM: Handle MSA Disabled exceptions from guest commit 98119ad53376885819d93dfb8737b6a9a61ca0ba upstream. Guest user mode can generate a guest MSA Disabled exception on an MSA capable core by simply trying to execute an MSA instruction. Since this exception is unknown to KVM it will be passed on to the guest kernel. However guest Linux kernels prior to v3.15 do not set up an exception handler for the MSA Disabled exception as they don't support any MSA capable cores. This results in a guest OS panic. Since an older processor ID may be being emulated, and MSA support is not advertised to the guest, the correct behaviour is to generate a Reserved Instruction exception in the guest kernel so it can send the guest process an illegal instruction signal (SIGILL), as would happen with a non-MSA-capable core. Fix this as minimally as reasonably possible by preventing kvm_mips_check_privilege() from relaying MSA Disabled exceptions from guest user mode to the guest kernel, and handling the MSA Disabled exception by emulating a Reserved Instruction exception in the guest, via a new handle_msa_disabled() KVM callback. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Paul Burton Cc: Ralf Baechle Cc: Gleb Natapov Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9656af0b6cee1496640cfd6dc321e216ff650d37 Author: Ben Serebrin Date: Thu Apr 16 11:58:05 2015 -0700 KVM: VMX: Preserve host CR4.MCE value while in guest mode. commit 085e68eeafbf76e21848ad5bafaecec88a11dd64 upstream. The host's decision to enable machine check exceptions should remain in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset and passed a slightly-modified 0 to the vmcs.guest_cr4 value. Tested: Built. On earlier version, tested by injecting machine check while a guest is spinning. Before the change, if guest CR4.MCE==0, then the machine check is escalated to Catastrophic Error (CATERR) and the machine dies. If guest CR4.MCE==1, then the machine check causes VMEXIT and is handled normally by host Linux. After the change, injecting a machine check causes normal Linux machine check handling. Signed-off-by: Ben Serebrin Reviewed-by: Venkatesh Srinivas Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit fb124f8c695ec8ddc72f19a8b3247b5ee872422f Author: Andre Przywara Date: Fri Apr 10 16:17:59 2015 +0100 KVM: arm/arm64: check IRQ number on userland injection commit fd1d0ddf2ae92fb3df42ed476939861806c5d785 upstream. When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ #114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [] lr : [] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara Reviewed-by: Christoffer Dall [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 15254fde3f5d723bd591a73d88296e9aecdd6bb7 Author: Radim Krčmář Date: Wed Apr 8 14:16:48 2015 +0200 KVM: use slowpath for cross page cached accesses commit ca3f0874723fad81d0c701b63ae3a17a408d5f25 upstream. kvm_write_guest_cached() does not mark all written pages as dirty and code comments in kvm_gfn_to_hva_cache_init() talk about NULL memslot with cross page accesses. Fix all the easy way. The check is '<= 1' to have the same result for 'len = 0' cache anywhere in the page. (nr_pages_needed is 0 on page boundary.) Fixes: 8f964525a121 ("KVM: Allow cross page reads and writes from cached translations.") Signed-off-by: Radim Krčmář Message-Id: <20150408121648.GA3519@potion.brq.redhat.com> Reviewed-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 654de1f9fd289e10a3de1daf0806051f05f57d92 Author: Heiko Carstens Date: Wed Mar 25 10:13:33 2015 +0100 s390/hibernate: fix save and restore of kernel text section commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream. Sebastian reported a crash caused by a jump label mismatch after resume. This happens because we do not save the kernel text section during suspend and therefore also do not restore it during resume, but use the kernel image that restores the old system. This means that after a suspend/resume cycle we lost all modifications done to the kernel text section. The reason for this is the pfn_is_nosave() function, which incorrectly returns that read-only pages don't need to be saved. This is incorrect since we mark the kernel text section read-only. We still need to make sure to not save and restore pages contained within NSS and DCSS segment. To fix this add an extra case for the kernel text section and only save those pages if they are not contained within an NSS segment. Fixes the following crash (and the above bugs as well): Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0 Found: c0 04 00 00 00 00 Expected: c0 f4 00 00 00 11 New: c0 04 00 00 00 00 Kernel panic - not syncing: Corrupted kernel text CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4 Call Trace: [<0000000000113972>] show_stack+0x72/0xf0 [<000000000081f15e>] dump_stack+0x6e/0x90 [<000000000081c4e8>] panic+0x108/0x2b0 [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108 [<0000000000112176>] __jump_label_transform+0x9e/0xd0 [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50 [<00000000001d1136>] multi_cpu_stop+0x12e/0x170 [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168 [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0 [<0000000000158baa>] kthread+0x10a/0x110 [<0000000000824a86>] kernel_thread_starter+0x6/0xc Reported-and-tested-by: Sebastian Ott Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 4756129f7d1bf8fa4ff6011a39f729f5d3bc64c4 Author: Jens Freimann Date: Mon Mar 16 12:17:13 2015 +0100 KVM: s390: fix get_all_floating_irqs commit 94aa033efcac47b09db22cb561e135baf37b7887 upstream. This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390: add floating irq controller"). get_all_floating_irqs() does copy_to_user() while holding a spin lock. Let's fix this by filling a temporary buffer first and copy it to userspace after giving up the lock. Reviewed-by: David Hildenbrand Signed-off-by: Jens Freimann Signed-off-by: Christian Borntraeger Acked-by: Cornelia Huck Signed-off-by: Greg Kroah-Hartman commit 7f1a4ebee923455bb5f50ab4ce832194dff859a7 Author: Ekaterina Tumanova Date: Tue Mar 3 09:54:41 2015 +0100 KVM: s390: Zero out current VMDB of STSI before including level3 data. commit b75f4c9afac2604feb971441116c07a24ecca1ec upstream. s390 documentation requires words 0 and 10-15 to be reserved and stored as zeros. As we fill out all other fields, we can memset the full structure. Signed-off-by: Ekaterina Tumanova Reviewed-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 98529eff3f93a3179a35f9ae459e21f64e8be813 Author: David Hildenbrand Date: Wed Feb 4 15:59:11 2015 +0100 KVM: s390: reinjection of irqs can fail in the tpi handler commit 15462e37ca848abac7477dece65f8af25febd744 upstream. The reinjection of an I/O interrupt can fail if the list is at the limit and between the dequeue and the reinjection, another I/O interrupt is injected (e.g. if user space floods kvm with I/O interrupts). This patch avoids this memory leak and returns -EFAULT in this special case. This error is not recoverable, so let's fail hard. This can later be avoided by not dequeuing the interrupt but working directly on the locked list. Signed-off-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit bcdd54ffac32205938fa2cdd656604973275214b Author: David Hildenbrand Date: Wed Feb 4 15:53:42 2015 +0100 KVM: s390: fix handling of write errors in the tpi handler commit 261520dcfcba93ca5dfe671b88ffab038cd940c8 upstream. If the I/O interrupt could not be written to the guest provided area (e.g. access exception), a program exception was injected into the guest but "inti" wasn't freed, therefore resulting in a memory leak. In addition, the I/O interrupt wasn't reinjected. Therefore the dequeued interrupt is lost. This patch fixes the problem while cleaning up the function and making the cc and rc logic easier to handle. Signed-off-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 9297ed24421df19f5c5085d65ee2575a63524447 Author: Andrzej Pietrasiewicz Date: Tue Mar 3 10:52:05 2015 +0100 usb: gadget: printer: enqueue printer's response for setup request commit eb132ccbdec5df46e29c9814adf76075ce83576b upstream. Function-specific setup requests should be handled in such a way, that apart from filling in the data buffer, the requests are also actually enqueued: if function-specific setup is called from composte_setup(), the "usb_ep_queue()" block of code in composite_setup() is skipped. The printer function lacks this part and it results in e.g. get device id requests failing: the host expects some response, the device prepares it but does not equeue it for sending to the host, so the host finally asserts timeout. This patch adds enqueueing the prepared responses. Fixes: 2e87edf49227: "usb: gadget: make g_printer use composite" Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 5cb46afa0f6d4c48714951dc856c404d79315a39 Author: Scott Wood Date: Fri Apr 10 19:37:34 2015 -0500 powerpc/hugetlb: Call mm_dec_nr_pmds() in hugetlb_free_pmd_range() commit 50c6a665b383cb5839e45d04e36faeeefaffa052 upstream. Commit dc6c9a35b66b5 ("mm: account pmd page tables to the process") added a counter that is incremented whenever a PMD is allocated and decremented whenever a PMD is freed. For hugepages on PPC, common code is used to allocated PMDs, but arch-specific code is used to free PMDs. This results in kernel output such as "BUG: non-zero nr_pmds on freeing mm: 1" when using hugepages. Update the PPC hugepage PMD freeing code to decrement the count, just as the above commit did for free_pmd_range(). Fixes: dc6c9a35b66b5 ("mm: account pmd page tables to the process") Signed-off-by: Scott Wood Reviewed-by: Aneesh Kumar K.V Signed-off-by: Greg Kroah-Hartman commit 5683056e4853891106ae0a99938c96dfdc8fa881 Author: Gerald Schaefer Date: Tue Apr 14 15:42:30 2015 -0700 mm/hugetlb: use pmd_page() in follow_huge_pmd() commit 97534127012f0e396eddea4691f4c9b170aed74b upstream. Commit 61f77eda9bbf ("mm/hugetlb: reduce arch dependent code around follow_huge_*") broke follow_huge_pmd() on s390, where pmd and pte layout differ and using pte_page() on a huge pmd will return wrong results. Using pmd_page() instead fixes this. All architectures that were touched by that commit have pmd_page() defined, so this should not break anything on other architectures. Fixes: 61f77eda "mm/hugetlb: reduce arch dependent code around follow_huge_*" Signed-off-by: Gerald Schaefer Acked-by: Naoya Horiguchi Cc: Hugh Dickins Cc: Michal Hocko Cc: Andrea Arcangeli Cc: Martin Schwidefsky Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 68ea2629745f61ddf8a603970e74b294737bc5d7 Author: Filipe Manana Date: Mon Mar 30 18:26:47 2015 +0100 Btrfs: fix inode eviction infinite loop after extent_same ioctl commit 113e8283869b9855c8b999796aadd506bbac155f upstream. If we pass a length of 0 to the extent_same ioctl, we end up locking an extent range with a start offset greater then its end offset (if the destination file's offset is greater than zero). This results in a warning from extent_io.c:insert_state through the following call chain: btrfs_extent_same() btrfs_double_lock() lock_extent_range() lock_extent(inode->io_tree, offset, offset + len - 1) lock_extent_bits() __set_extent_bit() insert_state() --> WARN_ON(end < start) This leads to an infinite loop when evicting the inode. This is the same problem that my previous patch titled "Btrfs: fix inode eviction infinite loop after cloning into it" addressed but for the extent_same ioctl instead of the clone ioctl. Signed-off-by: Filipe Manana Reviewed-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 9301d5068d8732a0f2d787240270a1426d09ecf5 Author: Filipe Manana Date: Mon Mar 30 18:23:59 2015 +0100 Btrfs: fix inode eviction infinite loop after cloning into it commit ccccf3d67294714af2d72a6fd6fd7d73b01c9329 upstream. If we attempt to clone a 0 length region into a file we can end up inserting a range in the inode's extent_io tree with a start offset that is greater then the end offset, which triggers immediately the following warning: [ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3914.620886] BTRFS: end < start 4095 4096 (...) [ 3914.638093] Call Trace: [ 3914.638636] [] dump_stack+0x4c/0x65 [ 3914.639620] [] warn_slowpath_common+0xa1/0xbb [ 3914.640789] [] ? insert_state+0x4b/0x10b [btrfs] [ 3914.642041] [] warn_slowpath_fmt+0x46/0x48 [ 3914.643236] [] insert_state+0x4b/0x10b [btrfs] [ 3914.644441] [] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3914.645711] [] lock_extent_bits+0x65/0x1bf [btrfs] [ 3914.646914] [] ? _raw_spin_unlock+0x28/0x33 [ 3914.648058] [] ? test_range_bit+0xcc/0xde [btrfs] [ 3914.650105] [] lock_extent+0x13/0x15 [btrfs] [ 3914.651361] [] lock_extent_range+0x3d/0xcd [btrfs] [ 3914.652761] [] btrfs_ioctl_clone+0x278/0x388 [btrfs] [ 3914.654128] [] ? might_fault+0x58/0xb5 [ 3914.655320] [] btrfs_ioctl+0xb51/0x2195 [btrfs] (...) [ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]--- This later makes the inode eviction handler enter an infinite loop that keeps dumping the following warning over and over: [ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3915.119913] BTRFS: end < start 4095 4096 (...) [ 3915.137394] Call Trace: [ 3915.137913] [] dump_stack+0x4c/0x65 [ 3915.139154] [] warn_slowpath_common+0xa1/0xbb [ 3915.140316] [] ? insert_state+0x4b/0x10b [btrfs] [ 3915.141505] [] warn_slowpath_fmt+0x46/0x48 [ 3915.142709] [] insert_state+0x4b/0x10b [btrfs] [ 3915.143849] [] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3915.145120] [] ? btrfs_kill_super+0x17/0x23 [btrfs] [ 3915.146352] [] ? deactivate_locked_super+0x3b/0x50 [ 3915.147565] [] lock_extent_bits+0x65/0x1bf [btrfs] [ 3915.148785] [] ? _raw_write_unlock+0x28/0x33 [ 3915.149931] [] btrfs_evict_inode+0x196/0x482 [btrfs] [ 3915.151154] [] evict+0xa0/0x148 [ 3915.152094] [] dispose_list+0x39/0x43 [ 3915.153081] [] evict_inodes+0xdc/0xeb [ 3915.154062] [] generic_shutdown_super+0x49/0xef [ 3915.155193] [] kill_anon_super+0x13/0x1e [ 3915.156274] [] btrfs_kill_super+0x17/0x23 [btrfs] (...) [ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]--- So just bail out of the clone ioctl if the length of the region to clone is zero, without locking any extent range, in order to prevent this issue (same behaviour as a pwrite with a 0 length for example). This is trivial to reproduce. For example, the steps for the test I just made for fstests: mkfs.btrfs -f SCRATCH_DEV mount SCRATCH_DEV $SCRATCH_MNT touch $SCRATCH_MNT/foo touch $SCRATCH_MNT/bar $CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar umount $SCRATCH_MNT A test case for fstests follows soon. Signed-off-by: Filipe Manana Reviewed-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 1f6719c298def2c3440dc5e9ca9532053877fff7 Author: David Sterba Date: Wed Mar 25 19:26:41 2015 +0100 btrfs: don't accept bare namespace as a valid xattr commit 3c3b04d10ff1811a27f86684ccd2f5ba6983211d upstream. Due to insufficient check in btrfs_is_valid_xattr, this unexpectedly works: $ touch file $ setfattr -n user. -v 1 file $ getfattr -d file user.="1" ie. the missing attribute name after the namespace. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94291 Reported-by: William Douglas Signed-off-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 7362dcdba904cf6a1c3791c253f25f85390d45c0 Author: Filipe Manana Date: Mon Mar 23 14:07:40 2015 +0000 Btrfs: fix log tree corruption when fs mounted with -o discard commit dcc82f4783ad91d4ab654f89f37ae9291cdc846a upstream. While committing a transaction we free the log roots before we write the new super block. Freeing the log roots implies marking the disk location of every node/leaf (metadata extent) as pinned before the new super block is written. This is to prevent the disk location of log metadata extents from being reused before the new super block is written, otherwise we would have a corrupted log tree if before the new super block is written a crash/reboot happens and the location of any log tree metadata extent ended up being reused and rewritten. Even though we pinned the log tree's metadata extents, we were issuing a discard against them if the fs was mounted with the -o discard option, resulting in corruption of the log tree if a crash/reboot happened before writing the new super block - the next time the fs was mounted, during the log replay process we would find nodes/leafs of the log btree with a content full of zeroes, causing the process to fail and require the use of the tool btrfs-zero-log to wipeout the log tree (and all data previously fsynced becoming lost forever). Fix this by not doing a discard when pinning an extent. The discard will be done later when it's safe (after the new super block is committed) at extent-tree.c:btrfs_finish_extent_commit(). Fixes: e688b7252f78 (Btrfs: fix extent pinning bugs in the tree log) Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 47b34f8519e8a009d3ba8506ea8c5e7fe4314a6d Author: Nadav Amit Date: Sun Apr 12 21:47:15 2015 +0300 KVM: x86: Fix MSR_IA32_BNDCFGS in msrs_to_save commit 9e9c3fe40bcd28e3f98f0ad8408435f4503f2781 upstream. kvm_init_msr_list is currently called before hardware_setup. As a result, vmx_mpx_supported always returns false when kvm_init_msr_list checks whether to save MSR_IA32_BNDCFGS. Move kvm_init_msr_list after vmx_hardware_setup is called to fix this issue. Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman Message-Id: <1428864435-4732-1-git-send-email-namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini commit 5c966c4f563f8b10e276e43579c0f27ea2a3cef2 Author: Linus Torvalds Date: Thu Apr 23 08:33:59 2015 -0700 x86: fix special __probe_kernel_write() tail zeroing case commit d869844bd081081bf537e806a44811884230643e upstream. Commit cae2a173fe94 ("x86: clean up/fix 'copy_in_user()' tail zeroing") fixed the failure case tail zeroing of one special case of the x86-64 generic user-copy routine, namely when used for the user-to-user case ("copy_in_user()"). But in the process it broke an even more unusual case: using the user copy routine for kernel-to-kernel copying. Now, normally kernel-kernel copies are obviously done using memcpy(), but we have a couple of special cases when we use the user-copy functions. One is when we pass a kernel buffer to a regular user-buffer routine, using set_fs(KERNEL_DS). That's a "normal" case, and continued to work fine, because it never takes any faults (with the possible exception of a silent and successful vmalloc fault). But Jan Beulich pointed out another, very unusual, special case: when we use the user-copy routines not because it's a path that expects a user pointer, but for a couple of ftrace/kgdb cases that want to do a kernel copy, but do so using "unsafe" buffers, and use the user-copy routine to gracefully handle faults. IOW, for probe_kernel_write(). And that broke for the case of a faulting kernel destination, because we saw the kernel destination and wanted to try to clear the tail of the buffer. Which doesn't work, since that's what faults. This only triggers for things like kgdb and ftrace users (eg trying setting a breakpoint on read-only memory), but it's definitely a bug. The fix is to not compare against the kernel address start (TASK_SIZE), but instead use the same limits "access_ok()" uses. Reported-and-tested-by: Jan Beulich Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6e4dd840cca3053125c3f55650df1a9313b91615 Author: Peter Zijlstra Date: Sat Apr 11 12:16:22 2015 +0200 perf/x86/intel: Fix Core2,Atom,NHM,WSM cycles:pp events commit 517e6341fa123ec3a2f9ea78ad547be910529881 upstream. Ingo reported that cycles:pp didn't work for him on some machines. It turns out that in this commit: af4bdcf675cf perf/x86/intel: Disallow flags for most Core2/Atom/Nehalem/Westmere events Andi forgot to explicitly allow that event when he disabled event flags for PEBS on those uarchs. Reported-by: Ingo Molnar Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Fixes: af4bdcf675cf ("perf/x86/intel: Disallow flags for most Core2/Atom/Nehalem/Westmere events") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit aaa51337c5819599af0d1f6aba6a31639dd1c0a6 Author: Mike Galbraith Date: Sat Jan 18 17:14:44 2014 +0100 sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs commit f8e617f4582995f7c25ef25b4167213120ad122b upstream. To fully take advantage of MWAIT, apparently the CLFLUSH instruction needs another quirk on certain CPUs: proper barriers around it on certain machines. On a Q6600 SMP system, pipe-test scheduling performance, cross core, improves significantly: 3.8.13 487.2 KHz 1.000 3.13.0-master 415.5 KHz .852 3.13.0-master+ 415.2 KHz .852 + restore mwait_idle 3.13.0-master++ 488.5 KHz 1.002 + restore mwait_idle + IPI fix Since X86_BUG_CLFLUSH_MONITOR is already a quirk, don't create a separate quirk for the extra smp_mb()s. Signed-off-by: Mike Galbraith Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Ian Malone Cc: Josh Boyer Cc: Len Brown Cc: Len Brown Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1390061684.5566.4.camel@marge.simpson.net [ Ported to recent kernel, added comments about the quirk. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0e625b6df5ac57968c7ab197e916ea03f70e4a24 Author: Len Brown Date: Wed Jan 15 00:37:34 2014 -0500 sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance commit b253149b843f89cd300cbdbea27ce1f847506f99 upstream. In Linux-3.9 we removed the mwait_idle() loop: 69fb3676df33 ("x86 idle: remove mwait_idle() and "idle=mwait" cmdline param") The reasoning was that modern machines should be sufficiently happy during the boot process using the default_idle() HALT loop, until cpuidle loads and either acpi_idle or intel_idle invoke the newer MWAIT-with-hints idle loop. But two machines reported problems: 1. Certain Core2-era machines support MWAIT-C1 and HALT only. MWAIT-C1 is preferred for optimal power and performance. But if they support just C1, cpuidle never loads and so they use the boot-time default idle loop forever. 2. Some laptops will boot-hang if HALT is used, but will boot successfully if MWAIT is used. This appears to be a hidden assumption in BIOS SMI, that is presumably valid on the proprietary OS where the BIOS was validated. https://bugzilla.kernel.org/show_bug.cgi?id=60770 So here we effectively revert the patch above, restoring the mwait_idle() loop. However, we don't bother restoring the idle=mwait cmdline parameter, since it appears to add no value. Maintainer notes: For 3.9, simply revert 69fb3676df for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context For 3.11, 3.12, 3.13, this patch applies cleanly Tested-by: Mike Galbraith Signed-off-by: Len Brown Acked-by: Mike Galbraith Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Ian Malone Cc: Josh Boyer Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/345254a551eb5a6a866e048d7ab570fd2193aca4.1389763084.git.len.brown@intel.com [ Ported to recent kernels. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 82a7e6737ca5b18841f7130821dbec007d736b0b Author: Radim Krčmář Date: Thu Apr 2 20:44:23 2015 +0200 x86: vdso: fix pvclock races with task migration commit 80f7fdb1c7f0f9266421f823964fd1962681f6ce upstream. If we were migrated right after __getcpu, but before reading the migration_count, we wouldn't notice that we read TSC of a different VCPU, nor that KVM's bug made pvti invalid, as only migration_count on source VCPU is increased. Change vdso instead of updating migration_count on destination. Signed-off-by: Radim Krčmář Fixes: 0a4e6be9ca17 ("x86: kvm: Revert "remove sched notifier for cross-cpu migrations"") Message-Id: <1428000263-11892-1-git-send-email-rkrcmar@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3fbb83fdcd2be33c3091f2c1094c37b5054da9f8 Author: Marcelo Tosatti Date: Mon Mar 23 20:21:51 2015 -0300 x86: kvm: Revert "remove sched notifier for cross-cpu migrations" commit 0a4e6be9ca17c54817cf814b4b5aa60478c6df27 upstream. The following point: 2. per-CPU pvclock time info is updated if the underlying CPU changes. Is not true anymore since "KVM: x86: update pvclock area conditionally, on cpu migration". Add task migration notification back. Problem noticed by Andy Lutomirski. Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit bbe33d7992b2dd4a79499aeb384a4597b73451eb Author: Andy Lutomirski Date: Tue Jan 27 16:06:02 2015 -0800 x86/asm/decoder: Fix and enforce max instruction size in the insn decoder commit 91e5ed49fca09c2b83b262b9757d1376ee2b46c3 upstream. x86 instructions cannot exceed 15 bytes, and the instruction decoder should enforce that. Prior to 6ba48ff46f76, the instruction length limit was implicitly set to 16, which was an approximation of 15, but there is currently no limit at all. Fix MAX_INSN_SIZE (it should be 15, not 16), and fix the decoder to reject instructions that exceed MAX_INSN_SIZE. Other than potentially confusing some of the decoder sanity checks, I'm not aware of any actual problems that omitting this check would cause, nor am I aware of any practical problems caused by the MAX_INSN_SIZE error. Signed-off-by: Andy Lutomirski Acked-by: Masami Hiramatsu Cc: Dave Hansen Fixes: 6ba48ff46f76 ("x86: Remove arbitrary instruction size limit ... Link: http://lkml.kernel.org/r/f8f0bc9b8c58cfd6830f7d88400bf1396cbdcd0f.1422403511.git.luto@amacapital.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8336ee9076303fbdb38e89f18e921ec238d9c48c Author: Gu Zheng Date: Fri Apr 3 08:44:47 2015 +0800 md: fix md io stats accounting broken commit 74672d069b298b03e9f657fd70915e055739882e upstream. Simon reported the md io stats accounting issue: " I'm seeing "iostat -x -k 1" print this after a RAID1 rebuild on 4.0-rc5. It's not abnormal other than it's 3-disk, with one being SSD (sdc) and the other two being write-mostly: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 345.00 0.00 0.00 0.00 0.00 100.00 md2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 58779.00 0.00 0.00 0.00 0.00 100.00 md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12.00 0.00 0.00 0.00 0.00 100.00 " The cause is commit "18c0b223cf9901727ef3b02da6711ac930b4e5d4" uses the generic_start_io_acct to account the disk stats rather than the open code, but it also introduced the increase to .in_flight[rw] which is needless to md. So we re-use the open code here to fix it. Reported-by: Simon Kirby Signed-off-by: Gu Zheng Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 36fb8ea94764c1435bc5357057373c73f1055be9 Author: Amir Vadai Date: Mon Apr 27 13:40:56 2015 +0300 net/mlx4_en: Prevent setting invalid RSS hash function [ Upstream commit b37069090b7c5615610a8aa6b36533d67b364d38 ] mlx4_en_check_rxfh_func() was checking for hardware support before setting a known RSS hash function, but didn't do any check before setting unknown RSS hash function. Need to make it fail on such values. In this occasion, moved the actual setting of the new value from the check function into mlx4_en_set_rxfh(). Fixes: 947cbb0 ("net/mlx4_en: Support for configurable RSS hash function") Signed-off-by: Amir Vadai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b32dec8a9f5834b14daaa75bd3e49f3b54272d65 Author: Eric Dumazet Date: Sat Apr 25 09:35:24 2015 -0700 net: rfs: fix crash in get_rps_cpus() [ Upstream commit a31196b07f8034eba6a3487a1ad1bb5ec5cd58a5 ] Commit 567e4b79731c ("net: rfs: add hash collision detection") had one mistake : RPS_NO_CPU is no longer the marker for invalid cpu in set_rps_cpu() and get_rps_cpu(), as @next_cpu was the result of an AND with rps_cpu_mask This bug showed up on a host with 72 cpus : next_cpu was 0x7f, and the code was trying to access percpu data of an non existent cpu. In a follow up patch, we might get rid of compares against nr_cpu_ids, if we init the tables with 0. This is silly to test for a very unlikely condition that exists only shortly after table initialization, as we got rid of rps_reset_sock_flow() and similar functions that were writing this RPS_NO_CPU magic value at flow dismantle : When table is old enough, it never contains this value anymore. Fixes: 567e4b79731c ("net: rfs: add hash collision detection") Signed-off-by: Eric Dumazet Cc: Tom Herbert Cc: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f80e3eb94b7d4b5b9ebf999da1f50cd5b263a23d Author: Alexey Khoroshilov Date: Sat Apr 25 04:07:03 2015 +0300 pxa168: fix double deallocation of managed resources [ Upstream commit 0e03fd3e335d272bee88fe733d5fd13f5c5b7140 ] Commit 43d3ddf87a57 ("net: pxa168_eth: add device tree support") starts to use managed resources by adding devm_clk_get() and devm_ioremap_resource(), but it leaves explicit iounmap() and clock_put() in pxa168_eth_remove() and in failure handling code of pxa168_eth_probe(). As a result double free can happen. The patch removes explicit resource deallocation. Also it converts clk_disable() to clk_disable_unprepare() to make it symmetrical with clk_prepare_enable(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f009181dcccd55398f872d090fa2e1780b4ca270 Author: Eric Dumazet Date: Fri Apr 24 16:05:01 2015 -0700 net: fix crash in build_skb() [ Upstream commit 2ea2f62c8bda242433809c7f4e9eae1c52c40bbe ] When I added pfmemalloc support in build_skb(), I forgot netlink was using build_skb() with a vmalloc() area. In this patch I introduce __build_skb() for netlink use, and build_skb() is a wrapper handling both skb->head_frag and skb->pfmemalloc This means netlink no longer has to hack skb->head_frag [ 1567.700067] kernel BUG at arch/x86/mm/physaddr.c:26! [ 1567.700067] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1567.700067] Dumping ftrace buffer: [ 1567.700067] (ftrace buffer empty) [ 1567.700067] Modules linked in: [ 1567.700067] CPU: 9 PID: 16186 Comm: trinity-c182 Not tainted 4.0.0-next-20150424-sasha-00037-g4796e21 #2167 [ 1567.700067] task: ffff880127efb000 ti: ffff880246770000 task.ti: ffff880246770000 [ 1567.700067] RIP: __phys_addr (arch/x86/mm/physaddr.c:26 (discriminator 3)) [ 1567.700067] RSP: 0018:ffff8802467779d8 EFLAGS: 00010202 [ 1567.700067] RAX: 000041000ed8e000 RBX: ffffc9008ed8e000 RCX: 000000000000002c [ 1567.700067] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffffb3fd6049 [ 1567.700067] RBP: ffff8802467779f8 R08: 0000000000000019 R09: ffff8801d0168000 [ 1567.700067] R10: ffff8801d01680c7 R11: ffffed003a02d019 R12: ffffc9000ed8e000 [ 1567.700067] R13: 0000000000000f40 R14: 0000000000001180 R15: ffffc9000ed8e000 [ 1567.700067] FS: 00007f2a7da3f700(0000) GS:ffff8801d1000000(0000) knlGS:0000000000000000 [ 1567.700067] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1567.700067] CR2: 0000000000738308 CR3: 000000022e329000 CR4: 00000000000007e0 [ 1567.700067] Stack: [ 1567.700067] ffffc9000ed8e000 ffff8801d0168000 ffffc9000ed8e000 ffff8801d0168000 [ 1567.700067] ffff880246777a28 ffffffffad7c0a21 0000000000001080 ffff880246777c08 [ 1567.700067] ffff88060d302e68 ffff880246777b58 ffff880246777b88 ffffffffad9a6821 [ 1567.700067] Call Trace: [ 1567.700067] build_skb (include/linux/mm.h:508 net/core/skbuff.c:316) [ 1567.700067] netlink_sendmsg (net/netlink/af_netlink.c:1633 net/netlink/af_netlink.c:2329) [ 1567.774369] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] sock_sendmsg (net/socket.c:614 net/socket.c:623) [ 1567.774369] sock_write_iter (net/socket.c:823) [ 1567.774369] ? sock_sendmsg (net/socket.c:806) [ 1567.774369] __vfs_write (fs/read_write.c:479 fs/read_write.c:491) [ 1567.774369] ? get_lock_stats (kernel/locking/lockdep.c:249) [ 1567.774369] ? default_llseek (fs/read_write.c:487) [ 1567.774369] ? vtime_account_user (kernel/sched/cputime.c:701) [ 1567.774369] ? rw_verify_area (fs/read_write.c:406 (discriminator 4)) [ 1567.774369] vfs_write (fs/read_write.c:539) [ 1567.774369] SyS_write (fs/read_write.c:586 fs/read_write.c:577) [ 1567.774369] ? SyS_read (fs/read_write.c:577) [ 1567.774369] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1567.774369] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636) [ 1567.774369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42) [ 1567.774369] system_call_fastpath (arch/x86/kernel/entry_64.S:261) Fixes: 79930f5892e ("net: do not deplete pfmemalloc reserve") Signed-off-by: Eric Dumazet Reported-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e591662c1a5fb0e9ee486bf8edbed14d0507cfb4 Author: Eric Dumazet Date: Wed Apr 22 07:33:36 2015 -0700 net: do not deplete pfmemalloc reserve [ Upstream commit 79930f5892e134c6da1254389577fffb8bd72c66 ] build_skb() should look at the page pfmemalloc status. If set, this means page allocator allocated this page in the expectation it would help to free other pages. Networking stack can do that only if skb->pfmemalloc is also set. Also, we must refrain using high order pages from the pfmemalloc reserve, so __page_frag_refill() must also use __GFP_NOMEMALLOC for them. Under memory pressure, using order-0 pages is probably the best strategy. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7e72469760dd73a44e8cfd6105bf695b7572e246 Author: Eric Dumazet Date: Thu Apr 23 10:42:39 2015 -0700 tcp: avoid looping in tcp_send_fin() [ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ] Presence of an unbound loop in tcp_send_fin() had always been hard to explain when analyzing crash dumps involving gigantic dying processes with millions of sockets. Lets try a different strategy : In case of memory pressure, try to add the FIN flag to last packet in write queue, even if packet was already sent. TCP stack will be able to deliver this FIN after a timeout event. Note that this FIN being delivered by a retransmit, it also carries a Push flag given our current implementation. By checking sk_under_memory_pressure(), we anticipate that cooking many FIN packets might deplete tcp memory. In the case we could not allocate a packet, even with __GFP_WAIT allocation, then not sending a FIN seems quite reasonable if it allows to get rid of this socket, free memory, and not block the process from eventually doing other useful work. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e1b095eb7de9dc2235c86e15be6b9d0bff56a6ab Author: Eric Dumazet Date: Tue Apr 21 18:32:24 2015 -0700 tcp: fix possible deadlock in tcp_send_fin() [ Upstream commit d83769a580f1132ac26439f50068a29b02be535e ] Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in case a huge process is killed by OOM, and tcp_mem[2] is hit. To be able to free memory we need to make progress, so this patch allows FIN packets to not care about tcp_mem[2], if skb allocation succeeded. In a follow-up patch, we might abort tcp_send_fin() infinite loop in case TIF_MEMDIE is set on this thread, as memory allocator did its best getting extra memory already. This patch reverts d22e15371811 ("tcp: fix tcp fin memory accounting") Fixes: d22e15371811 ("tcp: fix tcp fin memory accounting") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5a248fca60021d0e35a9de9bd0620eff840365ca Author: Tom Herbert Date: Mon Apr 20 14:10:05 2015 -0700 ppp: call skb_checksum_complete_unset in ppp_receive_frame [ Upstream commit 3dfb05340ec6676e6fc71a9ae87bbbe66d3c2998 ] Call checksum_complete_unset in PPP receive to discard checksum-complete value. PPP does not pull checksum for headers and also modifies packet as in VJ compression. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8a6846e3226bb475db9686590da85bcc609c75a9 Author: Tom Herbert Date: Mon Apr 20 14:10:04 2015 -0700 net: add skb_checksum_complete_unset [ Upstream commit 4e18b9adf2f910ec4d30b811a74a5b626e6c6125 ] This function changes ip_summed to CHECKSUM_NONE if CHECKSUM_COMPLETE is set. This is called to discard checksum-complete when packet is being modified and checksum is not pulled for headers in a layer. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7bebf970047f59c16ddd5660b54562c8bcd40074 Author: Sebastian Pöhn Date: Mon Apr 20 09:19:20 2015 +0200 ip_forward: Drop frames with attached skb->sk [ Upstream commit 2ab957492d13bb819400ac29ae55911d50a82a13 ] Initial discussion was: [FYI] xfrm: Don't lookup sk_policy for timewait sockets Forwarded frames should not have a socket attached. Especially tw sockets will lead to panics later-on in the stack. This was observed with TPROXY assigning a tw socket and broken policy routing (misconfigured). As a result frame enters forwarding path instead of input. We cannot solve this in TPROXY as it cannot know that policy routing is broken. v2: Remove useless comment Signed-off-by: Sebastian Poehn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman