commit f1178e991adbe6ea8a7524c8c83fa479dc26c765
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jul 10 10:40:38 2015 -0700

    Linux 3.10.84

commit 9b9724dc865428f0bc900f653b636456e81d8e3b
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 21 16:05:52 2015 +0200

    fs: Fix S_NOSEC handling
    
    commit 2426f3910069ed47c0cc58559a6d088af7920201 upstream.
    
    file_remove_suid() could mistakenly set S_NOSEC inode bit when root was
    modifying the file. As a result following writes to the file by ordinary
    user would avoid clearing suid or sgid bits.
    
    Fix the bug by checking actual mode bits before setting S_NOSEC.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 455aa7c4b828827944a2b24df33de9b64b8d18cb
Author: Radim Krčmář <rkrcmar@redhat.com>
Date:   Wed Jul 1 15:31:49 2015 +0200

    KVM: x86: make vapics_in_nmi_mode atomic
    
    commit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream.
    
    Writes were a bit racy, but hard to turn into a bug at the same time.
    (Particularly because modern Linux doesn't use this feature anymore.)
    
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [Actually the next patch makes it much, much easier to trigger the race
     so I'm including this one for stable@ as well. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce2eb12c5858e7d67a4e22188734e0136c311d8e
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Apr 27 15:07:16 2015 +0100

    MIPS: Fix KVM guest fixmap address
    
    commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 upstream.
    
    KVM guest kernels for trap & emulate run in user mode, with a modified
    set of kernel memory segments. However the fixmap address is still in
    the normal KSeg3 region at 0xfffe0000 regardless, causing problems when
    cache alias handling makes use of them when handling copy on write.
    
    Therefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped
    region when CONFIG_KVM_GUEST is defined.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/9887/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc86cafe9a0c6d10c2e1a7c6d6e3ff1c98b65edc
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Jun 9 18:54:07 2015 -0500

    x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A
    
    commit 1dace0116d0b05c967d94644fc4dfe96be2ecd3d upstream.
    
    The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign
    resources correctly without the information from _CRS that tells us which
    address ranges are claimed by which bridge.  In the bugs mentioned below,
    we incorrectly assign a sound card address (this example is from 1033299):
    
      bus: 00 index 2 [mem 0x80000000-0xfcffffffff]
      ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
      pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored)
      pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored)
      pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored)
      ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])
      pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored)
      pci 0000:80:01.0: [1106:3288] type 0 class 0x000403
      pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit]
      pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff]
      pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit]
      BUG: unable to handle kernel paging request at ffffc90000378000
      IP: [<ffffffffa0345f63>] azx_create+0x37c/0x822 [snd_hda_intel]
    
    We assigned 0xfd_0000_0000, but that is not in any of the host bridge
    windows, and the sound card doesn't work.
    
    Turn on pci=use_crs automatically for this system.
    
    Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368
    Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa517b185cf09969c4783d04de3243ee5d60adad
