1. 24 10月, 2009 1 次提交
  2. 05 10月, 2009 2 次提交
  3. 02 10月, 2009 1 次提交
  4. 25 9月, 2009 2 次提交
  5. 01 9月, 2009 1 次提交
  6. 29 8月, 2009 15 次提交
  7. 08 6月, 2009 1 次提交
  8. 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
  9. 22 5月, 2009 1 次提交
  10. 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
  11. 27 2月, 2009 1 次提交
  12. 26 11月, 2008 1 次提交
  13. 21 11月, 2008 1 次提交
  14. 20 11月, 2008 1 次提交
  15. 11 11月, 2008 1 次提交
  16. 29 10月, 2008 1 次提交
  17. 28 10月, 2008 1 次提交
  18. 14 10月, 2008 1 次提交
  19. 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
  20. 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
  21. 06 8月, 2008 2 次提交
  22. 01 8月, 2008 1 次提交
  23. 20 7月, 2008 1 次提交