1. 09 11月, 2019 25 次提交
  2. 08 11月, 2019 15 次提交
    • G
      cfg80211: VLAN offload support for set_key and set_sta_vlan · 14f34e36
      Gurumoorthi Gnanasambandhan 提交于
      This provides an alternative mechanism for AP VLAN support where a
      single netdev is used with VLAN tagged frames instead of separate
      netdevs for each VLAN without tagged frames from the WLAN driver.
      
      By setting NL80211_EXT_FEATURE_VLAN_OFFLOAD flag the driver indicates
      support for a single netdev with VLAN tagged frames. Separate
      VLAN-specific netdevs can be added using RTM_NEWLINK/IFLA_VLAN_ID
      similarly to Ethernet. NL80211_CMD_NEW_KEY (for group keys),
      NL80211_CMD_NEW_STATION, and NL80211_CMD_SET_STATION will optionally
      specify vlan_id using NL80211_ATTR_VLAN_ID.
      Signed-off-by: NGurumoorthi Gnanasambandhan <gguru@codeaurora.org>
      Signed-off-by: NJouni Malinen <jouni@codeaurora.org>
      Link: https://lore.kernel.org/r/20191031214640.5012-1-jouni@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      14f34e36
    • T
      mac80211: Shrink the size of ack_frame_id to make room for tx_time_est · 6912daed
      Toke Høiland-Jørgensen 提交于
      To implement airtime queue limiting, we need to keep a running account of
      the estimated airtime of all skbs queued into the device. Do to this
      correctly, we need to store the airtime estimate into the skb so we can
      decrease the outstanding balance when the skb is freed. This means that the
      time estimate must be stored somewhere that will survive for the lifetime
      of the skb.
      
      To get this, decrease the size of the ack_frame_id field to 6 bits, and
      lower the size of the ID space accordingly. This leaves 10 bits for use for
      tx_time_est, which is enough to store a maximum of 4096 us, if we shift the
      values so they become units of 4us.
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Link: https://lore.kernel.org/r/157182474063.150713.16132669599100802716.stgit@toke.dkSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      6912daed
    • J
      mac80211: don't re-parse elems in ieee80211_assoc_success() · f61d7884
      Johannes Berg 提交于
      We've already parsed the same data in the caller, so we can
      pass it. The only thing is that we might fill in more details
      in ieee80211_assoc_success(), but that doesn't bother the
      caller, so it's fine to do even when we share the parsed data.
      
      This reduces the stack space usage of the call stack here,
      Arnd reported it had grown above the 1024 byte warning limit.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Link: https://lore.kernel.org/r/20191028125240.cb7661671bd2.I757c8752bf4f2f35e54f5e0a2c0a9cd9216c3d8b@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      f61d7884
    • J
      mac80211: move store skb ack code to its own function · 5d8983c8
      John Crispin 提交于
      This patch moves the code handling SKBTX_WIFI_STATUS inside the TX path
      into an extra function. This allows us to reuse it inside the 802.11 encap
      offloading datapath.
      Signed-off-by: NJohn Crispin <john@phrozen.org>
      Link: https://lore.kernel.org/r/20191029091304.7330-2-john@phrozen.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      5d8983c8
    • Z
      mac80211_hwsim: use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs fops · 7d13cf1e
      zhong jiang 提交于
      It is more clear to use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs file
      operation rather than DEFINE_SIMPLE_ATTRIBUTE.
      
      It is detected with the help of coccinelle.
      Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
      Link: https://lore.kernel.org/r/1572404462-45462-1-git-send-email-zhongjiang@huawei.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      7d13cf1e
    • H
      tipc: eliminate checking netns if node established · d408bef4
      Hoang Le 提交于
      Currently, we scan over all network namespaces at each received
      discovery message in order to check if the sending peer might be
      present in a host local namespaces.
      
      This is unnecessary since we can assume that a peer will not change its
      location during an established session.
      
      We now improve the condition for this testing so that we don't perform
      any redundant scans.
      
      Fixes: f73b1281 ("tipc: improve throughput between nodes in netns")
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NHoang Le <hoang.h.le@dektech.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d408bef4
    • E
      net: add a READ_ONCE() in skb_peek_tail() · f8cc62ca
      Eric Dumazet 提交于
      skb_peek_tail() can be used without protection of a lock,
      as spotted by KCSAN [1]
      
      In order to avoid load-stearing, add a READ_ONCE()
      
      Note that the corresponding WRITE_ONCE() are already there.
      
      [1]
      BUG: KCSAN: data-race in sk_wait_data / skb_queue_tail
      
      read to 0xffff8880b36a4118 of 8 bytes by task 20426 on cpu 1:
       skb_peek_tail include/linux/skbuff.h:1784 [inline]
       sk_wait_data+0x15b/0x250 net/core/sock.c:2477
       kcm_wait_data+0x112/0x1f0 net/kcm/kcmsock.c:1103
       kcm_recvmsg+0xac/0x320 net/kcm/kcmsock.c:1130
       sock_recvmsg_nosec net/socket.c:871 [inline]
       sock_recvmsg net/socket.c:889 [inline]
       sock_recvmsg+0x92/0xb0 net/socket.c:885
       ___sys_recvmsg+0x1a0/0x3e0 net/socket.c:2480
       do_recvmmsg+0x19a/0x5c0 net/socket.c:2601
       __sys_recvmmsg+0x1ef/0x200 net/socket.c:2680
       __do_sys_recvmmsg net/socket.c:2703 [inline]
       __se_sys_recvmmsg net/socket.c:2696 [inline]
       __x64_sys_recvmmsg+0x89/0xb0 net/socket.c:2696
       do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      write to 0xffff8880b36a4118 of 8 bytes by task 451 on cpu 0:
       __skb_insert include/linux/skbuff.h:1852 [inline]
       __skb_queue_before include/linux/skbuff.h:1958 [inline]
       __skb_queue_tail include/linux/skbuff.h:1991 [inline]
       skb_queue_tail+0x7e/0xc0 net/core/skbuff.c:3145
       kcm_queue_rcv_skb+0x202/0x310 net/kcm/kcmsock.c:206
       kcm_rcv_strparser+0x74/0x4b0 net/kcm/kcmsock.c:370
       __strp_recv+0x348/0xf50 net/strparser/strparser.c:309
       strp_recv+0x84/0xa0 net/strparser/strparser.c:343
       tcp_read_sock+0x174/0x5c0 net/ipv4/tcp.c:1639
       strp_read_sock+0xd4/0x140 net/strparser/strparser.c:366
       do_strp_work net/strparser/strparser.c:414 [inline]
       strp_work+0x9a/0xe0 net/strparser/strparser.c:423
       process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
       worker_thread+0xa0/0x800 kernel/workqueue.c:2415
       kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 451 Comm: kworker/u4:3 Not tainted 5.4.0-rc3+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: kstrp strp_work
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8cc62ca
    • E
      net: add annotations on hh->hh_len lockless accesses · c305c6ae
      Eric Dumazet 提交于
      KCSAN reported a data-race [1]
      
      While we can use READ_ONCE() on the read sides,
      we need to make sure hh->hh_len is written last.
      
      [1]
      
      BUG: KCSAN: data-race in eth_header_cache / neigh_resolve_output
      
      write to 0xffff8880b9dedcb8 of 4 bytes by task 29760 on cpu 0:
       eth_header_cache+0xa9/0xd0 net/ethernet/eth.c:247
       neigh_hh_init net/core/neighbour.c:1463 [inline]
       neigh_resolve_output net/core/neighbour.c:1480 [inline]
       neigh_resolve_output+0x415/0x470 net/core/neighbour.c:1470
       neigh_output include/net/neighbour.h:511 [inline]
       ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
       __ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
       __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
       ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
       NF_HOOK_COND include/linux/netfilter.h:294 [inline]
       ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
       dst_output include/net/dst.h:436 [inline]
       NF_HOOK include/linux/netfilter.h:305 [inline]
       ndisc_send_skb+0x459/0x5f0 net/ipv6/ndisc.c:505
       ndisc_send_ns+0x207/0x430 net/ipv6/ndisc.c:647
       rt6_probe_deferred+0x98/0xf0 net/ipv6/route.c:615
       process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
       worker_thread+0xa0/0x800 kernel/workqueue.c:2415
       kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
      
      read to 0xffff8880b9dedcb8 of 4 bytes by task 29572 on cpu 1:
       neigh_resolve_output net/core/neighbour.c:1479 [inline]
       neigh_resolve_output+0x113/0x470 net/core/neighbour.c:1470
       neigh_output include/net/neighbour.h:511 [inline]
       ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
       __ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
       __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
       ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
       NF_HOOK_COND include/linux/netfilter.h:294 [inline]
       ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
       dst_output include/net/dst.h:436 [inline]
       NF_HOOK include/linux/netfilter.h:305 [inline]
       ndisc_send_skb+0x459/0x5f0 net/ipv6/ndisc.c:505
       ndisc_send_ns+0x207/0x430 net/ipv6/ndisc.c:647
       rt6_probe_deferred+0x98/0xf0 net/ipv6/route.c:615
       process_one_work+0x3d4/0x890 kernel/workqueue.c:2269
       worker_thread+0xa0/0x800 kernel/workqueue.c:2415
       kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 29572 Comm: kworker/1:4 Not tainted 5.4.0-rc6+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events rt6_probe_deferred
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c305c6ae
    • D
      Merge branch 'u64_stats_t' · 9dfd8714
      David S. Miller 提交于
      Eric Dumazet says:
      
      ====================
      net: introduce u64_stats_t
      
      KCSAN found a data-race in per-cpu u64 stats accounting.
      
      (The stack traces are included in the 8th patch :
       tun: switch to u64_stats_t)
      
      This patch series first consolidate code in five patches.
      Then the last three patches address the data-race resolution.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9dfd8714
    • E
      net: use u64_stats_t in struct pcpu_lstats · fd2f4737
      Eric Dumazet 提交于
      In order to fix the data-race found by KCSAN, we
      can use the new u64_stats_t type and its accessors instead
      of plain u64 fields. This will still generate optimal code
      for both 32 and 64 bit platforms.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd2f4737
    • E
      tun: switch to u64_stats_t · 5260dd3e
      Eric Dumazet 提交于
      In order to fix this data-race found by KCSAN [1],
      switch to u64_stats_t helpers. They provide all
      the needed annotations, without adding extra cost.
      
      [1]
      BUG: KCSAN: data-race in tun_get_user / tun_net_get_stats64
      
      read to 0xffffe8ffffd8aca8 of 8 bytes by task 4882 on cpu 0:
       tun_net_get_stats64+0x9b/0x230 drivers/net/tun.c:1171
       dev_get_stats+0x89/0x1e0 net/core/dev.c:9103
       rtnl_fill_stats+0x56/0x370 net/core/rtnetlink.c:1177
       rtnl_fill_ifinfo+0xd3b/0x2100 net/core/rtnetlink.c:1667
       rtmsg_ifinfo_build_skb+0xb0/0x150 net/core/rtnetlink.c:3472
       rtmsg_ifinfo_event.part.0+0x4e/0xb0 net/core/rtnetlink.c:3504
       rtmsg_ifinfo_event net/core/rtnetlink.c:3515 [inline]
       rtmsg_ifinfo+0x85/0x90 net/core/rtnetlink.c:3513
       __dev_notify_flags+0x18b/0x200 net/core/dev.c:7649
       dev_change_flags+0xb8/0xe0 net/core/dev.c:7691
       dev_ifsioc+0x201/0x6a0 net/core/dev_ioctl.c:237
       dev_ioctl+0x149/0x660 net/core/dev_ioctl.c:489
       sock_do_ioctl+0xdb/0x230 net/socket.c:1061
       sock_ioctl+0x3a3/0x5e0 net/socket.c:1189
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0x991/0xc60 fs/ioctl.c:696
      
      write to 0xffffe8ffffd8aca8 of 8 bytes by task 4883 on cpu 1:
       tun_get_user+0x1d94/0x2ba0 drivers/net/tun.c:2002
       tun_chr_write_iter+0x79/0xd0 drivers/net/tun.c:2022
       call_write_iter include/linux/fs.h:1895 [inline]
       new_sync_write+0x388/0x4a0 fs/read_write.c:483
       __vfs_write+0xb1/0xc0 fs/read_write.c:496
       __kernel_write+0xb8/0x240 fs/read_write.c:515
       write_pipe_buf+0xb6/0xf0 fs/splice.c:794
       splice_from_pipe_feed fs/splice.c:500 [inline]
       __splice_from_pipe+0x248/0x480 fs/splice.c:624
       splice_from_pipe+0xbb/0x100 fs/splice.c:659
       default_file_splice_write+0x45/0x90 fs/splice.c:806
       do_splice_from fs/splice.c:848 [inline]
       direct_splice_actor+0xa0/0xc0 fs/splice.c:1020
       splice_direct_to_actor+0x215/0x510 fs/splice.c:975
       do_splice_direct+0x161/0x1e0 fs/splice.c:1063
       do_sendfile+0x384/0x7f0 fs/read_write.c:1464
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 4883 Comm: syz-executor.1 Not tainted 5.4.0-rc3+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5260dd3e
    • E
      u64_stats: provide u64_stats_t type · 316580b6
      Eric Dumazet 提交于
      On 64bit arches, struct u64_stats_sync is empty and provides
      no help against load/store tearing.
      
      Using READ_ONCE()/WRITE_ONCE() would be needed.
      
      But the update side would be slightly more expensive.
      
      local64_t was defined so that we could use regular adds
      in a manner which is atomic wrt IRQs.
      
      However the u64_stats infra means we do not have to use
      local64_t on 32bit arches since the syncp provides the needed
      protection.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      316580b6
    • E
      net: dummy: use standard dev_lstats_add() and dev_lstats_read() · 4a43b1f9
      Eric Dumazet 提交于
      This driver can simply use the common infrastructure instead
      of duplicating it.
      
      This cleanup will ease u64_stats_t adoption in a single location.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a43b1f9
    • E
      vsockmon: use standard dev_lstats_add() and dev_lstats_read() · 4f77eb09
      Eric Dumazet 提交于
      This cleanup will ease u64_stats_t adoption in a single location.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f77eb09
    • E
      veth: use standard dev_lstats_add() and dev_lstats_read() · b4fba476
      Eric Dumazet 提交于
      This cleanup will ease u64_stats_t adoption in a single location.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4fba476