Skip to content
Snippets Groups Projects
  1. Nov 15, 2020
  2. Nov 14, 2020
  3. Nov 13, 2020
    • Martin KaFai Lau's avatar
      bpf: Allow using bpf_sk_storage in FENTRY/FEXIT/RAW_TP · 8e4597c6
      Martin KaFai Lau authored
      
      This patch enables the FENTRY/FEXIT/RAW_TP tracing program to use
      the bpf_sk_storage_(get|delete) helper, so those tracing programs
      can access the sk's bpf_local_storage and the later selftest
      will show some examples.
      
      The bpf_sk_storage is currently used in bpf-tcp-cc, tc,
      cg sockops...etc which is running either in softirq or
      task context.
      
      This patch adds bpf_sk_storage_get_tracing_proto and
      bpf_sk_storage_delete_tracing_proto.  They will check
      in runtime that the helpers can only be called when serving
      softirq or running in a task context.  That should enable
      most common tracing use cases on sk.
      
      During the load time, the new tracing_allowed() function
      will ensure the tracing prog using the bpf_sk_storage_(get|delete)
      helper is not tracing any bpf_sk_storage*() function itself.
      The sk is passed as "void *" when calling into bpf_local_storage.
      
      This patch only allows tracing a kernel function.
      
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20201112211313.2587383-1-kafai@fb.com
      8e4597c6
  4. Nov 11, 2020
  5. Nov 10, 2020
  6. Nov 07, 2020
  7. Nov 06, 2020
  8. Nov 05, 2020
  9. Nov 03, 2020
  10. Oct 31, 2020
  11. Oct 30, 2020
  12. Oct 29, 2020
    • Arnd Bergmann's avatar
      wimax: move out to staging · f54ec58f
      Arnd Bergmann authored
      There are no known users of this driver as of October 2020, and it will
      be removed unless someone turns out to still need it in future releases.
      
      According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there
      have been many public wimax networks, but it appears that many of these
      have migrated to LTE or discontinued their service altogether.
      As most PCs and phones lack WiMAX hardware support, the remaining
      networks tend to use standalone routers. These almost certainly
      run Linux, but not a modern kernel or the mainline wimax driver stack.
      
      NetworkManager appears to have dropped userspace support in 2015
      https://bugzilla.gnome.org/show_bug.cgi?id=747846
      
      , the
      www.linuxwimax.org
      site had already shut down earlier.
      
      WiMax is apparently still being deployed on airport campus networks
      ("AeroMACS"), but in a frequency band that was not supported by the old
      Intel 2400m (used in Sandy Bridge laptops and earlier), which is the
      only driver using the kernel's wimax stack.
      
      Move all files into drivers/staging/wimax, including the uapi header
      files and documentation, to make it easier to remove it when it gets
      to that. Only minimal changes are made to the source files, in order
      to make it possible to port patches across the move.
      
      Also remove the MAINTAINERS entry that refers to a broken mailing
      list and website.
      
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-By: default avatarInaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Suggested-by: default avatarInaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      f54ec58f
    • Magnus Karlsson's avatar
      xsk: Fix possible memory leak at socket close · e5e1a4bc
      Magnus Karlsson authored
      
      Fix a possible memory leak at xsk socket close that is caused by the
      refcounting of the umem object being wrong. The reference count of the
      umem was decremented only after the pool had been freed. Note that if
      the buffer pool is destroyed, it is important that the umem is
      destroyed after the pool, otherwise the umem would disappear while the
      driver is still running. And as the buffer pool needs to be destroyed
      in a work queue, the umem is also (if its refcount reaches zero)
      destroyed after the buffer pool in that same work queue.
      
      What was missing is that the refcount also needs to be decremented
      when the pool is not freed and when the pool has not even been
      created. The first case happens when the refcount of the pool is
      higher than 1, i.e. it is still being used by some other socket using
      the same device and queue id. In this case, it is safe to decrement
      the refcount of the umem outside of the work queue as the umem will
      never be freed because the refcount of the umem is always greater than
      or equal to the refcount of the buffer pool. The second case is if the
      buffer pool has not been created yet, i.e. the socket was closed
      before it was bound but after the umem was created. In this case, it
      is safe to destroy the umem outside of the work queue, since there is
      no pool that can use it by definition.
      
      Fixes: 1c1efc2a ("xsk: Create and free buffer pool independently from umem")
      Reported-by: default avatar <syzbot+eb71df123dc2be2c1456@syzkaller.appspotmail.com>
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Link: https://lore.kernel.org/bpf/1603801921-2712-1-git-send-email-magnus.karlsson@gmail.com
      e5e1a4bc
  13. Oct 20, 2020
  14. Oct 15, 2020
    • Leon Romanovsky's avatar
      net: sched: Fix suspicious RCU usage while accessing tcf_tunnel_info · d086a1c6
      Leon Romanovsky authored
      
      The access of tcf_tunnel_info() produces the following splat, so fix it
      by dereferencing the tcf_tunnel_key_params pointer with marker that
      internal tcfa_liock is held.
      
       =============================
       WARNING: suspicious RCU usage
       5.9.0+ #1 Not tainted
       -----------------------------
       include/net/tc_act/tc_tunnel_key.h:59 suspicious rcu_dereference_protected() usage!
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 1
       1 lock held by tc/34839:
        #0: ffff88828572c2a0 (&p->tcfa_lock){+...}-{2:2}, at: tc_setup_flow_action+0xb3/0x48b5
       stack backtrace:
       CPU: 1 PID: 34839 Comm: tc Not tainted 5.9.0+ #1
       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
       Call Trace:
        dump_stack+0x9a/0xd0
        tc_setup_flow_action+0x14cb/0x48b5
        fl_hw_replace_filter+0x347/0x690 [cls_flower]
        fl_change+0x2bad/0x4875 [cls_flower]
        tc_new_tfilter+0xf6f/0x1ba0
        rtnetlink_rcv_msg+0x5f2/0x870
        netlink_rcv_skb+0x124/0x350
        netlink_unicast+0x433/0x700
        netlink_sendmsg+0x6f1/0xbd0
        sock_sendmsg+0xb0/0xe0
        ____sys_sendmsg+0x4fa/0x6d0
        ___sys_sendmsg+0x12e/0x1b0
        __sys_sendmsg+0xa4/0x120
        do_syscall_64+0x2d/0x40
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7f1f8cd4fe57
       Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
       RSP: 002b:00007ffdc1e193b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
       RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f8cd4fe57
       RDX: 0000000000000000 RSI: 00007ffdc1e19420 RDI: 0000000000000003
       RBP: 000000005f85aafa R08: 0000000000000001 R09: 00007ffdc1e1936c
       R10: 000000000040522d R11: 0000000000000246 R12: 0000000000000001
       R13: 0000000000000000 R14: 00007ffdc1e1d6f0 R15: 0000000000482420
      
      Fixes: 3ebaf6da ("net: sched: Do not assume RTNL is held in tunnel key action helpers")
      Fixes: 7a472814 ("net: sched: lock action when translating it to flow_action infra")
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d086a1c6
    • Mauro Carvalho Chehab's avatar
      nl80211: docs: add a description for s1g_cap parameter · 8a50c057
      Mauro Carvalho Chehab authored
      
      Changeset df78a0c0 ("nl80211: S1G band and channel definitions")
      added a new parameter, but didn't add the corresponding kernel-doc
      markup, as repoted when doing "make htmldocs":
      
      	./include/net/cfg80211.h:471: warning: Function parameter or member 's1g_cap' not described in 'ieee80211_supported_band'
      
      Add a documentation for it.
      
      Fixes: df78a0c0 ("nl80211: S1G band and channel definitions")
      Signed-off-by: default avatarThomas Pedersen <thomas@adapt-ip.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      8a50c057
    • Pablo Neira Ayuso's avatar
      netfilter: restore NF_INET_NUMHOOKS · d25e2e93
      Pablo Neira Ayuso authored
      
      This definition is used by the iptables legacy UAPI, restore it.
      
      Fixes: d3519cb8 ("netfilter: nf_tables: add inet ingress support")
      Reported-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Tested-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d25e2e93
  15. Oct 13, 2020
    • Pablo Neira Ayuso's avatar
      netfilter: nf_log: missing vlan offload tag and proto · 0d9826bc
      Pablo Neira Ayuso authored
      
      Dump vlan tag and proto for the usual vlan offload case if the
      NF_LOG_MACDECODE flag is set on. Without this information the logging is
      misleading as there is no reference to the VLAN header.
      
      [12716.993704] test: IN=veth0 OUT= MACSRC=86:6c:92:ea:d6:73 MACDST=0e:3b:eb:86:73:76 VPROTO=8100 VID=10 MACPROTO=0800 SRC=192.168.10.2 DST=172.217.168.163 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2548 DF PROTO=TCP SPT=55848 DPT=80 WINDOW=501 RES=0x00 ACK FIN URGP=0
      [12721.157643] test: IN=veth0 OUT= MACSRC=86:6c:92:ea:d6:73 MACDST=0e:3b:eb:86:73:76 VPROTO=8100 VID=10 MACPROTO=0806 ARP HTYPE=1 PTYPE=0x0800 OPCODE=2 MACSRC=86:6c:92:ea:d6:73 IPSRC=192.168.10.2 MACDST=0e:3b:eb:86:73:76 IPDST=192.168.10.1
      
      Fixes: 83e96d44 ("netfilter: log: split family specific code to nf_log_{ip,ip6,common}.c files")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      0d9826bc
  16. Oct 12, 2020
  17. Oct 11, 2020
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: add inet ingress support · d3519cb8
      Pablo Neira Ayuso authored
      
      This patch adds a new ingress hook for the inet family. The inet ingress
      hook emulates the IP receive path code, therefore, unclean packets are
      drop before walking over the ruleset in this basechain.
      
      This patch also introduces the nft_base_chain_netdev() helper function
      to check if this hook is bound to one or more devices (through the hook
      list infrastructure). This check allows to perform the same handling for
      the inet ingress as it would be a netdev ingress chain from the control
      plane.
      
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      d3519cb8
Loading