1. 20 5月, 2014 1 次提交
  2. 19 5月, 2014 4 次提交
  3. 15 5月, 2014 4 次提交
  4. 13 5月, 2014 1 次提交
  5. 09 5月, 2014 1 次提交
  6. 08 5月, 2014 1 次提交
  7. 06 5月, 2014 2 次提交
    • M
      cfg80211: export interface stopping function · f04c2203
      Michal Kazior 提交于
      This exports a new cfg80211_stop_iface() function.
      
      This is intended for driver internal interface
      combination management and channel switching.
      
      Due to locking issues (it re-enters driver) the
      call is asynchronous and uses cfg80211 event
      list/worker.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f04c2203
    • M
      mac80211: fix CSA tx queue stopping · 59af6928
      Michal Kazior 提交于
      It was possible for tx queues to be stuck stopped
      if AP CSA finalization failed. In that case
      neither stop_ap nor do_stop woke the queues up.
      This means it was impossible to perform tx at all
      until driver was reloaded or a successful CSA was
      performed later.
      
      It was possible to solve this in a simpler manner
      however this is more robust and future proof
      (having multi-vif CSA in mind).
      
      New sdata->csa_block_tx is introduced to keep
      track of which interfaces requested tx to be
      blocked for CSA. This is required because mac80211
      stops all tx queues for that purpose. This means
      queues must be awoken only when last tx-blocking
      CSA interface is finished.
      
      It is still possible to have tx queues stopped
      after CSA failure but as soon as offending
      interfaces are stopped from userspace (stop_ap or
      ifdown) tx queues are woken up properly.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      59af6928
  8. 05 5月, 2014 1 次提交
  9. 29 4月, 2014 1 次提交
  10. 25 4月, 2014 3 次提交
  11. 09 4月, 2014 10 次提交
  12. 02 4月, 2014 1 次提交
  13. 01 4月, 2014 1 次提交
  14. 31 3月, 2014 1 次提交
    • D
      net: filter: move filter accounting to filter core · fbc907f0
      Daniel Borkmann 提交于
      This patch basically does two things, i) removes the extern keyword
      from the include/linux/filter.h file to be more consistent with the
      rest of Joe's changes, and ii) moves filter accounting into the filter
      core framework.
      
      Filter accounting mainly done through sk_filter_{un,}charge() take
      care of the case when sockets are being cloned through sk_clone_lock()
      so that removal of the filter on one socket won't result in eviction
      as it's still referenced by the other.
      
      These functions actually belong to net/core/filter.c and not
      include/net/sock.h as we want to keep all that in a central place.
      It's also not in fast-path so uninlining them is fine and even allows
      us to get rd of sk_filter_release_rcu()'s EXPORT_SYMBOL and a forward
      declaration.
      
      Joint work with Alexei Starovoitov.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbc907f0
  15. 29 3月, 2014 1 次提交
    • H
      ipv6: move DAD and addrconf_verify processing to workqueue · c15b1cca
      Hannes Frederic Sowa 提交于
      addrconf_join_solict and addrconf_join_anycast may cause actions which
      need rtnl locked, especially on first address creation.
      
      A new DAD state is introduced which defers processing of the initial
      DAD processing into a workqueue.
      
      To get rtnl lock we need to push the code paths which depend on those
      calls up to workqueues, specifically addrconf_verify and the DAD
      processing.
      
      (v2)
      addrconf_dad_failure needs to be queued up to the workqueue, too. This
      patch introduces a new DAD state and stop the DAD processing in the
      workqueue (this is because of the possible ipv6_del_addr processing
      which removes the solicited multicast address from the device).
      
      addrconf_verify_lock is removed, too. After the transition it is not
      needed any more.
      
      As we are not processing in bottom half anymore we need to be a bit more
      careful about disabling bottom half out when we lock spin_locks which are also
      used in bh.
      
      Relevant backtrace:
      [  541.030090] RTNL: assertion failed at net/core/dev.c (4496)
      [  541.031143] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O 3.10.33-1-amd64-vyatta #1
      [  541.031145] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  541.031146]  ffffffff8148a9f0 000000000000002f ffffffff813c98c1 ffff88007c4451f8
      [  541.031148]  0000000000000000 0000000000000000 ffffffff813d3540 ffff88007fc03d18
      [  541.031150]  0000880000000006 ffff88007c445000 ffffffffa0194160 0000000000000000
      [  541.031152] Call Trace:
      [  541.031153]  <IRQ>  [<ffffffff8148a9f0>] ? dump_stack+0xd/0x17
      [  541.031180]  [<ffffffff813c98c1>] ? __dev_set_promiscuity+0x101/0x180
      [  541.031183]  [<ffffffff813d3540>] ? __hw_addr_create_ex+0x60/0xc0
      [  541.031185]  [<ffffffff813cfe1a>] ? __dev_set_rx_mode+0xaa/0xc0
      [  541.031189]  [<ffffffff813d3a81>] ? __dev_mc_add+0x61/0x90
      [  541.031198]  [<ffffffffa01dcf9c>] ? igmp6_group_added+0xfc/0x1a0 [ipv6]
      [  541.031208]  [<ffffffff8111237b>] ? kmem_cache_alloc+0xcb/0xd0
      [  541.031212]  [<ffffffffa01ddcd7>] ? ipv6_dev_mc_inc+0x267/0x300 [ipv6]
      [  541.031216]  [<ffffffffa01c2fae>] ? addrconf_join_solict+0x2e/0x40 [ipv6]
      [  541.031219]  [<ffffffffa01ba2e9>] ? ipv6_dev_ac_inc+0x159/0x1f0 [ipv6]
      [  541.031223]  [<ffffffffa01c0772>] ? addrconf_join_anycast+0x92/0xa0 [ipv6]
      [  541.031226]  [<ffffffffa01c311e>] ? __ipv6_ifa_notify+0x11e/0x1e0 [ipv6]
      [  541.031229]  [<ffffffffa01c3213>] ? ipv6_ifa_notify+0x33/0x50 [ipv6]
      [  541.031233]  [<ffffffffa01c36c8>] ? addrconf_dad_completed+0x28/0x100 [ipv6]
      [  541.031241]  [<ffffffff81075c1d>] ? task_cputime+0x2d/0x50
      [  541.031244]  [<ffffffffa01c38d6>] ? addrconf_dad_timer+0x136/0x150 [ipv6]
      [  541.031247]  [<ffffffffa01c37a0>] ? addrconf_dad_completed+0x100/0x100 [ipv6]
      [  541.031255]  [<ffffffff8105313a>] ? call_timer_fn.isra.22+0x2a/0x90
      [  541.031258]  [<ffffffffa01c37a0>] ? addrconf_dad_completed+0x100/0x100 [ipv6]
      
      Hunks and backtrace stolen from a patch by Stephen Hemminger.
      Reported-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15b1cca
  16. 28 3月, 2014 1 次提交
    • M
      ipv6: do not overwrite inetpeer metrics prematurely · e5fd387a
      Michal Kubeček 提交于
      If an IPv6 host route with metrics exists, an attempt to add a
      new route for the same target with different metrics fails but
      rewrites the metrics anyway:
      
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1000
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  rto_min lock 1s
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1500
      RTNETLINK answers: File exists
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  rto_min lock 1.5s
      
      This is caused by all IPv6 host routes using the metrics in
      their inetpeer (or the shared default). This also holds for the
      new route created in ip6_route_add() which shares the metrics
      with the already existing route and thus ip6_route_add()
      rewrites the metrics even if the new route ends up not being
      used at all.
      
      Another problem is that old metrics in inetpeer can reappear
      unexpectedly for a new route, e.g.
      
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1000
      12sp0:~ # ip route del fec0::1
      12sp0:~ # ip route add fec0::1 dev eth0
      12sp0:~ # ip route change fec0::1 dev eth0 hoplimit 10
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  hoplimit 10 rto_min lock 1s
      
      Resolve the first problem by moving the setting of metrics down
      into fib6_add_rt2node() to the point we are sure we are
      inserting the new route into the tree. Second problem is
      addressed by introducing new flag DST_METRICS_FORCE_OVERWRITE
      which is set for a new host route in ip6_route_add() and makes
      ipv6_cow_metrics() always overwrite the metrics in inetpeer
      (even if they are not "new"); it is reset after that.
      
      v5: use a flag in _metrics member rather than one in flags
      
      v4: fix a typo making a condition always true (thanks to Hannes
      Frederic Sowa)
      
      v3: rewritten based on David Miller's idea to move setting the
      metrics (and allocation in non-host case) down to the point we
      already know the route is to be inserted. Also rebased to
      net-next as it is quite late in the cycle.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5fd387a
  17. 27 3月, 2014 1 次提交
  18. 25 3月, 2014 1 次提交
  19. 24 3月, 2014 1 次提交
    • E
      net: optimize csum_replace2() · 99f0b958
      Eric Dumazet 提交于
      When changing one 16bit value by another in IP header, we can adjust
      the IP checksum by doing a simple operation described in RFC 1624, as
      reminded by David.
      
      csum_partial() is a complex function on x86_64, not really suited for
      small number of checksummed bytes.
      
      I spotted csum_partial() being in the top 20 most consuming functions
      (more than 1 %) in a GRO workload, which was rather unexpected.
      
      The caller was inet_gro_complete() doing a csum_replace2() when
      building the new IP header for the GRO packet.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99f0b958
  20. 22 3月, 2014 1 次提交
  21. 21 3月, 2014 1 次提交
  22. 20 3月, 2014 1 次提交