1. 15 Dec, 2015 5 commits
  2. 23 Nov, 2015 1 commit
  3. 20 Nov, 2015 1 commit
  4. 10 Nov, 2015 2 commits
  5. 05 Nov, 2015 5 commits
  6. 04 Nov, 2015 2 commits
  7. 03 Nov, 2015 5 commits
  8. 27 Oct, 2015 19 commits
    • moonman's avatar
    • Greg Kroah-Hartman's avatar
      Linux 3.10.92 · d17332eb
      Greg Kroah-Hartman authored
      d17332eb
    • Ilya Dryomov's avatar
      rbd: fix double free on rbd_dev->header_name · f2271406
      Ilya Dryomov authored
      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: 's avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: 's avatarAlex Elder <elder@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2271406
    • Mike Snitzer's avatar
      dm thin: fix missing pool reference count decrement in pool_ctr error path · ad824a82
      Mike Snitzer authored
      commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd upstream.
      
      Fixes: ac8c3f3d ("dm thin: generate event when metadata threshold passed")
      Signed-off-by: 's avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad824a82
    • Shaohua Li's avatar
      workqueue: make sure delayed work run in local cpu · 334c9407
      Shaohua Li authored
      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: 's avatarShaohua Li <shli@fb.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      334c9407
    • Wolfram Sang's avatar
      i2c: rcar: enable RuntimePM before registering to the core · 49d851ce
      Wolfram Sang authored
      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: 's avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: 's avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: 's avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49d851ce
    • Russell King's avatar
      crypto: ahash - ensure statesize is non-zero · 2aafe811
      Russell King authored
      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: 's avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2aafe811
    • Dave Kleikamp's avatar
      crypto: sparc - initialize blkcipher.ivsize · 29e5b424
      Dave Kleikamp authored
      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: 's avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29e5b424
    • Geert Uytterhoeven's avatar
      m68k/uaccess: Fix asm constraints for userspace access · 31e29b7b
      Geert Uytterhoeven authored
      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: 's avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31e29b7b
    • Charles Keepax's avatar
      asix: Do full reset during ax88772_bind · 37673fd3
      Charles Keepax authored
      [ 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: 's avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Tested-by: 's avatarRiku Voipio <riku.voipio@linaro.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37673fd3
    • Michel Stam's avatar
      asix: Don't reset PHY on if_up for ASIX 88772 · d54ee99a
      Michel Stam authored
      [ 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: 's avatarMichel Stam <m.stam@fugro.nl>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d54ee99a
    • Joe Perches's avatar
      ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings · c4fc18cc
      Joe Perches authored
      [ 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: 's avatarJoe Perches <joe@perches.com>
      Acked-by: 's avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4fc18cc
    • Guillaume Nault's avatar
      ppp: don't override sk->sk_state in pppoe_flush_dev() · 9db7ed14
      Guillaume Nault authored
      [ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ]
      
      Since commit 2b018d57 ("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: 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
      Tested-by: 's avatarOleksii Berezhniak <core@irc.lg.ua>
      Signed-off-by: 's avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9db7ed14
    • Eric Dumazet's avatar
      net: add pfmemalloc check in sk_add_backlog() · dec23a55
      Eric Dumazet authored
      [ 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: b4b9e355 ("netvm: set PF_MEMALLOC as appropriate during SKB processing")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarGreg Thelen <gthelen@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dec23a55
    • Pravin B Shelar's avatar
      skbuff: Fix skb checksum partial check. · f03a8061
      Pravin B Shelar authored
      [ 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: 's avatarAndrew Vagin <avagin@odin.com>
      Signed-off-by: 's avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f03a8061
    • Pravin B Shelar's avatar
      skbuff: Fix skb checksum flag on skb pull · 275ceb01
      Pravin B Shelar authored
      [ 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: 's avatarAnupam Chanda <achanda@vmware.com>
      Signed-off-by: 's avatarPravin B Shelar <pshelar@nicira.com>
      Acked-by: 's avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      275ceb01
    • Aaron Conole's avatar
      af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag · 1f21dc67
      Aaron Conole authored
      [ 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: 's avatarAaron Conole <aconole@bytheb.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f21dc67
    • Aaron Conole's avatar
      af_unix: Convert the unix_sk macro to an inline function for type safety · f9b8d11b
      Aaron Conole authored
      [ 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: 's avatarAaron Conole <aconole@bytheb.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9b8d11b
    • Alexander Couzens's avatar
      l2tp: protect tunnel->del_work by ref_count · 9bbb3d0d
      Alexander Couzens authored
      [ 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: 's avatarAlexander Couzens <lynxis@fe80.eu>
      Acked-by: 's avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9bbb3d0d