commit c48465423908a8955cd6de09b871161324cf5205
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jul 3 19:48:19 2015 -0700

    Linux 3.10.83

commit 2667677fb84b4b92e31573f2f2ffaec7a8772747
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Mon Apr 14 15:47:01 2014 +0200

    bus: mvebu: pass the coherency availability information at init time
    
    commit 5686a1e5aa436c49187a60052d5885fb1f541ce6 upstream.
    
    Until now, the mvebu-mbus was guessing by itself whether hardware I/O
    coherency was available or not by poking into the Device Tree to see
    if the coherency fabric Device Tree node was present or not.
    
    However, on some upcoming SoCs, the presence or absence of the
    coherency fabric DT node isn't sufficient: in CONFIG_SMP, the
    coherency can be enabled, but not in !CONFIG_SMP.
    
    In order to clean this up, the mvebu_mbus_dt_init() function is
    extended to get a boolean argument telling whether coherency is
    enabled or not. Therefore, the logic to decide whether coherency is
    available or not now belongs to the core SoC code instead of the
    mvebu-mbus driver itself, which is much better.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    
    [ Greg Ungerer: back ported to linux-3.10.y
      Back port necessary due to large code differences in affected files.
      This change in combination with commit e553554536 ("ARM: mvebu: disable
      I/O coherency on non-SMP situations on Armada 370/375/38x/XP") is
      critical to the hardware I/O coherency being set correctly by both the
      mbus driver and all peripheral hardware drivers. Without this change
      drivers will incorrectly enable I/O coherency window attributes and
      this causes rare unreliable system behavior including oops. ]
    
    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea0d66be1c27f55825a80d01ad1ff72f6e005c29
Author: Bandan Das <bsd@redhat.com>
Date:   Thu Jun 11 02:05:33 2015 -0400

    KVM: nSVM: Check for NRIPS support before updating control field
    
    commit f104765b4f81fd74d69e0eb161e89096deade2db upstream.
    
    If hardware doesn't support DecodeAssist - a feature that provides
    more information about the intercept in the VMCB, KVM decodes the
    instruction and then updates the next_rip vmcb control field.
    However, NRIP support itself depends on cpuid Fn8000_000A_EDX[NRIPS].
    Since skip_emulated_instruction() doesn't verify nrip support
    before accepting control.next_rip as valid, avoid writing this
    field if support isn't present.
    
    Signed-off-by: Bandan Das <bsd@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cae4bbc1a8f5258a986801d72678752f9075a64
Author: Sebastien Szymanski <sebastien.szymanski@armadeus.com>
Date:   Wed May 20 16:30:37 2015 +0200

    ARM: clk-imx6q: refine sata's parent
    
    commit da946aeaeadcd24ff0cda9984c6fb8ed2bfd462a upstream.
    
    According to IMX6D/Q RM, table 18-3, sata clock's parent is ahb, not ipg.
    
    Signed-off-by: Sebastien Szymanski <sebastien.szymanski@armadeus.com>
    Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    [dirk.behme: Adjust moved file]
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b93e0acc5001b80153cb0c7efcdcc53cc56aac4a
Author: Jari Ruusu <jariruusu@users.sourceforge.net>
Date:   Sat Jun 13 19:01:31 2015 +0300

    d_walk() might skip too much
    
    When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
    backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
    was copied to 3 different places. Later, a bug in that code was discovered.
    Al Viro's fix involved fixing only one part of code in mainline kernel. That
    fix is called "d_walk() might skip too much".
    
    3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
    different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
    too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
    fix.
    
    The patch below was not written by me. I only applied Al Viro's "d_walk()
    might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
    the fixes went to correct places. With this patch applied, all 3 places that
    I am aware of 3.10.y stable branch are now fixed.
    
    Signed-off-by: Jari Ruusu <jariruusu@users.sourceforge.net>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1e1eb159efadf28f0da0de550d696abdb30aefc
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Thu Aug 1 10:04:24 2013 +0200

    ipv6: update ip6_rt_last_gc every time GC is run
    
    commit 49a18d86f66d33a20144ecb5a34bba0d1856b260 upstream.
    
    As pointed out by Eric Dumazet, net->ipv6.ip6_rt_last_gc should
    hold the last time garbage collector was run so that we should
    update it whenever fib6_run_gc() calls fib6_clean_all(), not only
    if we got there from ip6_dst_gc().
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba310bc86f54169bf4ec414683bd61dcd2f8675f
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Thu Aug 1 10:04:14 2013 +0200

    ipv6: prevent fib6_run_gc() contention
    
    commit 2ac3ac8f86f2fe065d746d9a9abaca867adec577 upstream.
    
    On a high-traffic router with many processors and many IPv6 dst
    entries, soft lockup in fib6_run_gc() can occur when number of
    entries reaches gc_thresh.
    
    This happens because fib6_run_gc() uses fib6_gc_lock to allow
    only one thread to run the garbage collector but ip6_dst_gc()
    doesn't update net->ipv6.ip6_rt_last_gc until fib6_run_gc()
    returns. On a system with many entries, this can take some time
    so that in the meantime, other threads pass the tests in
    ip6_dst_gc() (ip6_rt_last_gc is still not updated) and wait for
    the lock. They then have to run the garbage collector one after
    another which blocks them for quite long.
    
    Resolve this by replacing special value ~0UL of expire parameter
    to fib6_run_gc() by explicit "force" parameter to choose between
    spin_lock_bh() and spin_trylock_bh() and call fib6_run_gc() with
    force=false if gc_thresh is reached but not max_size.
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 528555d05bde69c436bb0126ea95635da24d889e
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Fri Oct 25 10:21:32 2013 +0200

    xfrm: Increase the garbage collector threshold
    
    commit eeb1b73378b560e00ff1da2ef09fed9254f4e128 upstream.
    
    With the removal of the routing cache, we lost the
    option to tweak the garbage collector threshold
    along with the maximum routing cache size. So git
    commit 703fb94ec ("xfrm: Fix the gc threshold value
    for ipv4") moved back to a static threshold.
    
    It turned out that the current threshold before we
    start garbage collecting is much to small for some
    workloads, so increase it from 1024 to 32768. This
    means that we start the garbage collector if we have
    more than 32768 dst entries in the system and refuse
    new allocations if we are above 65536.
    
    Reported-by: Wolfgang Walter <linux@stwm.de>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Stephen Hemminger <shemming@brocade.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43f2e3615d181a7028ab797114c5960977669b2a
Author: Filipe Manana <fdmanana@suse.com>
Date:   Sun Nov 9 08:38:39 2014 +0000

    Btrfs: make xattr replace operations atomic
    
    commit 5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339 upstream.
    
    Replacing a xattr consists of doing a lookup for its existing value, delete
    the current value from the respective leaf, release the search path and then
    finally insert the new value. This leaves a time window where readers (getxattr,
    listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
    so this has security implications.
    
    This change also fixes 2 other existing issues which were:
    
    *) Deleting the old xattr value without verifying first if the new xattr will
       fit in the existing leaf item (in case multiple xattrs are packed in the
       same item due to name hash collision);
    
    *) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
       exist but we have have an existing item that packs muliple xattrs with
       the same name hash as the input xattr. In this case we should return ENOSPC.
    
    A test case for xfstests follows soon.
    
    Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
    implementation.
    
    Reported-by: Alexandre Oliva <oliva@gnu.org>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    [shengyong: backport to 3.10
     - FIX: CVE-2014-9710
     - adjust context
     - ASSERT() was added v3.12, so we do check with if statement
     - set the first parameter of btrfs_item_nr() as NULL, because it is not
       used, and is removed in v3.13
    ]
    Signed-off-by: Sheng Yong <shengyong1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66bd44e6a5c8f24805f94d19f943301d7a7f418e
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date:   Tue Feb 3 13:00:22 2015 +0100

    x86/microcode/intel: Guard against stack overflow in the loader
    
    commit f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4 upstream.
    
    mc_saved_tmp is a static array allocated on the stack, we need to make
    sure mc_saved_count stays within its bounds, otherwise we're overflowing
    the stack in _save_mc(). A specially crafted microcode header could lead
    to a kernel crash or potentially kernel execution.
    
    Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Link: http://lkml.kernel.org/r/1422964824-22056-1-git-send-email-quentin.casasnovas@oracle.com
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Sheng Yong <shengyong1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eae8ac6ab40b896b472c526afe7847e798f4f36
Author: Jann Horn <jann@thejh.net>
Date:   Sun Apr 19 02:48:39 2015 +0200

    fs: take i_mutex during prepare_binprm for set[ug]id executables
    
    commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543 upstream.
    
    This prevents a race between chown() and execve(), where chowning a
    setuid-user binary to root would momentarily make the binary setuid
    root.
    
    This patch was mostly written by Linus Torvalds.
    
    Signed-off-by: Jann Horn <jann@thejh.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Charles Williams <ciwillia@brocade.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Sheng Yong <shengyong1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31884f5463499bf023772ce94b003d40b5db08fc
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Fri Sep 12 14:44:15 2014 +0200

    hpsa: add missing pci_set_master in kdump path
    
    commit 859c75aba20264d87dd026bab0d0ca3bff385955 upstream.
    
    Add a call to pci_set_master(...)  missing in the previous
    patch "hpsa: refine the pci enable/disable handling".
    Found thanks to Rob Elliot.
    
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Robert Elliott <elliott@hp.com>
    Tested-by: Robert Elliott <elliott@hp.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a82524ebeb75562563192218e01462fb60c68f4
Author: Tomas Henzl <thenzl@redhat.com>
Date:   Thu Aug 14 16:12:39 2014 +0200

    hpsa: refine the pci enable/disable handling
    
    commit 132aa220b45d60e9b20def1e9d8be9422eed9616 upstream.
    
    When a second(kdump) kernel starts and the hard reset method is used
    the driver calls pci_disable_device without previously enabling it,
    so the kernel shows a warning -
    [   16.876248] WARNING: at drivers/pci/pci.c:1431 pci_disable_device+0x84/0x90()
    [   16.882686] Device hpsa
    disabling already-disabled device
    ...
    This patch fixes it, in addition to this I tried to balance also some other pairs
    of enable/disable device in the driver.
    Unfortunately I wasn't able to verify the functionality for the case of a sw reset,
    because of a lack of proper hw.
    
    Signed-off-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29e7fa7cb70a5f4b0e934f80949d1f1c6a6dc0a6
Author: Jim Snow <jim.m.snow@intel.com>
Date:   Tue Nov 18 14:51:09 2014 +0100

    sb_edac: Fix erroneous bytes->gigabytes conversion
    
    commit 8c009100295597f23978c224aec5751a365bc965 upstream.
    
    Signed-off-by: Jim Snow <jim.snow@intel.com>
    Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Vinson Lee <vlee@twopensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2dac7a1d62f940989d3695d44d04afef4d291f6
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Mon Apr 13 11:48:52 2015 +0800

    ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.
    
    commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream.
    
    ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6
    
    For physical addresses, since the address may exceed 32-bit address range
    after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
    and ACPI_FORMAT_UINT64() instead of
    ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().
    
    This patch also removes above replaced macros as there are no users.
    
    This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
    kernel builds.
    
    Link: https://github.com/acpica/acpica/commit/b6061237
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    [gdavis: Move tbprint.c changes to tbutils.c due to lack of commit
    	 "42f4786 ACPICA: Split table print utilities to a new a
    	 separate file" in linux-3.10.y]
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dce4607145619ed563859413db8374c270319f6
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Mon Apr 13 11:48:46 2015 +0800

    ACPICA: Utilities: Cleanup to convert physical address printing formats.
    
    commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream.
    
    ACPICA commit 7f06739db43a85083a70371c14141008f20b2198
    
    For physical addresses, since the address may exceed 32-bit address range
    after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
    convert the %p formats.
    
    This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
    kernel builds.
    
    Link: https://github.com/acpica/acpica/commit/7f06739d
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
    [gdavis: Move tbinstall.c changes to tbutils.c due to lack of commit
    	 "42f4786 ACPICA: Split table print utilities to a new a
    	 separate file" in linux-3.10.y]
    Signed-off-by: George G. Davis <george_davis@mentor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a20cc70d1e37617c25c336ec036186d369946765
Author: Mark Grondona <mgrondona@llnl.gov>
Date:   Wed Sep 11 14:24:31 2013 -0700

    __ptrace_may_access() should not deny sub-threads
    
    commit 73af963f9f3036dffed55c3a2898598186db1045 upstream.
    
    __ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task !=
    current, this can can lead to surprising results.
    
    For example, a sub-thread can't readlink("/proc/self/exe") if the
    executable is not readable.  setup_new_exec()->would_dump() notices that
    inode_permission(MAY_READ) fails and then it does
    set_dumpable(suid_dumpable).  After that get_dumpable() fails.
    
    (It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we
    could add PTRACE_MODE_NODUMPABLE)
    
    Change __ptrace_may_access() to use same_thread_group() instead of "task
    == current".  Any security check is pointless when the tasks share the
    same ->mm.
    
    Signed-off-by: Mark Grondona <mgrondona@llnl.gov>
    Signed-off-by: Ben Woodard <woodard@redhat.com>
    Signed-off-by: Oleg Nesterov <oleg@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 434c32f798d372fbeff6258a1178dbeb41d960d4
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Wed Sep 11 14:20:06 2013 -0700

    include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid
    
    commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream.
    
    task_struct->pid/tgid should go away.
    
    1. Change same_thread_group() to use task->signal for comparison.
    
    2. Change has_group_leader_pid(task) to compare task_pid(task) with
       signal->leader_pid.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Sergey Dyasly <dserrg@gmail.com>
    Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c6300bb4934b8f9f881b1645c087b2ddba922f9
Author: Ian Wilson <iwilson@brocade.com>
Date:   Thu Mar 12 09:37:58 2015 +0000

    netfilter: Zero the tuple in nfnl_cthelper_parse_tuple()
    
    commit 78146572b9cd20452da47951812f35b1ad4906be upstream.
    
    nfnl_cthelper_parse_tuple() is called from nfnl_cthelper_new(),
    nfnl_cthelper_get() and nfnl_cthelper_del().  In each case they pass
    a pointer to an nf_conntrack_tuple data structure local variable:
    
        struct nf_conntrack_tuple tuple;
        ...
        ret = nfnl_cthelper_parse_tuple(&tuple, tb[NFCTH_TUPLE]);
    
    The problem is that this local variable is not initialized, and
    nfnl_cthelper_parse_tuple() only initializes two fields: src.l3num and
    dst.protonum.  This leaves all other fields with undefined values
    based on whatever is on the stack:
    
        tuple->src.l3num = ntohs(nla_get_be16(tb[NFCTH_TUPLE_L3PROTONUM]));
        tuple->dst.protonum = nla_get_u8(tb[NFCTH_TUPLE_L4PROTONUM]);
    
    The symptom observed was that when the rpc and tns helpers were added
    then traffic to port 1536 was being sent to user-space.
    
    Signed-off-by: Ian Wilson <iwilson@brocade.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59bc21951c78625486741b33eafdacbe57ce688d
Author: Chen Gang <gang.chen.5i5j@gmail.com>
Date:   Wed Dec 24 23:04:54 2014 +0800

    netfilter: nfnetlink_cthelper: Remove 'const' and '&' to avoid warnings
    
    commit b18c5d15e8714336365d9d51782d5b53afa0443c upstream.
    
    The related code can be simplified, and also can avoid related warnings
    (with allmodconfig under parisc):
    
        CC [M]  net/netfilter/nfnetlink_cthelper.o
      net/netfilter/nfnetlink_cthelper.c: In function ‘nfnl_cthelper_from_nlattr’:
      net/netfilter/nfnetlink_cthelper.c:97:9: warning: passing argument 1 o ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]
        memcpy(&help->data, nla_data(attr), help->helper->data_len);
               ^
      In file included from include/linux/string.h:17:0,
                       from include/uapi/linux/uuid.h:25,
                       from include/linux/uuid.h:23,
                       from include/linux/mod_devicetable.h:12,
                       from ./arch/parisc/include/asm/hardware.h:4,
                       from ./arch/parisc/include/asm/processor.h:15,
                       from ./arch/parisc/include/asm/spinlock.h:6,
                       from ./arch/parisc/include/asm/atomic.h:21,
                       from include/linux/atomic.h:4,
                       from ./arch/parisc/include/asm/bitops.h:12,
                       from include/linux/bitops.h:36,
                       from include/linux/kernel.h:10,
                       from include/linux/list.h:8,
                       from include/linux/module.h:9,
                       from net/netfilter/nfnetlink_cthelper.c:11:
      ./arch/parisc/include/asm/string.h:8:8: note: expected ‘void *’ but argument is of type ‘const char (*)[]’
       void * memcpy(void * dest,const void *src,size_t count);
              ^
    
    Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@soleta.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff19fc34c96fa1e6eef703eccaaf14f47cfd08ce
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Apr 17 15:04:48 2015 -0400

    config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected
    
    commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream.
    
    A huge amount of NIC drivers use the DMA API, however if
    compiled under 32-bit an very important part of the DMA API can
    be ommitted leading to the drivers not working at all
    (especially if used with 'swiotlb=force iommu=soft').
    
    As Prashant Sreedharan explains it: "the driver [tg3] uses
    DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of
    the dma "mapping" and dma_unmap_addr() to get the "mapping"
    value. On most of the platforms this is a no-op, but ... with
    "iommu=soft and swiotlb=force" this house keeping is required,
    ... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_
    instead of the DMA address."
    
    As such enable this even when using 32-bit kernels.
    
    Reported-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Acked-by: Prashant Sreedharan <prashant@broadcom.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michael Chan <mchan@broadcom.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: boris.ostrovsky@oracle.com
    Cc: cascardo@linux.vnet.ibm.com
    Cc: david.vrabel@citrix.com
    Cc: sanjeevb@broadcom.com
    Cc: siva.kallam@broadcom.com
    Cc: vyasevich@gmail.com
    Cc: xen-devel@lists.xensource.com
    Link: http://lkml.kernel.org/r/20150417190448.GA9462@l.oracle.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68c8a7ae3030f73631a98d4d9ee16e31cba0c1b5
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Oct 4 11:06:42 2013 -0400

    get rid of s_files and files_lock
    
    commit eee5cc2702929fd41cce28058dc6d6717f723f87 upstream.
    
    The only thing we need it for is alt-sysrq-r (emergency remount r/o)
    and these days we can do just as well without going through the
    list of files.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [wangkai: backport to 3.10: adjust context]
    Signed-off-by: Wang Kai <morgan.wang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a7abb5a0b35ca8f7c9f8113322fbff87b5d6667
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Jul 8 14:24:16 2013 -0700

    fput: turn "list_head delayed_fput_list" into llist_head
    
    commit 4f5e65a1cc90bbb15b9f6cdc362922af1bcc155a upstream.
    
    fput() and delayed_fput() can use llist and avoid the locking.
    
    This is unlikely path, it is not that this change can improve
    the performance, but this way the code looks simpler.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Suggested-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Andrey Vagin <avagin@openvz.org>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Wang Kai <morgan.wang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>