commit bf061ff726972b1f2e3c0e369f096405243c3a0f Author: Greg Kroah-Hartman Date: Thu Apr 3 12:02:51 2014 -0700 Linux 3.13.9 commit 0249715db671fa91b820595049df2e1a94b707bb Author: Daniel Borkmann Date: Mon Jan 6 00:57:54 2014 +0100 netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream. Some occurences in the netfilter tree use skb_header_pointer() in the following way ... struct dccp_hdr _dh, *dh; ... skb_header_pointer(skb, dataoff, sizeof(_dh), &dh); ... where dh itself is a pointer that is being passed as the copy buffer. Instead, we need to use &_dh as the forth argument so that we're copying the data into an actual buffer that sits on the stack. Currently, we probably could overwrite memory on the stack (e.g. with a possibly mal-formed DCCP packet), but unintentionally, as we only want the buffer to be placed into _dh variable. Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support") Signed-off-by: Daniel Borkmann Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 5636796e985b1278d778b18ff1e7176be0ed312d Author: Li Zefan Date: Tue Feb 11 16:05:46 2014 +0800 cgroup: protect modifications to cgroup_idr with cgroup_mutex commit 0ab02ca8f887908152d1a96db5130fc661d36a1e upstream. Setup cgroupfs like this: # mount -t cgroup -o cpuacct xxx /cgroup # mkdir /cgroup/sub1 # mkdir /cgroup/sub2 Then run these two commands: # for ((; ;)) { mkdir /cgroup/sub1/tmp && rmdir /mnt/sub1/tmp; } & # for ((; ;)) { mkdir /cgroup/sub2/tmp && rmdir /mnt/sub2/tmp; } & After seconds you may see this warning: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 25243 at lib/idr.c:527 sub_remove+0x87/0x1b0() idr_remove called for id=6 which is not allocated. ... Call Trace: [] dump_stack+0x7a/0x96 [] warn_slowpath_common+0x8c/0xc0 [] warn_slowpath_fmt+0x46/0x50 [] sub_remove+0x87/0x1b0 [] ? css_killed_work_fn+0x32/0x1b0 [] idr_remove+0x25/0xd0 [] cgroup_destroy_css_killed+0x5b/0xc0 [] css_killed_work_fn+0x130/0x1b0 [] process_one_work+0x26c/0x550 [] worker_thread+0x12e/0x3b0 [] kthread+0xe6/0xf0 [] ret_from_fork+0x7c/0xb0 ---[ end trace 2d1577ec10cf80d0 ]--- It's because allocating/removing cgroup ID is not properly synchronized. The bug was introduced when we converted cgroup_ida to cgroup_idr. While synchronization is already done inside ida_simple_{get,remove}(), users are responsible for concurrent calls to idr_{alloc,remove}(). tj: Refreshed on top of b58c89986a77 ("cgroup: fix error return from cgroup_create()"). [mhocko@suse.cz: ported to 3.12] Fixes: 4e96ee8e981b ("cgroup: convert cgroup_ida to cgroup_idr") Cc: #3.12+ Reported-by: Michal Hocko Signed-off-by: Li Zefan Signed-off-by: Michal Hocko Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit cbce468a26f090f20ec145a00ac9e9c98d5fb146 Author: David Rientjes Date: Mon Mar 3 15:38:18 2014 -0800 mm: close PageTail race commit 668f9abbd4334e6c29fa8acd71635c4f9101caa7 upstream. Commit bf6bddf1924e ("mm: introduce compaction and migration for ballooned pages") introduces page_count(page) into memory compaction which dereferences page->first_page if PageTail(page). This results in a very rare NULL pointer dereference on the aforementioned page_count(page). Indeed, anything that does compound_head(), including page_count() is susceptible to racing with prep_compound_page() and seeing a NULL or dangling page->first_page pointer. This patch uses Andrea's implementation of compound_trans_head() that deals with such a race and makes it the default compound_head() implementation. This includes a read memory barrier that ensures that if PageTail(head) is true that we return a head page that is neither NULL nor dangling. The patch then adds a store memory barrier to prep_compound_page() to ensure page->first_page is set. This is the safest way to ensure we see the head page that we are expecting, PageTail(page) is already in the unlikely() path and the memory barriers are unfortunately required. Hugetlbfs is the exception, we don't enforce a store memory barrier during init since no race is possible. Signed-off-by: David Rientjes Cc: Holger Kiehl Cc: Christoph Lameter Cc: Rafael Aquini Cc: Vlastimil Babka Cc: Michal Hocko Cc: Mel Gorman Cc: Andrea Arcangeli Cc: Rik van Riel Cc: "Kirill A. Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f8a954ced934f77f2987e4b16a1881419bd6fbf3 Author: Al Viro Date: Thu Mar 20 21:10:51 2014 -0400 switch mnt_hash to hlist commit 38129a13e6e71f666e0468e99fdd932a687b4d7e upstream. fixes RCU bug - walking through hlist is safe in face of element moves, since it's self-terminating. Cyclic lists are not - if we end up jumping to another hash chain, we'll loop infinitely without ever hitting the original list head. [fix for dumb braino folded] Spotted by: Max Kellermann Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 92dbca18848fcc88661cd8a8ec17fd59ecc430cc Author: Al Viro Date: Fri Mar 21 10:14:08 2014 -0400 don't bother with propagate_mnt() unless the target is shared commit 0b1b901b5a98bb36943d10820efc796f7cd45ff3 upstream. If the dest_mnt is not shared, propagate_mnt() does nothing - there's no mounts to propagate to and thus no copies to create. Might as well don't bother calling it in that case. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 12007ca282cf6f7636d029d61ae4223b59a08088 Author: Al Viro Date: Thu Mar 20 20:34:43 2014 -0400 keep shadowed vfsmounts together commit 1d6a32acd70ab18499829c0a9a5dbe2bace72a13 upstream. preparation to switching mnt_hash to hlist Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 742ceaba530995da02ef5e5ac32f1478d60efd35 Author: Al Viro Date: Fri Feb 28 13:46:44 2014 -0500 resizable namespace.c hashes commit 0818bf27c05b2de56c5b2bd08cfae2a939bd5f52 upstream. * switch allocation to alloc_large_system_hash() * make sizes overridable by boot parameters (mhash_entries=, mphash_entries=) * switch mountpoint_hashtable from list_head to hlist_head Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 33414adac4d5e475c1fda0286996b55253b12d3f Author: Sasha Levin Date: Fri Mar 28 17:38:42 2014 +0100 random32: avoid attempt to late reseed if in the middle of seeding commit 05efa8c943b1d5d90fa8c8147571837573338bb6 upstream. Commit 4af712e8df ("random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized") has added a late reseed stage that happens as soon as the nonblocking pool is marked as initialized. This fails in the case that the nonblocking pool gets initialized during __prandom_reseed()'s call to get_random_bytes(). In that case we'd double back into __prandom_reseed() in an attempt to do a late reseed - deadlocking on 'lock' early on in the boot process. Instead, just avoid even waiting to do a reseed if a reseed is already occuring. Fixes: 4af712e8df99 ("random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized") Signed-off-by: Sasha Levin Acked-by: Hannes Frederic Sowa Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 396b229b683fdc08d8705883860ec5a1b810546a Author: Thomas Petazzoni Date: Wed Mar 26 00:25:42 2014 +0100 net: mvneta: fix usage as a module on RGMII configurations commit e3a8786c10e75903f1269474e21fe8cb49c3a670 upstream. Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as module') fixed the mvneta driver to make it work properly when loaded as a module in SGMII configuration, which was tested successful by the author on the Armada XP OpenBlocks AX3, which uses SGMII. However, it turns out that the Armada XP GP, which uses RGMII, is affected by a similar problem: its SERDES configuration is lost when mvneta is loaded as a module, because this configuration is set by the bootloader, and then lost because the clock is gated by the clock framework until the mvneta driver is loaded again and the clock is re-enabled. However, it turns out that for the RGMII case, setting the SERDES configuration is not sufficient: the PCS enable bit in the MVNETA_GMAC_CTRL_2 register must also be set, like in the SGMII configuration. Therefore, this commit reworks the SGMII/RGMII initialization: the only difference between the two now is a different SERDES configuration, all the rest is identical. In detail, to achieve this, the commit: * Renames MVNETA_SGMII_SERDES_CFG to MVNETA_SERDES_CFG because it is not specific to SGMII, but also used on RGMII configurations. * Adds a MVNETA_RGMII_SERDES_PROTO definition, that must be used as the MVNETA_SERDES_CFG value in RGMII configurations. * Removes the mvneta_gmac_rgmii_set() and mvneta_port_sgmii_config() functions, and instead directly do the SGMII/RGMII configuration in mvneta_port_up(), from where those functions where called. It is worth mentioning that mvneta_gmac_rgmii_set() had an 'enable' parameter that was always passed as '1', so it was pretty useless. * Reworks the mvneta_port_up() function to set the MVNETA_SERDES_CFG register to the appropriate value depending on the RGMII vs. SGMII configuration. It also unconditionally set the PCS_ENABLE bit (was already done for SGMII, but is now also needed for RGMII), and sets the PORT_RGMII bit (which was already done for both SGMII and RGMII). This commit was successfully tested with mvneta compiled as a module, on both the OpenBlocks AX3 (SGMII configuration) and the Armada XP GP (RGMII configuration). Reported-by: Steve McIntyre Signed-off-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ea64e1f33d9d627da5d38da035e5d7443276e84e Author: Thomas Petazzoni Date: Wed Mar 26 00:25:41 2014 +0100 net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE commit a79121d3b57e7ad61f0b5d23eae05214054f3ccd upstream. Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS, not the PSC: there was a typo in the name of the define, which this commit fixes. Signed-off-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fa82051f97c1e81e44ae1517a4303db6ceba1e2b Author: Al Viro Date: Sun Mar 23 00:28:40 2014 -0400 make prepend_name() work correctly when called with negative *buflen commit e825196d48d2b89a6ec3a8eff280098d2a78207e upstream. In all callchains leading to prepend_name(), the value left in *buflen is eventually discarded unused if prepend_name() has returned a negative. So we are free to do what prepend() does, and subtract from *buflen *before* checking for underflow (which turns into checking the sign of subtraction result, of course). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit abfabd98494dcba8cefe726a28c006be87b34d0c Author: Artem Fetishev Date: Fri Mar 28 13:33:39 2014 -0700 x86: fix boot on uniprocessor systems commit 825600c0f20e595daaa7a6dd8970f84fa2a2ee57 upstream. On x86 uniprocessor systems topology_physical_package_id() returns -1 which causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized which leads to GPF in rapl_pmu_init(). See arch/x86/kernel/cpu/perf_event_intel_rapl.c. It turns out that physical_package_id and core_id can actually be retreived for uniprocessor systems too. Enabling them also fixes rapl_pmu code. Signed-off-by: Artem Fetishev Cc: Stephane Eranian Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 120ecfe57c8fb2d53c1f77bedca199536545628b Author: Daniel Vetter Date: Wed Mar 26 20:10:09 2014 +0100 drm/i915: Undo gtt scratch pte unmapping again commit 8ee661b505613ef2747b350ca2871a31b3781bee upstream. It apparently blows up on some machines. This functionally reverts commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841 Reported-and-Tested-by: Brad Jackson Cc: Takashi Iwai Cc: Paulo Zanoni Cc: Todd Previte Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit ff5fe53714d1944ab53b7e0ffe43d040b415b573 Author: Scott Wood Date: Tue Mar 18 16:10:24 2014 -0500 i2c: cpm: Fix build by adding of_address.h and of_irq.h commit 5f12c5eca6e6b7aeb4b2028d579f614b4fe7a81f upstream. Fixes a build break due to the undeclared use of irq_of_parse_and_map() and of_iomap(). This build break was apparently introduced while the driver was unbuildable due to the bug fixed by 62c19c9d29e65086e5ae76df371ed2e6b23f00cd ("i2c: Remove usage of orphaned symbol OF_I2C"). When 62c19c was added in v3.14-rc7, the driver was enabled again, breaking the powerpc mpc85xx_defconfig and mpc85xx_smp_defconfig. 62c19c is marked for stable, so this should go there as well. Reported-by: Geert Uytterhoeven Signed-off-by: Scott Wood Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit f974c74cfa24b0872009d1cbab78f743c2535570 Author: David Vrabel Date: Tue Mar 25 10:38:37 2014 +0000 Revert "xen: properly account for _PAGE_NUMA during xen pte translations" commit 5926f87fdaad4be3ed10cec563bf357915e55a86 upstream. This reverts commit a9c8e4beeeb64c22b84c803747487857fe424b68. PTEs in Xen PV guests must contain machine addresses if _PAGE_PRESENT is set and pseudo-physical addresses is _PAGE_PRESENT is clear. This is because during a domain save/restore (migration) the page table entries are "canonicalised" and uncanonicalised". i.e., MFNs are converted to PFNs during domain save so that on a restore the page table entries may be rewritten with the new MFNs on the destination. This canonicalisation is only done for PTEs that are present. This change resulted in writing PTEs with MFNs if _PAGE_PROTNONE (or _PAGE_NUMA) was set but _PAGE_PRESENT was clear. These PTEs would be migrated as-is which would result in unexpected behaviour in the destination domain. Either a) the MFN would be translated to the wrong PFN/page; b) setting the _PAGE_PRESENT bit would clear the PTE because the MFN is no longer owned by the domain; or c) the present bit would not get set. Symptoms include "Bad page" reports when munmapping after migrating a domain. Signed-off-by: David Vrabel Acked-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit a0a7b1fa22feddc90b25f12aca70bf29a548031e Author: Wei Liu Date: Sat Mar 15 16:11:47 2014 +0000 xen/balloon: flush persistent kmaps in correct position commit 09ed3d5ba06137913960f9c9385f71fc384193ab upstream. Xen balloon driver will update ballooned out pages' P2M entries to point to scratch page for PV guests. In 24f69373e2 ("xen/balloon: don't alloc page while non-preemptible", kmap_flush_unused was moved after updating P2M table. In that case for 32 bit PV guest we might end up with P2M X -----> S (S is mfn of balloon scratch page) M2P Y -----> X (Y is mfn in persistent kmap entry) kmap_flush_unused() iterates through all the PTEs in the kmap address space, using pte_to_page() to obtain the page. If the p2m and the m2p are inconsistent the incorrect page is returned. This will clear page->address on the wrong page which may cause subsequent oopses if that page is currently kmap'ed. Move the flush back between get_page and __set_phys_to_machine to fix this. Signed-off-by: Wei Liu Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 7bad2a982359394a7d5fd5c7462b75d4d3ae95fc Author: Hans de Goede Date: Wed Mar 26 13:30:52 2014 -0700 Input: cypress_ps2 - don't report as a button pads commit 6797b39e6f6f34c74177736e146406e894b9482b upstream. The cypress PS/2 trackpad models supported by the cypress_ps2 driver emulate BTN_RIGHT events in firmware based on the finger position, as part of this no motion events are sent when the finger is in the button area. The INPUT_PROP_BUTTONPAD property is there to indicate to userspace that BTN_RIGHT events should be emulated in userspace, which is not necessary in this case. When INPUT_PROP_BUTTONPAD is advertised userspace will wait for a motion event before propagating the button event higher up the stack, as it needs current abs x + y data for its BTN_RIGHT emulation. Since in the cypress_ps2 pads don't report motion events in the button area, this means that clicks in the button area end up being ignored, so INPUT_PROP_BUTTONPAD actually causes problems for these touchpads, and removing it fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76341 Reported-by: Adam Williamson Tested-by: Adam Williamson Reviewed-by: Peter Hutterer Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 66d8b4f316fec00821dfe6e040ca1cbc71dbcacb Author: Hans de Goede Date: Fri Mar 28 01:01:38 2014 -0700 Input: synaptics - add manual min/max quirk for ThinkPad X240 commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream. This extends Benjamin Tissoires manual min/max quirk table with support for the ThinkPad X240. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 0329ff65cb99ada6c930c307f94af65e7ccf80bd Author: Benjamin Tissoires Date: Fri Mar 28 00:43:00 2014 -0700 Input: synaptics - add manual min/max quirk commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream. The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad. However, these new Synaptics devices report bad axis ranges. Under Windows, it is not a problem because the Windows driver uses RMI4 over SMBus to talk to the device. Under Linux, we are using the PS/2 fallback interface and it occurs the reported ranges are wrong. Of course, it would be too easy to have only one range for the whole series, each touchpad seems to be calibrated in a different way. We can not use SMBus to get the actual range because I suspect the firmware will switch into the SMBus mode and stop talking through PS/2 (this is the case for hybrid HID over I2C / PS/2 Synaptics touchpads). So as a temporary solution (until RMI4 land into upstream), start a new list of quirks with the min/max manually set. Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e9148d1137b5b950d8d2b5ea87bcd21c2726017d Author: Dmitry Torokhov Date: Thu Mar 6 12:57:24 2014 -0800 Input: mousedev - fix race when creating mixed device commit e4dbedc7eac7da9db363a36f2bd4366962eeefcc upstream. We should not be using static variable mousedev_mix in methods that can be called before that singleton gets assigned. While at it let's add open and close methods to mousedev structure so that we do not need to test if we are dealing with multiplexor or normal device and simply call appropriate method directly. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551 Reported-by: GiulioDP Tested-by: GiulioDP Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7ce510b1e42d51dfbf2e184778039a34dbba6131 Author: Al Viro Date: Thu Mar 20 15:18:22 2014 -0400 rcuwalk: recheck mount_lock after mountpoint crossing attempts commit b37199e626b31e1175fb06764c5d1d687723aac2 upstream. We can get false negative from __lookup_mnt() if an unrelated vfsmount gets moved. In that case legitimize_mnt() is guaranteed to fail, and we will fall back to non-RCU walk... unless we end up running into a hard error on a filesystem object we wouldn't have reached if not for that false negative. IOW, delaying that check until the end of pathname resolution is wrong - we should recheck right after we attempt to cross the mountpoint. We don't need to recheck unless we see d_mountpoint() being true - in that case even if we have just raced with mount/umount, we can simply go on as if we'd come at the moment when the sucker wasn't a mountpoint; if we run into a hard error as the result, it was a legitimate outcome. __lookup_mnt() returning NULL is different in that respect, since it might've happened due to operation on completely unrelated mountpoint. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit da49d7d6349af87e838f881f593337c9459d883a Author: Theodore Ts'o Date: Sun Mar 30 10:20:01 2014 -0400 ext4: atomically set inode->i_flags in ext4_set_inode_flags() commit 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream. Use cmpxchg() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race where an immutable file has the immutable flag cleared for a brief window of time. Reported-by: John Sullivan Signed-off-by: "Theodore Ts'o" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman