1. 19 4月, 2017 28 次提交
  2. 18 4月, 2017 12 次提交
    • C
      bonding: deliver link-local packets with skb->dev set to link that packets arrived on · b89f04c6
      Chonggang Li 提交于
      Bonding driver changes the skb->dev to the bonding-master before
      passing the packet to stack for further processing. This, however
      does not make sense for the link-local packets and it loses "the
      link info" once its skb->dev is changed to bonding-master.  This
      patch changes this behavior for link-local packets by not changing
      the skb->dev to the bonding-master and maintaining it as it is,
      i.e. the link on which the packet arrived.
      Signed-off-by: NChonggang Li <chonggangli@google.com>
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NMaciej Żenczykowski <maze@google.com>
      Signed-off-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b89f04c6
    • D
      net: rtnetlink: plumb extended ack to doit function · c21ef3e3
      David Ahern 提交于
      Add netlink_ext_ack arg to rtnl_doit_func. Pass extack arg to nlmsg_parse
      for doit functions that call it directly.
      
      This is the first step to using extended error reporting in rtnetlink.
      >From here individual subsystems can be updated to set netlink_ext_ack as
      needed.
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c21ef3e3
    • D
      ipv6: sr: fix BUG due to headroom too small after SRH push · af3b5158
      David Lebrun 提交于
      When a locally generated packet receives an SRH with two or more segments,
      the remaining headroom is too small to push an ethernet header. This patch
      ensures that the headroom is large enough after SRH push.
      
      The BUG generated the following trace.
      
      [  192.950285] skbuff: skb_under_panic: text:ffffffff81809675 len:198 put:14 head:ffff88006f306400 data:ffff88006f3063fa tail:0xc0 end:0x2c0 dev:A-1
      [  192.952456] ------------[ cut here ]------------
      [  192.953218] kernel BUG at net/core/skbuff.c:105!
      [  192.953411] invalid opcode: 0000 [#1] PREEMPT SMP
      [  192.953411] Modules linked in:
      [  192.953411] CPU: 5 PID: 3433 Comm: ping6 Not tainted 4.11.0-rc3+ #237
      [  192.953411] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
      [  192.953411] task: ffff88007c2d42c0 task.stack: ffffc90000ef4000
      [  192.953411] RIP: 0010:skb_panic+0x61/0x70
      [  192.953411] RSP: 0018:ffffc90000ef7900 EFLAGS: 00010286
      [  192.953411] RAX: 0000000000000085 RBX: 00000000000086dd RCX: 0000000000000201
      [  192.953411] RDX: 0000000080000201 RSI: ffffffff81d104c5 RDI: 00000000ffffffff
      [  192.953411] RBP: ffffc90000ef7920 R08: 0000000000000001 R09: 0000000000000000
      [  192.953411] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      [  192.953411] R13: ffff88007c5a4000 R14: ffff88007b363d80 R15: 00000000000000b8
      [  192.953411] FS:  00007f94b558b700(0000) GS:ffff88007fd40000(0000) knlGS:0000000000000000
      [  192.953411] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  192.953411] CR2: 00007fff5ecd5080 CR3: 0000000074141000 CR4: 00000000001406e0
      [  192.953411] Call Trace:
      [  192.953411]  skb_push+0x3b/0x40
      [  192.953411]  eth_header+0x25/0xc0
      [  192.953411]  neigh_resolve_output+0x168/0x230
      [  192.953411]  ? ip6_finish_output2+0x242/0x8f0
      [  192.953411]  ip6_finish_output2+0x242/0x8f0
      [  192.953411]  ? ip6_finish_output2+0x76/0x8f0
      [  192.953411]  ip6_finish_output+0xa8/0x1d0
      [  192.953411]  ip6_output+0x64/0x2d0
      [  192.953411]  ? ip6_output+0x73/0x2d0
      [  192.953411]  ? ip6_dst_check+0xb5/0xc0
      [  192.953411]  ? dst_cache_per_cpu_get.isra.2+0x40/0x80
      [  192.953411]  seg6_output+0xb0/0x220
      [  192.953411]  lwtunnel_output+0xcf/0x210
      [  192.953411]  ? lwtunnel_output+0x59/0x210
      [  192.953411]  ip6_local_out+0x38/0x70
      [  192.953411]  ip6_send_skb+0x2a/0xb0
      [  192.953411]  ip6_push_pending_frames+0x48/0x50
      [  192.953411]  rawv6_sendmsg+0xa39/0xf10
      [  192.953411]  ? __lock_acquire+0x489/0x890
      [  192.953411]  ? __mutex_lock+0x1fc/0x970
      [  192.953411]  ? __lock_acquire+0x489/0x890
      [  192.953411]  ? __mutex_lock+0x1fc/0x970
      [  192.953411]  ? tty_ioctl+0x283/0xec0
      [  192.953411]  inet_sendmsg+0x45/0x1d0
      [  192.953411]  ? _copy_from_user+0x54/0x80
      [  192.953411]  sock_sendmsg+0x33/0x40
      [  192.953411]  SYSC_sendto+0xef/0x170
      [  192.953411]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
      [  192.953411]  ? trace_hardirqs_on_caller+0x12b/0x1b0
      [  192.953411]  ? trace_hardirqs_on_thunk+0x1a/0x1c
      [  192.953411]  SyS_sendto+0x9/0x10
      [  192.953411]  entry_SYSCALL_64_fastpath+0x1f/0xc2
      [  192.953411] RIP: 0033:0x7f94b453db33
      [  192.953411] RSP: 002b:00007fff5ecd0578 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [  192.953411] RAX: ffffffffffffffda RBX: 00007fff5ecd16e0 RCX: 00007f94b453db33
      [  192.953411] RDX: 0000000000000040 RSI: 000055a78352e9c0 RDI: 0000000000000003
      [  192.953411] RBP: 00007fff5ecd1690 R08: 000055a78352c940 R09: 000000000000001c
      [  192.953411] R10: 0000000000000000 R11: 0000000000000246 R12: 000055a783321e10
      [  192.953411] R13: 000055a7839890c0 R14: 0000000000000004 R15: 0000000000000000
      [  192.953411] Code: 00 00 48 89 44 24 10 8b 87 c4 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 90 58 d2 81 48 89 04 24 31 c0 e8 4f 70 9a ff <0f> 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 97 d8 00 00
      [  192.953411] RIP: skb_panic+0x61/0x70 RSP: ffffc90000ef7900
      [  193.000186] ---[ end trace bd0b89fabdf2f92c ]---
      [  193.000951] Kernel panic - not syncing: Fatal exception in interrupt
      [  193.001137] Kernel Offset: disabled
      [  193.001169] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      
      Fixes: 19d5a26f ("ipv6: sr: expand skb head only if necessary")
      Signed-off-by: NDavid Lebrun <david.lebrun@uclouvain.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af3b5158
    • I
      gso: Validate assumption of frag_list segementation · 7a7a9bd7
      Ilan Tayari 提交于
      Commit 07b26c94 ("gso: Support partial splitting at the frag_list
      pointer") assumes that all SKBs in a frag_list (except maybe the last
      one) contain the same amount of GSO payload.
      
      This assumption is not always correct, resulting in the following
      warning message in the log:
          skb_segment: too many frags
      
      For example, mlx5 driver in Striding RQ mode creates some RX SKBs with
      one frag, and some with 2 frags.
      After GRO, the frag_list SKBs end up having different amounts of payload.
      If this frag_list SKB is then forwarded, the aforementioned assumption
      is violated.
      
      Validate the assumption, and fall back to software GSO if it not true.
      
      Fixes: 07b26c94 ("gso: Support partial splitting at the frag_list pointer")
      Signed-off-by: NIlan Tayari <ilant@mellanox.com>
      Signed-off-by: NIlya Lesokhin <ilyal@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a7a9bd7
    • X
      sctp: get list_of_streams of strreset outreq earlier · edb12f2d
      Xin Long 提交于
      Now when processing strreset out responses, it gets outreq->list_of_streams
      only when result is performed. But if result is not performed, str_p will
      be NULL. It will cause panic in sctp_ulpevent_make_stream_reset_event if
      nums is not 0.
      
      This patch is to fix it by getting outreq->list_of_streams earlier, and
      also to improve some codes for the strreset inreq process.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      edb12f2d
    • C
      Add uid and cookie bpf helper to cg_skb_func_proto · 9fd0f315
      Chenbo Feng 提交于
      BPF helper functions get_socket_cookie and get_socket_uid can be
      used for network traffic classifications, among others. Expose
      them also to programs of type BPF_PROG_TYPE_CGROUP_SKB. As of
      commit 8f917bba ("bpf: pass sk to helper functions") the
      required skb->sk function is available at both cgroup bpf ingress
      and egress hooks. With these two new helper, cg_skb_func_proto is
      effectively the same as sk_filter_func_proto.
      
      Change since V1:
      Instead of add the helper to cg_skb_func_proto, redirect the
      cg_skb_func_proto to sk_filter_func_proto since all helper function
      in sk_filter_func_proto are applicable to cg_skb_func_proto now.
      Signed-off-by: NChenbo Feng <fengc@google.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fd0f315
    • S
      hv_netvsc: change netvsc device default duplex to FULL · f3c9d40e
      Simon Xiao 提交于
      The netvsc device supports full duplex by default.
      This warnings in log from bonding device which did not like
      seeing UNKNOWN duplex.
      Signed-off-by: NSimon Xiao <sixiao@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3c9d40e
    • S
      netvsc: fix RCU warning in get_stats · 776e726b
      stephen hemminger 提交于
      The statistics functionis called with RTNL held during probe
      but with RCU held during access from /proc and elsewhere.
      This is safe so update the lockdep annotation.
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      776e726b
    • D
      net: phy: test the right variable in phy_write_mmd() · 1dbba4cb
      Dan Carpenter 提交于
      This is a copy and paste buglet.  We meant to test for ->write_mmd but
      we test for ->read_mmd.
      
      Fixes: 1ee6b9bc ("net: phy: make phy_(read|write)_mmd() generic MMD accessors")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1dbba4cb
    • D
      Merge branch 'for-upstream' of... · 450cc8cc
      David S. Miller 提交于
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2017-04-14
      
      Here's the main batch of Bluetooth & 802.15.4 patches for the 4.12
      kernel.
      
       - Many fixes to 6LoWPAN, in particular for BLE
       - New CA8210 IEEE 802.15.4 device driver (accounting for most of the
         lines of code added in this pull request)
       - Added Nokia Bluetooth (UART) HCI driver
       - Some serdev & TTY changes that are dependencies for the Nokia
         driver (with acks from relevant maintainers and an agreement that
         these come through the bluetooth tree)
       - Support for new Intel Bluetooth device
       - Various other minor cleanups/fixes here and there
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      450cc8cc
    • D
      Merge branch 'bpf-lru-perf' · d584fec6
      David S. Miller 提交于
      Martin KaFai Lau says:
      
      ====================
      bpf: LRU performance and test-program improvements
      
      The first 4 patches make a few improvements to the LRU tests.
      
      Patch 5/6 is to improve the performance of BPF_F_NO_COMMON_LRU map.
      
      Patch 6/6 adds an example in using LRU map with map-in-map.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d584fec6
    • M
      bpf: lru: Add map-in-map LRU example · 3a5795b8
      Martin KaFai Lau 提交于
      This patch adds a map-in-map LRU example.
      If we know only a subset of cores will use the
      LRU, we can allocate a common LRU list per targeting core
      and store it into an array-of-hashs.
      
      It allows using the common LRU map with map-update performance
      comparable to the BPF_F_NO_COMMON_LRU map but without wasting memory
      on the unused cores that we know they will never access the LRU map.
      
      BPF_F_NO_COMMON_LRU:
      > map_perf_test 32 8 10000000 10000000 | awk '{sum += $3}END{print sum}'
      9234314 (9.23M/s)
      
      map-in-map LRU:
      > map_perf_test 512 8 1260000 80000000 | awk '{sum += $3}END{print sum}'
      9962743 (9.96M/s)
      
      Notes that the max_entries for the map-in-map LRU test is 1260000 which
      is the max_entries for each inner LRU map.  8 processes have been
      started, so 8 * 1260000 = 10080000 (~10M) which is close to what is
      used in the BPF_F_NO_COMMON_LRU test.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a5795b8