1. 19 1月, 2017 1 次提交
  2. 26 9月, 2016 1 次提交
    • N
      ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route · 2cf75070
      Nikolay Aleksandrov 提交于
      Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
      instead of the previous dst_pid which was copied from in_skb's portid.
      Since the skb is new the portid is 0 at that point so the packets are sent
      to the kernel and we get scheduling while atomic or a deadlock (depending
      on where it happens) by trying to acquire rtnl two times.
      Also since this is RTM_GETROUTE, it can be triggered by a normal user.
      
      Here's the sleeping while atomic trace:
      [ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
      [ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
      [ 7858.212881] 2 locks held by swapper/0/0:
      [ 7858.213013]  #0:  (((&mrt->ipmr_expire_timer))){+.-...}, at: [<ffffffff810fbbf5>] call_timer_fn+0x5/0x350
      [ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [<ffffffff8161e005>] ipmr_expire_process+0x25/0x130
      [ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179
      [ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [ 7858.214108]  0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000
      [ 7858.214412]  ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e
      [ 7858.214716]  000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f
      [ 7858.215251] Call Trace:
      [ 7858.215412]  <IRQ>  [<ffffffff813a7804>] dump_stack+0x85/0xc1
      [ 7858.215662]  [<ffffffff810a4a72>] ___might_sleep+0x192/0x250
      [ 7858.215868]  [<ffffffff810a4b9f>] __might_sleep+0x6f/0x100
      [ 7858.216072]  [<ffffffff8165bea3>] mutex_lock_nested+0x33/0x4d0
      [ 7858.216279]  [<ffffffff815a7a5f>] ? netlink_lookup+0x25f/0x460
      [ 7858.216487]  [<ffffffff8157474b>] rtnetlink_rcv+0x1b/0x40
      [ 7858.216687]  [<ffffffff815a9a0c>] netlink_unicast+0x19c/0x260
      [ 7858.216900]  [<ffffffff81573c70>] rtnl_unicast+0x20/0x30
      [ 7858.217128]  [<ffffffff8161cd39>] ipmr_destroy_unres+0xa9/0xf0
      [ 7858.217351]  [<ffffffff8161e06f>] ipmr_expire_process+0x8f/0x130
      [ 7858.217581]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.217785]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.217990]  [<ffffffff810fbc95>] call_timer_fn+0xa5/0x350
      [ 7858.218192]  [<ffffffff810fbbf5>] ? call_timer_fn+0x5/0x350
      [ 7858.218415]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.218656]  [<ffffffff810fde10>] run_timer_softirq+0x260/0x640
      [ 7858.218865]  [<ffffffff8166379b>] ? __do_softirq+0xbb/0x54f
      [ 7858.219068]  [<ffffffff816637c8>] __do_softirq+0xe8/0x54f
      [ 7858.219269]  [<ffffffff8107a948>] irq_exit+0xb8/0xc0
      [ 7858.219463]  [<ffffffff81663452>] smp_apic_timer_interrupt+0x42/0x50
      [ 7858.219678]  [<ffffffff816625bc>] apic_timer_interrupt+0x8c/0xa0
      [ 7858.219897]  <EOI>  [<ffffffff81055f16>] ? native_safe_halt+0x6/0x10
      [ 7858.220165]  [<ffffffff810d64dd>] ? trace_hardirqs_on+0xd/0x10
      [ 7858.220373]  [<ffffffff810298e3>] default_idle+0x23/0x190
      [ 7858.220574]  [<ffffffff8102a20f>] arch_cpu_idle+0xf/0x20
      [ 7858.220790]  [<ffffffff810c9f8c>] default_idle_call+0x4c/0x60
      [ 7858.221016]  [<ffffffff810ca33b>] cpu_startup_entry+0x39b/0x4d0
      [ 7858.221257]  [<ffffffff8164f995>] rest_init+0x135/0x140
      [ 7858.221469]  [<ffffffff81f83014>] start_kernel+0x50e/0x51b
      [ 7858.221670]  [<ffffffff81f82120>] ? early_idt_handler_array+0x120/0x120
      [ 7858.221894]  [<ffffffff81f8243f>] x86_64_start_reservations+0x2a/0x2c
      [ 7858.222113]  [<ffffffff81f8257c>] x86_64_start_kernel+0x13b/0x14a
      
      Fixes: 2942e900 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cf75070
  3. 17 7月, 2016 1 次提交
    • N
      net: ipmr/ip6mr: add support for keeping an entry age · 43b9e127
      Nikolay Aleksandrov 提交于
      In preparation for hardware offloading of ipmr/ip6mr we need an
      interface that allows to check (and later update) the age of entries.
      Relying on stats alone can show activity but not actual age of the entry,
      furthermore when there're tens of thousands of entries a lot of the
      hardware implementations only support "hit" bits which are cleared on
      read to denote that the entry was active and shouldn't be aged out,
      these can then be naturally translated into age timestamp and will be
      compatible with the software forwarding age. Using a lastuse entry doesn't
      affect performance because the members in that cache line are written to
      along with the age.
      Since all new users are encouraged to use ipmr via netlink, this is
      exported via the RTA_EXPIRES attribute.
      Also do a minor local variable declaration style adjustment - arrange them
      longest to shortest.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      CC: Shrijeet Mukherjee <shm@cumulusnetworks.com>
      CC: Satish Ashok <sashok@cumulusnetworks.com>
      CC: Donald Sharp <sharpd@cumulusnetworks.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      CC: James Morris <jmorris@namei.org>
      CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      CC: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43b9e127
  4. 22 1月, 2013 1 次提交
  5. 13 10月, 2012 1 次提交
  6. 13 12月, 2011 1 次提交
  7. 31 3月, 2011 1 次提交
  8. 04 2月, 2011 1 次提交
  9. 11 5月, 2010 4 次提交
    • P
      ipv6: ip6mr: support multiple tables · d1db275d
      Patrick McHardy 提交于
      This patch adds support for multiple independant multicast routing instances,
      named "tables".
      
      Userspace multicast routing daemons can bind to a specific table instance by
      issuing a setsockopt call using a new option MRT6_TABLE. The table number is
      stored in the raw socket data and affects all following ip6mr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
      is created with a default routing rule pointing to it. Newly created pim6reg
      devices have the table number appended ("pim6regX"), with the exception of
      devices created in the default table, which are named just "pim6reg" for
      compatibility reasons.
      
      Packets are directed to a specific table instance using routing rules,
      similar to how regular routing rules work. Currently iif, oif and mark
      are supported as keys, source and destination addresses could be supported
      additionally.
      
      Example usage:
      
      - bind pimd/xorp/... to a specific table:
      
      uint32_t table = 123;
      setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip -6 mrule add iif eth0 lookup 123
      # ip -6 mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d1db275d
    • P
      6bd52143
    • P
      f30a7784
    • P
      ipv6: ip6mr: remove net pointer from struct mfc6_cache · b5aa30b1
      Patrick McHardy 提交于
      Now that cache entries in unres_queue don't need to be distinguished by their
      network namespace pointer anymore, we can remove it from struct mfc6_cache
      add pass the namespace as function argument to the functions that need it.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      b5aa30b1
  10. 05 11月, 2009 1 次提交
  11. 01 10月, 2009 1 次提交
  12. 27 3月, 2009 1 次提交
    • A
      make exported headers use strict posix types · 85efde6f
      Arnd Bergmann 提交于
      A number of standard posix types are used in exported headers, which
      is not allowed if __STRICT_KERNEL_NAMES is defined. In order to
      get rid of the non-__STRICT_KERNEL_NAMES part and to make sane headers
      the default, we have to change them all to safe types.
      
      There are also still some leftovers in reiserfs_fs.h, elfcore.h
      and coda.h, but these files have not compiled in user space for
      a long time.
      
      This leaves out the various integer types ({u_,u,}int{8,16,32,64}_t),
      which we take care of separately.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Cc: netdev@vger.kernel.org
      Cc: linux-ppp@vger.kernel.org
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      85efde6f
  13. 11 12月, 2008 3 次提交
    • B
      netns: ip6mr: enable namespace support in ipv6 multicast forwarding code · 8229efda
      Benjamin Thery 提交于
      This last patch makes the appropriate changes to use and propagate the
      network namespace where needed in IPv6 multicast forwarding code.
      
      This consists mainly in replacing all the remaining init_net occurences
      with current netns pointer retrieved from sockets, net devices or 
      mfc6_caches depending on the routines' contexts.
      
      Some routines receive a new 'struct net' parameter to propagate the current
      netns:
      * ip6mr_get_route
      * ip6mr_cache_report
      * ip6mr_cache_find
      * ip6mr_cache_unresolved
      * mif6_add/mif6_delete
      * ip6mr_mfc_add/ip6mr_mfc_delete
      * ip6mr_reg_vif
      
      All the IPv6 multicast forwarding variables moved to struct netns_ipv6 by
      the previous patches are now referenced in the correct namespace.
      
      Changelog:
      ==========
      * Take into account the net associated to mfc6_cache when matching entries in
        mfc_unres_queue list.
      * Call mroute_clean_tables() in ip6mr_net_exit() to free memory allocated
        per-namespace.
      * Call dev_net_set() in ip6mr_reg_vif() to initialize dev->nd_net 
        correctly.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8229efda
    • B
      netns: ip6mr: store netns in struct mfc6_cache · 58701ad4
      Benjamin Thery 提交于
      This patch stores into struct mfc6_cache the network namespace each
      mfc6_cache belongs to. The new member is mfc6_net.
      
      mfc6_net is assigned at cache allocation and doesn't change during
      the rest of the cache entry life.
      
      This will help to retrieve the current netns around the IPv6 multicast
      forwarding code.
      
      At the moment, all mfc6_cache are allocated in init_net.
      
      Changelog:
      ==========
      * Use write_pnet()/read_pnet() to set and get mfc6_net.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58701ad4
    • B
      netns: ip6mr: allocate mroute6_socket per-namespace. · bd91b8bf
      Benjamin Thery 提交于
      Preliminary work to make IPv6 multicast forwarding netns-aware.
      
      Make IPv6 multicast forwarding mroute6_socket per-namespace,
      moves it into struct netns_ipv6.
      
      At the moment, mroute6_socket is only referenced in init_net.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd91b8bf
  14. 30 8月, 2008 1 次提交
    • D
      net: Unbreak userspace usage of linux/mroute.h · 7c19a3d2
      David S. Miller 提交于
      Nothing in linux/pim.h should be exported to userspace.
      
      This should fix the XORP build failure reported by
      Jose Calhariz, the debain package maintainer.
      
      Nothing originally in linux/mroute.h was exported to userspace
      ever, but some of this stuff started to be when it was moved into
      this new linux/pim.h, and that was wrong.  If we didn't provide these
      definitions for 10 years we can reasonably expect that applications
      defined this stuff locally or used GLIBC headers providing the
      protocol definitions.  And as such the only result of this can
      be conflict and userland build breakage.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c19a3d2
  15. 03 7月, 2008 2 次提交
  16. 14 4月, 2008 1 次提交
  17. 05 4月, 2008 2 次提交