1. 01 9月, 2009 1 次提交
  2. 29 8月, 2009 15 次提交
  3. 08 6月, 2009 1 次提交
  4. 26 5月, 2009 1 次提交
    • E
      net: txq_trans_update() helper · 08baf561
      Eric Dumazet 提交于
      We would like to get rid of netdev->trans_start = jiffies; that about all net
      drivers have to use in their start_xmit() function, and use txq->trans_start
      instead.
      
      This can be done generically in core network, as suggested by David.
      
      Some devices, (particularly loopback) dont need trans_start update, because
      they dont have transmit watchdog. We could add a new device flag, or rely
      on fact that txq->tran_start can be updated is txq->xmit_lock_owner is
      different than -1. Use a helper function to hide our choice.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08baf561
  5. 22 5月, 2009 1 次提交
  6. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  7. 27 2月, 2009 1 次提交
  8. 26 11月, 2008 1 次提交
  9. 21 11月, 2008 1 次提交
  10. 20 11月, 2008 1 次提交
  11. 11 11月, 2008 1 次提交
  12. 29 10月, 2008 1 次提交
  13. 28 10月, 2008 1 次提交
  14. 14 10月, 2008 1 次提交
  15. 14 8月, 2008 1 次提交
    • A
      pktgen: prevent pktgen from using bad tx queue · 64c00d81
      Andrew Gallatin 提交于
      With the new multi-queue transmit code, it is possible to accidentally
      make pktgen pick a non-existing tx queue simply by using a stale
      script to drive pktgen.  Access to this non-existing tx queue will
      then trigger a bad memory access and kill the machine.
      
      For example, setting "queue_map_max 2" will cause my machine to die
      when accessing a garbage spinlock in the non-existing tx queue:
      
      BUG: spinlock bad magic on CPU#0, kpktgend_0/564
        lock: ffff88001ddf6718, .magic: ffffffff, .owner: /-1, .owner_cpu: 0
      Pid: 564, comm: kpktgend_0 Not tainted 2.6.27-rc3 #35
      
      Call Trace:
        [<ffffffff803a1228>] spin_bug+0xa4/0xac
        [<ffffffff803a1253>] _raw_spin_lock+0x23/0x123
        [<ffffffff8055b06f>] _spin_lock_bh+0x17/0x1b
        [<ffffffff804cb57d>] pktgen_thread_worker+0xa97/0x1002
        [<ffffffff8022874d>] ? finish_task_switch+0x38/0x97
        [<ffffffff80242077>] ? autoremove_wake_function+0x0/0x36
        [<ffffffff80242077>] ? autoremove_wake_function+0x0/0x36
        [<ffffffff804caae6>] ? pktgen_thread_worker+0x0/0x1002
        [<ffffffff80241a40>] kthread+0x44/0x6d
        [<ffffffff8020c399>] child_rip+0xa/0x11
        [<ffffffff802419fc>] ? kthread+0x0/0x6d
        [<ffffffff8020c38f>] ? child_rip+0x0/0x11
      
      The attached patch adds some sanity checking to prevent
      these sorts of configuration errors.
      Signed-off-by: NAndrew Gallatin <gallatin@myri.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64c00d81
  16. 07 8月, 2008 1 次提交
    • R
      pktgen: multiqueue etc. · e6fce5b9
      Robert Olsson 提交于
      Sofar far pktgen have had a restriction to only use one device per kernel 
      thread. With the new multiqueue architecture this is no longer adequate.
      
      The patch below is an effort to remove this by in pktgen configuration 
      adding a tag to  the device name a la eth0@0 etc. The tag is used for 
      usual device config just as before. Also a new flag is introduced to mirror 
      queue_map with sending threads smp_processor_id() QUEUE_MAP_CPU.
      
      An example: We use 4 CPU's to send to one 10g interface (eth0)
       and we use the new tagging to send a mix of packet sizes, 64, 576 and
       1500 bytes. Also we use TX queues according to smp_processor_id()
      
       PGDEV=/proc/net/pktgen/kpktgend_0
       pgset "add_device eth0@0" 
      
       PGDEV=/proc/net/pktgen/kpktgend_1
       pgset "add_device eth0@1" 
      
       PGDEV=/proc/net/pktgen/kpktgend_2
       pgset "add_device eth0@2" 
      
       PGDEV=/proc/net/pktgen/kpktgend_3
       pgset "add_device eth0@3" 
      ....
      PGDEV=/proc/net/pktgen/eth0@0 
      pgset "pkt_size 64"
      pgset "flag QUEUE_MAP_CPU"
      
      PGDEV=/proc/net/pktgen/eth0@1
      pgset "pkt_size 572"
      pgset "flag QUEUE_MAP_CPU"
      
      PGDEV=/proc/net/pktgen/eth0@2
      pgset "pkt_size 1496"
      
      PGDEV=/proc/net/pktgen/eth0@3
      pgset "pkt_size 1496"
      pgset "flag QUEUE_MAP_CPU"
      Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6fce5b9
  17. 06 8月, 2008 2 次提交
  18. 01 8月, 2008 1 次提交
  19. 20 7月, 2008 1 次提交
  20. 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
  21. 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
  22. 02 5月, 2008 1 次提交
  23. 26 3月, 2008 1 次提交
  24. 29 2月, 2008 1 次提交
  25. 01 2月, 2008 1 次提交