Author: Anton Blanchard <anton@samba.org>
Date:   Tue May 26 15:10:24 2015 +1000

    powerpc/perf: Fix book3s kernel to userspace backtraces
    
    commit 72e349f1124a114435e599479c9b8d14bfd1ebcd upstream.
    
    When we take a PMU exception or a software event we call
    perf_read_regs(). This overloads regs->result with a boolean that
    describes if we should use the sampled instruction address register
    (SIAR) or the regs.
    
    If the exception is in kernel, we start with the kernel regs and
    backtrace through the kernel stack. At this point we switch to the
    userspace regs and backtrace the user stack with perf_callchain_user().
    
    Unfortunately these regs have not got the perf_read_regs() treatment,
    so regs->result could be anything. If it is non zero,
    perf_instruction_pointer() decides to use the SIAR, and we get issues
    like this:
    
    0.11%  qemu-system-ppc  [kernel.kallsyms]        [k] _raw_spin_lock_irqsave
           |
           ---_raw_spin_lock_irqsave
              |
              |--52.35%-- 0
              |          |
              |          |--46.39%-- __hrtimer_start_range_ns
              |          |          kvmppc_run_core
              |          |          kvmppc_vcpu_run_hv
              |          |          kvmppc_vcpu_run
              |          |          kvm_arch_vcpu_ioctl_run
              |          |          kvm_vcpu_ioctl
              |          |          do_vfs_ioctl
              |          |          sys_ioctl
              |          |          system_call
              |          |          |
              |          |          |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
              |          |          |          |
              |          |          |           --100.00%-- 0x7e714
              |          |          |                     0x7e714
    
    Notice the bogus _raw_spin_irqsave when we transition from kernel
    (system_call) to userspace (0x7e714). We inserted what was in the SIAR.
    
    Add a check in regs_use_siar() to check that the regs in question
    are from a PMU exception. With this fix the backtrace makes sense:
    
         0.47%  qemu-system-ppc  [kernel.vmlinux]         [k] _raw_spin_lock_irqsave
                |
                ---_raw_spin_lock_irqsave
                   |
                   |--53.83%-- 0
                   |          |
                   |          |--44.73%-- hrtimer_try_to_cancel
                   |          |          kvmppc_start_thread
                   |          |          kvmppc_run_core
                   |          |          kvmppc_vcpu_run_hv
                   |          |          kvmppc_vcpu_run
                   |          |          kvm_arch_vcpu_ioctl_run
                   |          |          kvm_vcpu_ioctl
                   |          |          do_vfs_ioctl
                   |          |          sys_ioctl
                   |          |          system_call
                   |          |          __ioctl
                   |          |          0x7e714
                   |          |          0x7e714
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06efcc8678f2f688680a058ae3ea9aa21925bf9a
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Mon Mar 16 10:59:43 2015 +0000

    arm: KVM: force execution of HCPTR access on VM exit
    
    commit 85e84ba31039595995dae80b277378213602891b upstream.
    
    On VM entry, we disable access to the VFP registers in order to
    perform a lazy save/restore of these registers.
    
    On VM exit, we restore access, test if we did enable them before,
    and save/restore the guest/host registers if necessary. In this
    sequence, the FPEXC register is always accessed, irrespective
    of the trapping configuration.
    
    If the guest didn't touch the VFP registers, then the HCPTR access
    has now enabled such access, but we're missing a barrier to ensure
    architectural execution of the new HCPTR configuration. If the HCPTR
    access has been delayed/reordered, the subsequent access to FPEXC
    will cause a trap, which we aren't prepared to handle at all.
    
    The same condition exists when trapping to enable VFP for the guest.
    
    The fix is to introduce a barrier after enabling VFP access. In the
    vmexit case, it can be relaxed to only takes place if the guest hasn't
    accessed its view of the VFP registers, making the access to FPEXC safe.
    
    The set_hcptr macro is modified to deal with both vmenter/vmexit and
    vmtrap operations, and now takes an optional label that is branched to
    when the guest hasn't touched the VFP registers.
    
    Reported-by: Vikram Sethi <vikrams@codeaurora.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd2db9b79cfa3d4e31ac9df258dcf076b5dbadf0
Author: Horia Geant? <horia.geanta@freescale.com>
Date:   Mon May 11 20:04:49 2015 +0300

    Revert "crypto: talitos - convert to use be16_add_cpu()"
    
    commit 69d9cd8c592f1abce820dbce7181bbbf6812cfbd upstream.
    
    This reverts commit 7291a932c6e27d9768e374e9d648086636daf61c.
    
    The conversion to be16_add_cpu() is incorrect in case cryptlen is
    negative due to premature (i.e. before addition / subtraction)
    implicit conversion of cryptlen (int -> u16) leading to sign loss.
    
    Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54b915793f085622ffa78e3cffd94a5733cc71b9
Author: Horia Geant? <horia.geanta@freescale.com>
Date:   Mon May 11 20:03:24 2015 +0300

    crypto: talitos - avoid memleak in talitos_alg_alloc()
    
    commit 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 upstream.
    
    Fixes: 1d11911a8c57 ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function")
    Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59a460c394a771501ffcd81e68c83fa2ed91e384
