1. 03 1月, 2014 1 次提交
    • F
      {pktgen, xfrm} Correct xfrm state lock usage when transforming · 0af0a413
      Fan Du 提交于
      xfrm_state lock protects its state, i.e., VALID/DEAD and statistics,
      not the transforming procedure, as both mode/type output functions
      are reentrant.
      
      Another issue is state lock can be used in BH context when state timer
      alarmed, after transformation in pktgen, update state statistics acquiring
      state lock should disabled BH context for a moment. Otherwise LOCKDEP
      critisize this:
      
      [   62.354339] pktgen: Packet Generator for packet performance testing. Version: 2.74
      [   62.655444]
      [   62.655448] =================================
      [   62.655451] [ INFO: inconsistent lock state ]
      [   62.655455] 3.13.0-rc2+ #70 Not tainted
      [   62.655457] ---------------------------------
      [   62.655459] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      [   62.655463] kpktgend_0/2764 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [   62.655466]  (&(&x->lock)->rlock){+.?...}, at: [<ffffffffa00886f6>] pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655479] {IN-SOFTIRQ-W} state was registered at:
      [   62.655484]   [<ffffffff8109a61d>] __lock_acquire+0x62d/0x1d70
      [   62.655492]   [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   62.655498]   [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   62.655505]   [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
      [   62.655511]   [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
      [   62.655519]   [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
      [   62.655523]   [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
      [   62.655526]   [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   62.655530]   [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
      [   62.655537]   [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
      [   62.655541]   [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
      [   62.655547]   [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
      [   62.655552]   [<ffffffff81761c3c>] rest_init+0xbc/0xd0
      [   62.655557]   [<ffffffff81ea5e5e>] start_kernel+0x3c4/0x3d1
      [   62.655583]   [<ffffffff81ea55a8>] x86_64_start_reservations+0x2a/0x2c
      [   62.655588]   [<ffffffff81ea569f>] x86_64_start_kernel+0xf5/0xfc
      [   62.655592] irq event stamp: 77
      [   62.655594] hardirqs last  enabled at (77): [<ffffffff810ab7f2>] vprintk_emit+0x1b2/0x520
      [   62.655597] hardirqs last disabled at (76): [<ffffffff810ab684>] vprintk_emit+0x44/0x520
      [   62.655601] softirqs last  enabled at (22): [<ffffffff81059b57>] __do_softirq+0x177/0x2d0
      [   62.655605] softirqs last disabled at (15): [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   62.655609]
      [   62.655609] other info that might help us debug this:
      [   62.655613]  Possible unsafe locking scenario:
      [   62.655613]
      [   62.655616]        CPU0
      [   62.655617]        ----
      [   62.655618]   lock(&(&x->lock)->rlock);
      [   62.655622]   <Interrupt>
      [   62.655623]     lock(&(&x->lock)->rlock);
      [   62.655626]
      [   62.655626]  *** DEADLOCK ***
      [   62.655626]
      [   62.655629] no locks held by kpktgend_0/2764.
      [   62.655631]
      [   62.655631] stack backtrace:
      [   62.655636] CPU: 0 PID: 2764 Comm: kpktgend_0 Not tainted 3.13.0-rc2+ #70
      [   62.655638] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
      [   62.655642]  ffffffff8216b7b0 ffff88001be43ab8 ffffffff8176af37 0000000000000007
      [   62.655652]  ffff88001c8d4fc0 ffff88001be43b18 ffffffff81766d78 0000000000000000
      [   62.655663]  ffff880000000001 ffff880000000001 ffffffff8101025f ffff88001be43b18
      [   62.655671] Call Trace:
      [   62.655680]  [<ffffffff8176af37>] dump_stack+0x46/0x58
      [   62.655685]  [<ffffffff81766d78>] print_usage_bug+0x1f1/0x202
      [   62.655691]  [<ffffffff8101025f>] ? save_stack_trace+0x2f/0x50
      [   62.655696]  [<ffffffff81099f8c>] mark_lock+0x28c/0x2f0
      [   62.655700]  [<ffffffff810994b0>] ? check_usage_forwards+0x150/0x150
      [   62.655704]  [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
      [   62.655712]  [<ffffffff81115b09>] ? irq_work_queue+0x69/0xb0
      [   62.655717]  [<ffffffff810ab7f2>] ? vprintk_emit+0x1b2/0x520
      [   62.655722]  [<ffffffff8109cec5>] ? trace_hardirqs_on_caller+0x105/0x1d0
      [   62.655730]  [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655734]  [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   62.655741]  [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655745]  [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   62.655752]  [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655758]  [<ffffffffa00886f6>] pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655766]  [<ffffffffa0087a79>] ? pktgen_thread_worker+0xb19/0x1860 [pktgen]
      [   62.655771]  [<ffffffff8109cf9d>] ? trace_hardirqs_on+0xd/0x10
      [   62.655777]  [<ffffffff81775410>] ? _raw_spin_unlock_irq+0x30/0x40
      [   62.655785]  [<ffffffff8151faa0>] ? e1000_clean+0x9d0/0x9d0
      [   62.655791]  [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
      [   62.655795]  [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
      [   62.655800]  [<ffffffffa0086f60>] ? mod_cur_headers+0x7f0/0x7f0 [pktgen]
      [   62.655806]  [<ffffffff81078f84>] kthread+0xe4/0x100
      [   62.655813]  [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
      [   62.655819]  [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
      [   62.655824]  [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      0af0a413
  2. 02 12月, 2013 1 次提交
    • F
      {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation · 3868204d
      fan.du 提交于
      commit a553e4a6 ("[PKTGEN]: IPSEC support")
      tried to support IPsec ESP transport transformation for pktgen, but acctually
      this doesn't work at all for two reasons(The orignal transformed packet has
      bad IPv4 checksum value, as well as wrong auth value, reported by wireshark)
      
      - After transpormation, IPv4 header total length needs update,
        because encrypted payload's length is NOT same as that of plain text.
      
      - After transformation, IPv4 checksum needs re-caculate because of payload
        has been changed.
      
      With this patch, armmed pktgen with below cofiguration, Wireshark is able to
      decrypted ESP packet generated by pktgen without any IPv4 checksum error or
      auth value error.
      
      pgset "flag IPSEC"
      pgset "flows 1"
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3868204d
  3. 29 7月, 2013 1 次提交
  4. 28 7月, 2013 2 次提交
  5. 12 6月, 2013 1 次提交
  6. 05 6月, 2013 1 次提交
  7. 29 5月, 2013 2 次提交
  8. 02 5月, 2013 1 次提交
  9. 30 4月, 2013 2 次提交
  10. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  11. 19 2月, 2013 1 次提交
  12. 30 1月, 2013 2 次提交
  13. 04 11月, 2012 1 次提交
  14. 22 10月, 2012 1 次提交
  15. 11 10月, 2012 5 次提交
  16. 14 9月, 2012 1 次提交
    • N
      pktgen: fix crash with vlan and packet size less than 46 · 6af773e7
      Nishank Trivedi 提交于
      If vlan option is being specified in the pktgen and packet size
      being requested is less than 46 bytes, despite being illogical
      request, pktgen should not crash the kernel.
      
      BUG: unable to handle kernel paging request at ffff88021fb82000
      Process kpktgend_0 (pid: 1184, threadinfo ffff880215f1a000, task ffff880218544530)
      Call Trace:
      [<ffffffffa0637cd2>] ? pktgen_finalize_skb+0x222/0x300 [pktgen]
      [<ffffffff814f0084>] ? build_skb+0x34/0x1c0
      [<ffffffffa0639b11>] pktgen_thread_worker+0x5d1/0x1790 [pktgen]
      [<ffffffffa03ffb10>] ? igb_xmit_frame_ring+0xa30/0xa30 [igb]
      [<ffffffff8107ba20>] ? wake_up_bit+0x40/0x40
      [<ffffffff8107ba20>] ? wake_up_bit+0x40/0x40
      [<ffffffffa0639540>] ? spin+0x240/0x240 [pktgen]
      [<ffffffff8107b4e3>] kthread+0x93/0xa0
      [<ffffffff81615de4>] kernel_thread_helper+0x4/0x10
      [<ffffffff8107b450>] ? flush_kthread_worker+0x80/0x80
      [<ffffffff81615de0>] ? gs_change+0x13/0x13
      
      The root cause of why pktgen is not able to handle this case is due
      to comparison of signed (datalen) and unsigned data (sizeof), which
      eventually passes a huge number to skb_put().
      Signed-off-by: NNishank Trivedi <nistrive@cisco.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6af773e7
  17. 19 5月, 2012 1 次提交
  18. 17 5月, 2012 1 次提交
  19. 16 5月, 2012 1 次提交
  20. 11 5月, 2012 1 次提交
    • E
      pktgen: fix crash at module unload · c57b5468
      Eric Dumazet 提交于
      commit 7d3d43da (net: In unregister_netdevice_notifier unregister
      the netdevices.) makes pktgen crashing at module unload.
      
      [  296.820578] BUG: spinlock bad magic on CPU#6, rmmod/3267
      [  296.820719]  lock: ffff880310c38000, .magic: ffff8803, .owner: <none>/-1, .owner_cpu: -1
      [  296.820943] Pid: 3267, comm: rmmod Not tainted 3.4.0-rc5+ #254
      [  296.821079] Call Trace:
      [  296.821211]  [<ffffffff8168a715>] spin_dump+0x8a/0x8f
      [  296.821345]  [<ffffffff8168a73b>] spin_bug+0x21/0x26
      [  296.821507]  [<ffffffff812b4741>] do_raw_spin_lock+0x131/0x140
      [  296.821648]  [<ffffffff8169188e>] _raw_spin_lock+0x1e/0x20
      [  296.821786]  [<ffffffffa00cc0fd>] __pktgen_NN_threads+0x4d/0x140 [pktgen]
      [  296.821928]  [<ffffffffa00ccf8d>] pktgen_device_event+0x10d/0x1e0 [pktgen]
      [  296.822073]  [<ffffffff8154ed4f>] unregister_netdevice_notifier+0x7f/0x100
      [  296.822216]  [<ffffffffa00d2a0b>] pg_cleanup+0x48/0x73 [pktgen]
      [  296.822357]  [<ffffffff8109528e>] sys_delete_module+0x17e/0x2a0
      [  296.822502]  [<ffffffff81699652>] system_call_fastpath+0x16/0x1b
      
      Hold the pktgen_thread_lock while splicing pktgen_threads, and test
      pktgen_exiting in pktgen_device_event() to make unload faster.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c57b5468
  21. 16 4月, 2012 1 次提交
  22. 23 1月, 2012 1 次提交
  23. 08 1月, 2012 1 次提交
  24. 30 11月, 2011 1 次提交
  25. 23 11月, 2011 1 次提交
  26. 21 10月, 2011 1 次提交
  27. 20 10月, 2011 1 次提交
  28. 19 10月, 2011 1 次提交
  29. 25 8月, 2011 1 次提交
  30. 28 7月, 2011 1 次提交
    • N
      net: add IFF_SKB_TX_SHARED flag to priv_flags · d8873315
      Neil Horman 提交于
      Pktgen attempts to transmit shared skbs to net devices, which can't be used by
      some drivers as they keep state information in skbs.  This patch adds a flag
      marking drivers as being able to handle shared skbs in their tx path.  Drivers
      are defaulted to being unable to do so, but calling ether_setup enables this
      flag, as 90% of the drivers calling ether_setup touch real hardware and can
      handle shared skbs.  A subsequent patch will audit drivers to ensure that the
      flag is set properly
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reported-by: NJiri Pirko <jpirko@redhat.com>
      CC: Robert Olsson <robert.olsson@its.uu.se>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Alexey Dobriyan <adobriyan@gmail.com>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8873315
  31. 23 5月, 2011 2 次提交