1. 06 8月, 2008 1 次提交
  2. 01 8月, 2008 1 次提交
  3. 20 7月, 2008 1 次提交
  4. 18 7月, 2008 1 次提交
    • D
      net: Use queue aware tests throughout. · fd2ea0a7
      David S. Miller 提交于
      This effectively "flips the switch" by making the core networking
      and multiqueue-aware drivers use the new TX multiqueue structures.
      
      Non-multiqueue drivers need no changes.  The interfaces they use such
      as netif_stop_queue() degenerate into an operation on TX queue zero.
      So everything "just works" for them.
      
      Code that really wants to do "X" to all TX queues now invokes a
      routine that does so, such as netif_tx_wake_all_queues(),
      netif_tx_stop_all_queues(), etc.
      
      pktgen and netpoll required a little bit more surgery than the others.
      
      In particular the pktgen changes, whilst functional, could be largely
      improved.  The initial check in pktgen_xmit() will sometimes check the
      wrong queue, which is mostly harmless.  The thing to do is probably to
      invoke fill_packet() earlier.
      
      The bulk of the netpoll changes is to make the code operate solely on
      the TX queue indicated by by the SKB queue mapping.
      
      Setting of the SKB queue mapping is entirely confined inside of
      net/core/dev.c:dev_pick_tx().  If we end up needing any kind of
      special semantics (drops, for example) it will be implemented here.
      
      Finally, we now have a "real_num_tx_queues" which is where the driver
      indicates how many TX queues are actually active.
      
      With IGB changes from Jeff Kirsher.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd2ea0a7
  5. 21 5月, 2008 1 次提交
    • D
      pktgen: make sure that pktgen_thread_worker has been executed · d3ede327
      Denis V. Lunev 提交于
      The following courruption can happen during pktgen stop:
      list_del corruption. prev->next should be ffff81007e8a5e70, but was 6b6b6b6b6b6b6b6b
      kernel BUG at lib/list_debug.c:67!
            :pktgen:pktgen_thread_worker+0x374/0x10b0
            ? autoremove_wake_function+0x0/0x40
            ? _spin_unlock_irqrestore+0x42/0x80
            ? :pktgen:pktgen_thread_worker+0x0/0x10b0
            kthread+0x4d/0x80
            child_rip+0xa/0x12
            ? restore_args+0x0/0x30
            ? kthread+0x0/0x80
            ? child_rip+0x0/0x12
      RIP  list_del+0x48/0x70
      
      The problem is that pktgen_thread_worker can not be executed if kthread_stop
      has been called too early. Insert a completion on the normal initialization
      path to make sure that pktgen_thread_worker will gain the control for sure.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Acked-by: NAlexey Dobriyan <adobriyan@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d3ede327
  6. 02 5月, 2008 1 次提交
  7. 26 3月, 2008 1 次提交
  8. 29 2月, 2008 1 次提交
  9. 01 2月, 2008 2 次提交
  10. 29 1月, 2008 4 次提交
  11. 20 11月, 2007 1 次提交
  12. 22 10月, 2007 2 次提交
  13. 20 10月, 2007 3 次提交
  14. 18 10月, 2007 1 次提交
    • H
      [IPSEC]: Rename mode to outer_mode and add inner_mode · 13996378
      Herbert Xu 提交于
      This patch adds a new field to xfrm states called inner_mode.  The existing
      mode object is renamed to outer_mode.
      
      This is the first part of an attempt to fix inter-family transforms.  As it
      is we always use the outer family when determining which mode to use.  As a
      result we may end up shoving IPv4 packets into netfilter6 and vice versa.
      
      What we really want is to use the inner family for the first part of outbound
      processing and the outer family for the second part.  For inbound processing
      we'd use the opposite pairing.
      
      I've also added a check to prevent silly combinations such as transport mode
      with inter-family transforms.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13996378
  15. 11 10月, 2007 7 次提交
  16. 17 9月, 2007 1 次提交
  17. 31 8月, 2007 1 次提交
  18. 29 8月, 2007 1 次提交
  19. 31 7月, 2007 2 次提交
  20. 18 7月, 2007 1 次提交
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  21. 11 7月, 2007 4 次提交
  22. 09 5月, 2007 1 次提交
  23. 26 4月, 2007 1 次提交