commit d17332ebfb5f2010ae5d3332a52df361f28ae4a8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 27 09:45:05 2015 +0900

    Linux 3.10.92

commit f22714069f1bc94b91b463bdc00cc82782f0e363
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Aug 31 15:21:39 2015 +0300

    rbd: fix double free on rbd_dev->header_name
    
    commit 3ebe138ac642a195c7f2efdb918f464734421fd6 upstream.
    
    If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name
    is freed twice: once in rbd_dev_probe_parent() and then in its caller
    rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to
    handle parent images).
    
    rbd_dev_probe_parent() is responsible for probing the parent, so it
    shouldn't muck with clone's fields.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad824a8286dd4db9c23e3e3febdd63d4c2c4ae9e
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Tue Oct 13 12:04:28 2015 -0400

    dm thin: fix missing pool reference count decrement in pool_ctr error path
    
    commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd upstream.
    
    Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed")
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 334c94072f03ff42ea823e81351f9baa933b4739
Author: Shaohua Li <shli@fb.com>
Date:   Wed Sep 30 09:05:30 2015 -0700

    workqueue: make sure delayed work run in local cpu
    
    commit 874bbfe600a660cba9c776b3957b1ce393151b76 upstream.
    
    My system keeps crashing with below message. vmstat_update() schedules a delayed
    work in current cpu and expects the work runs in the cpu.
    schedule_delayed_work() is expected to make delayed work run in local cpu. The
    problem is timer can be migrated with NO_HZ. __queue_work() queues work in
    timer handler, which could run in a different cpu other than where the delayed
    work is scheduled. The end result is the delayed work runs in different cpu.
    The patch makes __queue_delayed_work records local cpu earlier. Where the timer
    runs doesn't change where the work runs with the change.
    
    [   28.010131] ------------[ cut here ]------------
    [   28.010609] kernel BUG at ../mm/vmstat.c:1392!
    [   28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
    [   28.011860] Modules linked in:
    [   28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G        W4.3.0-rc3+ #634
    [   28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
    [   28.014160] Workqueue: events vmstat_update
    [   28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000
    [   28.015445] RIP: 0010:[<ffffffff8115f921>]  [<ffffffff8115f921>]vmstat_update+0x31/0x80
    [   28.016282] RSP: 0018:ffff8800ba42fd80  EFLAGS: 00010297
    [   28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000
    [   28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d
    [   28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000
    [   28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640
    [   28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000
    [   28.020071] FS:  0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000
    [   28.020071] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [   28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0
    [   28.020071] Stack:
    [   28.020071]  ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88
    [   28.020071]  ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8
    [   28.020071]  ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340
    [   28.020071] Call Trace:
    [   28.020071]  [<ffffffff8106bd88>] process_one_work+0x1c8/0x540
    [   28.020071]  [<ffffffff8106bd0b>] ? process_one_work+0x14b/0x540
    [   28.020071]  [<ffffffff8106c214>] worker_thread+0x114/0x460
    [   28.020071]  [<ffffffff8106c100>] ? process_one_work+0x540/0x540
    [   28.020071]  [<ffffffff81071bf8>] kthread+0xf8/0x110
    [   28.020071]  [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
    [   28.020071]  [<ffffffff81a6522f>] ret_from_fork+0x3f/0x70
    [   28.020071]  [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
    
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49d851cea0996812449cbe2ceb886cbbf413085a
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Fri Oct 9 10:39:25 2015 +0100

    i2c: rcar: enable RuntimePM before registering to the core
    
    commit 4f7effddf4549d57114289f273710f077c4c330a upstream.
    
    The core may register clients attached to this master which may use
    funtionality from the master. So, RuntimePM must be enabled before, otherwise
    this will fail. While here, move drvdata, too.
    
    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2aafe811b0d734f1dc743ce23bc9bec94dec26cb
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Oct 9 20:43:33 2015 +0100

    crypto: ahash - ensure statesize is non-zero
    
    commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a upstream.
    
    Unlike shash algorithms, ahash drivers must implement export
    and import as their descriptors may contain hardware state and
    cannot be exported as is.  Unfortunately some ahash drivers did
    not provide them and end up causing crashes with algif_hash.
    
    This patch adds a check to prevent these drivers from registering
    ahash algorithms until they are fixed.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29e5b4243743e13be5196622fd0267657dc2ccf5
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Mon Oct 5 10:08:51 2015 -0500

    crypto: sparc - initialize blkcipher.ivsize
    
    commit a66d7f724a96d6fd279bfbd2ee488def6b081bea upstream.
    
    Some of the crypto algorithms write to the initialization vector,
    but no space has been allocated for it. This clobbers adjacent memory.
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31e29b7bfcbece0d538cb4feec0e57b02b729ab2
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sun Jun 9 20:12:42 2013 +0200

    m68k/uaccess: Fix asm constraints for userspace access
    
    commit 631d8b674f5f8235e9cb7e628b0fe9e5200e3158 upstream.
    
    When compiling a MMU kernel with CPU_HAS_ADDRESS_SPACES=n (e.g. "MMU=y
    allnoconfig": "echo CONFIG_MMU=y > allno.config && make KCONFIG_ALLCONFIG=1
    allnoconfig"), we use plain "move" instead of "moves", and I got:
    
      CC      arch/m68k/lib/uaccess.o
    {standard input}: Assembler messages:
    {standard input}:47: Error: operands mismatch -- statement `move.b %a0,(%a1)' ignored
    
    This happens because plain "move" doesn't support byte transfers between
    memory and address registers, while "moves" does.
    
    Fix the asm constraints for __generic_copy_from_user(),
    __generic_copy_to_user(), and __clear_user() to only use data registers
    when accessing userspace.
    
    Also, relax the asm constraints for 16-bit userspace accesses in
    __put_user() and __get_user(), as both "move" and "moves" do support
    such transfers between memory and address registers.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37673fd3fbdf5a72cc2c3b054daf64d0a8e721b8
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Thu Nov 6 15:49:41 2014 +0000

    asix: Do full reset during ax88772_bind
    
    [ Upstream commit 436c2a5036b6ffe813310df2cf327d3b69be0734 ]
    
    commit 3cc81d85ee01 ("asix: Don't reset PHY on if_up for ASIX 88772")
    causes the ethernet on Arndale to no longer function. This appears to
    be because the Arndale ethernet requires a full reset before it will
    function correctly, however simply reverting the above patch causes
    problems with ethtool settings getting reset.
    
    It seems the problem is that the ethernet is not properly reset during
    bind, and indeed the code in ax88772_bind that resets the device is a
    very small subset of the actual ax88772_reset function. This patch uses
    ax88772_reset in place of the existing reset code in ax88772_bind which
    removes some code duplication and fixes the ethernet on Arndale.
    
    It is still possible that the original patch causes some issues with
    suspend and resume but that seems like a separate issue and I haven't
    had a chance to test that yet.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Tested-by: Riku Voipio <riku.voipio@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d54ee99a9dc2d78c7ab89f62a8316b6cf50795f5
Author: Michel Stam <m.stam@fugro.nl>
Date:   Thu Oct 2 10:22:02 2014 +0200

    asix: Don't reset PHY on if_up for ASIX 88772
    
    [ Upstream commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31 ]
    
    I've noticed every time the interface is set to 'up,', the kernel
    reports that the link speed is set to 100 Mbps/Full Duplex, even
    when ethtool is used to set autonegotiation to 'off', half
    duplex, 10 Mbps.
    It can be tested by:
     ifconfig eth0 down
     ethtool -s eth0 autoneg off speed 10 duplex half
     ifconfig eth0 up
    
    Then checking 'dmesg' for the link speed.
    
    Signed-off-by: Michel Stam <m.stam@fugro.nl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4fc18ccc48aaf9779633b0074036ba3c42f341c
Author: Joe Perches <joe@perches.com>
Date:   Wed Oct 14 01:09:40 2015 -0700

    ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings
    
    [ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ]
    
    It seems that kernel memory can leak into userspace by a
    kmalloc, ethtool_get_strings, then copy_to_user sequence.
    
    Avoid this by using kcalloc to zero fill the copied buffer.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Acked-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9db7ed146a62e3c66a8a7263fdf4adb5c48d16ca
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Sep 30 11:45:33 2015 +0200

    ppp: don't override sk->sk_state in pppoe_flush_dev()
    
    [ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ]
    
    Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
    pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
    PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
    PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
    following oops:
    
    [  570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
    [  570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
    [  570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
    [  570.144601] Oops: 0000 [#1] SMP
    [  570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
    [  570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
    [  570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
    [  570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
    [  570.144601] RIP: 0010:[<ffffffffa018c701>]  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
    [  570.144601] RSP: 0018:ffff880036b63e08  EFLAGS: 00010202
    [  570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
    [  570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
    [  570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
    [  570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
    [  570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
    [  570.144601] FS:  00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
    [  570.144601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
    [  570.144601] Stack:
    [  570.144601]  ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
    [  570.144601]  ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
    [  570.144601]  ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
    [  570.144601] Call Trace:
    [  570.144601]  [<ffffffff812caabe>] sock_release+0x1a/0x75
    [  570.144601]  [<ffffffff812cabad>] sock_close+0xd/0x11
    [  570.144601]  [<ffffffff811347f5>] __fput+0xff/0x1a5
    [  570.144601]  [<ffffffff811348cb>] ____fput+0x9/0xb
    [  570.144601]  [<ffffffff81056682>] task_work_run+0x66/0x90
    [  570.144601]  [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
    [  570.144601]  [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
    [  570.144601]  [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
    [  570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
    [  570.144601] RIP  [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
    [  570.144601]  RSP <ffff880036b63e08>
    [  570.144601] CR2: 00000000000004e0
    [  570.200518] ---[ end trace 46956baf17349563 ]---
    
    pppoe_flush_dev() has no reason to override sk->sk_state with
    PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
    PPPOX_DEAD, which is the correct state given that sk is unbound and
    po->pppoe_dev is NULL.
    
    Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
    Tested-by: Oleksii Berezhniak <core@irc.lg.ua>
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dec23a559fd24701c59f322b669bae73820b257d
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 29 18:52:25 2015 -0700

    net: add pfmemalloc check in sk_add_backlog()
    
    [ Upstream commit c7c49b8fde26b74277188bdc6c9dca38db6fa35b ]
    
    Greg reported crashes hitting the following check in __sk_backlog_rcv()
    
    	BUG_ON(!sock_flag(sk, SOCK_MEMALLOC));
    
    The pfmemalloc bit is currently checked in sk_filter().
    
    This works correctly for TCP, because sk_filter() is ran in
    tcp_v[46]_rcv() before hitting the prequeue or backlog checks.
    
    For UDP or other protocols, this does not work, because the sk_filter()
    is ran from sock_queue_rcv_skb(), which might be called _after_ backlog
    queuing if socket is owned by user by the time packet is processed by
    softirq handler.
    
    Fixes: b4b9e35585089 ("netvm: set PF_MEMALLOC as appropriate during SKB processing")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Greg Thelen <gthelen@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f03a8061b5c46dbc6fac58d7933de35ef91841f0
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Mon Sep 28 17:24:25 2015 -0700

    skbuff: Fix skb checksum partial check.
    
    [ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ]
    
    Earlier patch 6ae459bda tried to detect void ckecksum partial
    skb by comparing pull length to checksum offset. But it does
    not work for all cases since checksum-offset depends on
    updates to skb->data.
    
    Following patch fixes it by validating checksum start offset
    after skb-data pointer is updated. Negative value of checksum
    offset start means there is no need to checksum.
    
    Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull")
    Reported-by: Andrew Vagin <avagin@odin.com>
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 275ceb01d2bbf8013c907087e9fea084fd3c55c9
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Tue Sep 22 12:57:53 2015 -0700

    skbuff: Fix skb checksum flag on skb pull
    
    [ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ]
    
    VXLAN device can receive skb with checksum partial. But the checksum
    offset could be in outer header which is pulled on receive. This results
    in negative checksum offset for the skb. Such skb can cause the assert
    failure in skb_checksum_help(). Following patch fixes the bug by setting
    checksum-none while pulling outer header.
    
    Following is the kernel panic msg from old kernel hitting the bug.
    
    ------------[ cut here ]------------
    kernel BUG at net/core/dev.c:1906!
    RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
    Call Trace:
    <IRQ>
    [<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
    [<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
    [<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
    [<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
    [<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
    [<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
    [<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
    [<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
    [<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
    [<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
    [<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
    [<ffffffff81550128>] ip_local_deliver+0x88/0x90
    [<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
    [<ffffffff81550365>] ip_rcv+0x235/0x300
    [<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
    [<ffffffff8151c360>] netif_receive_skb+0x80/0x90
    [<ffffffff81459935>] virtnet_poll+0x555/0x6f0
    [<ffffffff8151cd04>] net_rx_action+0x134/0x290
    [<ffffffff810683d8>] __do_softirq+0xa8/0x210
    [<ffffffff8162fe6c>] call_softirq+0x1c/0x30
    [<ffffffff810161a5>] do_softirq+0x65/0xa0
    [<ffffffff810687be>] irq_exit+0x8e/0xb0
    [<ffffffff81630733>] do_IRQ+0x63/0xe0
    [<ffffffff81625f2e>] common_interrupt+0x6e/0x6e
    
    Reported-by: Anupam Chanda <achanda@vmware.com>
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Acked-by: Tom Herbert <tom@herbertland.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f21dc672d811af15694c6e9c68d275691f91343
Author: Aaron Conole <aconole@bytheb.org>
Date:   Sat Sep 26 18:50:43 2015 -0400

    af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag
    
    [ Upstream commit 9f389e35674f5b086edd70ed524ca0f287259725 ]
    
    AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag
    is set.
    
    This is referenced in kernel bugzilla #12323 @
    https://bugzilla.kernel.org/show_bug.cgi?id=12323
    
    As described both in the BZ and lkml thread @
    http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an
    AF_UNIX socket only reads a single skb, where the desired effect is
    to return as much skb data has been queued, until hitting the recv
    buffer size (whichever comes first).
    
    The modified MSG_PEEK path will now move to the next skb in the tree
    and jump to the again: label, rather than following the natural loop
    structure. This requires duplicating some of the loop head actions.
    
    This was tested using the python socketpair python code attached to
    the bugzilla issue.
    
    Signed-off-by: Aaron Conole <aconole@bytheb.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9b8d11b312f8caaa9dfcf15fc7ab60d9167a6d0
Author: Aaron Conole <aconole@bytheb.org>
Date:   Sat Sep 26 18:50:42 2015 -0400

    af_unix: Convert the unix_sk macro to an inline function for type safety
    
    [ Upstream commit 4613012db1d911f80897f9446a49de817b2c4c47 ]
    
    As suggested by Eric Dumazet this change replaces the
    #define with a static inline function to enjoy
    complaints by the compiler when misusing the API.
    
    Signed-off-by: Aaron Conole <aconole@bytheb.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bbb3d0d1d76d867a8425756e22b1af6d9654a1c
Author: Alexander Couzens <lynxis@fe80.eu>
Date:   Mon Sep 28 11:32:42 2015 +0200

    l2tp: protect tunnel->del_work by ref_count
    
    [ Upstream commit 06a15f51cf3618e32a73871ee6a547ef7fd902b5 ]
    
    There is a small chance that tunnel_free() is called before tunnel->del_work scheduled
    resulting in a zero pointer dereference.
    
    Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
    Acked-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>