commit bf061ff726972b1f2e3c0e369f096405243c3a0f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 3 12:02:51 2014 -0700

    Linux 3.13.9

commit 0249715db671fa91b820595049df2e1a94b707bb
Author: Daniel Borkmann <dborkman@redhat.com>
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 <dborkman@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5636796e985b1278d778b18ff1e7176be0ed312d
Author: Li Zefan <lizefan@huawei.com>
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:
     [<ffffffff8156063c>] dump_stack+0x7a/0x96
     [<ffffffff810591ac>] warn_slowpath_common+0x8c/0xc0
     [<ffffffff81059296>] warn_slowpath_fmt+0x46/0x50
     [<ffffffff81300aa7>] sub_remove+0x87/0x1b0
     [<ffffffff810f3f02>] ? css_killed_work_fn+0x32/0x1b0
     [<ffffffff81300bf5>] idr_remove+0x25/0xd0
     [<ffffffff810f2bab>] cgroup_destroy_css_killed+0x5b/0xc0
     [<ffffffff810f4000>] css_killed_work_fn+0x130/0x1b0
     [<ffffffff8107cdbc>] process_one_work+0x26c/0x550
     [<ffffffff8107eefe>] worker_thread+0x12e/0x3b0
     [<ffffffff81085f96>] kthread+0xe6/0xf0
     [<ffffffff81570bac>] 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: <stable@vger.kernel.org> #3.12+
    Reported-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbce468a26f090f20ec145a00ac9e9c98d5fb146
Author: David Rientjes <rientjes@google.com>
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 <rientjes@google.com>
    Cc: Holger Kiehl <Holger.Kiehl@dwd.de>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Rafael Aquini <aquini@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8a954ced934f77f2987e4b16a1881419bd6fbf3
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <mk@cm4all.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92dbca18848fcc88661cd8a8ec17fd59ecc430cc
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12007ca282cf6f7636d029d61ae4223b59a08088
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 742ceaba530995da02ef5e5ac32f1478d60efd35
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33414adac4d5e475c1fda0286996b55253b12d3f
Author: Sasha Levin <sasha.levin@oracle.com>
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 <sasha.levin@oracle.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 396b229b683fdc08d8705883860ec5a1b810546a
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <steve@einval.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea64e1f33d9d627da5d38da035e5d7443276e84e
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.petazzoni@free-electrons.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa82051f97c1e81e44ae1517a4303db6ceba1e2b
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abfabd98494dcba8cefe726a28c006be87b34d0c
Author: Artem Fetishev <artem_fetishev@epam.com>
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 <artem_fetishev@epam.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 120ecfe57c8fb2d53c1f77bedca199536545628b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <benjamin.widawsky@intel.com>
    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 <bjackson0971@gmail.com>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Cc: Todd Previte <tprevite@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff5fe53714d1944ab53b7e0ffe43d040b415b573
Author: Scott Wood <scottwood@freescale.com>
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 <geert@linux-m68k.org>
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f974c74cfa24b0872009d1cbab78f743c2535570
Author: David Vrabel <david.vrabel@citrix.com>
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 <david.vrabel@citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a7b1fa22feddc90b25f12aca70bf29a548031e
Author: Wei Liu <wei.liu2@citrix.com>
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 <wei.liu2@citrix.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bad2a982359394a7d5fd5c7462b75d4d3ae95fc
Author: Hans de Goede <hdegoede@redhat.com>
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 <awilliam@redhat.com>
    Tested-by: Adam Williamson <awilliam@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66d8b4f316fec00821dfe6e040ca1cbc71dbcacb
Author: Hans de Goede <hdegoede@redhat.com>
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 <hdegoede@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0329ff65cb99ada6c930c307f94af65e7ccf80bd
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
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 <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9148d1137b5b950d8d2b5ea87bcd21c2726017d
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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 <depasquale.giulio@gmail.com>
    Tested-by: GiulioDP <depasquale.giulio@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ce510b1e42d51dfbf2e184778039a34dbba6131
Author: Al Viro <viro@zeniv.linux.org.uk>
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 <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da49d7d6349af87e838f881f593337c9459d883a
Author: Theodore Ts'o <tytso@mit.edu>
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 <jsrhbz@kanargh.force9.co.uk>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>