An error occurred fetching the project authors.
  1. 09 May, 2018 1 commit
  2. 15 Sep, 2017 1 commit
  3. 11 Aug, 2017 1 commit
    • Nikolay Aleksandrov's avatar
      vrf: fix bug_on triggered by rx when destroying a vrf · f3ae716d
      Nikolay Aleksandrov authored
      BugLink: http://bugs.launchpad.net/bugs/1705707
      
      commit f630c38e upstream.
      
      When destroying a VRF device we cleanup the slaves in its ndo_uninit()
      function, but that causes packets to be switched (skb->dev == vrf being
      destroyed) even though we're pass the point where the VRF should be
      receiving any packets while it is being dismantled. This causes a BUG_ON
      to trigger if we have raw sockets (trace below).
      The reason is that the inetdev of the VRF has been destroyed but we're
      still sending packets up the stack with it, so let's free the slaves in
      the dellink callback as David Ahern suggested.
      
      Note that this fix doesn't prevent packets from going up when the VRF
      device is admin down.
      
      [   35.631371] ------------[ cut here ]------------
      [   35.631603] kernel BUG at net/ipv4/fib_frontend.c:285!
      [   35.631854] invalid opcode: 0000 [#1] SMP
      [   35.631977] Modules linked in:
      [   35.632081] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.12.0-rc7+ #45
      [   35.632247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [   35.632477] task: ffff88005ad68000 task.stack: ffff88005ad64000
      [   35.632632] RIP: 0010:fib_compute_spec_dst+0xfc/0x1ee
      [   35.632769] RSP: 0018:ffff88005ad67978 EFLAGS: 00010202
      [   35.632910] RAX: 0000000000000001 RBX: ffff880059a7f200 RCX: 0000000000000000
      [   35.633084] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff82274af0
      [   35.633256] RBP: ffff88005ad679f8 R08: 000000000001ef70 R09: 0000000000000046
      [   35.633430] R10: ffff88005ad679f8 R11: ffff880037731cb0 R12: 0000000000000001
      [   35.633603] R13: ffff8800599e3000 R14: 0000000000000000 R15: ffff8800599cb852
      [   35.634114] FS:  0000000000000000(0000) GS:ffff88005d900000(0000) knlGS:0000000000000000
      [   35.634306] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.634456] CR2: 00007f3563227095 CR3: 000000000201d000 CR4: 00000000000406e0
      [   35.634632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.634865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.635055] Call Trace:
      [   35.635271]  ? __lock_acquire+0xf0d/0x1117
      [   35.635522]  ipv4_pktinfo_prepare+0x82/0x151
      [   35.635831]  raw_rcv_skb+0x17/0x3c
      [   35.636062]  raw_rcv+0xe5/0xf7
      [   35.636287]  raw_local_deliver+0x169/0x1d9
      [   35.636534]  ip_local_deliver_finish+0x87/0x1c4
      [   35.636820]  ip_local_deliver+0x63/0x7f
      [   35.637058]  ip_rcv_finish+0x340/0x3a1
      [   35.637295]  ip_rcv+0x314/0x34a
      [   35.637525]  __netif_receive_skb_core+0x49f/0x7c5
      [   35.637780]  ? lock_acquire+0x13f/0x1d7
      [   35.638018]  ? lock_acquire+0x15e/0x1d7
      [   35.638259]  __netif_receive_skb+0x1e/0x94
      [   35.638502]  ? __netif_receive_skb+0x1e/0x94
      [   35.638748]  netif_receive_skb_internal+0x74/0x300
      [   35.639002]  ? dev_gro_receive+0x2ed/0x411
      [   35.639246]  ? lock_is_held_type+0xc4/0xd2
      [   35.639491]  napi_gro_receive+0x105/0x1a0
      [   35.639736]  receive_buf+0xc32/0xc74
      [   35.639965]  ? detach_buf+0x67/0x153
      [   35.640201]  ? virtqueue_get_buf_ctx+0x120/0x176
      [   35.640453]  virtnet_poll+0x128/0x1c5
      [   35.640690]  net_rx_action+0x103/0x343
      [   35.640932]  __do_softirq+0x1c7/0x4b7
      [   35.641171]  run_ksoftirqd+0x23/0x5c
      [   35.641403]  smpboot_thread_fn+0x24f/0x26d
      [   35.641646]  ? sort_range+0x22/0x22
      [   35.641878]  kthread+0x129/0x131
      [   35.642104]  ? __list_add+0x31/0x31
      [   35.642335]  ? __list_add+0x31/0x31
      [   35.642568]  ret_from_fork+0x2a/0x40
      [   35.642804] Code: 05 bd 87 a3 00 01 e8 1f ef 98 ff 4d 85 f6 48 c7 c7 f0 4a 27 82 41 0f 94 c4 31 c9 31 d2 41 0f b6 f4 e8 04 71 a1 ff 45 84 e4 74 02 <0f> 0b 0f b7 93 c4 00 00 00 4d 8b a5 80 05 00 00 48 03 93 d0 00
      [   35.644342] RIP: fib_compute_spec_dst+0xfc/0x1ee RSP: ffff88005ad67978
      
      Fixes: 193125db ("net: Introduce VRF device driver")
      Reported-by: default avatarChris Cormier <chriscormier@cumulusnetworks.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [backport to 4.4 - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      f3ae716d
  4. 06 Apr, 2017 1 commit
  5. 20 Jan, 2017 3 commits
  6. 21 Apr, 2016 1 commit
  7. 05 Jan, 2016 1 commit
    • David Ahern's avatar
      net: Propagate lookup failure in l3mdev_get_saddr to caller · b5bdacf3
      David Ahern authored
      Commands run in a vrf context are not failing as expected on a route lookup:
          root@kenny:~# ip ro ls table vrf-red
          unreachable default
      
          root@kenny:~# ping -I vrf-red -c1 -w1 10.100.1.254
          ping: Warning: source address might be selected on device other than vrf-red.
          PING 10.100.1.254 (10.100.1.254) from 0.0.0.0 vrf-red: 56(84) bytes of data.
      
          --- 10.100.1.254 ping statistics ---
          2 packets transmitted, 0 received, 100% packet loss, time 999ms
      
      Since the vrf table does not have a route for 10.100.1.254 the ping
      should have failed. The saddr lookup causes a full VRF table lookup.
      Propogating a lookup failure to the user allows the command to fail as
      expected:
      
          root@kenny:~# ping -I vrf-red -c1 -w1 10.100.1.254
          connect: No route to host
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5bdacf3
  8. 23 Nov, 2015 1 commit
    • Nikolay Aleksandrov's avatar
      vrf: fix double free and memory corruption on register_netdevice failure · 7f109f7c
      Nikolay Aleksandrov authored
      When vrf's ->newlink is called, if register_netdevice() fails then it
      does free_netdev(), but that's also done by rtnl_newlink() so a second
      free happens and memory gets corrupted, to reproduce execute the
      following line a couple of times (1 - 5 usually is enough):
      $ for i in `seq 1 5`; do ip link add vrf: type vrf table 1; done;
      This works because we fail in register_netdevice() because of the wrong
      name "vrf:".
      
      And here's a trace of one crash:
      [   28.792157] ------------[ cut here ]------------
      [   28.792407] kernel BUG at fs/namei.c:246!
      [   28.792608] invalid opcode: 0000 [#1] SMP
      [   28.793240] Modules linked in: vrf nfsd auth_rpcgss oid_registry
      nfs_acl nfs lockd grace sunrpc crct10dif_pclmul crc32_pclmul
      crc32c_intel qxl drm_kms_helper ttm drm aesni_intel aes_x86_64 psmouse
      glue_helper lrw evdev gf128mul i2c_piix4 ablk_helper cryptd ppdev
      parport_pc parport serio_raw pcspkr virtio_balloon virtio_console
      i2c_core acpi_cpufreq button 9pnet_virtio 9p 9pnet fscache ipv6 autofs4
      ext4 crc16 mbcache jbd2 virtio_blk virtio_net sg sr_mod cdrom
      ata_generic ehci_pci uhci_hcd ehci_hcd e1000 usbcore usb_common ata_piix
      libata virtio_pci virtio_ring virtio scsi_mod floppy
      [   28.796016] CPU: 0 PID: 1148 Comm: ld-linux-x86-64 Not tainted
      4.4.0-rc1+ #24
      [   28.796016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.8.1-20150318_183358- 04/01/2014
      [   28.796016] task: ffff8800352561c0 ti: ffff88003592c000 task.ti:
      ffff88003592c000
      [   28.796016] RIP: 0010:[<ffffffff812187b3>]  [<ffffffff812187b3>]
      putname+0x43/0x60
      [   28.796016] RSP: 0018:ffff88003592fe88  EFLAGS: 00010246
      [   28.796016] RAX: 0000000000000000 RBX: ffff8800352561c0 RCX:
      0000000000000001
      [   28.796016] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
      ffff88003784f000
      [   28.796016] RBP: ffff88003592ff08 R08: 0000000000000001 R09:
      0000000000000000
      [   28.796016] R10: 0000000000000000 R11: 0000000000000001 R12:
      0000000000000000
      [   28.796016] R13: 000000000000047c R14: ffff88003784f000 R15:
      ffff8800358c4a00
      [   28.796016] FS:  0000000000000000(0000) GS:ffff88003fc00000(0000)
      knlGS:0000000000000000
      [   28.796016] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   28.796016] CR2: 00007ffd583bc2d9 CR3: 0000000035a99000 CR4:
      00000000000406f0
      [   28.796016] Stack:
      [   28.796016]  ffffffff8121045d ffffffff812102d3 ffff8800352561c0
      ffff880035a91660
      [   28.796016]  ffff8800008a9880 0000000000000000 ffffffff81a49940
      00ffffff81218684
      [   28.796016]  ffff8800352561c0 000000000000047c 0000000000000000
      ffff880035b36d80
      [   28.796016] Call Trace:
      [   28.796016]  [<ffffffff8121045d>] ?
      do_execveat_common.isra.34+0x74d/0x930
      [   28.796016]  [<ffffffff812102d3>] ?
      do_execveat_common.isra.34+0x5c3/0x930
      [   28.796016]  [<ffffffff8121066c>] do_execve+0x2c/0x30
      [   28.796016]  [<ffffffff810939a0>]
      call_usermodehelper_exec_async+0xf0/0x140
      [   28.796016]  [<ffffffff810938b0>] ? umh_complete+0x40/0x40
      [   28.796016]  [<ffffffff815cb1af>] ret_from_fork+0x3f/0x70
      [   28.796016] Code: 48 8d 47 1c 48 89 e5 53 48 8b 37 48 89 fb 48 39 c6
      74 1a 48 8b 3d 7e e9 8f 00 e8 49 fa fc ff 48 89 df e8 f1 01 fd ff 5b 5d
      f3 c3 <0f> 0b 48 89 fe 48 8b 3d 61 e9 8f 00 e8 2c fa fc ff 5b 5d eb e9
      [   28.796016] RIP  [<ffffffff812187b3>] putname+0x43/0x60
      [   28.796016]  RSP <ffff88003592fe88>
      
      Fixes: 193125db ("net: Introduce VRF device driver")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f109f7c
  9. 13 Oct, 2015 1 commit
  10. 08 Oct, 2015 5 commits
  11. 07 Oct, 2015 3 commits
  12. 05 Oct, 2015 1 commit
    • WANG Cong's avatar
      vrf: fix a kernel warning · 0a15afd2
      WANG Cong authored
      This fixes:
      
       tried to remove device ip6gre0 from (null)
       ------------[ cut here ]------------
       kernel BUG at net/core/dev.c:5219!
       invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
       CPU: 3 PID: 161 Comm: kworker/u8:2 Not tainted 4.3.0-rc2+ #1142
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       Workqueue: netns cleanup_net
       task: ffff8800d784a9c0 ti: ffff8800d74a4000 task.ti: ffff8800d74a4000
       RIP: 0010:[<ffffffff817f0797>]  [<ffffffff817f0797>] __netdev_adjacent_dev_remove+0x40/0xec
       RSP: 0018:ffff8800d74a7a98  EFLAGS: 00010282
       RAX: 000000000000002a RBX: 0000000000000000 RCX: 0000000000000000
       RDX: ffff88011adcf701 RSI: ffff88011adccbf8 RDI: ffff88011adccbf8
       RBP: ffff8800d74a7ab8 R08: 0000000000000001 R09: 0000000000000000
       R10: ffffffff81d190ff R11: 00000000ffffffff R12: ffff8800d599e7c0
       R13: 0000000000000000 R14: ffff8800d599e890 R15: ffffffff82385e00
       FS:  0000000000000000(0000) GS:ffff88011ac00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00007ffd6f003000 CR3: 000000000220c000 CR4: 00000000000006e0
       Stack:
        0000000000000000 ffff8800d599e7c0 0000000000000b00 ffff8800d599e8a0
        ffff8800d74a7ad8 ffffffff817f0861 0000000000000000 ffff8800d599e7c0
        ffff8800d74a7af8 ffffffff817f088f 0000000000000000 ffff8800d599e7c0
       Call Trace:
        [<ffffffff817f0861>] __netdev_adjacent_dev_unlink+0x1e/0x35
        [<ffffffff817f088f>] __netdev_adjacent_dev_unlink_neighbour+0x17/0x41
        [<ffffffff817f56e6>] netdev_upper_dev_unlink+0x6c/0x13d
        [<ffffffff81674a3d>] vrf_del_slave+0x26/0x7d
        [<ffffffff81674ac3>] vrf_device_event+0x2f/0x34
        [<ffffffff81098c40>] notifier_call_chain+0x75/0x9c
        [<ffffffff81098fa2>] raw_notifier_call_chain+0x14/0x16
        [<ffffffff817ee129>] call_netdevice_notifiers_info+0x52/0x59
        [<ffffffff817f179d>] call_netdevice_notifiers+0x13/0x15
        [<ffffffff817f6f18>] rollback_registered_many+0x14f/0x24f
        [<ffffffff817f70f2>] unregister_netdevice_many+0x19/0x64
        [<ffffffff819a2455>] ip6gre_exit_net+0x163/0x177
        [<ffffffff817eb019>] ops_exit_list+0x44/0x55
        [<ffffffff817ebcb7>] cleanup_net+0x193/0x226
        [<ffffffff81091e1c>] process_one_work+0x26c/0x4d8
        [<ffffffff81091d20>] ? process_one_work+0x170/0x4d8
        [<ffffffff81092296>] worker_thread+0x1df/0x2c2
        [<ffffffff810920b7>] ? process_scheduled_works+0x2f/0x2f
        [<ffffffff810920b7>] ? process_scheduled_works+0x2f/0x2f
        [<ffffffff81097a20>] kthread+0xd4/0xdc
        [<ffffffff810bc523>] ? trace_hardirqs_on_caller+0x17d/0x199
        [<ffffffff8109794c>] ? __kthread_parkme+0x83/0x83
        [<ffffffff81a5240f>] ret_from_fork+0x3f/0x70
        [<ffffffff8109794c>] ? __kthread_parkme+0x83/0x83
      
      Fixes: 93a7e7e8 ("net: Remove the now unused vrf_ptr")
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a15afd2
  13. 30 Sep, 2015 4 commits
  14. 18 Sep, 2015 2 commits
    • Eric W. Biederman's avatar
      netfilter: Pass net into okfn · 0c4b51f0
      Eric W. Biederman authored
      This is immediately motivated by the bridge code that chains functions that
      call into netfilter.  Without passing net into the okfns the bridge code would
      need to guess about the best expression for the network namespace to process
      packets in.
      
      As net is frequently one of the first things computed in continuation functions
      after netfilter has done it's job passing in the desired network namespace is in
      many cases a code simplification.
      
      To support this change the function dst_output_okfn is introduced to
      simplify passing dst_output as an okfn.  For the moment dst_output_okfn
      just silently drops the struct net.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c4b51f0
    • Eric W. Biederman's avatar
      netfilter: Pass struct net into the netfilter hooks · 29a26a56
      Eric W. Biederman authored
      Pass a network namespace parameter into the netfilter hooks.  At the
      call site of the netfilter hooks the path a packet is taking through
      the network stack is well known which allows the network namespace to
      be easily and reliabily.
      
      This allows the replacement of magic code like
      "dev_net(state->in?:state->out)" that appears at the start of most
      netfilter hooks with "state->net".
      
      In almost all cases the network namespace passed in is derived
      from the first network device passed in, guaranteeing those
      paths will not see any changes in practice.
      
      The exceptions are:
      xfrm/xfrm_output.c:xfrm_output_resume()         xs_net(skb_dst(skb)->xfrm)
      ipvs/ip_vs_xmit.c:ip_vs_nat_send_or_cont()      ip_vs_conn_net(cp)
      ipvs/ip_vs_xmit.c:ip_vs_send_or_cont()          ip_vs_conn_net(cp)
      ipv4/raw.c:raw_send_hdrinc()                    sock_net(sk)
      ipv6/ip6_output.c:ip6_xmit()			sock_net(sk)
      ipv6/ndisc.c:ndisc_send_skb()                   dev_net(skb->dev) not dev_net(dst->dev)
      ipv6/raw.c:raw6_send_hdrinc()                   sock_net(sk)
      br_netfilter_hooks.c:br_nf_pre_routing_finish() dev_net(skb->dev) before skb->dev is set to nf_bridge->physindev
      
      In all cases these exceptions seem to be a better expression for the
      network namespace the packet is being processed in then the historic
      "dev_net(in?in:out)".  I am documenting them in case something odd
      pops up and someone starts trying to track down what happened.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29a26a56
  15. 17 Sep, 2015 1 commit
  16. 15 Sep, 2015 1 commit
  17. 28 Aug, 2015 1 commit
    • David Ahern's avatar
      net: Add ethernet header for pass through VRF device · 8f58336d
      David Ahern authored
      The change to use a custom dst broke tcpdump captures on the VRF device:
      
      $ tcpdump -n -i vrf10
      ...
      05:32:29.009362 IP 10.2.1.254 > 10.2.1.2: ICMP echo request, id 21989, seq 1, length 64
      05:32:29.009855 00:00:40:01:8d:36 > 45:00:00:54:d6:6f, ethertype Unknown (0x0a02), length 84:
      	0x0000:  0102 0a02 01fe 0000 9181 55e5 0001 bd11  ..........U.....
      	0x0010:  da55 0000 0000 bb5d 0700 0000 0000 1011  .U.....]........
      	0x0020:  1213 1415 1617 1819 1a1b 1c1d 1e1f 2021  ...............!
      	0x0030:  2223 2425 2627 2829 2a2b 2c2d 2e2f 3031  "#$%&'()*+,-./01
      	0x0040:  3233 3435 3637                           234567
      
      Local packets going through the VRF device are missing an ethernet header.
      Fix by adding one and then stripping it off before pushing back to the IP
      stack. With this patch you get the expected dumps:
      
      ...
      05:36:15.713944 IP 10.2.1.254 > 10.2.1.2: ICMP echo request, id 23795, seq 1, length 64
      05:36:15.714160 IP 10.2.1.2 > 10.2.1.254: ICMP echo reply, id 23795, seq 1, length 64
      ...
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f58336d
  18. 20 Aug, 2015 6 commits
  19. 19 Aug, 2015 4 commits
  20. 14 Aug, 2015 1 commit
    • David Ahern's avatar
      net: Introduce VRF device driver · 193125db
      David Ahern authored
      This driver borrows heavily from IPvlan and teaming drivers.
      
      Routing domains (VRF-lite) are created by instantiating a VRF master
      device with an associated table and enslaving all routed interfaces that
      participate in the domain. As part of the enslavement, all connected
      routes for the enslaved devices are moved to the table associated with
      the VRF device. Outgoing sockets must bind to the VRF device to function.
      
      Standard FIB rules bind the VRF device to tables and regular fib rule
      processing is followed. Routed traffic through the box, is forwarded by
      using the VRF device as the IIF and following the IIF rule to a table
      that is mated with the VRF.
      
      Example:
      
         Create vrf 1:
           ip link add vrf1 type vrf table 5
           ip rule add iif vrf1 table 5
           ip rule add oif vrf1 table 5
           ip route add table 5 prohibit default
           ip link set vrf1 up
      
         Add interface to vrf 1:
           ip link set eth1 master vrf1
      Signed-off-by: default avatarShrijeet Mukherjee <shm@cumulusnetworks.com>
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      193125db