1. 27 4月, 2022 1 次提交
  2. 26 4月, 2021 1 次提交
  3. 14 10月, 2020 1 次提交
  4. 09 10月, 2020 1 次提交
    • X
      xfrm: interface: fix the priorities for ipip and ipv6 tunnels · 7fe94612
      Xin Long 提交于
      As Nicolas noticed in his case, when xfrm_interface module is installed
      the standard IP tunnels will break in receiving packets.
      
      This is caused by the IP tunnel handlers with a higher priority in xfrm
      interface processing incoming packets by xfrm_input(), which would drop
      the packets and return 0 instead when anything wrong happens.
      
      Rather than changing xfrm_input(), this patch is to adjust the priority
      for the IP tunnel handlers in xfrm interface, so that the packets would
      go to xfrmi's later than the others', as the others' would not drop the
      packets when the handlers couldn't process them.
      
      Note that IPCOMP also defines its own IPIP tunnel handler and it calls
      xfrm_input() as well, so we must make its priority lower than xfrmi's,
      which means having xfrmi loaded would still break IPCOMP. We may seek
      another way to fix it in xfrm_input() in the future.
      Reported-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Tested-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Fixes: da9bbf05 ("xfrm: interface: support IPIP and IPIP6 tunnels processing with .cb_handler")
      FIxes: d7b360c2 ("xfrm: interface: support IP6IP6 and IP6IP tunnels processing with .cb_handler")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      7fe94612
  5. 06 10月, 2020 1 次提交
  6. 27 8月, 2020 1 次提交
  7. 17 7月, 2020 1 次提交
    • X
      xfrm: interface: use IS_REACHABLE to avoid some compile errors · 0a0d93b9
      Xin Long 提交于
      kernel test robot reported some compile errors:
      
        ia64-linux-ld: net/xfrm/xfrm_interface.o: in function `xfrmi4_fini':
        net/xfrm/xfrm_interface.c:900: undefined reference to `xfrm4_tunnel_deregister'
        ia64-linux-ld: net/xfrm/xfrm_interface.c:901: undefined reference to `xfrm4_tunnel_deregister'
        ia64-linux-ld: net/xfrm/xfrm_interface.o: in function `xfrmi4_init':
        net/xfrm/xfrm_interface.c:873: undefined reference to `xfrm4_tunnel_register'
        ia64-linux-ld: net/xfrm/xfrm_interface.c:876: undefined reference to `xfrm4_tunnel_register'
        ia64-linux-ld: net/xfrm/xfrm_interface.c:885: undefined reference to `xfrm4_tunnel_deregister'
      
      This happened when set CONFIG_XFRM_INTERFACE=y and CONFIG_INET_TUNNEL=m.
      We don't really want xfrm_interface to depend inet_tunnel completely,
      but only to disable the tunnel code when inet_tunnel is not seen.
      
      So instead of adding "select INET_TUNNEL" for XFRM_INTERFACE, this patch
      is only to change to IS_REACHABLE to avoid these compile error.
      Reported-by: Nkernel test robot <lkp@intel.com>
      Fixes: da9bbf05 ("xfrm: interface: support IPIP and IPIP6 tunnels processing with .cb_handler")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      0a0d93b9
  8. 14 7月, 2020 1 次提交
  9. 13 7月, 2020 2 次提交
  10. 09 7月, 2020 2 次提交
  11. 01 7月, 2020 1 次提交
  12. 28 4月, 2020 1 次提交
  13. 27 4月, 2020 1 次提交
  14. 23 4月, 2020 1 次提交
    • N
      xfrm interface: fix oops when deleting a x-netns interface · c95c5f58
      Nicolas Dichtel 提交于
      Here is the steps to reproduce the problem:
      ip netns add foo
      ip netns add bar
      ip -n foo link add xfrmi0 type xfrm dev lo if_id 42
      ip -n foo link set xfrmi0 netns bar
      ip netns del foo
      ip netns del bar
      
      Which results to:
      [  186.686395] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bd3: 0000 [#1] SMP PTI
      [  186.687665] CPU: 7 PID: 232 Comm: kworker/u16:2 Not tainted 5.6.0+ #1
      [  186.688430] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      [  186.689420] Workqueue: netns cleanup_net
      [  186.689903] RIP: 0010:xfrmi_dev_uninit+0x1b/0x4b [xfrm_interface]
      [  186.690657] Code: 44 f6 ff ff 31 c0 5b 5d 41 5c 41 5d 41 5e c3 48 8d 8f c0 08 00 00 8b 05 ce 14 00 00 48 8b 97 d0 08 00 00 48 8b 92 c0 0e 00 00 <48> 8b 14 c2 48 8b 02 48 85 c0 74 19 48 39 c1 75 0c 48 8b 87 c0 08
      [  186.692838] RSP: 0018:ffffc900003b7d68 EFLAGS: 00010286
      [  186.693435] RAX: 000000000000000d RBX: ffff8881b0f31000 RCX: ffff8881b0f318c0
      [  186.694334] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000246 RDI: ffff8881b0f31000
      [  186.695190] RBP: ffffc900003b7df0 R08: ffff888236c07740 R09: 0000000000000040
      [  186.696024] R10: ffffffff81fce1b8 R11: 0000000000000002 R12: ffffc900003b7d80
      [  186.696859] R13: ffff8881edcc6a40 R14: ffff8881a1b6e780 R15: ffffffff81ed47c8
      [  186.697738] FS:  0000000000000000(0000) GS:ffff888237dc0000(0000) knlGS:0000000000000000
      [  186.698705] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  186.699408] CR2: 00007f2129e93148 CR3: 0000000001e0a000 CR4: 00000000000006e0
      [  186.700221] Call Trace:
      [  186.700508]  rollback_registered_many+0x32b/0x3fd
      [  186.701058]  ? __rtnl_unlock+0x20/0x3d
      [  186.701494]  ? arch_local_irq_save+0x11/0x17
      [  186.702012]  unregister_netdevice_many+0x12/0x55
      [  186.702594]  default_device_exit_batch+0x12b/0x150
      [  186.703160]  ? prepare_to_wait_exclusive+0x60/0x60
      [  186.703719]  cleanup_net+0x17d/0x234
      [  186.704138]  process_one_work+0x196/0x2e8
      [  186.704652]  worker_thread+0x1a4/0x249
      [  186.705087]  ? cancel_delayed_work+0x92/0x92
      [  186.705620]  kthread+0x105/0x10f
      [  186.706000]  ? __kthread_bind_mask+0x57/0x57
      [  186.706501]  ret_from_fork+0x35/0x40
      [  186.706978] Modules linked in: xfrm_interface nfsv3 nfs_acl auth_rpcgss nfsv4 nfs lockd grace fscache sunrpc button parport_pc parport serio_raw evdev pcspkr loop ext4 crc16 mbcache jbd2 crc32c_generic 8139too ide_cd_mod cdrom ide_gd_mod ata_generic ata_piix libata scsi_mod piix psmouse i2c_piix4 ide_core 8139cp i2c_core mii floppy
      [  186.710423] ---[ end trace 463bba18105537e5 ]---
      
      The problem is that x-netns xfrm interface are not removed when the link
      netns is removed. This causes later this oops when thoses interfaces are
      removed.
      
      Let's add a handler to remove all interfaces related to a netns when this
      netns is removed.
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Reported-by: NChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      c95c5f58
  15. 14 2月, 2020 1 次提交
  16. 14 1月, 2020 2 次提交
  17. 02 10月, 2019 1 次提交
    • F
      netfilter: drop bridge nf reset from nf_reset · 895b5c9f
      Florian Westphal 提交于
      commit 174e2381
      ("sk_buff: drop all skb extensions on free and skb scrubbing") made napi
      recycle always drop skb extensions.  The additional skb_ext_del() that is
      performed via nf_reset on napi skb recycle is not needed anymore.
      
      Most nf_reset() calls in the stack are there so queued skb won't block
      'rmmod nf_conntrack' indefinitely.
      
      This removes the skb_ext_del from nf_reset, and renames it to a more
      fitting nf_reset_ct().
      
      In a few selected places, add a call to skb_ext_reset to make sure that
      no active extensions remain.
      
      I am submitting this for "net", because we're still early in the release
      cycle.  The patch applies to net-next too, but I think the rename causes
      needless divergence between those trees.
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      895b5c9f
  18. 01 10月, 2019 1 次提交
  19. 17 7月, 2019 4 次提交
  20. 03 7月, 2019 1 次提交
    • N
      xfrm interface: fix memory leak on creation · 56c5ee1a
      Nicolas Dichtel 提交于
      The following commands produce a backtrace and return an error but the xfrm
      interface is created (in the wrong netns):
      $ ip netns add foo
      $ ip netns add bar
      $ ip -n foo netns set bar 0
      $ ip -n foo link add xfrmi0 link-netnsid 0 type xfrm dev lo if_id 23
      RTNETLINK answers: Invalid argument
      $ ip -n bar link ls xfrmi0
      2: xfrmi0@lo: <NOARP,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
          link/none 00:00:00:00:00:00 brd 00:00:00:00:00:00
      
      Here is the backtrace:
      [   79.879174] WARNING: CPU: 0 PID: 1178 at net/core/dev.c:8172 rollback_registered_many+0x86/0x3c1
      [   79.880260] Modules linked in: xfrm_interface nfsv3 nfs_acl auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache button parport_pc parport serio_raw evdev pcspkr loop ext4 crc16 mbcache jbd2 crc32c_generic ide_cd_mod ide_gd_mod cdrom ata_$
      eneric ata_piix libata scsi_mod 8139too piix psmouse i2c_piix4 ide_core 8139cp mii i2c_core floppy
      [   79.883698] CPU: 0 PID: 1178 Comm: ip Not tainted 5.2.0-rc6+ #106
      [   79.884462] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
      [   79.885447] RIP: 0010:rollback_registered_many+0x86/0x3c1
      [   79.886120] Code: 01 e8 d7 7d c6 ff 0f 0b 48 8b 45 00 4c 8b 20 48 8d 58 90 49 83 ec 70 48 8d 7b 70 48 39 ef 74 44 8a 83 d0 04 00 00 84 c0 75 1f <0f> 0b e8 61 cd ff ff 48 b8 00 01 00 00 00 00 ad de 48 89 43 70 66
      [   79.888667] RSP: 0018:ffffc900015ab740 EFLAGS: 00010246
      [   79.889339] RAX: ffff8882353e5700 RBX: ffff8882353e56a0 RCX: ffff8882353e5710
      [   79.890174] RDX: ffffc900015ab7e0 RSI: ffffc900015ab7e0 RDI: ffff8882353e5710
      [   79.891029] RBP: ffffc900015ab7e0 R08: ffffc900015ab7e0 R09: ffffc900015ab7e0
      [   79.891866] R10: ffffc900015ab7a0 R11: ffffffff82233fec R12: ffffc900015ab770
      [   79.892728] R13: ffffffff81eb7ec0 R14: ffff88822ed6cf00 R15: 00000000ffffffea
      [   79.893557] FS:  00007ff350f31740(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      [   79.894581] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   79.895317] CR2: 00000000006c8580 CR3: 000000022c272000 CR4: 00000000000006f0
      [   79.896137] Call Trace:
      [   79.896464]  unregister_netdevice_many+0x12/0x6c
      [   79.896998]  __rtnl_newlink+0x6e2/0x73b
      [   79.897446]  ? __kmalloc_node_track_caller+0x15e/0x185
      [   79.898039]  ? pskb_expand_head+0x5f/0x1fe
      [   79.898556]  ? stack_access_ok+0xd/0x2c
      [   79.899009]  ? deref_stack_reg+0x12/0x20
      [   79.899462]  ? stack_access_ok+0xd/0x2c
      [   79.899927]  ? stack_access_ok+0xd/0x2c
      [   79.900404]  ? __module_text_address+0x9/0x4f
      [   79.900910]  ? is_bpf_text_address+0x5/0xc
      [   79.901390]  ? kernel_text_address+0x67/0x7b
      [   79.901884]  ? __kernel_text_address+0x1a/0x25
      [   79.902397]  ? unwind_get_return_address+0x12/0x23
      [   79.903122]  ? __cmpxchg_double_slab.isra.37+0x46/0x77
      [   79.903772]  rtnl_newlink+0x43/0x56
      [   79.904217]  rtnetlink_rcv_msg+0x200/0x24c
      
      In fact, each time a xfrm interface was created, a netdev was allocated
      by __rtnl_newlink()/rtnl_create_link() and then another one by
      xfrmi_newlink()/xfrmi_create(). Only the second one was registered, it's
      why the previous commands produce a backtrace: dev_change_net_namespace()
      was called on a netdev with reg_state set to NETREG_UNINITIALIZED (the
      first one).
      
      CC: Lorenzo Colitti <lorenzo@google.com>
      CC: Benedict Wong <benedictwong@google.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Shannon Nelson <shannon.nelson@oracle.com>
      CC: Antony Antony <antony@phenome.org>
      CC: Eyal Birger <eyal.birger@gmail.com>
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Reported-by: NJulien Floret <julien.floret@6wind.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      56c5ee1a
  21. 14 6月, 2019 1 次提交
  22. 08 4月, 2019 3 次提交
    • F
      xfrm: store xfrm_mode directly, not its address · c9500d7b
      Florian Westphal 提交于
      This structure is now only 4 bytes, so its more efficient
      to cache a copy rather than its address.
      
      No significant size difference in allmodconfig vmlinux.
      
      With non-modular kernel that has all XFRM options enabled, this
      series reduces vmlinux image size by ~11kb. All xfrm_mode
      indirections are gone and all modes are built-in.
      
      before (ipsec-next master):
          text      data      bss         dec   filename
      21071494   7233140 11104324    39408958   vmlinux.master
      
      after this series:
      21066448   7226772 11104324    39397544   vmlinux.patched
      
      With allmodconfig kernel, the size increase is only 362 bytes,
      even all the xfrm config options removed in this series are
      modular.
      
      before:
          text      data     bss      dec   filename
      15731286   6936912 4046908 26715106   vmlinux.master
      
      after this series:
      15731492   6937068  4046908  26715468 vmlinux
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      c9500d7b
    • F
      xfrm: make xfrm modes builtin · 4c145dce
      Florian Westphal 提交于
      after previous changes, xfrm_mode contains no function pointers anymore
      and all modules defining such struct contain no code except an init/exit
      functions to register the xfrm_mode struct with the xfrm core.
      
      Just place the xfrm modes core and remove the modules,
      the run-time xfrm_mode register/unregister functionality is removed.
      
      Before:
      
          text    data     bss      dec filename
          7523     200    2364    10087 net/xfrm/xfrm_input.o
         40003     628     440    41071 net/xfrm/xfrm_state.o
      15730338 6937080 4046908 26714326 vmlinux
      
          7389     200    2364    9953  net/xfrm/xfrm_input.o
         40574     656     440   41670  net/xfrm/xfrm_state.o
      15730084 6937068 4046908 26714060 vmlinux
      
      The xfrm*_mode_{transport,tunnel,beet} modules are gone.
      
      v2: replace CONFIG_INET6_XFRM_MODE_* IS_ENABLED guards with CONFIG_IPV6
          ones rather than removing them.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      4c145dce
    • F
      xfrm: prefer family stored in xfrm_mode struct · b45714b1
      Florian Westphal 提交于
      Now that we have the family available directly in the
      xfrm_mode struct, we can use that and avoid one extra dereference.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      b45714b1
  23. 27 3月, 2019 1 次提交
  24. 18 2月, 2019 1 次提交
    • T
      xfrm: Fix inbound traffic via XFRM interfaces across network namespaces · 660899dd
      Tobias Brunner 提交于
      After moving an XFRM interface to another namespace it stays associated
      with the original namespace (net in `struct xfrm_if` and the list keyed
      with `xfrmi_net_id`), allowing processes in the new namespace to use
      SAs/policies that were created in the original namespace.  For instance,
      this allows a keying daemon in one namespace to establish IPsec SAs for
      other namespaces without processes there having access to the keys or IKE
      credentials.
      
      This worked fine for outbound traffic, however, for inbound traffic the
      lookup for the interfaces and the policies used the incorrect namespace
      (the one the XFRM interface was moved to).
      
      Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces")
      Signed-off-by: NTobias Brunner <tobias@strongswan.org>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      660899dd
  25. 20 12月, 2018 1 次提交
  26. 08 10月, 2018 1 次提交
  27. 02 10月, 2018 1 次提交
  28. 27 9月, 2018 2 次提交
  29. 29 8月, 2018 1 次提交
  30. 27 7月, 2018 1 次提交
  31. 26 7月, 2018 1 次提交