1. 20 Aug, 2015 11 commits
    • Johannes Berg's avatar
      ath5k: use DECLARE_EWMA · 46f26ddf
      Johannes Berg authored
      This reduces code size slightly (at least on x86/64) while also
      removing memory consumption by two unsigned long values for each
      ath5k device.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46f26ddf
    • Johannes Berg's avatar
      virtio_net: use DECLARE_EWMA · 5377d758
      Johannes Berg authored
      Instead of using the out-of-line EWMA calculation, use DECLARE_EWMA()
      to create static inlines. On x86/64 this results in no change in code
      size for me, but reduces the struct receive_queue size by the two
      unsigned long values that store the parameters.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5377d758
    • Yuval Mintz's avatar
      bnx2x: Fix vxlan endianity issue · 0f8f27de
      Yuval Mintz authored
      Commit f34fa14c ("bnx2x: Add vxlan RSS support") has introduced an
      endianity issue when passing the vxlan UDP port to the HW.
      
      Reported-by: <fengguang.wu@intel.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f8f27de
    • David S. Miller's avatar
      Merge branch 'vrf-cleanups-part-2' · b86d598d
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      vrf: cleanups part 2
      
      This is the next part of vrf cleanups, patch 1 drops the SLAB_PANIC
      when creating kmem cache since it's handled, patch 02 removes a slave
      duplicate check which is already done by the lower/upper code, patch 3
      moves the ndo_add_slave code around a bit so we can drop an error
      label and patch 4 drops the master device checks which are unnecessary
      because the ops are taken from the master device itself so it can't be
      different.
      ====================
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      b86d598d
    • Nikolay Aleksandrov's avatar
      vrf: ndo_add|del_slave drop unnecessary checks · 2640b39c
      Nikolay Aleksandrov authored
      When ndo_add|del_slave ops are used, they're taken from the respective
      master device's netdev ops, so if the master device is a VRF only then
      the VRF ops will get called thus no need to check the type of the
      master.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2640b39c
    • Nikolay Aleksandrov's avatar
      vrf: move vrf_insert_slave so we can drop a goto label · 15df5e71
      Nikolay Aleksandrov authored
      We can simplify do_vrf_add_slave by moving vrf_insert_slave in the end
      of the enslaving and thus eliminate an error goto label. It always
      succeeds and isn't needed before that anyway.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15df5e71
    • Nikolay Aleksandrov's avatar
      vrf: remove unnecessary duplicate check · 67f3a90b
      Nikolay Aleksandrov authored
      The upper/lower functions already check for duplicate slaves so no need
      to do it again.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67f3a90b
    • Nikolay Aleksandrov's avatar
      vrf: don't panic on cache create failure · e367da02
      Nikolay Aleksandrov authored
      It's pointless to panic on cache create failure when that case is handled
      and even more so since it's not a kernel-wide fatal problem so don't
      panic.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e367da02
    • Nikolay Aleksandrov's avatar
      vrf: plug skb leaks · 57b8efa1
      Nikolay Aleksandrov authored
      Currently whenever a packet different from ETH_P_IP is sent through the
      VRF device it is leaked so plug the leaks and properly drop these
      packets.
      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>
      57b8efa1
    • Nikolay Aleksandrov's avatar
      vrf: vrf_master_ifindex_rcu is not always called with rcu read lock · 18041e31
      Nikolay Aleksandrov authored
      While running net-next I hit this:
      [  634.073119] ===============================
      [  634.073150] [ INFO: suspicious RCU usage. ]
      [  634.073182] 4.2.0-rc6+ #45 Not tainted
      [  634.073213] -------------------------------
      [  634.073244] include/net/vrf.h:38 suspicious rcu_dereference_check()
      usage!
      [  634.073274]
                     other info that might help us debug this:
      
      [  634.073307]
                     rcu_scheduler_active = 1, debug_locks = 1
      [  634.073338] 2 locks held by swapper/0/0:
      [  634.073369]  #0:  (((&n->timer))){+.-...}, at: [<ffffffff8112bc35>]
      call_timer_fn+0x5/0x480
      [  634.073412]  #1:  (slock-AF_INET){+.-...}, at: [<ffffffff8174f0f5>]
      icmp_send+0x155/0x5f0
      [  634.073450]
                     stack backtrace:
      [  634.073483] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6+ #45
      [  634.073514] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
      VirtualBox 12/01/2006
      [  634.073545]  0000000000000000 0593ba8242d9ace4 ffff88002fc03b48
      ffffffff81803f1b
      [  634.073612]  0000000000000000 ffffffff81e12500 ffff88002fc03b78
      ffffffff811003c5
      [  634.073642]  0000000000000000 ffff88002ec4e600 ffffffff81f00f80
      ffff88002fc03cf0
      [  634.073669] Call Trace:
      [  634.073694]  <IRQ>  [<ffffffff81803f1b>] dump_stack+0x4c/0x65
      [  634.073728]  [<ffffffff811003c5>] lockdep_rcu_suspicious+0xc5/0x100
      [  634.073763]  [<ffffffff8174eb56>] icmp_route_lookup+0x176/0x5c0
      [  634.073793]  [<ffffffff8174f2fb>] ? icmp_send+0x35b/0x5f0
      [  634.073818]  [<ffffffff8174f274>] ? icmp_send+0x2d4/0x5f0
      [  634.073844]  [<ffffffff8174f3ce>] icmp_send+0x42e/0x5f0
      [  634.073873]  [<ffffffff8170b662>] ipv4_link_failure+0x22/0xa0
      [  634.073899]  [<ffffffff8174bdda>] arp_error_report+0x3a/0x80
      [  634.073926]  [<ffffffff816d6100>] ? neigh_lookup+0x2c0/0x2c0
      [  634.073952]  [<ffffffff816d396e>] neigh_invalidate+0x8e/0x110
      [  634.073984]  [<ffffffff816d62ae>] neigh_timer_handler+0x1ae/0x290
      [  634.074013]  [<ffffffff816d6100>] ? neigh_lookup+0x2c0/0x2c0
      [  634.074013]  [<ffffffff8112bce3>] call_timer_fn+0xb3/0x480
      [  634.074013]  [<ffffffff8112bc35>] ? call_timer_fn+0x5/0x480
      [  634.074013]  [<ffffffff816d6100>] ? neigh_lookup+0x2c0/0x2c0
      [  634.074013]  [<ffffffff8112c2bc>] run_timer_softirq+0x20c/0x430
      [  634.074013]  [<ffffffff810af50e>] __do_softirq+0xde/0x630
      [  634.074013]  [<ffffffff810afc97>] irq_exit+0x117/0x120
      [  634.074013]  [<ffffffff81810976>] smp_apic_timer_interrupt+0x46/0x60
      [  634.074013]  [<ffffffff8180e950>] apic_timer_interrupt+0x70/0x80
      [  634.074013]  <EOI>  [<ffffffff8106b9d6>] ? native_safe_halt+0x6/0x10
      [  634.074013]  [<ffffffff81101d8d>] ? trace_hardirqs_on+0xd/0x10
      [  634.074013]  [<ffffffff81027d43>] default_idle+0x23/0x200
      [  634.074013]  [<ffffffff8102852f>] arch_cpu_idle+0xf/0x20
      [  634.074013]  [<ffffffff810f89ba>] default_idle_call+0x2a/0x40
      [  634.074013]  [<ffffffff810f8dcc>] cpu_startup_entry+0x39c/0x4c0
      [  634.074013]  [<ffffffff817f9cad>] rest_init+0x13d/0x150
      [  634.074013]  [<ffffffff81f69038>] start_kernel+0x4a8/0x4c9
      [  634.074013]  [<ffffffff81f68120>] ?
      early_idt_handler_array+0x120/0x120
      [  634.074013]  [<ffffffff81f68339>] x86_64_start_reservations+0x2a/0x2c
      [  634.074013]  [<ffffffff81f68485>] x86_64_start_kernel+0x14a/0x16d
      
      It would seem vrf_master_ifindex_rcu() can be called without RCU held in
      other contexts as well so introduce a new helper which acquires rcu and
      returns the ifindex.
      Also add curly braces around both the "if" and "else" parts as per the
      style guide.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18041e31
    • Ying Xue's avatar
      lwtunnel: Fix the sparse warnings in fib_encap_match · 824e7383
      Ying Xue authored
      When CONFIG_LWTUNNEL config is not enabled, the lwtstate_free() is not
      declared in lwtunnel.h at all. However, even in this case, the function
      is still referenced in fib_semantics.c so that there appears the
      following sparse warnings:
      
      net/ipv4/fib_semantics.c:553:17: error: undefined identifier 'lwtstate_free'
        CC      net/ipv4/fib_semantics.o
        net/ipv4/fib_semantics.c: In function ‘fib_encap_match’:
        net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function ‘lwtstate_free’ [-Werror=implicit-function-declaration]
        cc1: some warnings being treated as errors
        make[1]: *** [net/ipv4/fib_semantics.o] Error 1
        make: *** [net/ipv4/fib_semantics.o] Error 2
      
      To eliminate the error, we define an empty function for lwtstate_free()
      in lwtunnel.h when CONFIG_LWTUNNEL is disabled.
      
      Fixes: df383e62 ("lwtunnel: fix memory leak")
      Cc: Jiri Benc <jbenc@redhat.com>
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      824e7383
  2. 19 Aug, 2015 10 commits
  3. 18 Aug, 2015 19 commits