1. 29 8月, 2014 1 次提交
    • Y
      xfrm: remove useless hash_resize_mutex locks · 0244790c
      Ying Xue 提交于
      In xfrm_state.c, hash_resize_mutex is defined as a local variable
      and only used in xfrm_hash_resize() which is declared as a work
      handler of xfrm.state_hash_work. But when the xfrm.state_hash_work
      work is put in the global workqueue(system_wq) with schedule_work(),
      the work will be really inserted in the global workqueue if it was
      not already queued, otherwise, it is still left in the same position
      on the the global workqueue. This means the xfrm_hash_resize() work
      handler is only executed once at any time no matter how many times
      its work is scheduled, that is, xfrm_hash_resize() is not called
      concurrently at all, so hash_resize_mutex is redundant for us.
      
      Cc: Christophe Gouault <christophe.gouault@6wind.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      0244790c
  2. 07 8月, 2014 1 次提交
    • K
      list: fix order of arguments for hlist_add_after(_rcu) · 1d023284
      Ken Helias 提交于
      All other add functions for lists have the new item as first argument
      and the position where it is added as second argument.  This was changed
      for no good reason in this function and makes using it unnecessary
      confusing.
      
      The name was changed to hlist_add_behind() to cause unconverted code to
      generate a compile error instead of using the wrong parameter order.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NKen Helias <kenhelias@firemail.de>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>	[intel driver bits]
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d023284
  3. 30 6月, 2014 1 次提交
  4. 26 6月, 2014 1 次提交
  5. 04 6月, 2014 1 次提交
    • M
      xfrm: fix race between netns cleanup and state expire notification · 21ee543e
      Michal Kubecek 提交于
      The xfrm_user module registers its pernet init/exit after xfrm
      itself so that its net exit function xfrm_user_net_exit() is
      executed before xfrm_net_exit() which calls xfrm_state_fini() to
      cleanup the SA's (xfrm states). This opens a window between
      zeroing net->xfrm.nlsk pointer and deleting all xfrm_state
      instances which may access it (via the timer). If an xfrm state
      expires in this window, xfrm_exp_state_notify() will pass null
      pointer as socket to nlmsg_multicast().
      
      As the notifications are called inside rcu_read_lock() block, it
      is sufficient to retrieve the nlsk socket with rcu_dereference()
      and check the it for null.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21ee543e
  6. 13 5月, 2014 1 次提交
  7. 08 5月, 2014 1 次提交
    • W
      net: clean up snmp stats code · 698365fa
      WANG Cong 提交于
      commit 8f0ea0fe (snmp: reduce percpu needs by 50%)
      reduced snmp array size to 1, so technically it doesn't have to be
      an array any more. What's more, after the following commit:
      
      	commit 933393f5
      	Date:   Thu Dec 22 11:58:51 2011 -0600
      
      	    percpu: Remove irqsafe_cpu_xxx variants
      
      	    We simply say that regular this_cpu use must be safe regardless of
      	    preemption and interrupt state.  That has no material change for x86
      	    and s390 implementations of this_cpu operations.  However, arches that
      	    do not provide their own implementation for this_cpu operations will
      	    now get code generated that disables interrupts instead of preemption.
      
      probably no arch wants to have SNMP_ARRAY_SZ == 2. At least after
      almost 3 years, no one complains.
      
      So, just convert the array to a single pointer and remove snmp_mib_init()
      and snmp_mib_free() as well.
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      698365fa
  8. 25 4月, 2014 1 次提交
  9. 23 4月, 2014 1 次提交
  10. 22 4月, 2014 1 次提交
    • T
      xfrm: Remove useless secid field from xfrm_audit. · f1370cc4
      Tetsuo Handa 提交于
      It seems to me that commit ab5f5e8b "[XFRM]: xfrm audit calls" is doing
      something strange at xfrm_audit_helper_usrinfo().
      If secid != 0 && security_secid_to_secctx(secid) != 0, the caller calls
      audit_log_task_context() which basically does
      secid != 0 && security_secid_to_secctx(secid) == 0 case
      except that secid is obtained from current thread's context.
      
      Oh, what happens if secid passed to xfrm_audit_helper_usrinfo() was
      obtained from other thread's context? It might audit current thread's
      context rather than other thread's context if security_secid_to_secctx()
      in xfrm_audit_helper_usrinfo() failed for some reason.
      
      Then, are all the caller of xfrm_audit_helper_usrinfo() passing either
      secid obtained from current thread's context or secid == 0?
      It seems to me that they are.
      
      If I didn't miss something, we don't need to pass secid to
      xfrm_audit_helper_usrinfo() because audit_log_task_context() will
      obtain secid from current thread's context.
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      f1370cc4
  11. 16 4月, 2014 1 次提交
  12. 14 3月, 2014 1 次提交
  13. 13 3月, 2014 1 次提交
  14. 10 3月, 2014 1 次提交
    • N
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov 提交于
      security_xfrm_policy_alloc can be called in atomic context so the
      allocation should be done with GFP_ATOMIC. Add an argument to let the
      callers choose the appropriate way. In order to do so a gfp argument
      needs to be added to the method xfrm_policy_alloc_security in struct
      security_operations and to the internal function
      selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic
      callers and leave GFP_KERNEL as before for the rest.
      The path that needed the gfp argument addition is:
      security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security ->
      all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) ->
      selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only)
      
      Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also
      add it to security_context_to_sid which is used inside and prior to this
      patch did only GFP_KERNEL allocation. So add gfp argument to
      security_context_to_sid and adjust all of its callers as well.
      
      CC: Paul Moore <paul@paul-moore.com>
      CC: Dave Jones <davej@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Fan Du <fan.du@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: LSM list <linux-security-module@vger.kernel.org>
      CC: SELinux list <selinux@tycho.nsa.gov>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
  15. 07 3月, 2014 1 次提交
  16. 26 2月, 2014 1 次提交
  17. 25 2月, 2014 2 次提交
  18. 21 2月, 2014 1 次提交
  19. 20 2月, 2014 3 次提交
  20. 19 2月, 2014 1 次提交
  21. 17 2月, 2014 1 次提交
    • N
      ipsec: add support of limited SA dump · d3623099
      Nicolas Dichtel 提交于
      The goal of this patch is to allow userland to dump only a part of SA by
      specifying a filter during the dump.
      The kernel is in charge to filter SA, this avoids to generate useless netlink
      traffic (it save also some cpu cycles). This is particularly useful when there
      is a big number of SA set on the system.
      
      Note that I removed the union in struct xfrm_state_walk to fix a problem on arm.
      struct netlink_callback->args is defined as a array of 6 long and the first long
      is used in xfrm code to flag the cb as initialized. Hence, we must have:
      sizeof(struct xfrm_state_walk) <= sizeof(long) * 5.
      With the union, it was false on arm (sizeof(struct xfrm_state_walk) was
      sizeof(long) * 7), due to the padding.
      In fact, whatever the arch is, this union seems useless, there will be always
      padding after it. Removing it will not increase the size of this struct (and
      reduce it on arm).
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      d3623099
  22. 13 2月, 2014 1 次提交
  23. 12 2月, 2014 2 次提交
  24. 15 1月, 2014 1 次提交
  25. 14 1月, 2014 1 次提交
  26. 08 1月, 2014 2 次提交
  27. 03 1月, 2014 2 次提交
    • F
      {pktgen, xfrm} Introduce xfrm_state_lookup_byspi for pktgen · c454997e
      Fan Du 提交于
      Introduce xfrm_state_lookup_byspi to find user specified by custom
      from "pgset spi xxx". Using this scheme, any flow regardless its
      saddr/daddr could be transform by SA specified with configurable
      spi.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      c454997e
    • F
      {pktgen, xfrm} Correct xfrm_state_lock usage in xfrm_stateonly_find · 4ae770bf
      Fan Du 提交于
      Acquiring xfrm_state_lock in process context is expected to turn BH off,
      as this lock is also used in BH context, namely xfrm state timer handler.
      Otherwise it surprises LOCKDEP with below messages.
      
      [   81.422781] pktgen: Packet Generator for packet performance testing. Version: 2.74
      [   81.725194]
      [   81.725211] =========================================================
      [   81.725212] [ INFO: possible irq lock inversion dependency detected ]
      [   81.725215] 3.13.0-rc2+ #92 Not tainted
      [   81.725216] ---------------------------------------------------------
      [   81.725218] kpktgend_0/2780 just changed the state of lock:
      [   81.725220]  (xfrm_state_lock){+.+...}, at: [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
      [   81.725231] but this lock was taken by another, SOFTIRQ-safe lock in the past:
      [   81.725232]  (&(&x->lock)->rlock){+.-...}
      [   81.725232]
      [   81.725232] and interrupts could create inverse lock ordering between them.
      [   81.725232]
      [   81.725235]
      [   81.725235] other info that might help us debug this:
      [   81.725237]  Possible interrupt unsafe locking scenario:
      [   81.725237]
      [   81.725238]        CPU0                    CPU1
      [   81.725240]        ----                    ----
      [   81.725241]   lock(xfrm_state_lock);
      [   81.725243]                                local_irq_disable();
      [   81.725244]                                lock(&(&x->lock)->rlock);
      [   81.725246]                                lock(xfrm_state_lock);
      [   81.725248]   <Interrupt>
      [   81.725249]     lock(&(&x->lock)->rlock);
      [   81.725251]
      [   81.725251]  *** DEADLOCK ***
      [   81.725251]
      [   81.725254] no locks held by kpktgend_0/2780.
      [   81.725255]
      [   81.725255] the shortest dependencies between 2nd lock and 1st lock:
      [   81.725269]  -> (&(&x->lock)->rlock){+.-...} ops: 8 {
      [   81.725274]     HARDIRQ-ON-W at:
      [   81.725276]                       [<ffffffff8109a64b>] __lock_acquire+0x65b/0x1d70
      [   81.725282]                       [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725284]                       [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725289]                       [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
      [   81.725292]                       [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
      [   81.725300]                       [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
      [   81.725303]                       [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
      [   81.725305]                       [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   81.725308]                       [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
      [   81.725313]                       [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
      [   81.725316]                       [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
      [   81.725329]                       [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
      [   81.725333]                       [<ffffffff8102e5b0>] start_secondary+0x190/0x1f0
      [   81.725338]     IN-SOFTIRQ-W at:
      [   81.725340]                       [<ffffffff8109a61d>] __lock_acquire+0x62d/0x1d70
      [   81.725342]                       [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725344]                       [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725347]                       [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
      [   81.725349]                       [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
      [   81.725352]                       [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
      [   81.725355]                       [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
      [   81.725358]                       [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   81.725360]                       [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
      [   81.725363]                       [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
      [   81.725365]                       [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
      [   81.725368]                       [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
      [   81.725370]                       [<ffffffff8102e5b0>] start_secondary+0x190/0x1f0
      [   81.725373]     INITIAL USE at:
      [   81.725375]                      [<ffffffff8109a31a>] __lock_acquire+0x32a/0x1d70
      [   81.725385]                      [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725388]                      [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725390]                      [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
      [   81.725394]                      [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
      [   81.725398]                      [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
      [   81.725401]                      [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
      [   81.725404]                      [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   81.725407]                      [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
      [   81.725409]                      [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
      [   81.725412]                      [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
      [   81.725415]                      [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
      [   81.725417]                      [<ffffffff8102e5b0>] start_secondary+0x190/0x1f0
      [   81.725420]   }
      [   81.725421]   ... key      at: [<ffffffff8295b9c8>] __key.46349+0x0/0x8
      [   81.725445]   ... acquired at:
      [   81.725446]    [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725449]    [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725452]    [<ffffffff816dc057>] __xfrm_state_delete+0x37/0x140
      [   81.725454]    [<ffffffff816dc18c>] xfrm_state_delete+0x2c/0x50
      [   81.725456]    [<ffffffff816dc277>] xfrm_state_flush+0xc7/0x1b0
      [   81.725458]    [<ffffffffa005f6cc>] pfkey_flush+0x7c/0x100 [af_key]
      [   81.725465]    [<ffffffffa005efb7>] pfkey_process+0x1c7/0x1f0 [af_key]
      [   81.725468]    [<ffffffffa005f139>] pfkey_sendmsg+0x159/0x260 [af_key]
      [   81.725471]    [<ffffffff8162c16f>] sock_sendmsg+0xaf/0xc0
      [   81.725476]    [<ffffffff8162c99c>] SYSC_sendto+0xfc/0x130
      [   81.725479]    [<ffffffff8162cf3e>] SyS_sendto+0xe/0x10
      [   81.725482]    [<ffffffff8177dd12>] system_call_fastpath+0x16/0x1b
      [   81.725484]
      [   81.725486] -> (xfrm_state_lock){+.+...} ops: 11 {
      [   81.725490]    HARDIRQ-ON-W at:
      [   81.725493]                     [<ffffffff8109a64b>] __lock_acquire+0x65b/0x1d70
      [   81.725504]                     [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725507]                     [<ffffffff81774e4b>] _raw_spin_lock_bh+0x3b/0x70
      [   81.725510]                     [<ffffffff816dc1df>] xfrm_state_flush+0x2f/0x1b0
      [   81.725513]                     [<ffffffffa005f6cc>] pfkey_flush+0x7c/0x100 [af_key]
      [   81.725516]                     [<ffffffffa005efb7>] pfkey_process+0x1c7/0x1f0 [af_key]
      [   81.725519]                     [<ffffffffa005f139>] pfkey_sendmsg+0x159/0x260 [af_key]
      [   81.725522]                     [<ffffffff8162c16f>] sock_sendmsg+0xaf/0xc0
      [   81.725525]                     [<ffffffff8162c99c>] SYSC_sendto+0xfc/0x130
      [   81.725527]                     [<ffffffff8162cf3e>] SyS_sendto+0xe/0x10
      [   81.725530]                     [<ffffffff8177dd12>] system_call_fastpath+0x16/0x1b
      [   81.725533]    SOFTIRQ-ON-W at:
      [   81.725534]                     [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
      [   81.725537]                     [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725539]                     [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725541]                     [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
      [   81.725544]                     [<ffffffffa008af03>] mod_cur_headers+0x793/0x7f0 [pktgen]
      [   81.725547]                     [<ffffffffa008bca2>] pktgen_thread_worker+0xd42/0x1880 [pktgen]
      [   81.725550]                     [<ffffffff81078f84>] kthread+0xe4/0x100
      [   81.725555]                     [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
      [   81.725565]    INITIAL USE at:
      [   81.725567]                    [<ffffffff8109a31a>] __lock_acquire+0x32a/0x1d70
      [   81.725569]                    [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725572]                    [<ffffffff81774e4b>] _raw_spin_lock_bh+0x3b/0x70
      [   81.725574]                    [<ffffffff816dc1df>] xfrm_state_flush+0x2f/0x1b0
      [   81.725576]                    [<ffffffffa005f6cc>] pfkey_flush+0x7c/0x100 [af_key]
      [   81.725580]                    [<ffffffffa005efb7>] pfkey_process+0x1c7/0x1f0 [af_key]
      [   81.725583]                    [<ffffffffa005f139>] pfkey_sendmsg+0x159/0x260 [af_key]
      [   81.725586]                    [<ffffffff8162c16f>] sock_sendmsg+0xaf/0xc0
      [   81.725589]                    [<ffffffff8162c99c>] SYSC_sendto+0xfc/0x130
      [   81.725594]                    [<ffffffff8162cf3e>] SyS_sendto+0xe/0x10
      [   81.725597]                    [<ffffffff8177dd12>] system_call_fastpath+0x16/0x1b
      [   81.725599]  }
      [   81.725600]  ... key      at: [<ffffffff81cadef8>] xfrm_state_lock+0x18/0x50
      [   81.725606]  ... acquired at:
      [   81.725607]    [<ffffffff810995c0>] check_usage_backwards+0x110/0x150
      [   81.725609]    [<ffffffff81099e96>] mark_lock+0x196/0x2f0
      [   81.725611]    [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
      [   81.725614]    [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725616]    [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725627]    [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
      [   81.725629]    [<ffffffffa008af03>] mod_cur_headers+0x793/0x7f0 [pktgen]
      [   81.725632]    [<ffffffffa008bca2>] pktgen_thread_worker+0xd42/0x1880 [pktgen]
      [   81.725635]    [<ffffffff81078f84>] kthread+0xe4/0x100
      [   81.725637]    [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
      [   81.725640]
      [   81.725641]
      [   81.725641] stack backtrace:
      [   81.725645] CPU: 0 PID: 2780 Comm: kpktgend_0 Not tainted 3.13.0-rc2+ #92
      [   81.725647] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
      [   81.725649]  ffffffff82537b80 ffff880018199988 ffffffff8176af37 0000000000000007
      [   81.725652]  ffff8800181999f0 ffff8800181999d8 ffffffff81099358 ffffffff82537b80
      [   81.725655]  ffffffff81a32def ffff8800181999f4 0000000000000000 ffff880002cbeaa8
      [   81.725659] Call Trace:
      [   81.725664]  [<ffffffff8176af37>] dump_stack+0x46/0x58
      [   81.725667]  [<ffffffff81099358>] print_irq_inversion_bug.part.42+0x1e8/0x1f0
      [   81.725670]  [<ffffffff810995c0>] check_usage_backwards+0x110/0x150
      [   81.725672]  [<ffffffff81099e96>] mark_lock+0x196/0x2f0
      [   81.725675]  [<ffffffff810994b0>] ? check_usage_forwards+0x150/0x150
      [   81.725685]  [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
      [   81.725691]  [<ffffffff810899a5>] ? sched_clock_local+0x25/0x90
      [   81.725694]  [<ffffffff81089b38>] ? sched_clock_cpu+0xa8/0x120
      [   81.725697]  [<ffffffff8109a31a>] ? __lock_acquire+0x32a/0x1d70
      [   81.725699]  [<ffffffff816dd751>] ? xfrm_stateonly_find+0x41/0x1f0
      [   81.725702]  [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   81.725704]  [<ffffffff816dd751>] ? xfrm_stateonly_find+0x41/0x1f0
      [   81.725707]  [<ffffffff810899a5>] ? sched_clock_local+0x25/0x90
      [   81.725710]  [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   81.725712]  [<ffffffff816dd751>] ? xfrm_stateonly_find+0x41/0x1f0
      [   81.725715]  [<ffffffff810971ec>] ? lock_release_holdtime.part.26+0x1c/0x1a0
      [   81.725717]  [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
      [   81.725721]  [<ffffffffa008af03>] mod_cur_headers+0x793/0x7f0 [pktgen]
      [   81.725724]  [<ffffffffa008bca2>] pktgen_thread_worker+0xd42/0x1880 [pktgen]
      [   81.725727]  [<ffffffffa008ba71>] ? pktgen_thread_worker+0xb11/0x1880 [pktgen]
      [   81.725729]  [<ffffffff8109cf9d>] ? trace_hardirqs_on+0xd/0x10
      [   81.725733]  [<ffffffff81775410>] ? _raw_spin_unlock_irq+0x30/0x40
      [   81.725745]  [<ffffffff8151faa0>] ? e1000_clean+0x9d0/0x9d0
      [   81.725751]  [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
      [   81.725753]  [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
      [   81.725757]  [<ffffffffa008af60>] ? mod_cur_headers+0x7f0/0x7f0 [pktgen]
      [   81.725759]  [<ffffffff81078f84>] kthread+0xe4/0x100
      [   81.725762]  [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
      [   81.725765]  [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
      [   81.725768]  [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      4ae770bf
  28. 02 1月, 2014 5 次提交
  29. 16 12月, 2013 2 次提交