commit 7214c55cba9630a4728f86ae6b3c73c962430711 Author: Greg Kroah-Hartman Date: Wed May 6 22:02:18 2015 +0200 Linux 3.19.7 commit 2cb887418ffa5e28cc8dbbb4f585d9f71ed4314a 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 fb2eb817150444c37f17361b72623d3a39d093ef 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 9e862ee60a60dde9a812ee90dc17dd613b335fed 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 6e2d6fbdb0e00db8ec61e385ba6e2164591801e3 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 9280cd6080bcf3c0c771d3410faae6ed58598dd4 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 5e0b20030d95a992d2c3fb25d83e5e9b82a5a1d8 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 3b70a774de37a87e6e0fce39b7ecdce5d52376fc 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 84d466e88289b6f953b94dbe949d9bf74a5d7f83 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 ef5c23892b7de84e1f88b84a62fa17ab7cb71986 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 869c623bcdcf2e806cb5e31fed7c3bbdf47ffc6e 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 b5d458c11722dc457541d0e1f8231a63031d924e 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 a2499fb975a63b01d3e8eba7b54e1077ea681acd 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 465460c3372b36390b9a884f9d54427fb0ded391 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 b3d6135d6b83abca927ded331d252a2d59c25901 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 8e418cbd93be5f7da1a1dd54e110935314ef747b 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 e39af30e485c42273f815499bc228527322398dd 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 717ec2427a645204a8561552a6566929011a568c 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 1047055e84c0ce7ef33cc1e19297786c14fe919f 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 93812e3077da327257c0c2a685db05aa3e7539e0 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 f8443d1aaf7798f104b96bf1e551d9ced931bdfd 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 c8e2265865392533b56108ec928ff2ff245eb206 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 66908fde0cb392814bace26dbb9f0166d894509b 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 bb55569e6e1314a2df0108374c0f3c454b8f91af 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 acee1d666ce6c26b5de8df512ce8f8d0c1955405 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 0bc7e7404e441922083bdee22c0b75f46b5a3fc0 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 a0525be6dc515578a68d11a6938e96d68a70014f 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 7c897ccd3c9865b879c7bf970423e365dad1f1ab 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 c95f44c727e16ef9e671c548747e8633451db00f 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 ad87f87368f68b1671aafe8aac18df8fbf7da81c 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 d362d17c1feea01778f0be5950632a05f7c69e4a 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 04bb88958d0baabe2cbf2a948878604cd140df87 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 b9a587d12522dd28916aa45f758b12d91907fb18 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 c02afbd3d3894c525c1ce43057bc5ec8726e253f 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 39b4acfe8b96b735bcc96e0e57bbf11073fd2226 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 617dd1ff2fc341d23609997b89302349db429c96 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 9ab8410129181585500e397d9d09c45fee86584d 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 5cc4c31815bb2e9035fe44287c8e42a862cefc7e 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 d8ec87c0d49900faa8ae522420fc03ad700e9a52 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 08b1599d174c902aa90758fdd2bdc457f6b72306 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 37efb2d903916d324315e49b60f7185666cd97e7 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 9b3d0690b69cad5dde6249a186a230f3ab98f3dc 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 ac6d9ccab7586a928255cf98a60806bb92a84d72 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 ca0406fdd6f5a57e8a40d7c09b2fbcacaa1fc805 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 7a72886edfe74726a993e6e8738a51d2a51447d0 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 3b8d9b7b05f6a9cf53be51523fb20551c4644780 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 42a91c57dc61e5fda6850e4ebcdc6713e470a971 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 47be4d899cf93cb2256819076eafe8b40767c255 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 bc79646f319e43529cd2acdc5b146ac10b23ce98 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 03e361e9b2d54fa6cc78e1b79827f9be786a856d 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 71df56108669f3f2b213c554b0131020c0f427d4 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 ec84e96cd3b265f9a6406cee37a0fa01760d5bd8 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 2867b8dff162e7778f3fdfa46c45b5bf8b96d80e 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 88fc9d649db8af3a8ff462d816f4577160697264 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 f5b26dd4d771bd4929c82de3aba08d282bc392b5 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 301d2a20404d50d263f8aff06a8e6609f0b9597b 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 987883bd7381d2aefe1846eba9ecade3109887bd 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 e20179f27bbe7beea759c4567d2ae8db8fb8a57a 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 0a814e8a843c9fa505c0d7fe204934b44b8c8915 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 4bbea4fee4f957f524167501a419753e887e1479 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 709bff6be04a8308b940d7af4fbc24c0accda8fc 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 7d538c38494c54b447fa78d7440c977797dc36e2 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 5404b891394c8006b854e2f37bf5c227ed4919fe 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 d5bfa1792f39c34d814a53d36c40d82fc8fd345f 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 f885c032f9d8064597c958a6a6816740a671e091 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 898cac8dce3dc725231f7e5f8d6641c27ffa24ca 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 b550a4a6fc788d2b552a5e462677d090e39aee89 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 e99c884fc76c98d049116f086527e4ac0417471c 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 0472db1958ec6a1e0ec68da62366dcc10d99abeb 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 1370373214fd93706f13d73f8068c59a35aa71c2 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 4b52f2be874cfe9e58cff6ac5cf6af14de36553e 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 d276bf763d572e4f5f675f092c1f3ed82ebd4873 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 fb39546cc50266e4420ed831ea3ce481eacc1467 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 dc46735a46371b9b48efb24447ba77180c386fb9 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 e48647022b8a9d21f21a83d1db9c28df2f6b6b00 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 3124dbf1bce530328c3f97b0ab454c2572c4c49a 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 b8ff035def3ccfc3682bc1c3666fc2783b4a6af4 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 985694876352824bd94892ac3f460aecaa9918ef 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 2f6dccd3122af4707c9745c9370654223f665d7b 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 b6430aceced58caaff7997651222b7adda01a7ae 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 8ecdbbd7e73bb824bf62395a49fcef5b03a72620 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 f3b5e50198335d4c1dd8978f2cd3e54c921d6cfe 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 14a2b31e96ebf7800cd71611d63d01a767229b8a 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 6910342c504d04e94b06d661b51afbae98331261 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 1d71c2af69b76f349707625ad30e63a3e4623816 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 a05bb816362fea597495d0d8af9d9db7f8b0c231 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 d2ba91e1883f0bf2b75b5ad35820cc7e9f1ce032 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 c57394c58bafec25208cdaefb721a73cf1ea4d54 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 31064e86b01887a28fa26af528dc5239be384435 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 036eb6b99f18606c04f3316a53587c6765b94d65 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 1293128dc178d03cbe456b7aef1342c33128ebba 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 bef1f40028cc305d533ac18ded2eef31756da903 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 d697ef7a97150ddaf915aaa3e79378de9e78a515 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 2652931b983f78460691305d935e7be8a1103d39 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 92465054d08aa11c32b77969bc3be89d1c229f9f 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 3f29324d1345690dde2207d8a1e7b436d4e38f01 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 e17b67c96fa7c21966b9201ec155034dd53a4e55 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 c67881fc890916206e723329e774391c6ed354ce 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 d7f24470bf614ff986c9370f5704fa635b448918 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 dc7507e89e2c67143e5bb51488f4e5c7e0f6d3bd 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 44e1e2a85ee76e14afb5fb649ef951969bd261ce 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 5eba79e79c415cab7f7f88fa8b2e7a37b1e847df 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 5027b574abc167a5dfdec607d7ce1384af44817d 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 0243c3043ce4047c9523370f4222b22c4edd2429 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 d3d8f2c37446856f862f19b3f7b1ee31d49634ca 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 04b7e3351294274745ec3b4e6fb0b30d051fec2a 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 6f5be645857c96ae2abfbd4b0dc7b4a3800ecf22 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 87814ff1bbcbdbeb1fd58f966f112bc4c936238d 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 3945b9394b5fa537daa717970a70890c555ec213 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 5c3059afd1c64312fb9bfa1ef7fe2e433146b597 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 dc7a0b0a432521d4b40987b344a9b5473a9bd18b 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 7e83678dcf4b7840c00183349128f52ca615657a 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 e4f3adf88ba5237adbff176ed08b1607f1a9fc24 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 30dc82970a6a3b597d62624b88de719c491453ee 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 4cd4bf4c9391fee778d115906ed6ab6d2081436b 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 22a08adb89148a47a82ad101b02443092a8c9f6b 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 ce45240c84179a7f965d08c69274ee992da585bf 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 4dcafe787396525d0947ca5fc8ee7f186680ce3a 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 87150f3f719deeea7bb26a8f38a75ecaf13d5de4 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 6660a281770a2c8d53ff79afca82124929545ffa 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 3c4bc0dfe52e72ccf06d7298efed130116431801 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 6df215154931e29c9bb2844716400f9d4452ff81 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 5a1443eb87ff36e960589a288aef580a7f680552 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 2aaf51704e0015394da44f6d7c6ab8a8db185417 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 7767a4cb88376d7bfbcc9efe7f072ec495bb9c9f 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 17e330e91693f948dd964c49e20b8f8183fb5cf3 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 20d8423c2f3fb5505d42577e62e5c0a51815b1bd 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 40fc64c2f34867e11672d8ea2932766af2dcb27d 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 bc90eb37fb52fd013103a82b2117ead4dabdbf80 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 d6e6b42583ff9439f73e7a0a936856969c0d9373 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 28b8f9e057b103123d25eb09fe184656f1f1a91e 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 b16e2f69832c1f9f777d24d2e5ccce4791a7f9eb 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 7595f5425cad83e037639e228ee24d5052510139 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 4b4c40a89685298337f978f6195da45923324c35 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 11ebd79a59cf22f9790dbb102a431b0151437ec5 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 433a727c236a599f5adae6dd70d55293013dd641 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 d3aaa3af2622ff2a551103042d5aa010e8ac5112 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 0627a78c93593741309fcab7dab363c08d8344d3 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 10f1ea0dbcc36915f23ce6c0a5aa7eea1dd275f8 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 3fea9d6af8882a96be90e4012905be87ac81c4fb 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 7cc05e906a4c5823f4a6c86854b79dc0b61dce3d 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 ad875fd27cb3311a97cc7c0150d9f957cefbbff4 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 2652d12246c4f3d7c189404762c6cefd1f2c2c79 Author: Christoffer Dall Date: Fri Mar 13 17:02:56 2015 +0000 arm/arm64: KVM: Keep elrsr/aisr in sync with software model commit ae705930fca6322600690df9dc1c7d0516145a93 upstream. There is an interesting bug in the vgic code, which manifests itself when the KVM run loop has a signal pending or needs a vmid generation rollover after having disabled interrupts but before actually switching to the guest. In this case, we flush the vgic as usual, but we sync back the vgic state and exit to userspace before entering the guest. The consequence is that we will be syncing the list registers back to the software model using the GICH_ELRSR and GICH_EISR from the last execution of the guest, potentially overwriting a list register containing an interrupt. This showed up during migration testing where we would capture a state where the VM has masked the arch timer but there were no interrupts, resulting in a hung test. Cc: Marc Zyngier Reported-by: Alex Bennee Signed-off-by: Christoffer Dall Signed-off-by: Alex Bennée Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit ce7a2289d658eddffa9781c9577df03bede2c3fb Author: Marc Zyngier Date: Tue Mar 10 19:07:00 2015 +0000 arm64: KVM: Do not use pgd_index to index stage-2 pgd commit 04b8dc85bf4a64517e3cf20e409eeaa503b15cc1 upstream. The kernel's pgd_index macro is designed to index a normal, page sized array. KVM is a bit diffferent, as we can use concatenated pages to have a bigger address space (for example 40bit IPA with 4kB pages gives us an 8kB PGD. In the above case, the use of pgd_index will always return an index inside the first 4kB, which makes a guest that has memory above 0x8000000000 rather unhappy, as it spins forever in a page fault, whist the host happilly corrupts the lower pgd. The obvious fix is to get our own kvm_pgd_index that does the right thing(tm). Tested on X-Gene with a hacked kvmtool that put memory at a stupidly high address. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 1cb2f1488f628b6103f98e14b3b2461a790520b6 Author: Marc Zyngier Date: Tue Mar 10 19:06:59 2015 +0000 arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting commit a987370f8e7a1677ae385042644326d9cd145a20 upstream. We're using __get_free_pages with to allocate the guest's stage-2 PGD. The standard behaviour of this function is to return a set of pages where only the head page has a valid refcount. This behaviour gets us into trouble when we're trying to increment the refcount on a non-head page: page:ffff7c00cfb693c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() page dumped because: VM_BUG_ON_PAGE((*({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) *)&((&page->_count)->counter); })) <= 0) BUG: failure at include/linux/mm.h:548/get_page()! Kernel panic - not syncing: BUG! CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825 Hardware name: APM X-Gene Mustang board (DT) Call trace: [] dump_backtrace+0x0/0x13c [] show_stack+0x10/0x1c [] dump_stack+0x74/0x94 [] panic+0x100/0x240 [] stage2_get_pmd+0x17c/0x2bc [] kvm_handle_guest_abort+0x4b4/0x6b0 [] handle_exit+0x58/0x180 [] kvm_arch_vcpu_ioctl_run+0x114/0x45c [] kvm_vcpu_ioctl+0x2e0/0x754 [] do_vfs_ioctl+0x424/0x5c8 [] SyS_ioctl+0x40/0x78 CPU0: stopping A possible approach for this is to split the compound page using split_page() at allocation time, and change the teardown path to free one page at a time. It turns out that alloc_pages_exact() and free_pages_exact() does exactly that. While we're at it, the PGD allocation code is reworked to reduce duplication. This has been tested on an X-Gene platform with a 4kB/48bit-VA host kernel, and kvmtool hacked to place memory in the second page of the hardware PGD (PUD for the host kernel). Also regression-tested on a Cubietruck (Cortex-A7). [ Reworked to use alloc_pages_exact() and free_pages_exact() and to return pointers directly instead of by reference as arguments - Christoffer ] Reported-by: Mark Rutland Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit d0fd61c7048d4741ee86fb1ac314df19b49747da Author: Jan Kiszka Date: Sat Feb 7 22:21:20 2015 +0100 ARM: KVM: Fix size check in __coherent_cache_guest_page commit a050dfb21cc22ac0c666d52531040c1bc48184cc upstream. The check is supposed to catch page-unaligned sizes, not the inverse. Signed-off-by: Jan Kiszka Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 66a97aa44c7d2f90765067e15451a29ff8b6c16b Author: Eric Auger Date: Mon Dec 15 18:43:32 2014 +0100 KVM: arm/arm64: vgic: vgic_init returns -ENODEV when no online vcpu commit 66b030e48af68fd4c22d343908bc057207a0a31e upstream. To be more explicit on vgic initialization failure, -ENODEV is returned by vgic_init when no online vcpus can be found at init. Signed-off-by: Eric Auger Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 288e76c094a2d219d67eb980de66721e0145b2fb 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 d4b02c75d65d39d989a91c16594c147c93db062c 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 0b9f85366c8e13e54df01ac190d33f58f87c9fd7 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 a71a03f3e9169d0b9b75f1a8b0b99efeff88915e 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 5470fcaa7a54a9961d9b8431fe924455bee1af89 Author: Christian Borntraeger Date: Wed Dec 17 10:36:04 2014 +0100 KVM: s390: no need to hold the kvm->mutex for floating interrupts commit 69a8d456263849152826542c7cb0a164b90e68a8 upstream. The kvm mutex was (probably) used to protect against cpu hotplug. The current code no longer needs to protect against that, as we only rely on CPU data structures that are guaranteed to be available if we can access the CPU. (e.g. vcpu_create will put the cpu in the array AFTER the cpu is ready). Signed-off-by: Christian Borntraeger Acked-by: Cornelia Huck Reviewed-by: Jens Freimann Signed-off-by: Greg Kroah-Hartman commit 82c55615d4387089ecb19a613d4c2d3e4aec9a23 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 132213f3068a6cdbe930f8bc48dbed12e938ea66 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 ae3ead5986d80516e9a89006099d93194946f297 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 c911aa145a9eca73f6ce43c1c4710e332d8d35a9 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 9dc106617d5669a6f8d86e08f620dc2fb0413e21 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 449b46275ce58e1d3fc20d1efacd0d0369c6070f 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 1bb2835ed4f8ee186d8110817cf5a96ef9e35ab3 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 3909e5a93ed64a186a396c1b7fd1db07e065728f 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 702a71cf592282298395b3359f49a9a985182934 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 0d2b51f3a9465ca51973a1aa561b5c2acda6394c 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 a166e4b13b1be95a8120f8f1b098facf8b61ade9 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 0e126cfab3928e8b01e17e1e707eec2bfdb4f1c2 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 30d7277d02c5073cd9e834b812ff996be202be00 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 e637b3ecb86017b9b52fb672038709e141043535 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 8272d13a37c46c03d382609876476850d2a96dfe 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 b3b8ae82113c38559c04311de3611fa642c87709 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 5e2b1498d4903daeaeedff8efc0a62091336467d 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 ac375adcb8d77980f5c2d25ad586a9ecd4cfd595 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 ecff0913d0461f08cba78a9b9308b7dbc794d39c 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 275b7c404e7537584d801495b116da5df4de7326 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 c0a790513cac301b5d9c7fb067ac017c3fa00365 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 38fd84e60a9a305dba4d748c1f07f6d97279e240 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 cf5bab3a832bea1f13b52a36eb7b8667260e64e7 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