commit 660613d1a4e94144490850b6c3d350331860fac4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 18 14:11:52 2015 +0100

    Linux 3.19.2

commit 4b7326a3f8e9051bd99c3c7241e8565c3c875eea
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Mar 16 14:52:21 2015 +0100

    Revert "netfilter: xt_recent: relax ip_pkt_list_tot restrictions"
    
    This reverts commit abc86d0f99242b7f142b7cb8f90e30081dd3c256 as it is
    broken in 3.19 and is easier to revert here than try to fix it.
    
    Reported-by: Florian Westphal <fw@strlen.de
    Reported-by: David Miller <davem@redhat.com>
    Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

commit 1181ed21a973f1a8c5a535276685cc09c43a246f
Author: Ian Munsie <imunsie@au1.ibm.com>
Date:   Wed Feb 4 19:10:38 2015 +1100

    cxl: Add missing return statement after handling AFU errror
    
    commit a6130ed253a931d2169c26ab0958d81b0dce4d6e upstream.
    
    We were missing a return statement in the PSL interrupt handler in the
    case of an AFU error, which would trigger an "Unhandled CXL PSL IRQ"
    warning. We do actually handle these type of errors (by notifying
    userspace), so add the missing return IRQ_HANDLED so we don't throw
    unecessary warnings.
    
    Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5bc28d181ddc8edf78e4203fae42755a24db94d