Author: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date:   Mon Jun 29 10:41:03 2015 +0200

    sctp: Fix race between OOTB responce and route removal
    
    [ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ]
    
    There is NULL pointer dereference possible during statistics update if the route
    used for OOTB responce is removed at unfortunate time. If the route exists when
    we receive OOTB packet and we finally jump into sctp_packet_transmit() to send
    ABORT, but in the meantime route is removed under our feet, we take "no_route"
    path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...).
    
    But sctp_ootb_pkt_new() used to prepare responce packet doesn't call
    sctp_transport_set_owner() and therefore there is no asoc associated with this
    packet. Probably temporary asoc just for OOTB responces is overkill, so just
    introduce a check like in all other places in sctp_packet_transmit(), where
    "asoc" is dereferenced.
    
    To reproduce this, one needs to
    0. ensure that sctp module is loaded (otherwise ABORT is not generated)
    1. remove default route on the machine
    2. while true; do
         ip route del [interface-specific route]
         ip route add [interface-specific route]
       done
    3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT
       responce
    
    On x86_64 the crash looks like this:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    IP: [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
    PGD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in: ...
    CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.0.5-1-ARCH #1
    Hardware name: ...
    task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000
    RIP: 0010:[<ffffffffa05ec9ac>]  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
    RSP: 0018:ffff880127c037b8  EFLAGS: 00010296
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480
    RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700
    RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af
    R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28
    R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0
    FS:  0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0
    Stack:
     ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400
     ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520
     0000000000000000 0000000000000001 0000000000000000 0000000000000000
    Call Trace:
     <IRQ>
     [<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp]
     [<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp]
     [<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp]
     [<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210
     [<ffffffff810e0329>] ? update_process_times+0x59/0x60
     [<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0
     [<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0
     [<ffffffff8101f599>] ? read_tsc+0x9/0x10
     [<ffffffff8116d4b5>] ? put_page+0x55/0x60
     [<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100
     [<ffffffff81462b68>] ? skb_free_head+0x58/0x80
     [<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic]
     [<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0
     [<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp]
     [<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp]
     [<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp]
     [<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp]
     [<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp]
     [<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30
     [<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150
     [<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210
     [<ffffffff814b2e15>] ip_local_deliver+0x35/0x90
     [<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370
     [<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0
     [<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50
     [<ffffffff81476c28>] __netif_receive_skb+0x18/0x60
     [<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0
     [<ffffffff814776c8>] napi_gro_receive+0xe8/0x120
     [<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169]
     [<ffffffff8147896a>] net_rx_action+0x21a/0x360
     [<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0
     [<ffffffff8107912d>] irq_exit+0xad/0xb0
     [<ffffffff8157d158>] do_IRQ+0x58/0xf0
     [<ffffffff8157b06d>] common_interrupt+0x6d/0x6d
     <EOI>
     [<ffffffff810e1218>] ? hrtimer_start+0x18/0x20
     [<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp]
     [<ffffffff81020c50>] ? mwait_idle+0x60/0xa0
     [<ffffffff810216ef>] arch_cpu_idle+0xf/0x20
     [<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480
     [<ffffffff8156b365>] rest_init+0x85/0x90
     [<ffffffff818eb035>] start_kernel+0x48b/0x4ac
     [<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120
     [<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c
     [<ffffffff818ea49c>] x86_64_start_kernel+0x161/0x184
    Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9
    RIP  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
     RSP <ffff880127c037b8>
    CR2: 0000000000000020
    ---[ end trace 5aec7fd2dc983574 ]---
    Kernel panic - not syncing: Fatal exception in interrupt
    Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
    drm_kms_helper: panic occurred, switching back to text console
    ---[ end Kernel panic - not syncing: Fatal exception in interrupt
    
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4552ddd07a1f2f502243cb8d4609f1e3fad57958
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Jun 17 15:59:34 2015 -0400

    packet: avoid out of bounds read in round robin fanout
    
    [ Upstream commit 468479e6043c84f5a65299cc07cb08a22a28c2b1 ]
    
    PACKET_FANOUT_LB computes f->rr_cur such that it is modulo
    f->num_members. It returns the old value unconditionally, but
    f->num_members may have changed since the last store. Ensure
    that the return value is always < num.
    
    When modifying the logic, simplify it further by replacing the loop
    with an unconditional atomic increment.
    
    Fixes: dc99f600698d ("packet: Add fanout support.")
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.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 7eee92bf2e54235ab90f90d4b97b9256f51b076d
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 16 07:59:11 2015 -0700

    packet: read num_members once in packet_rcv_fanout()
    
    [ Upstream commit f98f4514d07871da7a113dd9e3e330743fd70ae4 ]
    
    We need to tell compiler it must not read f->num_members multiple
    times. Otherwise testing if num is not zero is flaky, and we could
    attempt an invalid divide by 0 in fanout_demux_cpu()
    
    Note bug was present in packet_rcv_fanout_hash() and
    packet_rcv_fanout_lb() but final 3.1 had a simple location
    after commit 95ec3eb417115fb ("packet: Add 'cpu' fanout policy.")
    
    Fixes: dc99f600698dc ("packet: Add fanout support.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 019b1332afd4dc4c80fa83379866d01984933694
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Mon Jun 15 20:28:51 2015 +0300

    bridge: fix br_stp_set_bridge_priority race conditions
    
    [ Upstream commit 2dab80a8b486f02222a69daca6859519e05781d9 ]
    
    After the ->set() spinlocks were removed br_stp_set_bridge_priority
    was left running without any protection when used via sysfs. It can
    race with port add/del and could result in use-after-free cases and
    corrupted lists. Tested by running port add/del in a loop with stp
    enabled while setting priority in a loop, crashes are easily
    reproducible.
    The spinlocks around sysfs ->set() were removed in commit:
    14f98f258f19 ("bridge: range check STP parameters")
    There's also a race condition in the netlink priority support that is
    fixed by this change, but it was introduced recently and the fixes tag
    covers it, just in case it's needed the commit is:
    af615762e972 ("bridge: add ageing_time, stp_state, priority over netlink")
    
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Fixes: 14f98f258f19 ("bridge: range check STP parameters")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80cbc4a31be6abe812cdbd81d4b98e4d7771c7fa
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Jun 9 10:23:57 2015 -0700

    bridge: fix multicast router rlist endless loop
    
    [ Upstream commit 1a040eaca1a22f8da8285ceda6b5e4a2cb704867 ]
    
    Since the addition of sysfs multicast router support if one set
    multicast_router to "2" more than once, then the port would be added to
    the hlist every time and could end up linking to itself and thus causing an
    endless loop for rlist walkers.
    So to reproduce just do:
    echo 2 > multicast_router; echo 2 > multicast_router;
    in a bridge port and let some igmp traffic flow, for me it hangs up
    in br_multicast_flood().
    Fix this by adding a check in br_multicast_add_router() if the port is
    already linked.
    The reason this didn't happen before the addition of multicast_router
    sysfs entries is because there's a !hlist_unhashed check that prevents
    it.
    
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Fixes: 0909e11758bd ("bridge: Add multicast_router sysfs entries")
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc911b31255d65ef7e54e416bfbea810af56cf7a
Author: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date:   Tue Apr 21 10:30:41 2015 -0400

    sparc: Use GFP_ATOMIC in ldc_alloc_exp_dring() as it can be called in softirq context
    
    Upstream commit 671d773297969bebb1732e1cdc1ec03aa53c6be2
    
    Since it is possible for vnet_event_napi to end up doing
    vnet_control_pkt_engine -> ... -> vnet_send_attr ->
    vnet_port_alloc_tx_ring -> ldc_alloc_exp_dring -> kzalloc()
    (i.e., in softirq context), kzalloc() should be called with
    GFP_ATOMIC from ldc_alloc_exp_dring.
    
    Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>