Author: Ryan Grimm <grimm@linux.vnet.ibm.com>
Date:   Wed Jan 28 20:16:04 2015 -0600

    cxl: Fix device_node reference counting
    
    commit 6f963ec2d6bf2476a16799eece920acb2100ff1c upstream.
    
    When unbinding and rebinding the driver on a system with a card in PHB0, this
    error condition is reached after a few attempts:
    
    ERROR: Bad of_node_put() on /pciex@3fffe40000000
    CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe #152
    Call Trace:
    [c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable)
    [c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0
    [c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0
    [c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30
    [c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50
    [c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0
    [c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170
    [c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0
    [c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160
    [c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60
    [c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0
    [c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0
    [c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260
    [c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100
    [c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98
    
    We are missing a call to of_node_get(). pnv_pci_to_phb_node() should
    call of_node_get() otherwise np's reference count isn't incremented and
    it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node()
    so it's clear it calls of_node_get().
    
    Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
    Acked-by: Ian Munsie <imunsie@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b2ec8b4ab90f059a6db1bd6e9c86fc51512cf0a
Author: Ryan Grimm <grimm@linux.vnet.ibm.com>
Date:   Mon Jan 19 11:52:48 2015 -0600

    cxl: Use image state defaults for reloading FPGA
    
    commit 4beb5421babee1204757b877622830c6aa31be6d upstream.
    
    Select defaults such that a PERST causes flash image reload.  Select which
    image based on what the card is set up to load.
    
    CXL_VSEC_PERST_LOADS_IMAGE selects whether PERST assertion causes flash image
    load.
    
    CXL_VSEC_PERST_SELECT_USER selects which image is loaded on the next PERST.
    
    cxl_update_image_control writes these bits into the VSEC.
    
    Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
    Acked-by: Ian Munsie <imunsie@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40925067a80129d907abbf70dfa5285bbccd1967
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Wed Dec 24 17:43:27 2014 +0300

    clk-gate: fix bit # check in clk_register_gate()
    
    commit 2e9dcdae4068460c45a308dd891be5248260251c upstream.
    
    In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit #
    should be no higher than 15, however the corresponding check is obviously off-
    by-one.
    
    Fixes: 045779942c04 ("clk: gate: add CLK_GATE_HIWORD_MASK")
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5746f2d2f1fad069e2de754310b62e19440c0080
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Feb 9 11:53:18 2015 +0100

    sched/autogroup: Fix failure to set cpu.rt_runtime_us
    
    commit 1fe89e1b6d270aa0d3452c60d38461ea589594e3 upstream.
    
    Because task_group() uses a cache of autogroup_task_group(), whose
    output depends on sched_class, switching classes can generate
    problems.
    
    In particular, when started as fair, the cache points to the
    autogroup, so when switching to RT the tg_rt_schedulable() test fails
    for every cpu.rt_{runtime,period}_us change because now the autogroup
    has tasks and no runtime.
    
    Furthermore, going back to the previous semantics of varying
    task_group() with sched_class has the down-side that the sched_debug
    output varies as well, even though the task really is in the
    autogroup.
    
    Therefore add an autogroup exception to tg_has_rt_tasks() -- such that
    both (all) task_group() usages in sched/core now have one. And remove
    all the remnants of the variable task_group() output.
    
    Reported-by: Zefan Li <lizefan@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
    Cc: Stefan Bader <stefan.bader@canonical.com>
    Fixes: 8323f26ce342 ("sched: Fix race in task_group()")
    Link: http://lkml.kernel.org/r/20150209112237.GR5029@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abe2114079571ffcbb410a3b427e528674526a1b
Author: Michal Hocko <mhocko@suse.cz>
Date:   Wed Feb 11 15:28:24 2015 -0800

    vmstat: do not use deferrable delayed work for vmstat_update
    
    commit ba4877b9ca51f80b5d30f304a46762f0509e1635 upstream.
    
    Vinayak Menon has reported that an excessive number of tasks was throttled
    in the direct reclaim inside too_many_isolated() because NR_ISOLATED_FILE
    was relatively high compared to NR_INACTIVE_FILE.  However it turned out
    that the real number of NR_ISOLATED_FILE was 0 and the per-cpu
    vm_stat_diff wasn't transferred into the global counter.
    
    vmstat_work which is responsible for the sync is defined as deferrable
    delayed work which means that the defined timeout doesn't wake up an idle
    CPU.  A CPU might stay in an idle state for a long time and general effort
    is to keep such a CPU in this state as long as possible which might lead
    to all sorts of troubles for vmstat consumers as can be seen with the
    excessive direct reclaim throttling.
    
    This patch basically reverts 39bf6270f524 ("VM statistics: Make timer
    deferrable") but it shouldn't cause any problems for idle CPUs because
    only CPUs with an active per-cpu drift are woken up since 7cc36bbddde5
    ("vmstat: on-demand vmstat workers v8") and CPUs which are idle for a
    longer time shouldn't have per-cpu drift.
    
    Fixes: 39bf6270f524 (VM statistics: Make timer deferrable)
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Reported-by: Vinayak Menon <vinmenon@codeaurora.org>
    Acked-by: Christoph Lameter <cl@linux.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vladimir Davydov <vdavydov@parallels.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: David Rientjes <rientjes@google.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 97df643ce1f1aa7e237bc7c51b6d6fcd848e88fa
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Jan 28 00:45:56 2015 +0100

    pinctrl: imx25: fix numbering for pins
    
    commit 34027ca2bbc6043fea8fc5c4a82670518b6be7df upstream.
    
    The pin id for a given tuple listed in a fsl,pins property is calculated
    by dividing the first entry (which is also a register offset) by 4.
    As the first available register is at offset 0x8 and configures the pad
    MX25_PAD_A10 the right id for this pin is 2. All other pins are off by
    one, too.
    
    This patch drops the definition MX25_PAD_RESERVE1 (together with its
    only use) and decrements all following values by 1.
    
    Fixes: b4a87c9b966f ("pinctrl: pinctrl-imx: add imx25 pinctrl driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a2454e51c75fff6a621bdb5a399aab062d956e
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Tue Jan 27 23:50:25 2015 +0100

    pinctrl: pinctrl-imx: don't use invalid value of conf_reg
    
    commit 4ff0f034e95d65f8f063a362dfcf86e986377a82 upstream.
    
    The right check for conf_reg to be invalid it testing against -1 not 0
    as is done in the rest of the driver.
    
    This fixes an oops that can be triggered by:
    
    	cat /sys/kernel/debug/pinctrl/43fac000.iomuxc/*
    
    Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f98283000a62ec475de3d9a3f2080d1a73e865c
Author: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Date:   Wed Feb 4 00:21:13 2015 +0300

    ath5k: fix spontaneus AR5312 freezes
    
    commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream.
    
    Sometimes while CPU have some load and ath5k doing the wireless
    interface reset the whole WiSoC completely freezes. Set of tests shows
    that using atomic delay function while we wait interface reset helps to
    avoid such freezes.
    
    The easiest way to reproduce this issue: create a station interface,
    start continous scan with wpa_supplicant and load CPU by something. Or
    just create multiple station interfaces and put them all in continous
    scan.
    
    This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
    usleep_range where possible"), which replaces initial udelay()
    by usleep_range().
    
    I do not know actual source of this issue, but all looks like that HW
    freeze is caused by transaction on internal SoC bus, while wireless
    block is in reset state.
    
    Also I should note that I do not know how many chips are affected, but I
    did not see this issue with chips, other than AR5312.
    
    CC: Jiri Slaby <jirislaby@gmail.com>
    CC: Nick Kossifidis <mickflemm@gmail.com>
    CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
    Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
    Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
    Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
    Tested-by: Eric Bree <ebree@nltinc.com>
    Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3449e4060ca5378d21a1536729797314ae6aa405
Author: Andrew Elble <aweits@rit.edu>
Date:   Mon Feb 9 12:53:04 2015 -0500

    GFS2: Fix crash during ACL deletion in acl max entry check in gfs2_set_acl()
    
    commit 278702074ff77b1a3fa2061267997095959f5e2c upstream.
    
    Fixes: e01580bf9e ("gfs2: use generic posix ACL infrastructure")
    Reported-by: Eric Meddaugh <etmsys@rit.edu>
    Tested-by: Eric Meddaugh <etmsys@rit.edu>
    Signed-off-by: Andrew Elble <aweits@rit.edu>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ac80c2fd4214e398b010ff52683924de81c88f5
Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date:   Tue Jan 27 18:01:45 2015 +0000

    of/pci: Free resources on failure in of_pci_get_host_bridge_resources()
    
    commit d2be00c0fb5ae0794deffcdb0425cd5a8d823db0 upstream.
    
    In the function of_pci_get_host_bridge_resources() if the parsing of ranges
    fails, previously allocated resources inclusive of bus_range are not freed
    and are not expected to be freed by the function caller on error return.
    
    This patch fixes the issues by adding code that properly frees resources
    and bus_range before exiting the function with an error return value.
    
    Fixes: cbe4097f8ae6 ("of/pci: Add support for parsing PCI host bridge resources from DT")
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Liviu Dudau <liviu.dudau@arm.com>
    CC: Arnd Bergmann <arnd@arndb.de>
    CC: Rob Herring <robh+dt@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d51da2c0217b18a1a408b1f8b1df1a9a2f6662f
Author: Wanpeng Li <wanpeng.li@linux.intel.com>
Date:   Wed Nov 26 08:44:06 2014 +0800

    sched: Fix hrtick_start() on UP
    
    commit 868933359a3bdda25b562e9d41bce7071edc1b08 upstream.
    
    The commit 177ef2a6315e ("sched/deadline: Fix a precision problem in
    the microseconds range") forgot to change the UP version of
    hrtick_start(), do so now.
    
    Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
    Fixes: 177ef2a6315e ("sched/deadline: Fix a precision problem in the microseconds range")
    [ Fixed the changelog. ]
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Juri Lelli <juri.lelli@arm.com>
    Cc: Kirill Tkhai <ktkhai@parallels.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1416962647-76792-7-git-send-email-wanpeng.li@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d55e0b17994aa9b2aaefe1671b9ef911e16c0384
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jan 9 16:57:12 2015 -0700

    coresight-etm: unlock on error paths in mode_store()
    
    commit 6ad1095990328e7e4b3a0e260825ad4b6406785a upstream.
    
    There are some missing unlocks on the error paths.
    
    Fixes: a939fc5a71ad ('coresight-etm: add CoreSight ETM/PTM driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66719267d8f5746951c407296d75f5d535a2a24d
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Thu Dec 18 14:55:53 2014 -0800

    stable_kernel_rules: reorganize and update submission options
    
    commit 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae upstream.
    
    The current organization of Documentation/stable_kernel_rules.txt
    doesn't clearly differentiate the mutually exclusive options for
    submission to the -stable review process. As I understand it, patches
    are not actually required to be mailed directly to
    stable@vger.kernel.org, but the instructions do not make this clear.
    
    Also, there are some established processes that are not listed --
    specifically, what I call Option 2 below.
    
    This patch updates and reorganizes a bit, to make things clearer.
    
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca729fdf691420fac264199140519c2f746d74c9
Author: Bard Liao <bardliao@realtek.com>
Date:   Mon Feb 16 13:06:45 2015 +0800

    ASoC: rt5670: Set RT5670_IRQ_CTRL1 non volatile
    
    commit 850529249d7cce02e9bfae9476d09c8c51410d28 upstream.
    
    RT5670_IRQ_CTRL1(0xbd) is a non volatile register. And we need to
    restore its value after suspend/resume.
    
    Signed-off-by: Bard Liao <bardliao@realtek.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 770728324034609df329e0622f5d474ac91889b0
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Tue Mar 3 13:38:14 2015 +0200

    ASoC: omap-pcm: Correct dma mask
    
    commit d51199a83a2cf82a291d19ee852c44caa511427d upstream.
    
    DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be
    set to 32.
    The 64 was introduced by commit (in 2009):
    a152ff24b978 ASoC: OMAP: Make DMA 64 aligned
    
    But the dma_mask and coherent_dma_mask can not be used to specify alignment.
    
    Fixes: a152ff24b978 (ASoC: OMAP: Make DMA 64 aligned)
    Reported-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e30b85e87ad77f9388801002a6b06679fbc7a2de
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Thu Feb 26 12:54:46 2015 -0500

    NFSv4: Don't call put_rpccred() under the rcu_read_lock()
    
    commit 7c0af9ffb7bb4e5355470fa60b3eb711ddf226fa upstream.
    
    put_rpccred() can sleep.
    
    Fixes: 8f649c3762547 ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b567d6586968a685389bfca0f4101eb08a4da33
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sun Feb 22 16:35:36 2015 -0500

    NFS: Don't invalidate a submounted dentry in nfs_prime_dcache()
    
    commit 6c441c254eea2354d686be7f5544bcd79fb6a61f upstream.
    
    If we're traversing a directory which contains a submounted filesystem,
    or one that has a referral, the NFS server that is processing the READDIR
    request will often return information for the underlying (mounted-on)
    directory. It may, or may not, also return filehandle information.
    
    If this happens, and the lookup in nfs_prime_dcache() returns the
    dentry for the submounted directory, the filehandle comparison will
    fail, and we call d_invalidate(). Post-commit 8ed936b5671bf
    ("vfs: Lazily remove mounts on unlinked files and directories."), this
    means the entire subtree is unmounted.
    
    The following minimal patch addresses this problem by punting on
    the invalidation if there is a submount.
    
    Kudos to Neil Brown <neilb@suse.de> for having tracked down this
    issue (see link).
    
    Reported-by: Nix <nix@esperi.org.uk>
    Link: http://lkml.kernel.org/r/87iofju9ht.fsf@spindle.srvr.nix
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c05d74e58cc4a61abf2353ce7eb46c52bb39e91c
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Fri Mar 6 15:48:38 2015 +0200

    ACPI / LPSS: provide con_id for the clkdev
    
    commit fcf0789a96777d79d20290e08bf43943a5619387 upstream.
    
    Commit 7d78cbefaa (serial: 8250_dw: add ability to handle
    the peripheral clock) introduces handling for a second clk
    to 8250_dw.c which is the driver also for LPSS UART. The
    second clk forces us to provide identifier (con_id) for the
    clkdev we create.
    
    This fixes an issue where 8250_dw.c is getting the same
    handler for both clocks.
    
    Fixes: 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock)
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 371817cdf176cb53b982aeabdf938ee5c06ced1c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Mar 1 10:41:37 2015 +0000

    ACPI / video: Load the module even if ACPI is disabled
    
    commit 6e17cb12881ba8d5e456b89f072dc6b70048af36 upstream.
    
    i915.ko depends upon the acpi/video.ko module and so refuses to load if
    ACPI is disabled at runtime if for example the BIOS is broken beyond
    repair. acpi/video provides an optional service for i915.ko and so we
    should just allow the modules to load, but do no nothing in order to let
    the machines boot correctly.
    
    Reported-by: Bill Augur <bill-auger@programmer.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Acked-by: Aaron Lu <aaron.lu@intel.com>
    [ rjw: Fixed up the new comment in acpi_video_init() ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1abae049257e1442679c09729243920cb5e600fd
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Feb 24 19:28:10 2015 -0600

    eCryptfs: don't pass fs-specific ioctl commands through
    
    commit 6d65261a09adaa374c05de807f73a144d783669e upstream.
    
    eCryptfs can't be aware of what to expect when after passing an
    arbitrary ioctl command through to the lower filesystem. The ioctl
    command may trigger an action in the lower filesystem that is
    incompatible with eCryptfs.
    
    One specific example is when one attempts to use the Btrfs clone
    ioctl command when the source file is in the Btrfs filesystem that
    eCryptfs is mounted on top of and the destination fd is from a new file
    created in the eCryptfs mount. The ioctl syscall incorrectly returns
    success because the command is passed down to Btrfs which thinks that it
    was able to do the clone operation. However, the result is an empty
    eCryptfs file.
    
    This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl
    commands through and then copies up the inode metadata from the lower
    inode to the eCryptfs inode to catch any changes made to the lower
    inode's metadata. Those five ioctl commands are mostly common across all
    filesystems but the whitelist may need to be further pruned in the
    future.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=93691
    https://launchpad.net/bugs/1305335
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: Rocko <rockorequin@hotmail.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c601ebbd3949d0bf307a61c35542121d98759b
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Feb 19 20:18:03 2015 -0800

    efi/libstub: Fix boundary checking in efi_high_alloc()
    
    commit 7ed620bb343f434f8a85f830020c04988df2a140 upstream.
    
    While adding support loading kernel and initrd above 4G to grub2 in legacy
    mode, I was referring to efi_high_alloc().
    That will allocate buffer for kernel and then initrd, and initrd will
    use kernel buffer start as limit.
    
    During testing found two buffers will be overlapped when initrd size is
    very big like 400M.
    
    It turns out efi_high_alloc() boundary checking is not right.
    end - size will be the new start, and should not compare new
    start with max, we need to make sure end is smaller than max.
    
    [ Basically, with the current efi_high_alloc() code it's possible to
      allocate memory above 'max', because efi_high_alloc() doesn't check
      that the tail of the allocation is below 'max'.
    
      If you have an EFI memory map with a single entry that looks like so,
    
       [0xc0000000-0xc0004000]
    
      And want to allocate 0x3000 bytes below 0xc0003000 the current code
      will allocate [0xc0001000-0xc0004000], not [0xc0000000-0xc0003000]
      like you would expect. - Matt ]
    
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51716c730b1560c1c79c1d7de6115be10b1eef8a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 15 12:21:21 2015 +0300

    efi: Small leak on error in runtime map code
    
    commit 86d68a58d00db3770735b5919ef2c6b12d7f06f3 upstream.
    
    The "> 0" here should ">= 0" so we free map_entries[0].
    
    Fixes: 926172d46038 ('efi: Export EFI runtime memory mapping to sysfs')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Dave Young <dyoung@redhat.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1802992eaf26ba6a1fe4e6789cb348f3a69d7170
Author: Andrew Elble <aweits@rit.edu>
Date:   Wed Feb 25 17:46:27 2015 -0500

    nfsd: fix clp->cl_revoked list deletion causing softlock in nfsd
    
    commit c876486be17aeefe0da569f3d111cbd8de6f675d upstream.
    
    commit 2d4a532d385f ("nfsd: ensure that clp->cl_revoked list is
    protected by clp->cl_lock") removed the use of the reaplist to
    clean out clp->cl_revoked. It failed to change list_entry() to
    walk clp->cl_revoked.next instead of reaplist.next
    
    Fixes: 2d4a532d385f ("nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock")
    Reported-by: Eric Meddaugh <etmsys@rit.edu>
    Tested-by: Eric Meddaugh <etmsys@rit.edu>
    Signed-off-by: Andrew Elble <aweits@rit.edu>
    Reviewed-by: Jeff Layton <jeff.layton@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00076b74987cf251b6a5788d590b32db9ccb400
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Jan 22 16:00:17 2015 +0900

    reservation: Remove shadowing local variable 'ret'
    
    commit 4eb2440ed60fb5793f7aa6da89b3d517cc59de43 upstream.
    
    It was causing the return value of fence_is_signaled to be ignored, making
    reservation objects signal too early.
    
    Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c0f288d39f786bdcaa0c8666e05f1ff747b2aac
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Feb 26 15:53:02 2015 +0000

    drm/i915: Check for driver readyness before handling an underrun interrupt
    
    commit 54fc7c1c961cb39edfe31f8a3f5ba6414e134b37 upstream.
    
    When we takeover from the BIOS and install our interrupt handler, the
    BIOS may have left us a few surprises in the form of spontaneous
    interrupts. (This is especially likely on hardware like 965gm where
    display fifo underruns are continuous and the GMCH cannot filter that
    interrupt souce.) As we enable our IRQ early so that we can use it
    during hardware probing, our interrupt handler must be prepared to
    handle a few sources prior to being fully configured. As such, we need
    to add a simple is-ready check prior to dereferencing our KMS state for
    reporting underruns.
    
    Reported-by: Rob Clark <rclark@redhat.com>
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [Jani: dropped the extra !]
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fddd92aa4bbf7853240fc2ceb80de2e044e22358
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Feb 24 11:14:30 2015 +0200

    drm/i915: avoid processing spurious/shared interrupts in low-power states
    
    commit 2dd2a883aad7c852400027c2261bcab69d9e238e upstream.
    
    Atm, it's possible that the interrupt handler is called when the device
    is in D3 or some other low-power state. It can be due to another device
    that is still in D0 state and shares the interrupt line with i915, or on
    some platforms there could be spurious interrupts even without sharing
    the interrupt line. The latter case was reported by Klaus Ethgen using a
    Lenovo x61p machine (gen 4). He noticed this issue via a system
    suspend/resume hang and bisected it to the following commit:
    
    commit e11aa362308f5de467ce355a2a2471321b15a35c
    Author: Jesse Barnes <jbarnes@virtuousgeek.org>
    Date:   Wed Jun 18 09:52:55 2014 -0700
    
        drm/i915: use runtime irq suspend/resume in freeze/thaw
    
    This is a problem, since in low-power states IIR will always read
    0xffffffff resulting in an endless IRQ servicing loop.
    
    Fix this by handling interrupts only when the driver explicitly enables
    them and so it's guaranteed that the interrupt registers return a valid
    value.
    
    Note that this issue existed even before the above commit, since during
    runtime suspend/resume we never unregistered the handler.
    
    v2:
    - clarify the purpose of smp_mb() vs. synchronize_irq() in the
      code comment (Chris)
    
    v3:
    - no need for an explicit smp_mb(), we can assume that synchronize_irq()
      and the mmio read/writes in the install hooks provide for this (Daniel)
    - remove code comment as the remaining synchronize_irq() is self
      explanatory (Daniel)
    
    v4:
    - drm_irq_uninstall() implies synchronize_irq(), so no need to call it
      explicitly (Daniel)
    
    Reference: https://lkml.org/lkml/2015/2/11/205
    Reported-and-bisected-by: Klaus Ethgen <Klaus@Ethgen.ch>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcff51b5798e3cdca590e06d7dbb919197ff0608
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Feb 19 10:53:39 2015 +0200

    drm/i915: Dell Chromebook 11 has PWM backlight
    
    commit cf6f0af9fbdd90b81af14fa6375387131cd8adf1 upstream.
    
    Add quirk for Dell Chromebook 11 backlight.
    
    Reported-and-tested-by: Owen Garland <garland.owen@gmail.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451
    Acked-by: Damien Lespiau <damien.lespiau@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07843963b59e9f1fc5faef9fc7e03b5eb5a89ee4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Feb 12 07:53:18 2015 +0000

    drm/i915: Check obj->vma_list under the struct_mutex
    
    commit 6c31a614c43ae274546f736b2a33363e149c3dc2 upstream.
    
    When we walk the list of vma, or even for protecting against concurrent
    framebuffer creation, we must hold the struct_mutex or else a second
    thread can corrupt the list as we walk it.
    
    Fixes regression from
    commit d7f46fc4e7323887494db13f063a8e59861fefb0
    Author: Ben Widawsky <benjamin.widawsky@intel.com>
    Date:   Fri Dec 6 14:10:55 2013 -0800
    
        drm/i915: Make pin count per VMA
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=89085
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5c1d274f82501c790c84da92870659aa245f179
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Wed Jan 21 11:46:32 2015 -0800

    drm/i915/bdw: PCI IDs ending in 0xb are ULT.
    
    commit 0dc6f20b9803f09726bbb682649d35cda8ef5b5d upstream.
    
    When reviewing patch that fixes VGA on BDW Halo Jani noticed that
    we also had other ULT IDs that weren't listed there.
    
    So this follow-up patch add these pci-ids as halo and fix comments
    on i915_pciids.h
    
    Cc: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bf1c600c62ba548282f8bb555f622fa27eea2a9
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Feb 19 16:02:15 2015 -0500

    drm/radeon: fix 1 RB harvest config setup for TN/RL
    
    commit dbfb00c3e7e18439f2ebf67fe99bf7a50b5bae1e upstream.
    
    The logic was reversed from what the hw actually exposed.
    Fixes graphics corruption in certain harvest configurations.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2742afe60ceaf837ac915b513be924cab4c2a86d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Feb 18 01:05:30 2015 -0500

    drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh
    
    commit 3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284 upstream.
    
    Just in case it hasn't been calculated for the mode.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba59d6da4dcd6cefe304350a63aef87912c3fdd5
Author: Nathan-J. Hirschauer <nathanhi@deepserve.info>
Date:   Wed Feb 18 02:01:19 2015 +0100

    drm/radeon: enable native backlight control on old macs
    
    commit 7a26f9ad1b5badfd0200ce2262ad696e2a6b7fbb upstream.
    
    Commit b7bc596ebbe0 ("drm/radeon: disable native
    backlight control on pre-r6xx asics (v2)") accidently
    broke backlight control on old mac laptops that use the
    on-GPU backlight controller.
    
    Signed-off-by: Nathan-J. Hirschauer <nathanhi@deepserve.info>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 556621de97a390c4e70ff1256a94418e79b196cb
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Thu Jan 22 15:53:28 2015 -0800

    HID: wacom: Report ABS_MISC event for Cintiq Companion Hybrid
    
    commit 33e5df0e0e32027866e9fb00451952998fc957f2 upstream.
    
    It appears that the Cintiq Companion Hybrid does not send an ABS_MISC event to
    userspace when any of its ExpressKeys are pressed. This is not strictly
    necessary now that the pad exists on its own device, but should be fixed for
    consistency's sake.
    
    Traditionally both the stylus and pad shared the same device node, and
    xf86-input-wacom would use ABS_MISC for disambiguation. Not sending this causes
    the Hybrid to behave incorrectly with xf86-input-wacom beginning with its
    8f44f3 commit.
    
    Signed-off-by: Jason Gerecke <killertofu@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b60843df9138ccf558e0c67ab015af57b7f2d125
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Jan 6 22:34:19 2015 +0100

    HID: fixup the conflicting keyboard mappings quirk
    
    commit 8e7b341037db1835ee6eea64663013cbfcf33575 upstream.
    
    The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion
    on conflicting mappings") needs to properly check for VARIABLE reports
    as well (ARRAY reports should be ignored), otherwise legitimate keyboards
    might break.
    
    Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings")
    Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
    Reported-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e146d4ebec69c68556d41cdbd65bdfb3da90f20a
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Mon Dec 29 15:21:26 2014 +0100

    HID: input: fix confusion on conflicting mappings
    
    commit 6ce901eb61aa30ba8565c62049ee80c90728ef14 upstream.
    
    On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
    neighbours look like this:
    
               +---+ +---+ +-------+
               | 1 | | 2 | |   5   |
               +---+ +---+ +-------+
                 +---+ +-----------+
                 | 3 | |     4     |
                 +---+ +-----------+
    
    On a PC-102/105 keyboard (European layout) it looks like this:
    
               +---+ +---+ +-------+
               | 1 | | 2 | |       |
               +---+ +---+ +-+  4  |
                 +---+ +---+ |     |
                 | 3 | | 5 | |     |
                 +---+ +---+ +-----+
    
    (Note that the number of keys is the same, but key '5' is moved down and
     the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
    
    The keys 1-4 report the same scan-code in HID in both layouts, even though
    the keysym they produce is usually different depending on the XKB-keymap
    used by user-space.
    However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
    and 0x32 for the lower layout, as defined by the HID spec. This is highly
    confusing as the linux-input API uses a single keycode for both.
    
    So far, this was never a problem as there never has been a keyboard with
    both of those keys present at the same time. It would have to look
    something like this:
    
               +---+ +---+ +-------+
               | 1 | | 2 | |  x31  |
               +---+ +---+ +-------+
                 +---+ +---+ +-----+
                 | 3 | |x32| |  4  |
                 +---+ +---+ +-----+
    
    HID can represent such a keyboard, but the linux-input API cannot.
    Furthermore, any user-space mapping would be confused by this and,
    luckily, no-one ever produced such hardware.
    
    Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
    the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
    is present on a hardware, this works just fine.
    
    Lets introduce hardware-vendors into this:
    ------------------------------------------
    
    Unfortunately, it seems way to expensive to produce a different device for
    American and European layouts. Therefore, hardware-vendors put both keys,
    (0x31 and 0x32) on the same keyboard, but only one of them is hooked up
    to the physical button, the other one is 'dead'.
    This means, they can use the same hardware, with a different button-layout
    and automatically produce the correct HID events for American *and*
    European layouts. This is unproblematic for normal keyboards, as the
    'dead' key will never report any KEY-DOWN events. But RollOver keyboards
    send the whole matrix on each key-event, allowing n-key roll-over mode.
    This means, we get a 0x31 and 0x32 event on each key-press. One of them
    will always be 0, the other reports the real state. As we map both to the
    same keycode, we will get spurious key-events, even though the real
    key-state never changed.
    
    The easiest way would be to blacklist 'dead' keys and never handle those.
    We could simply read the 'country' tag of USB devices and blacklist either
    key according to the layout. But... hardware vendors... want the same
    device for all countries and thus many of them set 'country' to 0 for all
    devices. Meh..
    
    So we have to deal with this properly. As we cannot know which of the keys
    is 'dead', we either need a heuristic and track those keys, or we simply
    make use of our value-tracking for HID fields. We simply ignore HID events
    for absolute data if the data didn't change. As HID tracks events on the
    HID level, we haven't done the keycode translation, yet. Therefore, the
    'dead' key is tracked independently of the real key, therefore, any events
    on it will be ignored.
    
    This patch simply discards any HID events for absolute data if it didn't
    change compared to the last report. We need to ignore relative and
    buffered-byte reports for obvious reasons. But those cannot be affected by
    this bug, so we're fine.
    
    Preferably, we'd do this filtering on the HID-core level. But this might
    break a lot of custom drivers, if they do not follow the HID specs.
    Therefore, we do this late in hid-input just before we inject it into the
    input layer (which does the exact same filtering, but on the keycode
    level).
    
    If this turns out to break some devices, we might have to limit filtering
    to EV_KEY events. But lets try to do the Right Thing first, and properly
    filter any absolute data that didn't change.
    
    This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
    hardware. We might wanna wait with backporting for a while, before we know
    it doesn't break anything else, though.
    
    Reported-by: Adam Goode <adam@spicenitz.org>
    Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
    Tested-by: Fredrik Hallenberg <megahallon@gmail.com>
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 330a8414f07972938cad16721d85e1f696c8d6b8
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Jan 19 14:47:27 2015 +0000

    staging: comedi: cb_pcidas64: fix incorrect AI range code handling
    
    commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.
    
    The hardware range code values and list of valid ranges for the AI
    subdevice is incorrect for several supported boards.  The hardware range
    code values for all boards except PCI-DAS4020/12 is determined by
    calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
    and whether it is bipolar or unipolar, however it only returns the
    correct hardware range code for the PCI-DAS60xx boards.  For
    PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
    ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
    ranges and the comedi range table is incorrect.
    
    Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
    member `ai_range_codes` of `struct pcidas64_board` to map the comedi
    range table indices to the hardware range codes.  Use a new comedi range
    table for the PCI-DAS64/Mx/16 boards (and the commented out variants).
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 632151d9f8d9179a975e81870baae4481de7e915
Author: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date:   Wed Feb 18 15:51:41 2015 +0200

    firmware: dmi_scan: Fix dmi scan to handle "End of Table" structure
    
    commit ce204e9a4bd82e9e6e7479bca8057e45aaac5c42 upstream.
    
    The dmi-sysfs should create "End of Table" entry, that is type 127. But
    after adding initial SMBIOS v3 support fc43026278b2 ("dmi: add support
    for SMBIOS 3.0 64-bit entry point") the 127-0 entry is not handled any
    more, as result it's not created in dmi sysfs for instance. This is
    important because the size of whole DMI table must correspond to sum of
    all DMI entry sizes.
    
    So move the end-of-table check after it's handled by dmi_table.
    
    Reviewed-by: Ard Biesheuvel <ard@linaro.org>
    Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96b012a4a065da89401e7cffd7558269b18ca0be
Author: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date:   Wed Feb 18 13:33:19 2015 +0200

    firmware: dmi_scan: Fix dmi_len type
    
    commit 6d9ff473317245e3e5cd9922b4520411c2296388 upstream.
    
    According to SMBIOSv3 specification the length of DMI table can be
    up to 32bits wide. So use appropriate type to avoid overflow.
    
    It's obvious that dmi_num theoretically can be more than u16 also,
    so it's can be changed to u32 or at least it's better to use int
    instead of u16, but on that moment I cannot imagine dmi structure
    count more than 65535 and it can require changing type of vars that
    work with it. So I didn't correct it.
    
    Acked-by: Ard Biesheuvel <ard@linaro.org>
    Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a694d185c0856800f7045b9621a50b704c7302d
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Feb 17 14:34:00 2015 -0500

    dm snapshot: fix a possible invalid memory access on unload
    
    commit 22aa66a3ee5b61e0f4a0bfeabcaa567861109ec3 upstream.
    
    When the snapshot target is unloaded, snapshot_dtr() waits until
    pending_exceptions_count drops to zero.  Then, it destroys the snapshot.
    Therefore, the function that decrements pending_exceptions_count
    should not touch the snapshot structure after the decrement.
    
    pending_complete() calls free_pending_exception(), which decrements
    pending_exceptions_count, and then it performs up_write(&s->lock) and it
    calls retry_origin_bios() which dereferences  s->origin.  These two
    memory accesses to the fields of the snapshot may touch the dm_snapshot
    struture after it is freed.
    
    This patch moves the call to free_pending_exception() to the end of
    pending_complete(), so that the snapshot will not be destroyed while
    pending_complete() is in progress.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6bafcd14630f6fd84a326f1d51ce1466dfd60df
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Feb 17 14:30:53 2015 -0500

    dm: fix a race condition in dm_get_md
    
    commit 2bec1f4a8832e74ebbe859f176d8a9cb20dd97f4 upstream.
    
    The function dm_get_md finds a device mapper device with a given dev_t,
    increases the reference count and returns the pointer.
    
    dm_get_md calls dm_find_md, dm_find_md takes _minor_lock, finds the
    device, tests that the device doesn't have DMF_DELETING or DMF_FREEING
    flag, drops _minor_lock and returns pointer to the device. dm_get_md then
    calls dm_get. dm_get calls BUG if the device has the DMF_FREEING flag,
    otherwise it increments the reference count.
    
    There is a possible race condition - after dm_find_md exits and before
    dm_get is called, there are no locks held, so the device may disappear or
    DMF_FREEING flag may be set, which results in BUG.
    
    To fix this bug, we need to call dm_get while we hold _minor_lock. This
    patch renames dm_find_md to dm_get_md and changes it so that it calls
    dm_get while holding the lock.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 144ab376d2c0342dc0caa050b078a1d9ebb04a9d
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Fri Feb 13 11:05:37 2015 -0800

    dm io: reject unsupported DISCARD requests with EOPNOTSUPP
    
    commit 37527b869207ad4c208b1e13967d69b8bba1fbf9 upstream.
    
    I created a dm-raid1 device backed by a device that supports DISCARD
    and another device that does NOT support DISCARD with the following
    dm configuration:
    
     #  echo '0 2048 mirror core 1 512 2 /dev/sda 0 /dev/sdb 0' | dmsetup create moo
     # lsblk -D
     NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
     sda                 0        4K       1G         0
     `-moo (dm-0)        0        4K       1G         0
     sdb                 0        0B       0B         0
     `-moo (dm-0)        0        4K       1G         0
    
    Notice that the mirror device /dev/mapper/moo advertises DISCARD
    support even though one of the mirror halves doesn't.
    
    If I issue a DISCARD request (via fstrim, mount -o discard, or ioctl
    BLKDISCARD) through the mirror, kmirrord gets stuck in an infinite
    loop in do_region() when it tries to issue a DISCARD request to sdb.
    The problem is that when we call do_region() against sdb, num_sectors
    is set to zero because q->limits.max_discard_sectors is zero.
    Therefore, "remaining" never decreases and the loop never terminates.
    
    To fix this: before entering the loop, check for the combination of
    REQ_DISCARD and no discard and return -EOPNOTSUPP to avoid hanging up
    the mirror device.
    
    This bug was found by the unfortunate coincidence of pvmove and a
    discard operation in the RHEL 6.5 kernel; upstream is also affected.
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Acked-by: "Martin K. Petersen" <martin.petersen@oracle.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5eb2654c6829c2e5dc8f8d4d641b93148bcca300
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Feb 12 10:09:20 2015 -0500

    dm mirror: do not degrade the mirror on discard error
    
    commit f2ed51ac64611d717d1917820a01930174c2f236 upstream.
    
    It may be possible that a device claims discard support but it rejects
    discards with -EOPNOTSUPP.  It happens when using loopback on ext2/ext3
    filesystem driven by the ext4 driver.  It may also happen if the
    underlying devices are moved from one disk on another.
    
    If discard error happens, we reject the bio with -EOPNOTSUPP, but we do
    not degrade the array.
    
    This patch fixes failed test shell/lvconvert-repair-transient.sh in the
    lvm2 testsuite if the testsuite is extracted on an ext2 or ext3
    filesystem and it is being driven by the ext4 driver.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ceed5c2a0a42ae9171338da039ef1b19efd790f
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jan 27 18:16:51 2015 +0000

    staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back
    
    commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream.
    
    `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
    This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
    back to user-space.  (This occurs when the low-level Comedi driver's
    `do_cmdtest()` handler returns non-zero to indicate a problem with the
    contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
    the `CMDF_BOGUS` flag set.)
    
    `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
    version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
    compatible version of `struct comedi_cmd` back to user-space, which is
    at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
    it, change `compat_cmd()` to copy a 32-bit compatible version of the
    `struct comedi_cmd` back to user-space when the main ioctl handler
    returns `-EAGAIN`.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3290574a76c29b219fb3982f41860ba134c36fb
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Jan 24 12:56:32 2015 +0100

    sunxi: clk: Set sun6i-pll1 n_start = 1
    
    commit 76820fcf7aa5a418b69cb7bed31b62d1feb1d6ad upstream.
    
    For all pll-s on sun6i n == 0 means use a multiplier of 1, rather then 0 as
    it means on sun4i / sun5i / sun7i. n_start = 1 is already correctly set
    for sun6i pll6, but was missing for pll1, this commit fixes this.
    
    Cc: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cd24fc0a79caee54b79408c2e0ea816c8eacaf2
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Jan 19 09:57:13 2015 +0000

    clk: Fix debugfs clk removal before inited
    
    commit 52bba9809a954d72bc77773bd560b9724b495eb7 upstream.
    
    Some of the clks can be registered & unregistered before the clk related debugfs
    entries are initialized at late_initcall. In the unregister path checking for only
    dentry before clk_debug_init() would lead dangling pointers in the debug clk list,
    because the list is already populated in register path and the clk pointer freed in
    unregister path.
    The side effect of not removing it from the list is either a null pointer
    dereference or if lucky to boot the system, the number of clk entries in
    debugfs disappear.
    
    We could add more checks like if (inited && !clk->dentry) but just removing
    the check for dentry made more sense as debugfs_remove_recursive() seems to be
    safe with null pointers. This will ensure that the unregistering clk would be
    removed from the debug list in all the code paths.
    
    Without this patch kernel would crash with log:
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c0204000
    [00000000] *pgd=00000000
    Internal error: Oops: 5 [#1] SMP ARM
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Tainted: G    B          3.19.0-rc3-00007-g412f9ba-dirty #840
    Hardware name: Qualcomm (Flattened Device Tree)
    task: ed948000 ti: ed944000 task.ti: ed944000
    PC is at strlen+0xc/0x40
    LR is at __create_file+0x64/0x1dc
    pc : [<c04ee604>]    lr : [<c049f1c4>]    psr: 60000013
    sp : ed945e40  ip : ed945e50  fp : ed945e4c
    r10: 00000000  r9 : c1006094  r8 : 00000000
    r7 : 000041ed  r6 : 00000000  r5 : ed4af998  r4 : c11b5e28
    r3 : 00000000  r2 : ed945e38  r1 : a0000013  r0 : 00000000
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    Control: 10c5787d  Table: 8020406a  DAC: 00000015
    Process swapper/0 (pid: 1, stack limit = 0xed944248)
    Stack: (0xed945e40 to 0xed946000)
    5e40: ed945e7c ed945e50 c049f1c4 c04ee604 c0fc2fa4 00000000 ecb748c0 c11c2b80
    5e60: c0beec04 0000011c c0fc2fa4 00000000 ed945e94 ed945e80 c049f3e0 c049f16c
    5e80: 00000000 00000000 ed945eac ed945e98 c08cbc50 c049f3c0 ecb748c0 c11c2b80
    5ea0: ed945ed4 ed945eb0 c0fc3080 c08cbc30 c0beec04 c107e1d8 ecdf0600 c107e1d8
    5ec0: c107e1d8 ecdf0600 ed945f54 ed945ed8 c0208ed4 c0fc2fb0 c026a784 c04ee628
    5ee0: ed945f0c ed945ef0 c0f5d600 c04ee604 c0f5d5ec ef7fcc7d c0b40ecc 0000011c
    5f00: ed945f54 ed945f10 c026a994 c0f5d5f8 c04ecc00 00000007 ef7fcc95 00000007
    5f20: c0e90744 c0dd0884 ed945f54 c106cde0 00000007 c117f8c0 0000011c c0f5d5ec
    5f40: c1006094 c100609c ed945f94 ed945f58 c0f5de34 c0208e50 00000007 00000007
    5f60: c0f5d5ec be9b5ae0 00000000 c117f8c0 c0af1680 00000000 00000000 00000000
    5f80: 00000000 00000000 ed945fac ed945f98 c0af169c c0f5dd2c ed944000 00000000
    5fa0: 00000000 ed945fb0 c020f298 c0af168c 00000000 00000000 00000000 00000000
    5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ebcc6d33 bfffca73
    [<c04ee604>] (strlen) from [<c049f1c4>] (__create_file+0x64/0x1dc)
    [<c049f1c4>] (__create_file) from [<c049f3e0>] (debugfs_create_dir+0x2c/0x34)
    [<c049f3e0>] (debugfs_create_dir) from [<c08cbc50>] (clk_debug_create_one+0x2c/0x16c)
    [<c08cbc50>] (clk_debug_create_one) from [<c0fc3080>] (clk_debug_init+0xdc/0x144)
    [<c0fc3080>] (clk_debug_init) from [<c0208ed4>] (do_one_initcall+0x90/0x1e0)
    [<c0208ed4>] (do_one_initcall) from [<c0f5de34>] (kernel_init_freeable+0x114/0x1e0)
    [<c0f5de34>] (kernel_init_freeable) from [<c0af169c>] (kernel_init+0x1c/0xfc)
    [<c0af169c>] (kernel_init) from [<c020f298>] (ret_from_fork+0x14/0x3c)
    Code: c0b40ecc e1a0c00d e92dd800 e24cb004 (e5d02000)
    ---[ end trace b940e45b5e25c1e7 ]---
    
    Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation"
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dad96ab777646836b86ec41701f22c3148c31ee2
Author: Soren Brinkmann <soren.brinkmann@xilinx.com>
Date:   Tue Jan 27 11:05:27 2015 -0800

    clk: zynq: Force CPU_2X clock to be ungated
    
    commit 3dccfecdb867fe35b305a4e493ef5652b7d9d4cb upstream.
    
    The CPU_2X clock does not have a classical in-kernel user, but is,
    amongst other things, required for OCM and debug access. Make sure this
    clock is not mistakenly disabled during boot up by enabling it in the
    platform's clock driver.
    
    Fixes: 0ee52b157b8e 'clk: zynq: Add clock controller driver'
    Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Michael Turquette <mturquette@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b62b65857443af31f1b92b7bbcf0419ea4aa857
Author: Minh Duc Tran <MinhDuc.Tran@Emulex.Com>
Date:   Mon Feb 9 18:54:09 2015 +0000

    fixed invalid assignment of 64bit mask to host dma_boundary for scatter gather segment boundary limit.
    
    commit f76a610a8b4b6280eaedf48f3af9d5d74e418b66 upstream.
    
    In reference to bug https://bugzilla.redhat.com/show_bug.cgi?id=1097141
    Assert is seen with AMD cpu whenever calling pci_alloc_consistent.
    
    [   29.406183] ------------[ cut here ]------------
    [   29.410505] kernel BUG at lib/iommu-helper.c:13!
    
    Signed-off-by: Minh Tran <minh.tran@emulex.com>
    Fixes: 6733b39a1301b0b020bbcbf3295852e93e624cb1
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 189a021fffea59620d912989d14e1eff15710e3a
Author: Ondrej Zary <linux@rainbow-software.org>
Date:   Mon Feb 9 13:38:21 2015 +0100

    wd719x: add missing .module to wd719x_template
    
    commit 2ecf8e0ae28cb22d434e628c351c6193fd75fafa upstream.
    
    wd719x_template is missing the .module field, causing module refcount
    not to work, allowing to rmmod the driver while in use (mounted filesystem),
    causing an oops.
    
    Set .module to THIS_MODULE to fix the problem.
    
    Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2ad09ddf093623f966a62102d1590b42d2b6fa1
Author: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Date:   Fri Feb 27 15:51:56 2015 -0800

    nilfs2: fix potential memory overrun on inode
    
    commit 957ed60b53b519064a54988c4e31e0087e47d091 upstream.
    
    Each inode of nilfs2 stores a root node of a b-tree, and it turned out to
    have a memory overrun issue:
    
    Each b-tree node of nilfs2 stores a set of key-value pairs and the number
    of them (in "bn_nchildren" member of nilfs_btree_node struct), as well as
    a few other "bn_*" members.
    
    Since the value of "bn_nchildren" is used for operations on the key-values
    within the b-tree node, it can cause memory access overrun if a large
    number is incorrectly set to "bn_nchildren".
    
    For instance, nilfs_btree_node_lookup() function determines the range of
    binary search with it, and too large "bn_nchildren" leads
    nilfs_btree_node_get_key() in that function to overrun.
    
    As for intermediate b-tree nodes, this is prevented by a sanity check
    performed when each node is read from a drive, however, no sanity check
    has been done for root nodes stored in inodes.
    
    This patch fixes the issue by adding missing sanity check against b-tree
    root nodes so that it's called when on-memory inodes are read from ifile,
    inode metadata file.
    
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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 00da0c72472a5512bd8fccf52973b6c4f545793b
Author: Ilya Nelkenbaum <ilyan@mellanox.com>
Date:   Thu Feb 5 13:53:48 2015 +0200

    IB/core: When marshaling ucma path from user-space, clear unused fields
    
    commit c2be9dc0e0fa59cc43c2c7084fc42b430809a0fe upstream.
    
    When marshaling a user path to the kernel struct ib_sa_path, we need
    to zero smac and dmac and set the vlan id to the "no vlan" value.
    
    This is to ensure that Ethernet attributes are not used with
    InfiniBand QPs.
    
    Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures")
    Signed-off-by: Ilya Nelkenbaum <ilyan@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26f9e525c4993205c7119859f2046ec726e6c25d
Author: Haggai Eran <haggaie@mellanox.com>
Date:   Tue Jan 6 13:56:02 2015 +0200

    IB/core: Properly handle registration of on-demand paging MRs after dereg
    
    commit 4fc701ead77ede96df3e8b3de13fdf2b1326ee5b upstream.
    
    When the last on-demand paging MR is released the notifier count is
    left non-zero so that concurrent page faults will have to abort. If a
    new MR is then registered, the counter is reset. However, the decision
    is made to put the new MR in the list waiting for the notifier count
    to reach zero, before the counter is reset. An invalidation or another
    MR registration can release the MR to handle page faults, but without
    such an event the MR can wait forever.
    
    The patch fixes this issue by adding a check whether the MR is the
    first on-demand paging MR when deciding whether it is ready to handle
    page faults. If it is the first MR, we know that there are no mmu
    notifiers running in parallel to the registration.
    
    Fixes: 882214e2b128 ("IB/core: Implement support for MMU notifiers regarding on demand paging regions")
    Signed-off-by: Haggai Eran <haggaie@mellanox.com>
    Signed-off-by: Shachar Raindel <raindel@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db2b084cd0e1fd7f98b0b82965b2d6581bc79e02
Author: Moshe Lazer <moshel@mellanox.com>
Date:   Thu Feb 5 13:53:52 2015 +0200

    IB/core: Fix deadlock on uverbs modify_qp error flow
    
    commit 0fb8bcf022f19a375d7c4bd79ac513da8ae6d78b upstream.
    
    The deadlock occurs in __uverbs_modify_qp: we take a lock (idr_read_qp)
    and in case of failure in ib_resolve_eth_l2_attrs we don't release
    it (put_qp_read).  Fix that.
    
    Fixes: ed4c54e5b4ba ("IB/core: Resolve Ethernet L2 addresses when modifying QP")
    Signed-off-by: Moshe Lazer <moshel@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d524fcea1f1bef297cae09a9d8bde4f60ed0c61e
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed Dec 17 16:17:34 2014 +0200

    IB/mlx4: Fix wrong usage of IPv4 protocol for multicast attach/detach
    
    commit e9a7faf11af94957e5107b40af46c2e329541510 upstream.
    
    The MLX4_PROT_IB_IPV4 protocol should only be used with RoCEv2 and such.
    Removing this wrong usage allows to run multicast applications over RoCE.
    
    Fixes: d487ee77740c ("IB/mlx4: Use IBoE (RoCE) IP based GIDs in the port GID table")
    Reported-by: Carol Soto <clsoto@linux.vnet.ibm.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 419672eea8f4f0fd1a7692e066389f1094ea152d
Author: Majd Dibbiny <majd@mellanox.com>
Date:   Thu Jan 29 10:41:41 2015 +0200

    IB/mlx4: Fix memory leak in __mlx4_ib_modify_qp
    
    commit bede98e781747623ae170667694a71ef19c6ba7f upstream.
    
    In case handle_eth_ud_smac_index fails, we need to free the allocated resources.
    
    Fixes: 2f5bb473681b ("mlx4: Add ref counting to port MAC table for RoCE")
    Signed-off-by: Majd Dibbiny <majd@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3f855626a6ccc309472f4adb2217b019af39f2b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jan 12 11:56:58 2015 +0300

    IB/mlx5: Fix error code in get_port_caps()
    
    commit f614fc15ae39ceb531586e3969f2b99fd23182a0 upstream.
    
    The current code returns success when kmalloc() fails.  It should
    return an error code, -ENOMEM.
    
    Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a86bea695e4c6a6678e48596f8785b66789dae7
Author: Roi Dayan <roid@mellanox.com>
Date:   Sun Dec 28 14:26:11 2014 +0200

    IB/iser: Use correct dma direction when unmapping SGs
    
    commit c6c95ef4cec680f7a10aa425a9970744b35b6489 upstream.
    
    We always unmap SGs with the same direction instead of unmapping
    with the direction the mapping was done, fix that.
    
    Fixes: 9a8b08fad2ef ("IB/iser: Generalize iser_unmap_task_data and [...]")
    Signed-off-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90bbda5070bfa913b4d7b50e4b31659fe4994776
Author: Sagi Grimberg <sagig@mellanox.com>
Date:   Sun Jan 18 16:51:06 2015 +0200

    IB/iser: Fix memory regions possible leak
    
    commit 6606e6a2ff2710b473838b291dc533cd8fc1471f upstream.
    
    When teardown process starts during live IO, we need to keep the
    memory regions pool (frmr/fmr) until all in-flight tasks are properly
    released, since each task may return a memory region to the pool. In
    order to do this, we pass a destroy flag to iser_free_ib_conn_res to
    indicate we can destroy the device and the memory regions
    pool. iser_conn_release will pass it as true and also DEVICE_REMOVAL
    event (we need to let the device to properly remove).
    
    Also, Since we conditionally call iser_free_rx_descriptors,
    remove the extra check on iser_conn->rx_descs.
    
    Fixes: 5426b1711fd0 ("IB/iser: Collapse cleanup and disconnect handlers")
    Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f3e58c469f29c908b410dc775f4bd08fb523d50
Author: Mitko Haralanov <mitko.haralanov@intel.com>
Date:   Fri Jan 16 08:55:27 2015 -0500

    IB/qib: Do not write EEPROM
    
    commit 18c0b82a3e4501511b08d0e8676fb08ac08734a3 upstream.
    
    This changeset removes all the code that allows the driver to write to
    the EEPROM and update the recorded error counters and power on hours.
    
    These two stats are unused and writing them exposes a timing risk
    which could leave the EEPROM in a bad state preventing further normal
    operation of the HCA.
    
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Mitko Haralanov <mitko.haralanov@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 003692d8d302302caafddc96d700ca6c0dad257c
Author: Tony Battersby <tonyb@cybernetics.com>
Date:   Wed Feb 11 11:32:06 2015 -0500

    sg: fix read() error reporting
    
    commit 3b524a683af8991b4eab4182b947c65f0ce1421b upstream.
    
    Fix SCSI generic read() incorrectly returning success after detecting an
    error.
    
    Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6221586c98cc3d1e3754c29df1206b6fe9f06394
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Feb 17 16:43:43 2015 +0100

    locking/rtmutex: Avoid a NULL pointer dereference on deadlock
    
    commit 8d1e5a1a1ccf5ae9d8a5a0ee7960202ccb0c5429 upstream.
    
    With task_blocks_on_rt_mutex() returning early -EDEADLK we never
    add the waiter to the waitqueue. Later, we try to remove it via
    remove_waiter() and go boom in rt_mutex_top_waiter() because
    rb_entry() gives a NULL pointer.
    
    ( Tested on v3.18-RT where rtmutex is used for regular mutex and I
      tried to get one twice in a row. )
    
    Not sure when this started but I guess 397335f004f4 ("rtmutex: Fix
    deadlock detector for real") or commit 3d5c9340d194 ("rtmutex:
    Handle deadlock detection smarter").
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1424187823-19600-1-git-send-email-bigeasy@linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 985defee8634240a01da504c81198a4d52aeb028
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Mar 6 14:03:57 2015 +0800

    ALSA: hda - One more Dell macine needs DELL1_MIC_NO_PRESENCE quirk
    
    commit 70658b99490dd86cfdbf4fca117bbe2ef9a80d03 upstream.
    
    BugLink: https://bugs.launchpad.net/bugs/1428947
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be31e55a3f9d83b1385bdde6cfe13777615bf6ea
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Fri Feb 27 09:39:32 2015 +0900

    ALSA: oxfw: fix a condition and return code in start_stream()
    
    commit f2b14c0bc510c6a8f67a4f36049deefe5d99a537 upstream.
    
    The amdtp_stream_wait_callback() doesn't return minus value and
    the return code is not for error code.
    
    This commit fixes with a propper condition and an error code.
    
    Fixes: f3699e2c7745 ('ALSA: oxfw: Change the way to start stream')
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aaec23cdaf872b643da8cc54ed71af37fc27ff39
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Feb 25 07:53:31 2015 +0100

    ALSA: hda - Disable runtime PM for Panther Point again
    
    commit de5d0ad506cb10ab143e2ffb9def7607e3671f83 upstream.
    
    This is essentially a partial revert of the commit [b1920c21102a:
    'ALSA: hda - Enable runtime PM on Panther Point'].  There was a bug
    report showing the HD-audio bus hang during runtime PM on HP Spectre
    XT.
    
    Reported-by: Dang Sananikone <dang.sananikone@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b983991880eeae927a4ce31bfe76b54e8fd40cf0
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Tue Feb 24 12:04:57 2015 +0100

    ALSA: hda: controller code - do not export static functions
    
    commit 37ed398839fa3e0d2de77925097db7a370abb096 upstream.
    
    It is a bad idea to export static functions. GCC for some platforms
    shows errors like:
    
      error: __ksymtab_azx_get_response causes a section type conflict
    
    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 547eea7bd46cb4551273bee0c775d4da5c62d5a5
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Feb 21 23:55:00 2015 +0900

    ALSA: fireworks/bebob/dice/oxfw: make it possible to shutdown safely
    
    commit dec84316dd53c90e93b4ee849483bd4bd1e9a585 upstream.
    
    A part of these drivers, especially BeBoB driver, are programmed to wait
    some events. Thus the drivers should not destroy any data in .remove()
    context.
    
    This commit moves some destructors from 'struct fw_driver.remove()' to
    'struct snd_card.private_free()' to shutdown safely.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e6dddf2532e416d6fb10f1ca86319e45a534cba
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Feb 21 23:54:59 2015 +0900

    ALSA: fireworks/bebob/dice/oxfw: allow stream destructor after releasing runtime
    
    commit d23c2cc4485d10f0cedfef99dd2961d9652b1b3f upstream.
    
    Currently stream destructor in each driver has a problem to be called in
    a context in which sound card object is released, because the destructors
    call amdtp_stream_pcm_abort() and touch PCM runtime data.
    
    The PCM runtime data is destroyed in application's context with
    snd_pcm_close(), on the other hand PCM substream data is destroyed after
    sound card object is released, in most case after all of ALSA character
    devices are released. When PCM runtime is destroyed and PCM substream is
    remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes
    Null-pointer-dereference.
    
    This commit changes stream destructors and allows each driver to call
    it after releasing runtime.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1972576af1db89251965ab266fd05aa58ff8e73
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Feb 21 23:54:58 2015 +0900

    ALSA: firewire-lib: remove reference counting
    
    commit c6f224dc20ad959175c2dfec70b5a61c6503a793 upstream.
    
    AMDTP helper functions increment/decrement reference counter for an
    instance of FireWire unit, while it's complicated for each driver to
    process error state.
    
    In previous commit, each driver has the role of reference counting. This
    commit removes this role from the helper function.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a5d626d0c627edd44347b0c55a7726faef95a3c
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Feb 21 23:54:57 2015 +0900

    ALSA: fireworks/bebob/dice/oxfw: add reference-counting for FireWire unit
    
    commit 12ed719291a953d443921f9cdb0ffee41066c340 upstream.
    
    Fireworks and Dice drivers try to touch instances of FireWire unit after
    sound card object is released, while references to the unit is decremented
    in .remove(). When unplugging during streaming, sound card object is
    released after .remove(), thus Fireworks and Dice drivers causes GPF or
    Null-pointer-dereferencing to application processes because an instance of
    FireWire unit was already released.
    
    This commit adds reference-counting for FireWire unit in drivers to allow
    them to touch an instance of FireWire unit after .remove(). In most case,
    any operations after .remove() may be failed safely.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e820f2b245ca9003589e9bddf768c0d068289c94
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Feb 19 13:01:37 2015 +0100

    ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec
    
    commit 6426460e5d87810e042962281fe3c1e8fc256162 upstream.
    
    BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need
    to give explicitly here.
    
    Reported-and-tested-by: Misan Thropos <misanthropos@gmx.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39bba749fa0219e1dd6925525eb51ee77794f72f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Dec 18 10:02:41 2014 +0100

    ALSA: pcm: Don't leave PREPARED state after draining
    
    commit 70372a7566b5e552dbe48abdac08c275081d8558 upstream.
    
    When a PCM draining is performed to an empty stream that has been
    already in PREPARED state, the current code just ignores and leaves as
    it is, although the drain is supposed to set all such streams to SETUP
    state.  This patch covers that overlooked case.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb1ca99e7f6b8edaef78cfb2eca6d215cc8765a9
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Sun Feb 15 18:32:16 2015 +0100

    serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO"
    
    commit ca8bb4aefb932e3da105f28cbfba36d57a931081 upstream.
    
    This reverts commit 0aa525d11859c1a4d5b78fdc704148e2ae03ae13.
    
    The conditional RX-FIFO read seems to cause spurious interrupts and we
    see just:
    |serial8250: too much work for irq29
    
    The previous behaviour was "default" for decades and Marvell's 88f6282 SoC
    might not be the only that relies on it. Therefore the Omap fix is
    reverted for now.
    
    Fixes: 0aa525d11859 ("tty: serial: 8250_core: read only RX if there is
    something in the FIFO")
    Reported-By: Nicolas Schichan <nschichan@freebox.fr>
    Debuged-By: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6656cf2fd5d654291931fa2afc5d06b61597aa2
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Feb 27 18:40:31 2015 +0100

    tty: fix up atime/mtime mess, take four
    
    commit f0bf0bd07943bfde8f5ac39a32664810a379c7d3 upstream.
    
    This problem was taken care of three times already in
    * b0de59b5733d18b0d1974a060860a8b5c1b36a2e (TTY: do not update
      atime/mtime on read/write),
    * 37b7f3c76595e23257f61bd80b223de8658617ee (TTY: fix atime/mtime
      regression), and
    * b0b885657b6c8ef63a46bc9299b2a7715d19acde (tty: fix up atime/mtime
      mess, take three)
    
    But it still misses one point. As John Paul correctly points out, we
    do not care about setting date. If somebody ever changes wall
    time backwards (by mistake for example), tty timestamps are never
    updated until the original wall time passes.
    
    So check the absolute difference of times and if it large than "8
    seconds or so", always update the time. That means we will update
    immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
    check, but it was always that way.
    
    Thanks John for serving me this so nicely debugged.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: John Paul Perry <john_paul.perry@alcatel-lucent.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14e96578f09632cdad32bc5eb0891acb26c4dbec
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Feb 27 10:39:17 2015 +0530

    ARC: Fix KSTK_ESP()
    
    commit 13648b0118a24f4fc76c34e6c7b6ccf447e46a2a upstream.
    
    /proc/<pid>/maps currently don't annotate stack vma with "[stack]"
    This is because KSTK_ESP ie expected to return usermode SP of tsk while
    currently it returns the kernel mode SP of a sleeping tsk.
    
    While the fix is trivial, we also need to adjust the ARC kernel stack
    unwinder to not use KSTK_SP and friends any more.
    
    Reported-and-suggested-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fed3a7947cc3954189dfd99baa7e5a48b760040
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Feb 13 13:08:25 2015 -0500

    SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock
    
    commit 813b00d63f6ca1ed40a2f4f9c034d59bc424025e upstream.
    
    Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock.
    xprt_complete_bc_request() should do the same.
    
    Fixes: 2ea24497a1b3 ("SUNRPC: RPC callbacks may be split . . .")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 202935e63a83d8295f74da296e255a8bfcb2c209
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Sat Mar 7 21:08:46 2015 +0000

    sunrpc: fix braino in ->poll()
    
    commit 1711fd9addf214823b993468567cab1f8254fc51 upstream.
    
    POLL_OUT isn't what callers of ->poll() are expecting to see; it's
    actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
    bit...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e95e69b89481deafaed9cf98fa1c7ae0c716d82c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 21 22:16:11 2015 -0500

    procfs: fix race between symlink removals and traversals
    
    commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9 upstream.
    
    use_pde()/unuse_pde() in ->follow_link()/->put_link() resp.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea149d39ea943c2022b2389faab508bc02363b52
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 21 22:05:11 2015 -0500

    debugfs: leave freeing a symlink body until inode eviction
    
    commit 0db59e59299f0b67450c5db21f7f316c8fb04e84 upstream.
    
    As it is, we have debugfs_remove() racing with symlink traversals.
    Supply ->evict_inode() and do freeing there - inode will remain
    pinned until we are done with the symlink body.
    
    And rip the idiocy with checking if dentry is positive right after
    we'd verified debugfs_positive(), which is a stronger check...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17a75de122bc850b3570d08757840f6798c113a3
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Fri Feb 6 16:28:17 2015 +0100

    autofs4: Wrong format for printing dentry
    
    commit 76bf3f6b1d6ac4c770bb121b0461c460aa068e64 upstream.
    
    %pD for struct file*, %pd for struct dentry*.
    
    Fixes: a455589f181e ("assorted conversions to %p[dD]")
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2f96bd06255a75ecae881adff82ac7eed226866
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 21 22:19:57 2015 -0500

    autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation
    
    commit 0a280962dc6e117e0e4baa668453f753579265d9 upstream.
    
    X-Coverup: just ask spender
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2cfb7dc7d236003bd8631f61a56a1d26d4b3b9c
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Feb 18 10:34:51 2015 +0700

    USB: serial: fix tty-device error handling at probe
    
    commit ca4383a3947a83286bc9b9c598a1f55e867871d7 upstream.
    
    Add missing error handling when registering the tty device at port
    probe. This avoids trying to remove an uninitialised character device
    when the port device is removed.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0db70c6d0c0d782ea2959278723a3d30bfa92de0
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Feb 18 10:34:50 2015 +0700

    USB: serial: fix potential use-after-free after failed probe
    
    commit 07fdfc5e9f1c966be8722e8fa927e5ea140df5ce upstream.
    
    Fix return value in probe error path, which could end up returning
    success (0) on errors. This could in turn lead to use-after-free or
    double free (e.g. in port_remove) when the port device is removed.
    
    Fixes: c706ebdfc895 ("USB: usb-serial: call port_probe and port_remove
    at the right times")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1fdf10bac5b902687c8aa693fe70ff40051b4d3
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Mar 4 10:39:06 2015 +0100

    TTY: fix tty_wait_until_sent on 64-bit machines
    
    commit 79fbf4a550ed6a22e1ae1516113e6c7fa5d56a53 upstream.
    
    Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
    infinite timeout (0) would be passed to the underlying tty-driver's
    wait_until_sent-operation as a negative timeout (-1), causing it to
    return immediately.
    
    This manifests itself for example as tcdrain() returning immediately,
    drivers not honouring the drain flags when setting terminal attributes,
    or even dropped data on close as a requested infinite closing-wait
    timeout would be ignored.
    
    The first symptom  was reported by Asier LLANO who noted that tcdrain()
    returned prematurely when using the ftdi_sio usb-serial driver.
    
    Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
    underlying tty driver.
    
    Note that the serial-core wait_until_sent-implementation is not affected
    by this bug due to a lucky chance (comparison to an unsigned maximum
    timeout), and neither is the cyclades one that had an explicit check for
    negative timeouts, but all other tty drivers appear to be affected.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: ZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0385cedcdfc205910ece9200bdd7fa30535f4349
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Mar 4 10:39:05 2015 +0100

    USB: serial: fix infinite wait_until_sent timeout
    
    commit f528bf4f57e43d1af4b2a5c97f09e43e0338c105 upstream.
    
    Make sure to handle an infinite timeout (0).
    
    Note that wait_until_sent is currently never called with a 0-timeout
    argument due to a bug in tty_wait_until_sent.
    
    Fixes: dcf010503966 ("USB: serial: add generic wait_until_sent
    implementation")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0c9b824b2f38ae9c8a455f8a9c8f6021f7cb905
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Mar 4 10:39:03 2015 +0100

    net: irda: fix wait_until_sent poll timeout
    
    commit 2c3fbe3cf28fbd7001545a92a83b4f8acfd9fa36 upstream.
    
    In case an infinite timeout (0) is requested, the irda wait_until_sent
    implementation would use a zero poll timeout rather than the default
    200ms.
    
    Note that wait_until_sent is currently never called with a 0-timeout
    argument due to a bug in tty_wait_until_sent.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8239b52a120cf2e6b7ac6320000dddb4bde507eb
Author: Luciano Coelho <luciano.coelho@intel.com>
Date:   Tue Dec 16 16:01:39 2014 +0200

    mac80211: notify channel switch at the end of ieee80211_chswitch_post_beacon()
    
    commit 688b1ecfb9ed0484754d2653386e3c44c58ede5c upstream.
    
    The call to cfg80211_ch_switch_notify() should be at the end of the
    ieee80211_chswitch_post_beacon() function, because it should only be
    sent if everything succeeded.
    
    Fixes: d04b5ac9e70b ("cfg80211/mac80211: allow any interface to send channel switch notifications")
    Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a34f1cb903e43aa39aaab80b68af64e0e3afacc
Author: Jouni Malinen <jouni@qca.qualcomm.com>
Date:   Thu Feb 26 15:50:50 2015 +0200

    mac80211: Send EAPOL frames at lowest rate
    
    commit 9c1c98a3bb7b7593b60264b9a07e001e68b46697 upstream.
    
    The current minstrel_ht rate control behavior is somewhat optimistic in
    trying to find optimum TX rate. While this is usually fine for normal
    Data frames, there are cases where a more conservative set of retry
    parameters would be beneficial to make the connection more robust.
    
    EAPOL frames are critical to the authentication and especially the
    EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
    important to get through to the AP. If that message is lost, the only
    recovery mechanism in many cases is to reassociate with the AP and start
    from scratch. This can often be avoided by trying to send the frame with
    more conservative rate and/or with more link layer retries.
    
    In most cases, minstrel_ht is currently using the initial EAPOL-Key
    frames for probing higher rates and this results in only five link layer
    transmission attempts (one at high(ish) MCS and four at MCS0). While
    this works with most APs, it looks like there are some deployed APs that
    may have issues with the EAPOL frames using HT MCS immediately after
    association. Similarly, there may be issues in cases where the signal
    strength or radio environment is not good enough to be able to get
    frames through even at couple of MCS 0 tries.
    
    The best approach for this would likely to be to reduce the TX rate for
    the last rate (3rd rate parameter in the set) to a low basic rate (say,
    6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
    requires some more effort. For now, we can start with a simple one-liner
    that forces the minimum rate to be used for EAPOL frames similarly how
    the TX rate is selected for the IEEE 802.11 Management frames. This does
    result in a small extra latency added to the cases where the AP would be
    able to receive the higher rate, but taken into account how small number
    of EAPOL frames are used, this is likely to be insignificant. A future
    optimization in the minstrel_ht design can also allow this patch to be
    reverted to get back to the more optimized initial TX rate.
    
    It should also be noted that many drivers that do not use minstrel as
    the rate control algorithm are already doing similar workarounds by
    forcing the lowest TX rate to be used for EAPOL frames.
    
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f51b8a1bd956b9d0edc995a33c2ced44217643d1
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Mar 6 17:23:19 2015 +0200

    xhci: Workaround for PME stuck issues in Intel xhci
    
    commit b8cb91e058cd0c0f02059c1207293c5b31d350fa upstream.
    
    The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
    workaround for a Stuck PME that might either block PME events in suspend,
    or create spurious PME events preventing runtime suspend.
    
    Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
    PMCTRL register at offset 0x80a4, in both suspend resume callbacks
    
    Without this, xhci connected usb devices might never be able to wake up the
    system from suspend, or prevent device from going to suspend (xhci d3)
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19584ca9b13815ee7e565b8f8ec4bf32a2c2c472
Author: Aleksander Morgado <aleksander@aleksander.es>
Date:   Fri Mar 6 17:14:21 2015 +0200

    xhci: fix reporting of 0-sized URBs in control endpoint
    
    commit 45ba2154d12fc43b70312198ec47085f10be801a upstream.
    
    When a control transfer has a short data stage, the xHCI controller generates
    two transfer events: a COMP_SHORT_TX event that specifies the untransferred
    amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
    COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
    urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
    urb->actual_length was set already by a previous COMP_SHORT_TX event.
    
    The driver checks this by seeing whether urb->actual_length == 0, but this alone
    is the wrong test, as it is entirely possible for a short transfer to have an
    urb->actual_length = 0.
    
    This patch changes the xhci driver to rely on a new td->urb_length_set flag,
    which is set to true when a COMP_SHORT_TX event is received and the URB length
    updated at that stage.
    
    This fixes a bug which affected the HSO plugin, which relies on URBs with
    urb->actual_length == 0 to halt re-submitting the RX URB in the control
    endpoint.
    
    Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f88b0324fa3b93dd80f2f931ddee1d556d6781a
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Feb 24 18:27:01 2015 +0200

    xhci: Allocate correct amount of scratchpad buffers
    
    commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream.
    
    Include the high order bit fields for Max scratchpad buffers when
    calculating how many scratchpad buffers are needed.
    
    I'm suprised this hasn't caused more issues, we never allocated more than
    32 buffers even if xhci needed more. Either we got lucky and xhci never
    really used past that area, or then we got enough zeroed dma memory anyway.
    
    Should be backported as far back as possible
    
    Reported-by: Tim Chen <tim.c.chen@linux.intel.com>
    Tested-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ae021266fd88e9e1a7394a255e0c28b17e88b7d
Author: Maxime Ripard <maxime.ripard@free-electrons.com>
Date:   Tue Feb 24 18:27:00 2015 +0200

    usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
    
    commit 1e7e4fb66489cc84366656ca5318f1cb61afd4ba upstream.
    
    The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
    375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
    375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
    
    However, that quirk was run before the clock the controllers needs has been
    enabled. This usually worked because the clock was first enabled by the
    bootloader, and left as such until the driver is probe, where it tries to
    access the MBUS configuration registers before enabling the clock.
    
    Things get messy when EPROBE_DEFER is involved during the probe, since as part
    of its error path, the driver will rightfully disable the clock. When the
    driver will be reprobed, it will retry to access the MBUS registers, but this
    time with the clock disabled, which hangs forever.
    
    Fix this by running the quirks after the clock has been enabled by the driver.
    
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f735fd3314b2dcee082db379afc3c5074cef5bca
Author: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Date:   Fri Feb 13 12:12:53 2015 +0100

    usb: gadget: configfs: don't NUL-terminate (sub)compatible ids
    
    commit a0456399fb07155637a2b597b91cc1c63bc25141 upstream.
    
    The "Extended Compat ID OS Feature Descriptor Specification" does not
    require the (sub)compatible ids to be NUL-terminated, because they
    are placed in a fixed-size buffer and only unused parts of it should
    contain NULs. If the buffer is fully utilized, there is no place for NULs.
    
    Consequently, the code which uses desc->ext_compat_id never expects the
    data contained to be NUL terminated.
    
    If the compatible id is stored after sub-compatible id, and the compatible
    id is full length (8 bytes), the (useless) NUL terminator overwrites the
    first byte of the sub-compatible id.
    
    If the sub-compatible id is full length (8 bytes), the (useless) NUL
    terminator ends up out of the buffer. The situation can happen in the RNDIS
    function, where the buffer is a part of struct f_rndis_opts. The next
    member of struct f_rndis_opts is a mutex, so its first byte gets
    overwritten. The said byte is a part of a mutex'es member which contains
    the information on whether the muext is locked or not. This can lead to a
    deadlock, because, in a configfs-composed gadget when a function is linked
    into a configuration with config_usb_cfg_link(), usb_get_function()
    is called, which then calls rndis_alloc(), which tries locking the same
    mutex and (wrongly) finds it already locked.
    
    This patch eliminates NUL terminating of the (sub)compatible id.
    
    Fixes: da4243145fb1: "usb: gadget: configfs: OS Extended Compatibility descriptors support"
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ebbda9ff931844cae217e11f59fe918f9df0dd0
Author: George Cherian <george.cherian@ti.com>
Date:   Fri Feb 13 10:13:24 2015 +0530

    usb: dwc3: dwc3-omap: Fix disable IRQ
    
    commit 96e5d31244c5542f5b2ea81d76f14ba4b8a7d440 upstream.
    
    In the wrapper the IRQ disable should be done by writing 1's to the
    IRQ*_CLR register. Existing code is broken because it instead writes
    zeros to IRQ*_SET register.
    
    Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
    dwc3_omap_write_irq0_clr() which do the right thing.
    
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Signed-off-by: George Cherian <george.cherian@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3ecce096759db41ab4130e674e2a9debc5c135d
Author: Max Mansfield <max.m.mansfield@gmail.com>
Date:   Mon Mar 2 18:38:02 2015 -0700

    usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards
    
    commit c7d373c3f0da2b2b78c4b1ce5ae41485b3ef848c upstream.
    
    This patch integrates Cyber Cortex AV boards with the existing
    ftdi_jtag_quirk in order to use serial port 0 with JTAG which is
    required by the manufacturers' software.
    
    Steps: 2
    
    [ftdi_sio_ids.h]
    1. Defined the device PID
    
    [ftdi_sio.c]
    2. Added a macro declaration to the ids array, in order to enable the
    jtag quirk for the device.
    
    Signed-off-by: Max Mansfield <max.m.mansfield@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8a475bd78c31403dbc7d1e342d5afdd5d1f79e2
Author: Mark Glover <mark@actisense.com>
Date:   Fri Feb 13 09:04:39 2015 +0000

    USB: ftdi_sio: add PIDs for Actisense USB devices
    
    commit f6950344d3cf4a1e231b5828b50c4ac168db3886 upstream.
    
    These product identifiers (PID) all deal with marine NMEA format data
    used on motor boats and yachts. We supply the programmed devices to
    Chetco, for use inside their equipment. The PIDs are a direct copy of
    our Windows device drivers (FTDI drivers with altered PIDs).
    
    Signed-off-by: Mark Glover <mark@actisense.com>
    [johan: edit commit message slightly ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af774ee88fa197407f43205f0b427bb206998ef5
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Feb 13 10:54:53 2015 -0500

    USB: usbfs: don't leak kernel data in siginfo
    
    commit f0c2b68198589249afd2b1f2c4e8de8c03e19c16 upstream.
    
    When a signal is delivered, the information in the siginfo structure
    is copied to userspace.  Good security practice dicatates that the
    unused fields in this structure should be initialized to 0 so that
    random kernel stack data isn't exposed to the user.  This patch adds
    such an initialization to the two places where usbfs raises signals.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Dave Mielke <dave@mielke.cc>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e1f2e34fdfc8df71c58ef2552cecb5df848979a
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Feb 18 11:51:07 2015 +0700

    USB: mxuport: fix null deref when used as a console
    
    commit db81de767e375743ebb0ad2bcad3326962c2b67e upstream.
    
    Fix null-pointer dereference at probe when the device is used as a
    console, in which case the tty argument to open will be NULL.
    
    Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
    driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Greg Kroah-Hartman <greg@kroah.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63834eef1577cef63aee30b17bff109ddb558a3d
Author: Michiel vd Garde <mgparser@gmail.com>
Date:   Fri Feb 27 02:08:29 2015 +0100

    USB: serial: cp210x: Adding Seletek device id's
    
    commit 675af70856d7cc026be8b6ea7a8b9db10b8b38a1 upstream.
    
    These device ID's are not associated with the cp210x module currently,
    but should be. This patch allows the devices to operate upon connecting
    them to the usb bus as intended.
    
    Signed-off-by: Michiel van de Garde <mgparser@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8356c502a889d7796e36989e5c59fa5e82e5ceb9
Author: Johan Hovold <johan@kernel.org>
Date:   Sun Feb 15 11:57:53 2015 +0700

    Revert "USB: serial: make bulk_out_size a lower limit"
    
    commit bc4b1f486fe69b86769e07c8edce472327a8462b upstream.
    
    This reverts commit 5083fd7bdfe6760577235a724cf6dccae13652c2.
    
    A bulk-out size smaller than the end-point size is indeed valid. The
    offending commit broke the usb-debug driver for EHCI debug devices,
    which use 8-byte buffers.
    
    Fixes: 5083fd7bdfe6 ("USB: serial: make bulk_out_size a lower limit")
    Reported-by: "Li, Elvin" <elvin.li@intel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5c2f30b5b29313198cf430e7b48949eb97ea717
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Feb 23 13:41:14 2015 +0100

    uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539
    
    commit 59e980efafd27df83a5c85c054f906d82bcbf752 upstream.
    
    Like the JMicron JMS567 enclosures with the JMS539 choke on report-opcodes,
    so avoid it.
    
    Tested-and-reported-by: Tom Arild Naess <tanaess@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89fce062e1c6c6e2a3a94c68b93ddb65ba1744ad
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Feb 24 11:46:20 2015 +0000

    KVM: MIPS: Fix trace event to save PC directly
    
    commit b3cffac04eca9af46e1e23560a8ee22b1bd36d43 upstream.
    
    Currently the guest exit trace event saves the VCPU pointer to the
    structure, and the guest PC is retrieved by dereferencing it when the
    event is printed rather than directly from the trace record. This isn't
    safe as the printing may occur long afterwards, after the PC has changed
    and potentially after the VCPU has been freed. Usually this results in
    the same (wrong) PC being printed for multiple trace events. It also
    isn't portable as userland has no way to access the VCPU data structure
    when interpreting the trace record itself.
    
    Lets save the actual PC in the structure so that the correct value is
    accessible later.
    
    Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1feb25231a0653a395ed17baefc29aa42b43c9e
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Feb 12 17:04:47 2015 +0100

    KVM: emulate: fix CMPXCHG8B on 32-bit hosts
    
    commit 4ff6f8e61eb7f96d3ca535c6d240f863ccd6fb7d upstream.
    
    This has been broken for a long time: it broke first in 2.6.35, then was
    almost fixed in 2.6.36 but this one-liner slipped through the cracks.
    The bug shows up as an infinite loop in Windows 7 (and newer) boot on
    32-bit hosts without EPT.
    
    Windows uses CMPXCHG8B to write to page tables, which causes a
    page fault if running without EPT; the emulator is then called from
    kvm_mmu_page_fault.  The loop then happens if the higher 4 bytes are
    not 0; the common case for this is that the NX bit (bit 63) is 1.
    
    Fixes: 6550e1f165f384f3a46b60a1be9aba4bc3c2adad
    Fixes: 16518d5ada690643453eb0aef3cc7841d3623c2d
    Reported-by: Erik Rull <erik.rull@rdsoftware.de>
    Tested-by: Erik Rull <erik.rull@rdsoftware.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0539dd5ecdcb164afc72aafd102db8626e42e49
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date:   Tue Mar 3 16:31:38 2015 +0100

    Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref.
    
    commit dd9ef135e3542ffc621c4eb7f0091870ec7a1504 upstream.
    
    Improper arithmetics when calculting the address of the extended ref could
    lead to an out of bounds memory read and kernel panic.
    
    Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4a7f91a08bd06f430c72b482c46386b4f3268e7
Author: Filipe Manana <fdmanana@suse.com>
Date:   Sun Mar 1 20:36:00 2015 +0000

    Btrfs: fix data loss in the fast fsync path
    
    commit 3a8b36f378060d20062a0918e99fae39ff077bf0 upstream.
    
    When using the fast file fsync code path we can miss the fact that new
    writes happened since the last file fsync and therefore return without
    waiting for the IO to finish and write the new extents to the fsync log.
    
    Here's an example scenario where the fsync will miss the fact that new
    file data exists that wasn't yet durably persisted:
    
    1. fs_info->last_trans_committed == N - 1 and current transaction is
       transaction N (fs_info->generation == N);
    
    2. do a buffered write;
    
    3. fsync our inode, this clears our inode's full sync flag, starts
       an ordered extent and waits for it to complete - when it completes
       at btrfs_finish_ordered_io(), the inode's last_trans is set to the
       value N (via btrfs_update_inode_fallback -> btrfs_update_inode ->
       btrfs_set_inode_last_trans);
    
    4. transaction N is committed, so fs_info->last_trans_committed is now
       set to the value N and fs_info->generation remains with the value N;
    
    5. do another buffered write, when this happens btrfs_file_write_iter
       sets our inode's last_trans to the value N + 1 (that is
       fs_info->generation + 1 == N + 1);
    
    6. transaction N + 1 is started and fs_info->generation now has the
       value N + 1;
    
    7. transaction N + 1 is committed, so fs_info->last_trans_committed
       is set to the value N + 1;
    
    8. fsync our inode - because it doesn't have the full sync flag set,
       we only start the ordered extent, we don't wait for it to complete
       (only in a later phase) therefore its last_trans field has the
       value N + 1 set previously by btrfs_file_write_iter(), and so we
       have:
    
           inode->last_trans <= fs_info->last_trans_committed
               (N + 1)              (N + 1)
    
       Which made us not log the last buffered write and exit the fsync
       handler immediately, returning success (0) to user space and resulting
       in data loss after a crash.
    
    This can actually be triggered deterministically and the following excerpt
    from a testcase I made for xfstests triggers the issue. It moves a dummy
    file across directories and then fsyncs the old parent directory - this
    is just to trigger a transaction commit, so moving files around isn't
    directly related to the issue but it was chosen because running 'sync' for
    example does more than just committing the current transaction, as it
    flushes/waits for all file data to be persisted. The issue can also happen
    at random periods, since the transaction kthread periodicaly commits the
    current transaction (about every 30 seconds by default).
    The body of the test is:
    
      _scratch_mkfs >> $seqres.full 2>&1
      _init_flakey
      _mount_flakey
    
      # Create our main test file 'foo', the one we check for data loss.
      # By doing an fsync against our file, it makes btrfs clear the 'needs_full_sync'
      # bit from its flags (btrfs inode specific flags).
      $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 8K" \
                      -c "fsync" $SCRATCH_MNT/foo | _filter_xfs_io
    
      # Now create one other file and 2 directories. We will move this second file
      # from one directory to the other later because it forces btrfs to commit its
      # currently open transaction if we fsync the old parent directory. This is
      # necessary to trigger the data loss bug that affected btrfs.
      mkdir $SCRATCH_MNT/testdir_1
      touch $SCRATCH_MNT/testdir_1/bar
      mkdir $SCRATCH_MNT/testdir_2
    
      # Make sure everything is durably persisted.
      sync
    
      # Write more 8Kb of data to our file.
      $XFS_IO_PROG -c "pwrite -S 0xbb 8K 8K" $SCRATCH_MNT/foo | _filter_xfs_io
    
      # Move our 'bar' file into a new directory.
      mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar
    
      # Fsync our first directory. Because it had a file moved into some other
      # directory, this made btrfs commit the currently open transaction. This is
      # a condition necessary to trigger the data loss bug.
      $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1
    
      # Now fsync our main test file. If the fsync succeeds, we expect the 8Kb of
      # data we wrote previously to be persisted and available if a crash happens.
      # This did not happen with btrfs, because of the transaction commit that
      # happened when we fsynced the parent directory.
      $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
    
      # Simulate a crash/power loss.
      _load_flakey_table $FLAKEY_DROP_WRITES
      _unmount_flakey
    
      _load_flakey_table $FLAKEY_ALLOW_WRITES
      _mount_flakey
    
      # Now check that all data we wrote before are available.
      echo "File content after log replay:"
      od -t x1 $SCRATCH_MNT/foo
    
      status=0
      exit
    
    The expected golden output for the test, which is what we get with this
    fix applied (or when running against ext3/4 and xfs), is:
    
      wrote 8192/8192 bytes at offset 0
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      wrote 8192/8192 bytes at offset 8192
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      File content after log replay:
      0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
      *
      0020000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
      *
      0040000
    
    Without this fix applied, the output shows the test file does not have
    the second 8Kb extent that we successfully fsynced:
    
      wrote 8192/8192 bytes at offset 0
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      wrote 8192/8192 bytes at offset 8192
      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      File content after log replay:
      0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
      *
      0020000
    
    So fix this by skipping the fsync only if we're doing a full sync and
    if the inode's last_trans is <= fs_info->last_trans_committed, or if
    the inode is already in the log. Also remove setting the inode's
    last_trans in btrfs_file_write_iter since it's useless/unreliable.
    
    Also because btrfs_file_write_iter no longer sets inode->last_trans to
    fs_info->generation + 1, don't set last_trans to 0 if we bail out and don't
    bail out if last_trans is 0, otherwise something as simple as the following
    example wouldn't log the second write on the last fsync:
    
      1. write to file
    
      2. fsync file
    
      3. fsync file
           |--> btrfs_inode_in_log() returns true and it set last_trans to 0
    
      4. write to file
           |--> btrfs_file_write_iter() no longers sets last_trans, so it
                remained with a value of 0
      5. fsync
           |--> inode->last_trans == 0, so it bails out without logging the
                second write
    
    A test case for xfstests will be sent soon.
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0d0ff380cb70231be173dbbcce430da873d92a7
Author: David Sterba <dsterba@suse.cz>
Date:   Tue Feb 24 18:57:18 2015 +0100

    btrfs: fix lost return value due to variable shadowing
    
    commit 1932b7be973b554ffe20a5bba6ffaed6fa995cdc upstream.
    
    A block-local variable stores error code but btrfs_get_blocks_direct may
    not return it in the end as there's a ret defined in the function scope.
    
    Fixes: d187663ef24c ("Btrfs: lock extents as we map them in DIO")
    Signed-off-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3ee1f705fd616cd6471db75ab7873fe240fa813
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Feb 9 17:17:43 2015 +0000

    Btrfs: fix fsync race leading to ordered extent memory leaks
    
    commit 4d884fceaa2c838abb598778813e93f6d9fea723 upstream.
    
    We can have multiple fsync operations against the same file during the
    same transaction and they can collect the same ordered extents while they
    don't complete (still accessible from the inode's ordered tree). If this
    happens, those ordered extents will never get their reference counts
    decremented to 0, leading to memory leaks and inode leaks (an iput for an
    ordered extent's inode is scheduled only when the ordered extent's refcount
    drops to 0). The following sequence diagram explains this race:
    
             CPU 1                                         CPU 2
    
    btrfs_sync_file()
    
                                                     btrfs_sync_file()
    
      mutex_lock(inode->i_mutex)
      btrfs_log_inode()
        btrfs_get_logged_extents()
          --> collects ordered extent X
          --> increments ordered
              extent X's refcount
        btrfs_submit_logged_extents()
      mutex_unlock(inode->i_mutex)
    
                                                       mutex_lock(inode->i_mutex)
      btrfs_sync_log()
         btrfs_wait_logged_extents()
           --> list_del_init(&ordered->log_list)
                                                         btrfs_log_inode()
                                                           btrfs_get_logged_extents()
                                                             --> Adds ordered extent X
                                                                 to logged_list because
                                                                 at this point:
                                                                 list_empty(&ordered->log_list)
                                                                 && test_bit(BTRFS_ORDERED_LOGGED,
                                                                             &ordered->flags) == 0
                                                             --> Increments ordered extent
                                                                 X's refcount
           --> check if ordered extent's io is
               finished or not, start it if
               necessary and wait for it to finish
           --> sets bit BTRFS_ORDERED_LOGGED
               on ordered extent X's flags
               and adds it to trans->ordered
      btrfs_sync_log() finishes
    
                                                           btrfs_submit_logged_extents()
                                                         btrfs_log_inode() finishes
                                                       mutex_unlock(inode->i_mutex)
    
    btrfs_sync_file() finishes
    
                                                       btrfs_sync_log()
                                                          btrfs_wait_logged_extents()
                                                            --> Sees ordered extent X has the
                                                                bit BTRFS_ORDERED_LOGGED set in
                                                                its flags
                                                            --> X's refcount is untouched
                                                       btrfs_sync_log() finishes
    
                                                     btrfs_sync_file() finishes
    
    btrfs_commit_transaction()
      --> called by transaction kthread for e.g.
      btrfs_wait_pending_ordered()
        --> waits for ordered extent X to
            complete
        --> decrements ordered extent X's
            refcount by 1 only, corresponding
            to the increment done by the fsync
            task ran by CPU 1
    
    In the scenario of the above diagram, after the transaction commit,
    the ordered extent will remain with a refcount of 1 forever, leaking
    the ordered extent structure and preventing the i_count of its inode
    from ever decreasing to 0, since the delayed iput is scheduled only
    when the ordered extent's refcount drops to 0, preventing the inode
    from ever being evicted by the VFS.
    
    Fix this by using the flag BTRFS_ORDERED_LOGGED differently. Use it to
    mean that an ordered extent is already being processed by an fsync call,
    which will attach it to the current transaction, preventing it from being
    collected by subsequent fsync operations against the same inode.
    
    This race was introduced with the following change (added in 3.19 and
    backported to stable 3.18 and 3.17):
    
      Btrfs: make sure logged extents complete in the current transaction V3
      commit 50d9aa99bd35c77200e0e3dd7a72274f8304701f
    
    I ran into this issue while running xfstests/generic/113 in a loop, which
    failed about 1 out of 10 runs with the following warning in dmesg:
    
    [ 2612.440038] WARNING: CPU: 4 PID: 22057 at fs/btrfs/disk-io.c:3558 free_fs_root+0x36/0x133 [btrfs]()
    [ 2612.442810] Modules linked in: btrfs crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop processor parport_pc parport psmouse therma
    l_sys i2c_piix4 serio_raw pcspkr evdev microcode button i2c_core ext4 crc16 jbd2 mbcache sd_mod sg sr_mod cdrom virtio_scsi ata_generic virtio_pci ata_piix virtio_ring libata virtio flo
    ppy e1000 scsi_mod [last unloaded: btrfs]
    [ 2612.452711] CPU: 4 PID: 22057 Comm: umount Tainted: G        W      3.19.0-rc5-btrfs-next-4+ #1
    [ 2612.454921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
    [ 2612.457709]  0000000000000009 ffff8801342c3c78 ffffffff8142425e ffff88023ec8f2d8
    [ 2612.459829]  0000000000000000 ffff8801342c3cb8 ffffffff81045308 ffff880046460000
    [ 2612.461564]  ffffffffa036da56 ffff88003d07b000 ffff880046460000 ffff880046460068
    [ 2612.463163] Call Trace:
    [ 2612.463719]  [<ffffffff8142425e>] dump_stack+0x4c/0x65
    [ 2612.464789]  [<ffffffff81045308>] warn_slowpath_common+0xa1/0xbb
    [ 2612.466026]  [<ffffffffa036da56>] ? free_fs_root+0x36/0x133 [btrfs]
    [ 2612.467247]  [<ffffffff810453c5>] warn_slowpath_null+0x1a/0x1c
    [ 2612.468416]  [<ffffffffa036da56>] free_fs_root+0x36/0x133 [btrfs]
    [ 2612.469625]  [<ffffffffa036f2a7>] btrfs_drop_and_free_fs_root+0x93/0x9b [btrfs]
    [ 2612.471251]  [<ffffffffa036f353>] btrfs_free_fs_roots+0xa4/0xd6 [btrfs]
    [ 2612.472536]  [<ffffffff8142612e>] ? wait_for_completion+0x24/0x26
    [ 2612.473742]  [<ffffffffa0370bbc>] close_ctree+0x1f3/0x33c [btrfs]
    [ 2612.475477]  [<ffffffff81059d1d>] ? destroy_workqueue+0x148/0x1ba
    [ 2612.476695]  [<ffffffffa034e3da>] btrfs_put_super+0x19/0x1b [btrfs]
    [ 2612.477911]  [<ffffffff81153e53>] generic_shutdown_super+0x73/0xef
    [ 2612.479106]  [<ffffffff811540e2>] kill_anon_super+0x13/0x1e
    [ 2612.480226]  [<ffffffffa034e1e3>] btrfs_kill_super+0x17/0x23 [btrfs]
    [ 2612.481471]  [<ffffffff81154307>] deactivate_locked_super+0x3b/0x50
    [ 2612.482686]  [<ffffffff811547a7>] deactivate_super+0x3f/0x43
    [ 2612.483791]  [<ffffffff8116b3ed>] cleanup_mnt+0x59/0x78
    [ 2612.484842]  [<ffffffff8116b44c>] __cleanup_mnt+0x12/0x14
    [ 2612.485900]  [<ffffffff8105d019>] task_work_run+0x8f/0xbc
    [ 2612.486960]  [<ffffffff810028d8>] do_notify_resume+0x5a/0x6b
    [ 2612.488083]  [<ffffffff81236e5b>] ? trace_hardirqs_on_thunk+0x3a/0x3f
    [ 2612.489333]  [<ffffffff8142a17f>] int_signal+0x12/0x17
    [ 2612.490353] ---[ end trace 54a960a6bdcb8d93 ]---
    [ 2612.557253] VFS: Busy inodes after unmount of sdb. Self-destruct in 5 seconds.  Have a nice day...
    
    Kmemleak confirmed the ordered extent leak (and btrfs inode specific
    structures such as delayed nodes):
    
    $ cat /sys/kernel/debug/kmemleak
    unreferenced object 0xffff880154290db0 (size 576):
      comm "btrfsck", pid 21980, jiffies 4295542503 (age 1273.412s)
      hex dump (first 32 bytes):
        01 40 00 00 01 00 00 00 b0 1d f1 4e 01 88 ff ff  .@.........N....
        00 00 00 00 00 00 00 00 c8 0d 29 54 01 88 ff ff  ..........)T....
      backtrace:
        [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a
        [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83
        [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190
        [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac
        [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs]
        [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs]
        [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs]
        [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs]
        [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs]
        [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed
        [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa
        [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b
        [<ffffffff81429e92>] system_call_fastpath+0x12/0x17
        [<ffffffffffffffff>] 0xffffffffffffffff
    unreferenced object 0xffff88014ef11db0 (size 576):
      comm "rm", pid 22009, jiffies 4295542593 (age 1273.052s)
      hex dump (first 32 bytes):
        02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 c8 1d f1 4e 01 88 ff ff  ...........N....
      backtrace:
        [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a
        [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83
        [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190
        [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac
        [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs]
        [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs]
        [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs]
        [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs]
        [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs]
        [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed
        [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa
        [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b
        [<ffffffff81429e92>] system_call_fastpath+0x12/0x17
        [<ffffffffffffffff>] 0xffffffffffffffff
    unreferenced object 0xffff8800336feda8 (size 584):
      comm "aio-stress", pid 22031, jiffies 4295543006 (age 1271.400s)
      hex dump (first 32 bytes):
        00 40 3e 00 00 00 00 00 00 00 8f 42 00 00 00 00  .@>........B....
        00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
      backtrace:
        [<ffffffff8114eb34>] create_object+0x172/0x29a
        [<ffffffff8141d790>] kmemleak_alloc+0x25/0x41
        [<ffffffff81141ae6>] kmemleak_alloc_recursive.constprop.52+0x16/0x18
        [<ffffffff81145288>] kmem_cache_alloc+0xf7/0x198
        [<ffffffffa0389243>] __btrfs_add_ordered_extent+0x43/0x309 [btrfs]
        [<ffffffffa038968b>] btrfs_add_ordered_extent_dio+0x12/0x14 [btrfs]
        [<ffffffffa03810e2>] btrfs_get_blocks_direct+0x3ef/0x571 [btrfs]
        [<ffffffff81181349>] do_blockdev_direct_IO+0x62a/0xb47
        [<ffffffff8118189a>] __blockdev_direct_IO+0x34/0x36
        [<ffffffffa03776e5>] btrfs_direct_IO+0x16a/0x1e8 [btrfs]
        [<ffffffff81100373>] generic_file_direct_write+0xb8/0x12d
        [<ffffffffa038615c>] btrfs_file_write_iter+0x24b/0x42f [btrfs]
        [<ffffffff8118bb0d>] aio_run_iocb+0x2b7/0x32e
        [<ffffffff8118c99a>] do_io_submit+0x26e/0x2ff
        [<ffffffff8118ca3b>] SyS_io_submit+0x10/0x12
        [<ffffffff81429e92>] system_call_fastpath+0x12/0x17
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2c34feb23e605beeca80ce1780ac5b6614838e7
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Tue Feb 10 10:36:36 2015 +0200

    mei: make device disabled on stop unconditionally
    
    commit 6c15a8516b8118eb19a59fd0bd22df41b9101c32 upstream.
    
    Set the internal device state to to disabled after hardware reset in stop flow.
    This will cover cases when driver was not brought to disabled state because of
    an error and in stop flow we wish not to retry the reset.
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75552ee54adb3f21719afd4e335b23a8a39b68b5
Author: Jonathan Cameron <jic23@kernel.org>
Date:   Sat Feb 14 11:32:17 2015 +0000

    Revert "iio:humidity:si7020: fix pointer to i2c client"
    
    commit e765537add38cf7967efa11999bb5daf84a6517d upstream.
    
    This reverts commit e0922e5e3ccb78aa0152e93dfbd1755ac39c8582.
    Requested by Andrey Smirnov.
    
    It incorrectly assumes that the level of indirection is not needed
    which is not true(probably because the driver incorrectly allocates
    sizeof(*client) instead of sizeof(*data) via devm_iio_device_alloc).
    If you look at the code of the probe function(see below) it is easy to
    see that what is being stored in the private memory of the IIO device
    instance is not a copy of a 'struct i2c_client' but a pointer to an
    instance passed as an argument to the probe function.
    
    struct i2c_client **data;
    int ret;
    
    < Some code skipped >
    
    indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*client));
    if (!indio_dev)
    return -ENOMEM;
    
    data = iio_priv(indio_dev);
    *data = client;
    
    Without reverting this change any read of a raw value of this sensor
    leads to a kernel oops due to a NULL pointer de-reference on my
    hardware setup.
    
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc77d1f2ff85e75ff2c9ac3ec462116468f98a63
Author: Andrey Smirnov <andrew.smirnov@gmail.com>
Date:   Thu Feb 12 23:58:41 2015 -0800

    IIO: si7020: Allocate correct amount of memory in devm_iio_device_alloc
    
    commit e01becbad300712a28f29b666e685536f45e83bc upstream.
    
    Since only a pointer to struct i2c_client is stored in a private area
    of IIO device created by the driver there's no need to allocate
    sizeof(struct i2c_client) worth of storage.
    
    Pushed to stable as this is linked to the revert patch previously.
    Without this followup the original patch looks sensible.
    
    Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3b2ffcff53dbd5358c04c1d8582dcf5b3421643
Author: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Date:   Wed Feb 4 15:14:26 2015 +0100

    iio:adc:mcp3422 Fix incorrect scales table
    
    commit 9e128ced3851d2802b6db870f6b2e93f449ce013 upstream.
    
    This patch fixes uncorrect order of mcp3422_scales table, the values
    was erroneously transposed.
    It removes also an unused array and a wrong comment.
    
    Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3616899d426f40854d104eae0cd7dd6d13268f7
Author: Urs Fässler <urs.fassler@bytesatwork.ch>
Date:   Mon Feb 2 17:12:23 2015 +0100

    iio: ad5686: fix optional reference voltage declaration
    
    commit da019f59cb16570e78feaf10380ac65a3a06861e upstream.
    
    When not using the "_optional" function, a dummy regulator is returned
    and the driver fails to initialize.
    
    Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fc76bbea3153b71689ebd61edab3b8868b04c27
Author: Kristina Martšenko <kristina.martsenko@gmail.com>
Date:   Sun Jan 25 18:28:22 2015 +0200

    iio: mxs-lradc: only update the buffer when its conversions have finished
    
    commit 89bb35e200bee745c539a96666e0792301ca40f1 upstream.
    
    Using the touchscreen while running buffered capture results in the
    buffer reporting lots of wrong values, often just zeros. This is because
    we push readings to the buffer every time a touchscreen interrupt
    arrives, including when the buffer's own conversions have not yet
    finished. So let's only push to the buffer when its conversions are
    ready.
    
    Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b55aacbd93ed7117ee1fb17dba974fe685dc11e
Author: Kristina Martšenko <kristina.martsenko@gmail.com>
Date:   Sun Jan 25 18:28:21 2015 +0200

    iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
    
    commit 6abe0300a1d5242f4ff89257197f284679af1a06 upstream.
    
    Reading a channel through sysfs, or starting a buffered capture, can
    occasionally turn off the touchscreen.
    
    This is because the read_raw() and buffer preenable()/postdisable()
    callbacks unschedule current conversions on all channels. If a delay
    channel happens to schedule a touchscreen conversion at the same time,
    the conversion gets cancelled and the touchscreen sequence stops.
    
    This is probably related to this note from the reference manual:
    
    	"If a delay group schedules channels to be sampled and a manual
    	write to the schedule field in CTRL0 occurs while the block is
    	discarding samples, the LRADC will switch to the new schedule
    	and will not sample the channels that were previously scheduled.
    	The time window for this to happen is very small and lasts only
    	while the LRADC is discarding samples."
    
    So make the callbacks only unschedule conversions for the channels they
    use. This means channel 0 for read_raw() and channels 0-5 for the buffer
    (if the touchscreen is enabled). Since the touchscreen uses different
    channels (6 and 7), it no longer gets turned off.
    
    This is tested and fixes the issue on i.MX28, but hasn't been tested on
    i.MX23.
    
    Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 119b8ee8826d5352589e3ecbafd3ff05d0ec3cdf
Author: Kristina Martšenko <kristina.martsenko@gmail.com>
Date:   Sun Jan 25 18:28:20 2015 +0200

    iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
    
    commit 86bf7f3ef7e961e91e16dceb31ae0f583483b204 upstream.
    
    Reading a channel through sysfs, or starting a buffered capture, will
    currently turn off the touchscreen. This is because the read_raw() and
    buffer preenable()/postdisable() callbacks disable interrupts for all
    LRADC channels, including those the touchscreen uses.
    
    So make the callbacks only disable interrupts for the channels they use.
    This means channel 0 for read_raw() and channels 0-5 for the buffer (if
    the touchscreen is enabled). Since the touchscreen uses different
    channels (6 and 7), it no longer gets turned off.
    
    Note that only i.MX28 is affected by this issue, i.MX23 should be fine.
    
    Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec43713668e5c247eda1d6a829a59879f4068619
Author: Kristina Martšenko <kristina.martsenko@gmail.com>
Date:   Sun Jan 25 18:28:19 2015 +0200

    iio: mxs-lradc: separate touchscreen and buffer virtual channels
    
    commit f81197b8a31b8fb287ae57f597b5b6841e1ece92 upstream.
    
    The touchscreen was initially designed [1] to map all of its physical
    channels to one virtual channel, leaving buffered capture to use the
    remaining 7 virtual channels. When the touchscreen was reimplemented
    [2], it was made to use four virtual channels, which overlap and
    conflict with the channels the buffer uses.
    
    As a result, when the buffer is enabled, the touchscreen's virtual
    channels are remapped to whichever physical channels the buffer was
    configured with, causing the touchscreen to read those instead of the
    touch measurement channels. Effectively the touchscreen stops working.
    
    So here we separate the channels again, giving the touchscreen 2 virtual
    channels and the buffer 6. We can't give the touchscreen just 1 channel
    as before, as the current pressure calculation requires 2 channels to be
    read at the same time.
    
    This makes the touchscreen continue to work during buffered capture. It
    has been tested on i.MX28, but not on i.MX23.
    
    [1] 06ddd353f5c8 ("iio: mxs: Implement support for touchscreen")
    [2] dee05308f602 ("Staging/iio/adc/touchscreen/MXS: add interrupt driven
    touch detection")
    
    Signed-off-by: Kristina Martšenko <kristina.martsenko@gmail.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c4edc63f0fde2267b236b6d533da96aefb95e4e
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Fri Jan 23 00:34:02 2015 +0100

    iio: imu: adis16400: Fix sign extension
    
    commit 19e353f2b344ad86cea6ebbc0002e5f903480a90 upstream.
    
    The intention is obviously to sign-extend a 12 bit quantity. But
    because of C's promotion rules, the assignment is equivalent to "val16
    &= 0xfff;". Use the proper API for this.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 569a32a34f892185d39d08f30bf8c90a531db6a8
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Sat Jan 3 20:34:12 2015 +0000

    iio: mxs-lradc: fix iio channel map regression
    
    commit 03305e535cd5cdc1079b32909bf4b2dd67d46f7f upstream.
    
    Since commit c8231a9af8147f8a ("iio: mxs-lradc: compute temperature
    from channel 8 and 9") with the removal of adc channel 9 there is
    no 1-1 mapping in the channel spec.
    
    All hwmon channel values above 9 are accessible via there index minus
    one. So add a hidden iio channel 9 to fix this issue.
    
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b6055fc682c2cbbdca5ff3a71af663af986f0e6
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date:   Thu Mar 5 13:19:22 2015 +0100

    x86/fpu/xsaves: Fix improper uses of __ex_table
    
    commit 06c8173eb92bbfc03a0fe8bb64315857d0badd06 upstream.
    
    Commit:
    
      f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area")
    
    introduced alternative instructions for XSAVES/XRSTORS and commit:
    
      adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time")
    
    added support for the XSAVES/XRSTORS instructions at boot time.
    
    Unfortunately both failed to properly protect them against faulting:
    
    The 'xstate_fault' macro will use the closest label named '1'
    backward and that ends up in the .altinstr_replacement section
    rather than in .text. This means that the kernel will never find
    in the __ex_table the .text address where this instruction might
    fault, leading to serious problems if userspace manages to
    trigger the fault.
    
    Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Signed-off-by: Jamie Iles <jamie.iles@oracle.com>
    [ Improved the changelog, fixed some whitespace noise. ]
    Acked-by: Borislav Petkov <bp@alien8.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Allan Xavier <mr.a.xavier@gmail.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time")
    Fixes: f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area")
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4d987805f78ddbc03cd901eed43aeb60ee344a
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Mar 5 01:09:44 2015 +0100

    x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization
    
    commit 956421fbb74c3a6261903f3836c0740187cf038b upstream.
    
    'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and
    the related state make sense for 'ret_from_sys_call'.  This is
    entirely the wrong check.  TS_COMPAT would make a little more
    sense, but there's really no point in keeping this optimization
    at all.
    
    This fixes a return to the wrong user CS if we came from int
    0x80 in a 64-bit task.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.luto@amacapital.net
    [ Backported from tip:x86/asm. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b69eac7c2fea68f6c53994915f8ad47f06f291e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Feb 13 22:27:40 2015 +0000

    target: Check for LBA + sectors wrap-around in sbc_parse_cdb
    
    commit aa179935edea9a64dec4b757090c8106a3907ffa upstream.
    
    This patch adds a check to sbc_parse_cdb() in order to detect when
    an LBA + sector vs. end-of-device calculation wraps when the LBA is
    sufficently large enough (eg: 0xFFFFFFFFFFFFFFFF).
    
    Cc: Martin Petersen <martin.petersen@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a36e39ae78ce0aabbe4932d152d83b9352d97ae
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Feb 13 22:09:47 2015 +0000

    target: Add missing WRITE_SAME end-of-device sanity check
    
    commit 8e575c50a171f2579e367a7f778f86477dfdaf49 upstream.
    
    This patch adds a check to sbc_setup_write_same() to verify
    the incoming WRITE_SAME LBA + number of blocks does not exceed
    past the end-of-device.
    
    Also check for potential LBA wrap-around as well.
    
    Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Martin Petersen <martin.petersen@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12c5ac27e69ca3d652a95d3f99423e5fadb274a1
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Feb 11 18:34:40 2015 -0800

    target: Fix PR_APTPL_BUF_LEN buffer size limitation
    
    commit f161d4b44d7cc1dc66b53365215227db356378b1 upstream.
    
    This patch addresses the original PR_APTPL_BUF_LEN = 8k limitiation
    for write-out of PR APTPL metadata that Martin has recently been
    running into.
    
    It changes core_scsi3_update_and_write_aptpl() to use vzalloc'ed
    memory instead of kzalloc, and increases the default hardcoded
    length to 256k.
    
    It also adds logic in core_scsi3_update_and_write_aptpl() to double
    the original length upon core_scsi3_update_aptpl_buf() failure, and
    retries until the vzalloc'ed buffer is large enough to accommodate
    the outgoing APTPL metadata.
    
    Reported-by: Martin Svec <martin.svec@zoner.cz>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a88c8685cd4acacc9bd6234e4f8124ec1ce7e494
Author: Tom O'Rourke <Tom.O'Rourke@intel.com>
Date:   Tue Feb 10 23:06:46 2015 -0800

    drm/i915: Clamp efficient frequency to valid range
    
    commit 46efa4abe5712276494adbce102f46e3214632fd upstream.
    
    The efficient frequency (RPe) should stay in the range
    RPn <= RPe <= RP0.  The pcode clamps the returned value
    internally on Broadwell but not on Haswell.
    
    Fix for missing range check in
    commit 93ee29203f506582cca2bcec5f05041526d9ab0a
    Author: Tom O'Rourke <Tom.O'Rourke@intel.com>
    Date:   Wed Nov 19 14:21:52 2014 -0800
    
        drm/i915: Use efficient frequency for HSW/BDW
    
    Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.html
    Reported-by: Michael Auchter <a@phire.org>
    Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d94ef0b654606fdf6256d1cb2c9f0a2615f4ef04
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date:   Thu Feb 5 17:10:56 2015 +0530

    drm/i915: Correct the IOSF Dev_FN field for IOSF transfers
    
    commit d180d2bbb66579e3bf449642b8ec2a76f4014fcd upstream.
    
    As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
    device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
    port ID should be enough to identify devices unless they are MFD. The
    SB_DevFn was intended to remove ambiguity in case of these MFD devices.
    
    For non MFD devices the recommendation for the target device IP was to
    ignore these fields, but not all of them followed the recommendation.
    Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so
    does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because
    of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0).
    It turned out that this did not follow the recommendation and expected 0
    in this field.
    
    In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for
    all devices except target PCI devices.
    
    Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 885aa661b25a0ffc983aa27654829696660a616b
Author: Michał Winiarski <michal.winiarski@intel.com>
Date:   Tue Feb 3 15:48:17 2015 +0100

    drm/i915: Prevent use-after-free in invalidate_range_start callback
    
    commit 460822b0b1a77db859b0320469799fa4dbe4d367 upstream.
    
    It's possible for invalidate_range_start mmu notifier callback to race
    against userptr object release. If the gem object was released prior to
    obtaining the spinlock in invalidate_range_start we're hitting null
    pointer dereference.
    
    Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close
    Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    [Jani: added code comment suggested by Chris]
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cae716d5ffa2e20546b9a974bf525270e9a66f84
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Nov 24 16:54:11 2014 +0100

    drm/i915: Drop vblank wait from intel_dp_link_down
    
    commit 0ca09685546fed5fc8f0535204f0626f352140f4 upstream.
    
    Nothing in Bspec seems to indicate that we actually needs this, and it
    looks like can't work since by this point the pipe is off and so
    vblanks won't really happen any more.
    
    Note that Bspec mentions that it takes a vblank for this bit to
    change, but _only_ when enabling.
    
    Dropping this code quenches an annoying backtrace introduced by the
    more anal checking since
    
    commit 51e31d49c89055299e34b8f44d13f70e19aaaad1
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Mon Sep 15 12:36:02 2014 +0200
    
        drm/i915: Use generic vblank wait
    
    Note: This fixes the fallout from the above commit, but does not address
    the shortcomings of the IBX transcoder select workaround implementation
    discussed during review [1].
    
    [1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b16a8497a0342524a343d07a234508cc12b68443
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jan 22 13:42:00 2015 +0000

    drm/i915: Insert a command barrier on BLT/BSD cache flushes
    
    commit f0a1fb10e5f79f5aaf8d7e94b9fa6bf2fa9aeebf upstream.
    
    This looked like an odd regression from
    
    commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Jun 12 10:28:55 2014 +0100
    
        drm/i915: Restrict GPU boost to the RCS engine
    
    but in reality it undercovered a much older coherency bug. The issue that
    boosting the GPU frequency on the BCS ring was masking was that we could
    wake the CPU up after completion of a BCS batch and inspect memory prior
    to the write cache being fully evicted. In order to serialise the
    breadcrumb interrupt (and so ensure that the CPU's view of memory is
    coherent) we need to perform a post-sync operation in the MI_FLUSH_DW.
    
    v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists).
    
    Also fix the invalidate_domains mask in gen8_emit_flush() for ring !=
    VCS.
    
    Testcase: gpuX-rcs-gpu-read-after-write
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12bc2f3df1d5c9445202a1eb9119460ca6928042
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Feb 12 00:40:58 2015 -0500

    drm/radeon: fix voltage setup on hawaii
    
    commit 09b6e85fc868568e1b2820235a2a851aecbccfcc upstream.
    
    Missing parameter when fetching the real voltage values
    from atom.  Fixes problems with dynamic clocking on
    certain boards.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=87457
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3aeb57ffdb5325636869d102f70ef6096b9d49d9
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Feb 11 18:34:36 2015 -0500

    drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary
    
    commit 66c2b84ba6256bc5399eed45582af9ebb3ba2c15 upstream.
    
    Don't restrict it to just eDP panels.  Some LVDS bridge chips require
    this.  Fixes blank panels on resume on certain laptops.  Noticed
    by mrnuke on IRC.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=42960
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52c35ffe609a225d465bcc49570817e7e443a7fc
Author: Christian König <christian.koenig@amd.com>
Date:   Tue Feb 10 14:26:39 2015 +0100

    drm/radeon: workaround for CP HW bug on CIK
    
    commit a9c73a0e022c33954835e66fec3cd744af90ec98 upstream.
    
    Emit the EOP twice to avoid cache flushing problems.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cec4e689a8daba945252db35b4debc683664e972
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Feb 6 12:53:27 2015 -0500

    drm/radeon: only enable kv/kb dpm interrupts once v3
    
    commit 410af8d7285a0b96314845c75c39fd612b755688 upstream.
    
    Enable at init and disable on fini. Workaround for hardware problems.
    
    v2 (chk): extend commit message
    v3: add new function
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com> (v2)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 002ce3eac5a3ac7bb053a42adabc6cffdf6cb891
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Feb 4 10:19:51 2015 +0900

    drm/radeon: Don't try to enable write-combining without PAT
    
    commit a53fa43873b88bad15a2eb1f01dc5efa689625ce upstream.
    
    Doing so can cause things to become slow.
    
    Print a warning at compile time and an informative message at runtime in
    that case.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65fee0e0a451415eca251c1b19e63cc62b054c45
Author: David Ung <davidu@nvidia.com>
Date:   Tue Jan 20 18:37:35 2015 -0800

    drm/tegra: Use correct relocation target offsets
    
    commit 31f40f86526b71009973854c1dfe799ee70f7588 upstream.
    
    When copying a relocation from userspace, copy the correct target
    offset.
    
    Signed-off-by: David Ung <davidu@nvidia.com>
    Fixes: 961e3beae3b2 ("drm/tegra: Make job submission 64-bit safe")
    [treding@nvidia.com: provide a better commit message]
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c749954dcd0b852f5d7a127eff72716cd7f9ca6
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Fri Feb 27 15:52:09 2015 -0800

    mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change
    
    commit cc87317726f851531ae8422e0c2d3d6e2d7b1955 upstream.
    
    Historically, !__GFP_FS allocations were not allowed to invoke the OOM
    killer once reclaim had failed, but nevertheless kept looping in the
    allocator.
    
    Commit 9879de7373fc ("mm: page_alloc: embed OOM killing naturally into
    allocation slowpath"), which should have been a simple cleanup patch,
    accidentally changed the behavior to aborting the allocation at that
    point.  This creates problems with filesystem callers (?) that currently
    rely on the allocator waiting for other tasks to intervene.
    
    Revert the behavior as it shouldn't have been changed as part of a
    cleanup patch.
    
    Fixes: 9879de7373fc ("mm: page_alloc: embed OOM killing naturally into allocation slowpath")
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Dave Chinner <david@fromorbit.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    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 51571a010cdd78d90ab74eed34303cabe2d97539
Author: Joonsoo Kim <js1304@gmail.com>
Date:   Fri Feb 27 15:51:43 2015 -0800

    mm/nommu: fix memory leak
    
    commit da616534ed7f6e8ffaab699258b55c8d78d0b4ea upstream.
    
    Maxime reported the following memory leak regression due to commit
    dbc8358c7237 ("mm/nommu: use alloc_pages_exact() rather than its own
    implementation").
    
    On v3.19, I am facing a memory leak.  Each time I run a command one page
    is lost.  Here an example with busybox's free command:
    
      / # free
                   total       used       free     shared    buffers     cached
      Mem:          7928       1972       5956          0          0        492
      -/+ buffers/cache:       1480       6448
      / # free
                   total       used       free     shared    buffers     cached
      Mem:          7928       1976       5952          0          0        492
      -/+ buffers/cache:       1484       6444
      / # free
                   total       used       free     shared    buffers     cached
      Mem:          7928       1980       5948          0          0        492
      -/+ buffers/cache:       1488       6440
      / # free
                   total       used       free     shared    buffers     cached
      Mem:          7928       1984       5944          0          0        492
      -/+ buffers/cache:       1492       6436
      / # free
                   total       used       free     shared    buffers     cached
      Mem:          7928       1988       5940          0          0        492
      -/+ buffers/cache:       1496       6432
    
    At some point, the system fails to sastisfy 256KB allocations:
    
      free: page allocation failure: order:6, mode:0xd0
      CPU: 0 PID: 67 Comm: free Not tainted 3.19.0-05389-gacf2cf1-dirty #64
      Hardware name: STM32 (Device Tree Support)
        show_stack+0xb/0xc
        warn_alloc_failed+0x97/0xbc
        __alloc_pages_nodemask+0x295/0x35c
        __get_free_pages+0xb/0x24
        alloc_pages_exact+0x19/0x24
        do_mmap_pgoff+0x423/0x658
        vm_mmap_pgoff+0x3f/0x4e
        load_flat_file+0x20d/0x4f8
        load_flat_binary+0x3f/0x26c
        search_binary_handler+0x51/0xe4
        do_execveat_common+0x271/0x35c
        do_execve+0x19/0x1c
        ret_fast_syscall+0x1/0x4a
      Mem-info:
      Normal per-cpu:
      CPU    0: hi:    0, btch:   1 usd:   0
      active_anon:0 inactive_anon:0 isolated_anon:0
       active_file:0 inactive_file:0 isolated_file:0
       unevictable:123 dirty:0 writeback:0 unstable:0
       free:1515 slab_reclaimable:17 slab_unreclaimable:139
       mapped:0 shmem:0 pagetables:0 bounce:0
       free_cma:0
      Normal free:6060kB min:352kB low:440kB high:528kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:492kB isolated(anon):0ks
      lowmem_reserve[]: 0 0
      Normal: 23*4kB (U) 22*8kB (U) 24*16kB (U) 23*32kB (U) 23*64kB (U) 23*128kB (U) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6060kB
      123 total pagecache pages
      2048 pages of RAM
      1538 free pages
      66 reserved pages
      109 slab pages
      -46 pages shared
      0 pages swap cached
      nommu: Allocation of length 221184 from process 67 (free) failed
      Normal per-cpu:
      CPU    0: hi:    0, btch:   1 usd:   0
      active_anon:0 inactive_anon:0 isolated_anon:0
       active_file:0 inactive_file:0 isolated_file:0
       unevictable:123 dirty:0 writeback:0 unstable:0
       free:1515 slab_reclaimable:17 slab_unreclaimable:139
       mapped:0 shmem:0 pagetables:0 bounce:0
       free_cma:0
      Normal free:6060kB min:352kB low:440kB high:528kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:492kB isolated(anon):0ks
      lowmem_reserve[]: 0 0
      Normal: 23*4kB (U) 22*8kB (U) 24*16kB (U) 23*32kB (U) 23*64kB (U) 23*128kB (U) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6060kB
      123 total pagecache pages
      Unable to allocate RAM for process text/data, errno 12 SEGV
    
    This problem happens because we allocate ordered page through
    __get_free_pages() in do_mmap_private() in some cases and we try to free
    individual pages rather than ordered page in free_page_series().  In
    this case, freeing pages whose refcount is not 0 won't be freed to the
    page allocator so memory leak happens.
    
    To fix the problem, this patch changes __get_free_pages() to
    alloc_pages_exact() since alloc_pages_exact() returns
    physically-contiguous pages but each pages are refcounted.
    
    Fixes: dbc8358c7237 ("mm/nommu: use alloc_pages_exact() rather than its own implementation").
    Reported-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Tested-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.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 2cd12f3d5799add8af547cec707404c9ad053c76
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Feb 12 15:00:28 2015 -0800

    mm: fix negative nr_isolated counts
    
    commit ff59909a077b3c51c168cb658601c6b63136a347 upstream.
    
    The vmstat interfaces are good at hiding negative counts (at least when
    CONFIG_SMP); but if you peer behind the curtain, you find that
    nr_isolated_anon and nr_isolated_file soon go negative, and grow ever
    more negative: so they can absorb larger and larger numbers of isolated
    pages, yet still appear to be zero.
    
    I'm happy to avoid a congestion_wait() when too_many_isolated() myself;
    but I guess it's there for a good reason, in which case we ought to get
    too_many_isolated() working again.
    
    The imbalance comes from isolate_migratepages()'s ISOLATE_ABORT case:
    putback_movable_pages() decrements the NR_ISOLATED counts, but we forgot
    to call acct_isolated() to increment them.
    
    It is possible that the bug whcih this patch fixes could cause OOM kills
    when the system still has a lot of reclaimable page cache.
    
    Fixes: edc2ca612496 ("mm, compaction: move pageblock checks up from isolate_migratepages_range()")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.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 1bab6ee0b41e4fa4550693da82742aa50a94290c
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Thu Feb 12 15:00:25 2015 -0800

    mm: hwpoison: drop lru_add_drain_all() in __soft_offline_page()
    
    commit 9ab3b598d2dfbdb0153ffa7e4b1456bbff59a25d upstream.
    
    A race condition starts to be visible in recent mmotm, where a PG_hwpoison
    flag is set on a migration source page *before* it's back in buddy page
    poo= l.
    
    This is problematic because no page flag is supposed to be set when
    freeing (see __free_one_page().) So the user-visible effect of this race
    is that it could trigger the BUG_ON() when soft-offlining is called.
    
    The root cause is that we call lru_add_drain_all() to make sure that the
    page is in buddy, but that doesn't work because this function just
    schedule= s a work item and doesn't wait its completion.
    drain_all_pages() does drainin= g directly, so simply dropping
    lru_add_drain_all() solves this problem.
    
    Fixes: f15bdfa802bf ("mm/memory-failure.c: fix memory leak in successful soft offlining")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Chen Gong <gong.chen@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 6f5468a717c8f18e721dc9bc7f8d7ce41f22eb1a
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Thu Feb 12 15:00:19 2015 -0800

    mm/memory.c: actually remap enough memory
    
    commit 9cb12d7b4ccaa976f97ce0c5fd0f1b6a83bc2a75 upstream.
    
    For whatever reason, generic_access_phys() only remaps one page, but
    actually allows to access arbitrary size.  It's quite easy to trigger
    large reads, like printing out large structure with gdb, which leads to a
    crash.  Fix it by remapping correct size.
    
    Fixes: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Cc: Rik van Riel <riel@redhat.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 cf4a79699bbeb8d677aa5f3a145a066ead7b43c4
Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date:   Thu Feb 12 14:59:50 2015 -0800

    mm/compaction: fix wrong order check in compact_finished()
    
    commit 372549c2a3778fd3df445819811c944ad54609ca upstream.
    
    What we want to check here is whether there is highorder freepage in buddy
    list of other migratetype in order to steal it without fragmentation.
    But, current code just checks cc->order which means allocation request
    order.  So, this is wrong.
    
    Without this fix, non-movable synchronous compaction below pageblock order
    would not stopped until compaction is complete, because migratetype of
    most pageblocks are movable and high order freepage made by compaction is
    usually on movable type buddy list.
    
    There is some report related to this bug. See below link.
    
      http://www.spinics.net/lists/linux-mm/msg81666.html
    
    Although the issued system still has load spike comes from compaction,
    this makes that system completely stable and responsive according to his
    report.
    
    stress-highalloc test in mmtests with non movable order 7 allocation
    doesn't show any notable difference in allocation success rate, but, it
    shows more compaction success rate.
    
    Compaction success rate (Compaction success * 100 / Compaction stalls, %)
    18.47 : 28.94
    
    Fixes: 1fb3f8ca0e92 ("mm: compaction: capture a suitable high-order page immediately when it is made available")
    Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Rik van Riel <riel@redhat.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 225c2a356300344510af5ee6c20a88eb84cc8ff2
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Wed Feb 11 15:28:42 2015 -0800

    mm/nommu.c: fix arithmetic overflow in __vm_enough_memory()
    
    commit 8138a67a5557ffea3a21dfd6f037842d4e748513 upstream.
    
    I noticed that "allowed" can easily overflow by falling below 0, because
    (total_vm / 32) can be larger than "allowed".  The problem occurs in
    OVERCOMMIT_NONE mode.
    
    In this case, a huge allocation can success and overcommit the system
    (despite OVERCOMMIT_NONE mode).  All subsequent allocations will fall
    (system-wide), so system become unusable.
    
    The problem was masked out by commit c9b1d0981fcc
    ("mm: limit growth of 3% hardcoded other user reserve"),
    but it's easy to reproduce it on older kernels:
    1) set overcommit_memory sysctl to 2
    2) mmap() large file multiple times (with VM_SHARED flag)
    3) try to malloc() large amount of memory
    
    It also can be reproduced on newer kernels, but miss-configured
    sysctl_user_reserve_kbytes is required.
    
    Fix this issue by switching to signed arithmetic here.
    
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Cc: Andrew Shewmaker <agshew@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    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 00f4f16b8e60acbba7de443a12ba3aa6c0de6d14
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Wed Feb 11 15:28:39 2015 -0800

    mm/mmap.c: fix arithmetic overflow in __vm_enough_memory()
    
    commit 5703b087dc8eaf47bfb399d6cf512d471beff405 upstream.
    
    I noticed, that "allowed" can easily overflow by falling below 0,
    because (total_vm / 32) can be larger than "allowed".  The problem
    occurs in OVERCOMMIT_NONE mode.
    
    In this case, a huge allocation can success and overcommit the system
    (despite OVERCOMMIT_NONE mode).  All subsequent allocations will fall
    (system-wide), so system become unusable.
    
    The problem was masked out by commit c9b1d0981fcc
    ("mm: limit growth of 3% hardcoded other user reserve"),
    but it's easy to reproduce it on older kernels:
    1) set overcommit_memory sysctl to 2
    2) mmap() large file multiple times (with VM_SHARED flag)
    3) try to malloc() large amount of memory
    
    It also can be reproduced on newer kernels, but miss-configured
    sysctl_user_reserve_kbytes is required.
    
    Fix this issue by switching to signed arithmetic here.
    
    [akpm@linux-foundation.org: use min_t]
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Cc: Andrew Shewmaker <agshew@gmail.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    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 cdf476685b5c9dcd20f0305791bd60212cace25d
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Wed Feb 11 15:28:15 2015 -0800

    mm: when stealing freepages, also take pages created by splitting buddy page
    
    commit 99592d598eca62bdbbf62b59941c189176dfc614 upstream.
    
    When studying page stealing, I noticed some weird looking decisions in
    try_to_steal_freepages().  The first I assume is a bug (Patch 1), the
    following two patches were driven by evaluation.
    
    Testing was done with stress-highalloc of mmtests, using the
    mm_page_alloc_extfrag tracepoint and postprocessing to get counts of how
    often page stealing occurs for individual migratetypes, and what
    migratetypes are used for fallbacks.  Arguably, the worst case of page
    stealing is when UNMOVABLE allocation steals from MOVABLE pageblock.
    RECLAIMABLE allocation stealing from MOVABLE allocation is also not ideal,
    so the goal is to minimize these two cases.
    
    The evaluation of v2 wasn't always clear win and Joonsoo questioned the
    results.  Here I used different baseline which includes RFC compaction
    improvements from [1].  I found that the compaction improvements reduce
    variability of stress-highalloc, so there's less noise in the data.
    
    First, let's look at stress-highalloc configured to do sync compaction,
    and how these patches reduce page stealing events during the test.  First
    column is after fresh reboot, other two are reiterations of test without
    reboot.  That was all accumulater over 5 re-iterations (so the benchmark
    was run 5x3 times with 5 fresh restarts).
    
    Baseline:
    
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                      5-nothp-1       5-nothp-2       5-nothp-3
    Page alloc extfrag event                               10264225     8702233    10244125
    Extfrag fragmenting                                    10263271     8701552    10243473
    Extfrag fragmenting for unmovable                         13595       17616       15960
    Extfrag fragmenting unmovable placed with movable          7989       12193        8447
    Extfrag fragmenting for reclaimable                         658        1840        1817
    Extfrag fragmenting reclaimable placed with movable         558        1677        1679
    Extfrag fragmenting for movable                        10249018     8682096    10225696
    
    With Patch 1:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                      6-nothp-1       6-nothp-2       6-nothp-3
    Page alloc extfrag event                               11834954     9877523     9774860
    Extfrag fragmenting                                    11833993     9876880     9774245
    Extfrag fragmenting for unmovable                          7342       16129       11712
    Extfrag fragmenting unmovable placed with movable          4191       10547        6270
    Extfrag fragmenting for reclaimable                         373        1130         923
    Extfrag fragmenting reclaimable placed with movable         302         906         738
    Extfrag fragmenting for movable                        11826278     9859621     9761610
    
    With Patch 2:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                      7-nothp-1       7-nothp-2       7-nothp-3
    Page alloc extfrag event                                4725990     3668793     3807436
    Extfrag fragmenting                                     4725104     3668252     3806898
    Extfrag fragmenting for unmovable                          6678        7974        7281
    Extfrag fragmenting unmovable placed with movable          2051        3829        4017
    Extfrag fragmenting for reclaimable                         429        1208        1278
    Extfrag fragmenting reclaimable placed with movable         369         976        1034
    Extfrag fragmenting for movable                         4717997     3659070     3798339
    
    With Patch 3:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                      8-nothp-1       8-nothp-2       8-nothp-3
    Page alloc extfrag event                                5016183     4700142     3850633
    Extfrag fragmenting                                     5015325     4699613     3850072
    Extfrag fragmenting for unmovable                          1312        3154        3088
    Extfrag fragmenting unmovable placed with movable          1115        2777        2714
    Extfrag fragmenting for reclaimable                         437        1193        1097
    Extfrag fragmenting reclaimable placed with movable         330         969         879
    Extfrag fragmenting for movable                         5013576     4695266     3845887
    
    In v2 we've seen apparent regression with Patch 1 for unmovable events,
    this is now gone, suggesting it was indeed noise.  Here, each patch
    improves the situation for unmovable events.  Reclaimable is improved by
    patch 1 and then either the same modulo noise, or perhaps sligtly worse -
    a small price for unmovable improvements, IMHO.  The number of movable
    allocations falling back to other migratetypes is most noisy, but it's
    reduced to half at Patch 2 nevertheless.  These are least critical as
    compaction can move them around.
    
    If we look at success rates, the patches don't affect them, that didn't change.
    
    Baseline:
                                 3.19-rc4              3.19-rc4              3.19-rc4
                                5-nothp-1             5-nothp-2             5-nothp-3
    Success 1 Min         49.00 (  0.00%)       42.00 ( 14.29%)       41.00 ( 16.33%)
    Success 1 Mean        51.00 (  0.00%)       45.00 ( 11.76%)       42.60 ( 16.47%)
    Success 1 Max         55.00 (  0.00%)       51.00 (  7.27%)       46.00 ( 16.36%)
    Success 2 Min         53.00 (  0.00%)       47.00 ( 11.32%)       44.00 ( 16.98%)
    Success 2 Mean        59.60 (  0.00%)       50.80 ( 14.77%)       48.20 ( 19.13%)
    Success 2 Max         64.00 (  0.00%)       56.00 ( 12.50%)       52.00 ( 18.75%)
    Success 3 Min         84.00 (  0.00%)       82.00 (  2.38%)       78.00 (  7.14%)
    Success 3 Mean        85.60 (  0.00%)       82.80 (  3.27%)       79.40 (  7.24%)
    Success 3 Max         86.00 (  0.00%)       83.00 (  3.49%)       80.00 (  6.98%)
    
    Patch 1:
                                 3.19-rc4              3.19-rc4              3.19-rc4
                                6-nothp-1             6-nothp-2             6-nothp-3
    Success 1 Min         49.00 (  0.00%)       44.00 ( 10.20%)       44.00 ( 10.20%)
    Success 1 Mean        51.80 (  0.00%)       46.00 ( 11.20%)       45.80 ( 11.58%)
    Success 1 Max         54.00 (  0.00%)       49.00 (  9.26%)       49.00 (  9.26%)
    Success 2 Min         58.00 (  0.00%)       49.00 ( 15.52%)       48.00 ( 17.24%)
    Success 2 Mean        60.40 (  0.00%)       51.80 ( 14.24%)       50.80 ( 15.89%)
    Success 2 Max         63.00 (  0.00%)       54.00 ( 14.29%)       55.00 ( 12.70%)
    Success 3 Min         84.00 (  0.00%)       81.00 (  3.57%)       79.00 (  5.95%)
    Success 3 Mean        85.00 (  0.00%)       81.60 (  4.00%)       79.80 (  6.12%)
    Success 3 Max         86.00 (  0.00%)       82.00 (  4.65%)       82.00 (  4.65%)
    
    Patch 2:
    
                                 3.19-rc4              3.19-rc4              3.19-rc4
                                7-nothp-1             7-nothp-2             7-nothp-3
    Success 1 Min         50.00 (  0.00%)       44.00 ( 12.00%)       39.00 ( 22.00%)
    Success 1 Mean        52.80 (  0.00%)       45.60 ( 13.64%)       42.40 ( 19.70%)
    Success 1 Max         55.00 (  0.00%)       46.00 ( 16.36%)       47.00 ( 14.55%)
    Success 2 Min         52.00 (  0.00%)       48.00 (  7.69%)       45.00 ( 13.46%)
    Success 2 Mean        53.40 (  0.00%)       49.80 (  6.74%)       48.80 (  8.61%)
    Success 2 Max         57.00 (  0.00%)       52.00 (  8.77%)       52.00 (  8.77%)
    Success 3 Min         84.00 (  0.00%)       81.00 (  3.57%)       79.00 (  5.95%)
    Success 3 Mean        85.00 (  0.00%)       82.40 (  3.06%)       79.60 (  6.35%)
    Success 3 Max         86.00 (  0.00%)       83.00 (  3.49%)       80.00 (  6.98%)
    
    Patch 3:
                                 3.19-rc4              3.19-rc4              3.19-rc4
                                8-nothp-1             8-nothp-2             8-nothp-3
    Success 1 Min         46.00 (  0.00%)       44.00 (  4.35%)       42.00 (  8.70%)
    Success 1 Mean        50.20 (  0.00%)       45.60 (  9.16%)       44.00 ( 12.35%)
    Success 1 Max         52.00 (  0.00%)       47.00 (  9.62%)       47.00 (  9.62%)
    Success 2 Min         53.00 (  0.00%)       49.00 (  7.55%)       48.00 (  9.43%)
    Success 2 Mean        55.80 (  0.00%)       50.60 (  9.32%)       49.00 ( 12.19%)
    Success 2 Max         59.00 (  0.00%)       52.00 ( 11.86%)       51.00 ( 13.56%)
    Success 3 Min         84.00 (  0.00%)       80.00 (  4.76%)       79.00 (  5.95%)
    Success 3 Mean        85.40 (  0.00%)       81.60 (  4.45%)       80.40 (  5.85%)
    Success 3 Max         87.00 (  0.00%)       83.00 (  4.60%)       82.00 (  5.75%)
    
    While there's no improvement here, I consider reduced fragmentation events
    to be worth on its own.  Patch 2 also seems to reduce scanning for free
    pages, and migrations in compaction, suggesting it has somewhat less work
    to do:
    
    Patch 1:
    
    Compaction stalls                 4153        3959        3978
    Compaction success                1523        1441        1446
    Compaction failures               2630        2517        2531
    Page migrate success           4600827     4943120     5104348
    Page migrate failure             19763       16656       17806
    Compaction pages isolated      9597640    10305617    10653541
    Compaction migrate scanned    77828948    86533283    87137064
    Compaction free scanned      517758295   521312840   521462251
    Compaction cost                   5503        5932        6110
    
    Patch 2:
    
    Compaction stalls                 3800        3450        3518
    Compaction success                1421        1316        1317
    Compaction failures               2379        2134        2201
    Page migrate success           4160421     4502708     4752148
    Page migrate failure             19705       14340       14911
    Compaction pages isolated      8731983     9382374     9910043
    Compaction migrate scanned    98362797    96349194    98609686
    Compaction free scanned      496512560   469502017   480442545
    Compaction cost                   5173        5526        5811
    
    As with v2, /proc/pagetypeinfo appears unaffected with respect to numbers
    of unmovable and reclaimable pageblocks.
    
    Configuring the benchmark to allocate like THP page fault (i.e.  no sync
    compaction) gives much noisier results for iterations 2 and 3 after
    reboot.  This is not so surprising given how [1] offers lower improvements
    in this scenario due to less restarts after deferred compaction which
    would change compaction pivot.
    
    Baseline:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                        5-thp-1         5-thp-2         5-thp-3
    Page alloc extfrag event                                8148965     6227815     6646741
    Extfrag fragmenting                                     8147872     6227130     6646117
    Extfrag fragmenting for unmovable                         10324       12942       15975
    Extfrag fragmenting unmovable placed with movable          5972        8495       10907
    Extfrag fragmenting for reclaimable                         601        1707        2210
    Extfrag fragmenting reclaimable placed with movable         520        1570        2000
    Extfrag fragmenting for movable                         8136947     6212481     6627932
    
    Patch 1:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                        6-thp-1         6-thp-2         6-thp-3
    Page alloc extfrag event                                8345457     7574471     7020419
    Extfrag fragmenting                                     8343546     7573777     7019718
    Extfrag fragmenting for unmovable                         10256       18535       30716
    Extfrag fragmenting unmovable placed with movable          6893       11726       22181
    Extfrag fragmenting for reclaimable                         465        1208        1023
    Extfrag fragmenting reclaimable placed with movable         353         996         843
    Extfrag fragmenting for movable                         8332825     7554034     6987979
    
    Patch 2:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                        7-thp-1         7-thp-2         7-thp-3
    Page alloc extfrag event                                3512847     3020756     2891625
    Extfrag fragmenting                                     3511940     3020185     2891059
    Extfrag fragmenting for unmovable                          9017        6892        6191
    Extfrag fragmenting unmovable placed with movable          1524        3053        2435
    Extfrag fragmenting for reclaimable                         445        1081        1160
    Extfrag fragmenting reclaimable placed with movable         375         918         986
    Extfrag fragmenting for movable                         3502478     3012212     2883708
    
    Patch 3:
                                                       3.19-rc4        3.19-rc4        3.19-rc4
                                                        8-thp-1         8-thp-2         8-thp-3
    Page alloc extfrag event                                3181699     3082881     2674164
    Extfrag fragmenting                                     3180812     3082303     2673611
    Extfrag fragmenting for unmovable                          1201        4031        4040
    Extfrag fragmenting unmovable placed with movable           974        3611        3645
    Extfrag fragmenting for reclaimable                         478        1165        1294
    Extfrag fragmenting reclaimable placed with movable         387         985        1030
    Extfrag fragmenting for movable                         3179133     3077107     2668277
    
    The improvements for first iteration are clear, the rest is much noisier
    and can appear like regression for Patch 1.  Anyway, patch 2 rectifies it.
    
    Allocation success rates are again unaffected so there's no point in
    making this e-mail any longer.
    
    [1] http://marc.info/?l=linux-mm&m=142166196321125&w=2
    
    This patch (of 3):
    
    When __rmqueue_fallback() is called to allocate a page of order X, it will
    find a page of order Y >= X of a fallback migratetype, which is different
    from the desired migratetype.  With the help of try_to_steal_freepages(),
    it may change the migratetype (to the desired one) also of:
    
    1) all currently free pages in the pageblock containing the fallback page
    2) the fallback pageblock itself
    3) buddy pages created by splitting the fallback page (when Y > X)
    
    These decisions take the order Y into account, as well as the desired
    migratetype, with the goal of preventing multiple fallback allocations
    that could e.g.  distribute UNMOVABLE allocations among multiple
    pageblocks.
    
    Originally, decision for 1) has implied the decision for 3).  Commit
    47118af076f6 ("mm: mmzone: MIGRATE_CMA migration type added") changed that
    (probably unintentionally) so that the buddy pages in case 3) are always
    changed to the desired migratetype, except for CMA pageblocks.
    
    Commit fef903efcf0c ("mm/page_allo.c: restructure free-page stealing code
    and fix a bug") did some refactoring and added a comment that the case of
    3) is intended.  Commit 0cbef29a7821 ("mm: __rmqueue_fallback() should
    respect pageblock type") removed the comment and tried to restore the
    original behavior where 1) implies 3), but due to the previous
    refactoring, the result is instead that only 2) implies 3) - and the
    conditions for 2) are less frequently met than conditions for 1).  This
    may increase fragmentation in situations where the code decides to steal
    all free pages from the pageblock (case 1)), but then gives back the buddy
    pages produced by splitting.
    
    This patch restores the original intended logic where 1) implies 3).
    During testing with stress-highalloc from mmtests, this has shown to
    decrease the number of events where UNMOVABLE and RECLAIMABLE allocations
    steal from MOVABLE pageblocks, which can lead to permanent fragmentation.
    In some cases it has increased the number of events when MOVABLE
    allocations steal from UNMOVABLE or RECLAIMABLE pageblocks, but these are
    fixable by sync compaction and thus less harmful.
    
    Note that evaluation has shown that the behavior introduced by
    47118af076f6 for buddy pages in case 3) is actually even better than the
    original logic, so the following patch will introduce it properly once
    again.  For stable backports of this patch it makes thus sense to only fix
    versions containing 0cbef29a7821.
    
    [iamjoonsoo.kim@lge.com: tracepoint fix]
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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 89316deb0dd1bbc8c4eff6b005ce66f30f378112
Author: Andrey Ryabinin <a.ryabinin@samsung.com>
Date:   Tue Feb 10 14:11:33 2015 -0800

    mm, hugetlb: remove unnecessary lower bound on sysctl handlers"?
    
    commit 3cd7645de624939c38f5124b4ac15f8b35a1a8b7 upstream.
    
    Commit ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and
    hugetlb_infinity") replaced 'unsigned long hugetlb_zero' with 'int zero'
    leading to out-of-bounds access in proc_doulongvec_minmax().  Use
    '.extra1 = NULL' instead of '.extra1 = &zero'.  Passing NULL is
    equivalent to passing minimal value, which is 0 for unsigned types.
    
    Fixes: ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity")
    Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Suggested-by: Manfred Spraul <manfred@colorfullife.com>
    Acked-by: David Rientjes <rientjes@google.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 3ffc797a2722ae09fdc2167b316c695f0b903e91
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:32 2015 -0800

    mm/hugetlb: add migration entry check in __unmap_hugepage_range
    
    commit 9fbc1f635fd0bd28cb32550211bf095753ac637a upstream.
    
    If __unmap_hugepage_range() tries to unmap the address range over which
    hugepage migration is on the way, we get the wrong page because pte_page()
    doesn't work for migration entries.  This patch simply clears the pte for
    migration entries as we do for hwpoison entries.
    
    Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    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 2c90c58c731c1877391e13da28a33d5dc7f813b1
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:28 2015 -0800

    mm/hugetlb: add migration/hwpoisoned entry check in hugetlb_change_protection
    
    commit a8bda28d87c38c6aa93de28ba5d30cc18e865a11 upstream.
    
    There is a race condition between hugepage migration and
    change_protection(), where hugetlb_change_protection() doesn't care about
    migration entries and wrongly overwrites them.  That causes unexpected
    results like kernel crash.  HWPoison entries also can cause the same
    problem.
    
    This patch adds is_hugetlb_entry_(migration|hwpoisoned) check in this
    function to do proper actions.
    
    Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    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 75809873eb40f3297dca579b043b26bce0666a14
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Feb 11 15:25:25 2015 -0800

    mm/hugetlb: fix getting refcount 0 page in hugetlb_fault()
    
    commit 0f792cf949a0be506c2aa8bfac0605746b146dda upstream.
    
    When running the test which causes the race as shown in the previous patch,
    we can hit the BUG "get_page() on refcount 0 page" in hugetlb_fault().
    
    This race happens when pte turns into migration entry just after the first
    check of is_hugetlb_entry_migration() in hugetlb_fault() passed with false.
    To fix this, we need to check pte_present() again after huge_ptep_get().
    
    This patch also reorders taking ptl and doing pte_page(), because
    pte_page() should be done in ptl.  Due to this reordering, we need use
    trylock_page() in page != pagecache_page case to respect locking order.
    
    Fixes: 66aebce747ea ("hugetlb: fix race condition in hugetlb_fault()")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    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 dde0b1d5470c7aa302cb82a9565ea626f90d3f28
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Wed Mar 4 08:36:31 2015 +0100

    team: don't traverse port list using rcu in team_set_mac_address
    
    [ Upstream commit 9215f437b85da339a7dfe3db6e288637406f88b2 ]
    
    Currently the list is traversed using rcu variant. That is not correct
    since dev_set_mac_address can be called which eventually calls
    rtmsg_ifinfo_build_skb and there, skb allocation can sleep. So fix this
    by remove the rcu usage here.
    
    Fixes: 3d249d4ca7 "net: introduce ethernet teaming device"
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2391f6b4220bd41b40be920c0f9ed0dc22f914b8
Author: Lorenzo Colitti <lorenzo@google.com>
Date:   Tue Mar 3 23:16:16 2015 +0900

    net: ping: Return EAFNOSUPPORT when appropriate.
    
    [ Upstream commit 9145736d4862145684009d6a72a6e61324a9439e ]
    
    1. For an IPv4 ping socket, ping_check_bind_addr does not check
       the family of the socket address that's passed in. Instead,
       make it behave like inet_bind, which enforces either that the
       address family is AF_INET, or that the family is AF_UNSPEC and
       the address is 0.0.0.0.
    2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL
       if the socket family is not AF_INET6. Return EAFNOSUPPORT
       instead, for consistency with inet6_bind.
    3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT
       instead of EINVAL if an incorrect socket address structure is
       passed in.
    4. Make IPv6 ping sockets be IPv6-only. The code does not support
       IPv4, and it cannot easily be made to support IPv4 because
       the protocol numbers for ICMP and ICMPv6 are different. This
       makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead
       of making the socket unusable.
    
    Among other things, this fixes an oops that can be triggered by:
    
        int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
        struct sockaddr_in6 sin6 = {
            .sin6_family = AF_INET6,
            .sin6_addr = in6addr_any,
        };
        bind(s, (struct sockaddr *) &sin6, sizeof(sin6));
    
    Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241
    Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 123303d42ce123e99354f5fd448edc157bbf04c1
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Mon Mar 2 18:27:11 2015 +0100

    udp: only allow UFO for packets from SOCK_DGRAM sockets
    
    [ Upstream commit acf8dd0a9d0b9e4cdb597c2f74802f79c699e802 ]
    
    If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a
    UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to
    CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer
    checksum is to be computed on segmentation. However, in this case,
    skb->csum_start and skb->csum_offset are never set as raw socket
    transmit path bypasses udp_send_skb() where they are usually set. As a
    result, driver may access invalid memory when trying to calculate the
    checksum and store the result (as observed in virtio_net driver).
    
    Moreover, the very idea of modifying the userspace provided UDP header
    is IMHO against raw socket semantics (I wasn't able to find a document
    clearly stating this or the opposite, though). And while allowing
    CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit
    too intrusive change just to handle a corner case like this. Therefore
    disallowing UFO for packets from SOCK_DGRAM seems to be the best option.
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da122a6bc08e9d764e5c7750c9893211847a69d2
Author: Ben Shelton <ben.shelton@ni.com>
Date:   Mon Feb 16 13:47:06 2015 -0600

    usb: plusb: Add support for National Instruments host-to-host cable
    
    [ Upstream commit 42c972a1f390e3bc51ca1e434b7e28764992067f ]
    
    The National Instruments USB Host-to-Host Cable is based on the Prolific
    PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.
    
    Signed-off-by: Ben Shelton <ben.shelton@ni.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25ba5bb0d71737c85ba2bb3b63069ef751396814
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 27 09:42:50 2015 -0800

    net: do not use rcu in rtnl_dump_ifinfo()
    
    [ Upstream commit cac5e65e8a7ea074f2626d2eaa53aa308452dec4 ]
    
    We did a failed attempt in the past to only use rcu in rtnl dump
    operations (commit e67f88dd12f6 "net: dont hold rtnl mutex during
    netlink dump callbacks")
    
    Now that dumps are holding RTNL anyway, there is no need to also
    use rcu locking, as it forbids any scheduling ability, like
    GFP_KERNEL allocations that controlling path should use instead
    of GFP_ATOMIC whenever possible.
    
    This should fix following splat Cong Wang reported :
    
     [ INFO: suspicious RCU usage. ]
     3.19.0+ #805 Tainted: G        W
    
     include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section!
    
     other info that might help us debug this:
    
     rcu_scheduler_active = 1, debug_locks = 0
     2 locks held by ip/771:
      #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff8182b8f4>] netlink_dump+0x21/0x26c
      #1:  (rcu_read_lock){......}, at: [<ffffffff817d785b>] rcu_read_lock+0x0/0x6e
    
     stack backtrace:
     CPU: 3 PID: 771 Comm: ip Tainted: G        W       3.19.0+ #805
     Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6
      ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd
      00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758
     Call Trace:
      [<ffffffff81a27457>] dump_stack+0x4c/0x65
      [<ffffffff810b539b>] lockdep_rcu_suspicious+0x107/0x110
      [<ffffffff8109796f>] rcu_preempt_sleep_check+0x45/0x47
      [<ffffffff8109e457>] ___might_sleep+0x1d/0x1cb
      [<ffffffff8109e67d>] __might_sleep+0x78/0x80
      [<ffffffff814b9b1f>] idr_alloc+0x45/0xd1
      [<ffffffff810cb7ab>] ? rcu_read_lock_held+0x3b/0x3d
      [<ffffffff814b9f9d>] ? idr_for_each+0x53/0x101
      [<ffffffff817c1383>] alloc_netid+0x61/0x69
      [<ffffffff817c14c3>] __peernet2id+0x79/0x8d
      [<ffffffff817c1ab7>] peernet2id+0x13/0x1f
      [<ffffffff817d8673>] rtnl_fill_ifinfo+0xa8d/0xc20
      [<ffffffff810b17d9>] ? __lock_is_held+0x39/0x52
      [<ffffffff817d894f>] rtnl_dump_ifinfo+0x149/0x213
      [<ffffffff8182b9c2>] netlink_dump+0xef/0x26c
      [<ffffffff8182bcba>] netlink_recvmsg+0x17b/0x2c5
      [<ffffffff817b0adc>] __sock_recvmsg+0x4e/0x59
      [<ffffffff817b1b40>] sock_recvmsg+0x3f/0x51
      [<ffffffff817b1f9a>] ___sys_recvmsg+0xf6/0x1d9
      [<ffffffff8115dc67>] ? handle_pte_fault+0x6e1/0xd3d
      [<ffffffff8100a3a0>] ? native_sched_clock+0x35/0x37
      [<ffffffff8109f45b>] ? sched_clock_local+0x12/0x72
      [<ffffffff8109f6ac>] ? sched_clock_cpu+0x9e/0xb7
      [<ffffffff810cb7ab>] ? rcu_read_lock_held+0x3b/0x3d
      [<ffffffff811abde8>] ? __fcheck_files+0x4c/0x58
      [<ffffffff811ac556>] ? __fget_light+0x2d/0x52
      [<ffffffff817b376f>] __sys_recvmsg+0x42/0x60
      [<ffffffff817b379f>] SyS_recvmsg+0x12/0x1c
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Fixes: 0c7aecd4bde4b7302 ("netns: add rtnl cmd to add and get peer netns ids")
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d97191b06b7971ce1da4eb695896981dfdf1c8aa
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Feb 27 17:16:26 2015 +0100

    sh_eth: Fix lost MAC address on kexec
    
    [ Upstream commit a14c7d15ca91b444e77df08b916befdce77562ab ]
    
    Commit 740c7f31c094703c ("sh_eth: Ensure DMA engines are stopped before
    freeing buffers") added a call to sh_eth_reset() to the
    sh_eth_set_ringparam() and sh_eth_close() paths.
    
    However, setting the software reset bit(s) in the EDMR register resets
    the MAC Address Registers to zero. Hence after kexec, the new kernel
    doesn't detect a valid MAC address and assigns a random MAC address,
    breaking DHCP.
    
    Set the MAC address again after the reset in sh_eth_dev_exit() to fix
    this.
    
    Tested on r8a7740/armadillo (GETHER) and r8a7791/koelsch (FAST_RCAR).
    
    Fixes: 740c7f31c094703c ("sh_eth: Ensure DMA engines are stopped before freeing buffers")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e0f5ee1f98b0d703482d6a013f8026789e619cb
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Sat Feb 28 18:09:16 2015 -0800

    net: bcmgenet: fix software maintained statistics
    
    [ Upstream commit f62ba9c14b85a682b64a4c421f91de0bd2aa8538 ]
    
    Commit 44c8bc3ce39f ("net: bcmgenet: log RX buffer allocation and RX/TX dma
    failures") added a few software maintained statistics using
    BCMGENET_STAT_MIB_RX and BCMGENET_STAT_MIB_TX. These statistics are read from
    the hardware MIB counters, such that bcmgenet_update_mib_counters() was trying
    to read from a non-existing MIB offset for these counters.
    
    Fix this by introducing a special type: BCMGENET_STAT_SOFT, similar to
    BCMGENET_STAT_NETDEV, such that bcmgenet_get_ethtool_stats will read from the
    software mib.
    
    Fixes: 44c8bc3ce39f ("net: bcmgenet: log RX buffer allocation and RX/TX dma failures")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 001f8cee4a23a1822bad0b3eae0d16ee3cb6834c
Author: Jaedon Shin <jaedon.shin@gmail.com>
Date:   Sat Feb 28 11:48:26 2015 +0900

    net: bcmgenet: fix throughtput regression
    
    [ Upstream commit 4092e6acf5cb16f56154e2dd22d647023dc3d646 ]
    
    This patch adds bcmgenet_tx_poll for the tx_rings. This can reduce the
    interrupt load and send xmit in network stack on time. This also
    separated for the completion of tx_ring16 from bcmgenet_poll.
    
    The bcmgenet_tx_reclaim of tx_ring[{0,1,2,3}] operative by an interrupt
    is to be not more than a certain number TxBDs. It is caused by too
    slowly reclaiming the transmitted skb. Therefore, performance
    degradation of xmit after 605ad7f ("tcp: refine TSO autosizing").
    
    Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72e726749c2067cbbe7ad7ed1df2ad559aeafa6d
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 27 18:35:35 2015 -0800

    macvtap: make sure neighbour code can push ethernet header
    
    [ Upstream commit 2f1d8b9e8afa5a833d96afcd23abcb8cdf8d83ab ]
    
    Brian reported crashes using IPv6 traffic with macvtap/veth combo.
    
    I tracked the crashes in neigh_hh_output()
    
    -> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD);
    
    Neighbour code assumes headroom to push Ethernet header is
    at least 16 bytes.
    
    It appears macvtap has only 14 bytes available on arches
    where NET_IP_ALIGN is 0 (like x86)
    
    Effect is a corruption of 2 bytes right before skb->head,
    and possible crashes if accessing non existing memory.
    
    This fix should also increase IPv4 performance, as paranoid code
    in ip_finish_output2() wont have to call skb_realloc_headroom()
    
    Reported-by: Brian Rak <brak@vultr.com>
    Tested-by: Brian Rak <brak@vultr.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9a44034d0a6e2b27636a082dbc3efc89935bcd1
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Mon Feb 23 18:12:56 2015 +0000

    net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send, recv}msg
    
    [ Upstream commit d720d8cec563ce4e4fa44a613d4f2dcb1caf2998 ]
    
    With commit a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg), the
    MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points,
    changing the kernel compat behaviour from the one before the commit it
    was trying to fix (1be374a0518a, net: Block MSG_CMSG_COMPAT in
    send(m)msg and recv(m)msg).
    
    On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native
    32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by
    the kernel). However, on a 64-bit kernel, the compat ABI is different
    with commit a7526eb5d06b.
    
    This patch changes the compat_sys_{send,recv}msg behaviour to the one
    prior to commit 1be374a0518a.
    
    The problem was found running 32-bit LTP (sendmsg01) binary on an arm64
    kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg()
    but the general rule is not to break user ABI (even when the user
    behaviour is not entirely sane).
    
    Fixes: a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg)
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82b92857cb40358a86d092db31aa667c5d87af1c
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Mon Feb 23 14:02:54 2015 +0100

    team: fix possible null pointer dereference in team_handle_frame
    
    [ Upstream commit 57e595631904c827cfa1a0f7bbd7cc9a49da5745 ]
    
    Currently following race is possible in team:
    
    CPU0                                        CPU1
                                                team_port_del
                                                  team_upper_dev_unlink
                                                    priv_flags &= ~IFF_TEAM_PORT
    team_handle_frame
      team_port_get_rcu
        team_port_exists
          priv_flags & IFF_TEAM_PORT == 0
        return NULL (instead of port got
                     from rx_handler_data)
                                                  netdev_rx_handler_unregister
    
    The thing is that the flag is removed before rx_handler is unregistered.
    If team_handle_frame is called in between, team_port_exists returns 0
    and team_port_get_rcu will return NULL.
    So do not check the flag here. It is guaranteed by netdev_rx_handler_unregister
    that team_handle_frame will always see valid rx_handler_data pointer.
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37c63bf5b692b8311722b3b64c9d7fe0022d43bf
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Feb 22 17:03:41 2015 -0800

    net: pktgen: disable xmit_clone on virtual devices
    
    [ Upstream commit 52d6c8c6ca125872459054daa70f2f1c698c8e75 ]
    
    Trying to use burst capability (aka xmit_more) on a virtual device
    like bonding is not supported.
    
    For example, skb might be queued multiple times on a qdisc, with
    various list corruptions.
    
    Fixes: 38b2cf2982dc ("net: pktgen: packet bursting via skb->xmit_more")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexei Starovoitov <ast@plumgrid.com>
    Acked-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ae56d8b65097d9f5b95e49663af5f6a479fe839
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Mar 10 18:47:33 2015 -0400

    Revert "r8169: add support for Byte Queue Limits"
    
    This reverts commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6.
    
    Revert BQL support in r8169 driver as several regressions
    point to this commit and we cannot figure out the real
    cause yet.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 465146d28c3173d31229df1cf53a4696360a399d
Author: Matthew Thode <mthode@mthode.org>
Date:   Tue Feb 17 18:31:57 2015 -0600

    net: reject creation of netdev names with colons
    
    [ Upstream commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 ]
    
    colons are used as a separator in netdev device lookup in dev_ioctl.c
    
    Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME
    
    Signed-off-by: Matthew Thode <mthode@mthode.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d0ba3cf285bc815de7d4cf3fc2bf9fe4d4e5c5c
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Feb 18 05:47:55 2015 -0800

    sock: sock_dequeue_err_skb() needs hard irq safety
    
    [ Upstream commit 997d5c3f4427f38562cbe207ce05bb25fdcb993b ]
    
    Non NAPI drivers can call skb_tstamp_tx() and then sock_queue_err_skb()
    from hard IRQ context.
    
    Therefore, sock_dequeue_err_skb() needs to block hard irq or
    corruptions or hangs can happen.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Fixes: 364a9e93243d1 ("sock: deduplicate errqueue dequeue")
    Fixes: cb820f8e4b7f7 ("net: Provide a generic socket error queue delivery method for Tx time stamps.")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 488da593c9e4eafd5783a631e644af67fd6cf003
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Tue Feb 17 11:23:10 2015 -0800

    openvswitch: Fix net exit.
    
    [ Upstream commit 7b4577a9da3702049650f7095506e9afd9f68849 ]
    
    Open vSwitch allows moving internal vport to different namespace
    while still connected to the bridge. But when namespace deleted
    OVS does not detach these vports, that results in dangling
    pointer to netdevice which causes kernel panic as follows.
    This issue is fixed by detaching all ovs ports from the deleted
    namespace at net-exit.
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
    IP: [<ffffffffa0aadaa5>] ovs_vport_locate+0x35/0x80 [openvswitch]
    Oops: 0000 [#1] SMP
    Call Trace:
     [<ffffffffa0aa6391>] lookup_vport+0x21/0xd0 [openvswitch]
     [<ffffffffa0aa65f9>] ovs_vport_cmd_get+0x59/0xf0 [openvswitch]
     [<ffffffff8167e07c>] genl_family_rcv_msg+0x1bc/0x3e0
     [<ffffffff8167e319>] genl_rcv_msg+0x79/0xc0
     [<ffffffff8167d919>] netlink_rcv_skb+0xb9/0xe0
     [<ffffffff8167deac>] genl_rcv+0x2c/0x40
     [<ffffffff8167cffd>] netlink_unicast+0x12d/0x1c0
     [<ffffffff8167d3da>] netlink_sendmsg+0x34a/0x6b0
     [<ffffffff8162e140>] sock_sendmsg+0xa0/0xe0
     [<ffffffff8162e5e8>] ___sys_sendmsg+0x408/0x420
     [<ffffffff8162f541>] __sys_sendmsg+0x51/0x90
     [<ffffffff8162f592>] SyS_sendmsg+0x12/0x20
     [<ffffffff81764ee9>] system_call_fastpath+0x12/0x17
    
    Reported-by: Assaf Muller <amuller@redhat.com>
    Fixes: 46df7b81454("openvswitch: Add support for network namespaces.")
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Reviewed-by: Thomas Graf <tgraf@noironetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f77f6c882bcd27a9bf750f96e9fe63ecbe443f5
Author: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date:   Tue Feb 17 20:15:20 2015 +0100

    ematch: Fix auto-loading of ematch modules.
    
    [ Upstream commit 34eea79e2664b314cab6a30fc582fdfa7a1bb1df ]
    
    In tcf_em_validate(), after calling request_module() to load the
    kind-specific module, set em->ops to NULL before returning -EAGAIN, so
    that module_put() is not called again by tcf_em_tree_destroy().
    
    Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
    Acked-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dd8e3243c434a4f45bf2a5d1d3a9a0baf37ef64
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Feb 17 09:36:22 2015 -0800

    net: phy: Fix verification of EEE support in phy_init_eee
    
    [ Upstream commit 54da5a8be3c1e924c35480eb44c6e9b275f6444e ]
    
    phy_init_eee uses phy_find_setting(phydev->speed, phydev->duplex)
    to find a valid entry in the settings array for the given speed
    and duplex value. For full duplex 1000baseT, this will return
    the first matching entry, which is the entry for 1000baseKX_Full.
    
    If the phy eee does not support 1000baseKX_Full, this entry will not
    match, causing phy_init_eee to fail for no good reason.
    
    Fixes: 9a9c56cb34e6 ("net: phy: fix a bug when verify the EEE support")
    Fixes: 3e7077067e80c ("phy: Expand phy speed/duplex settings array")
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8959499caafe926472ef0475344a913c825c2708
Author: Alexander Drozdov <al.drozdov@gmail.com>
Date:   Thu Mar 5 10:29:39 2015 +0300

    ipv4: ip_check_defrag should not assume that skb_network_offset is zero
    
    [ Upstream commit 3e32e733d1bbb3f227259dc782ef01d5706bdae0 ]
    
    ip_check_defrag() may be used by af_packet to defragment outgoing packets.
    skb_network_offset() of af_packet's outgoing packets is not zero.
    
    Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ccd26c9825ebeb625f04d2e7ebe9c8478a20afe
Author: Alexander Drozdov <al.drozdov@gmail.com>
Date:   Tue Feb 17 13:33:46 2015 +0300

    ipv4: ip_check_defrag should correctly check return value of skb_copy_bits
    
    [ Upstream commit fba04a9e0c869498889b6445fd06cbe7da9bb834 ]
    
    skb_copy_bits() returns zero on success and negative value on error,
    so it is needed to invert the condition in ip_check_defrag().
    
    Fixes: 1bf3751ec90c ("ipv4: ip_check_defrag must not modify skb before unsharing")
    Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e67e4522676c60772d3bf476bfbf99fd7d4c1aca
Author: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date:   Fri Feb 13 14:47:05 2015 -0800

    gen_stats.c: Duplicate xstats buffer for later use
    
    [ Upstream commit 1c4cff0cf55011792125b6041bc4e9713e46240f ]
    
    The gnet_stats_copy_app() function gets called, more often than not, with its
    second argument a pointer to an automatic variable in the caller's stack.
    Therefore, to avoid copying garbage afterwards when calling
    gnet_stats_finish_copy(), this data is better copied to a dynamically allocated
    memory that gets freed after use.
    
    [xiyou.wangcong@gmail.com: remove a useless kfree()]
    
    Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f3b6173e44a8add131deffe49c556472301f281
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Fri Feb 13 13:56:53 2015 -0800

    rtnetlink: call ->dellink on failure when ->newlink exists
    
    [ Upstream commit 7afb8886a05be68e376655539a064ec672de8a8e ]
    
    Ignacy reported that when eth0 is down and add a vlan device
    on top of it like:
    
      ip link add link eth0 name eth0.1 up type vlan id 1
    
    We will get a refcount leak:
    
      unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2
    
    The problem is when rtnl_configure_link() fails in rtnl_newlink(),
    we simply call unregister_device(), but for stacked device like vlan,
    we almost do nothing when we unregister the upper device, more work
    is done when we unregister the lower device, so call its ->dellink().
    
    Reported-by: Ignacy Gawedzki <ignacy.gawedzki@green-communications.fr>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29ec76704d111f747e5640ce3998611c5407049b
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Thu Feb 12 16:14:08 2015 -0800

    ipv6: fix ipv6_cow_metrics for non DST_HOST case
    
    [ Upstream commit 3b4711757d7903ab6fa88a9e7ab8901b8227da60 ]
    
    ipv6_cow_metrics() currently assumes only DST_HOST routes require
    dynamic metrics allocation from inetpeer.  The assumption breaks
    when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
    Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
    is called after the route is created.
    
    This patch creates the metrics array (by calling dst_cow_metrics_generic) in
    ipv6_cow_metrics().
    
    Test:
    radvd.conf:
    interface qemubr0
    {
    	AdvLinkMTU 1300;
    	AdvCurHopLimit 30;
    
    	prefix fd00:face:face:face::/64
    	{
    		AdvOnLink on;
    		AdvAutonomous on;
    		AdvRouterAddr off;
    	};
    };
    
    Before:
    [root@qemu1 ~]# ip -6 r show | egrep -v unreachable
    fd00:face:face:face::/64 dev eth0  proto kernel  metric 256  expires 27sec
    fe80::/64 dev eth0  proto kernel  metric 256
    default via fe80::74df:d0ff:fe23:8ef2 dev eth0  proto ra  metric 1024  expires 27sec
    
    After:
    [root@qemu1 ~]# ip -6 r show | egrep -v unreachable
    fd00:face:face:face::/64 dev eth0  proto kernel  metric 256  expires 27sec mtu 1300
    fe80::/64 dev eth0  proto kernel  metric 256  mtu 1300
    default via fe80::74df:d0ff:fe23:8ef2 dev eth0  proto ra  metric 1024  expires 27sec mtu 1300 hoplimit 30
    
    Fixes: 8e2ec639173f325 (ipv6: don't use inetpeer to store metrics for routes.)
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b73f6e471cdd6c4474aff6b6301af2779462d98d
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 13 04:47:12 2015 -0800

    tcp: make sure skb is not shared before using skb_get()
    
    [ Upstream commit ba34e6d9d346fe4e05d7e417b9edf5140772d34c ]
    
    IPv6 can keep a copy of SYN message using skb_get() in
    tcp_v6_conn_request() so that caller wont free the skb when calling
    kfree_skb() later.
    
    Therefore TCP fast open has to clone the skb it is queuing in
    child->sk_receive_queue, as all skbs consumed from receive_queue are
    freed using __kfree_skb() (ie assuming skb->users == 1)
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Fixes: 5b7ed0892f2af ("tcp: move fastopen functions to tcp_fastopen.c")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9519ba7401b98c4c882d06b218d14dce45fcb7c1
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Mon Feb 9 09:38:21 2015 -0500

    ipv6: Make __ipv6_select_ident static
    
    [ Upstream commit 8381eacf5c3b35cf7755f4bc521c4d56d24c1cd9 ]
    
    Make __ipv6_select_ident() static as it isn't used outside
    the file.
    
    Fixes: 0508c07f5e0c9 (ipv6: Select fragment id during UFO segmentation if not set.)
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aee614696c22c6ba6a12de0382e814a347ef25e0
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Mon Feb 9 09:38:20 2015 -0500

    ipv6: Fix fragment id assignment on LE arches.
    
    [ Upstream commit 51f30770e50eb787200f30a79105e2615b379334 ]
    
    Recent commit:
    0508c07f5e0c94f38afd5434e8b2a55b84553077
    Author: Vlad Yasevich <vyasevich@gmail.com>
    Date:   Tue Feb 3 16:36:15 2015 -0500
    
        ipv6: Select fragment id during UFO segmentation if not set.
    
    Introduced a bug on LE in how ipv6 fragment id is assigned.
    This was cought by nightly sparce check:
    
    Resolve the following sparce error:
     net/ipv6/output_core.c:57:38: sparse: incorrect type in assignment
     (different base types)
       net/ipv6/output_core.c:57:38:    expected restricted __be32
    [usertype] ip6_frag_id
       net/ipv6/output_core.c:57:38:    got unsigned int [unsigned]
    [assigned] [usertype] id
    
    Fixes: 0508c07f5e0c9 (ipv6: Select fragment id during UFO segmentation if not set.)
    Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f630d422d9a18523c75be7fa81d413210904a44
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Feb 5 18:44:04 2015 +0100

    rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY
    
    [ Upstream commit 364d5716a7adb91b731a35765d369602d68d2881 ]
    
    ifla_vf_policy[] is wrong in advertising its individual member types as
    NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
    len member as *max* attribute length [0, len].
    
    The issue is that when do_setvfinfo() is being called to set up a VF
    through ndo handler, we could set corrupted data if the attribute length
    is less than the size of the related structure itself.
    
    The intent is exactly the opposite, namely to make sure to pass at least
    data of minimum size of len.
    
    Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
    Cc: Mitch Williams <mitch.a.williams@intel.com>
    Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18bb5d3023fbf4331128c67df627cd88ab47911b
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Feb 4 23:08:50 2015 +0100

    pktgen: fix UDP checksum computation
    
    [ Upstream commit 7744b5f3693cc06695cb9d6667671c790282730f ]
    
    This patch fixes two issues in UDP checksum computation in pktgen.
    
    First, the pseudo-header uses the source and destination IP
    addresses. Currently, the ports are used for IPv4.
    
    Second, the UDP checksum covers both header and data.  So we need to
    generate the data earlier (move pktgen_finalize_skb up), and compute
    the checksum for UDP header + data.
    
    Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Acked-by: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5484abd9b6a0449ccca3875dc3eee4ad7e6ebcdd
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Feb 5 14:39:11 2015 +0100

    ipv6: addrconf: add missing validate_link_af handler
    
    [ Upstream commit 11b1f8288d4341af5d755281c871bff6c3e270dd ]
    
    We still need a validate_link_af() handler with an appropriate nla policy,
    similarly as we have in IPv4 case, otherwise size validations are not being
    done properly in that case.
    
    Fixes: f53adae4eae5 ("net: ipv6: add tokenized interface identifier support")
    Fixes: bc91b0f07ada ("ipv6: addrconf: implement address generation modes")
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ec37c5e28b90c8f9f5173c0a7a61d513684f7b5
Author: Miroslav Urbanek <mu@miroslavurbanek.com>
Date:   Thu Feb 5 16:36:50 2015 +0100

    flowcache: Fix kernel panic in flow_cache_flush_task
    
    [ Upstream commit 233c96fc077d310772375d47522fb444ff546905 ]
    
    flow_cache_flush_task references a structure member flow_cache_gc_work
    where it should reference flow_cache_flush_task instead.
    
    Kernel panic occurs on kernels using IPsec during XFRM garbage
    collection. The garbage collection interval can be shortened using the
    following sysctl settings:
    
    net.ipv4.xfrm4_gc_thresh=4
    net.ipv6.xfrm6_gc_thresh=4
    
    With the default settings, our productions servers crash approximately
    once a week. With the settings above, they crash immediately.
    
    Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
    Reported-by: Tomáš Charvát <tc@excello.cz>
    Tested-by: Jan Hejl <jh@excello.cz>
    Signed-off-by: Miroslav Urbanek <mu@miroslavurbanek.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>