1. 14 4月, 2017 2 次提交
  2. 16 1月, 2017 1 次提交
    • F
      xfrm: fix possible null deref in xfrm_init_tempstate · 3819a35f
      Florian Westphal 提交于
      Dan reports following smatch warning:
       net/xfrm/xfrm_state.c:659
       error: we previously assumed 'afinfo' could be null (see line 651)
      
       649  struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
       651  if (afinfo)
      		...
       658  }
       659  afinfo->init_temprop(x, tmpl, daddr, saddr);
      
      I am resonably sure afinfo cannot be NULL here.
      
      xfrm_state4.c and state6.c are both part of ipv4/ipv6 (depends on
      CONFIG_XFRM, a boolean) but even if ipv6 is a module state6.c can't
      be removed (ipv6 lacks module_exit so it cannot be removed).
      
      The only callers for xfrm6_fini that leads to state backend unregister
      are error unwinding paths that can be called during ipv6 init function.
      
      So after ipv6 module is loaded successfully the state backend cannot go
      away anymore.
      
      The family value from policy lookup path is taken from dst_entry, so
      that should always be AF_INET(6).
      
      However, since this silences the warning and avoids readers of this
      code wondering about possible null deref it seems preferrable to
      be defensive and just add the old check back.
      
      Fixes: 711059b9 ("xfrm: add and use xfrm_state_afinfo_get_rcu")
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      3819a35f
  3. 10 1月, 2017 4 次提交
  4. 06 1月, 2017 1 次提交
    • F
      xfrm: state: do not acquire lock in get_mtu helpers · b3b73b8e
      Florian Westphal 提交于
      Once flow cache gets removed the mtu initialisation happens for every skb
      that gets an xfrm attached, so this lock starts to show up in perf.
      
      It is not obvious why this lock is required -- the caller holds
      reference on the state struct, type->destructor is only called from the
      state gc worker (all state structs on gc list must have refcount 0).
      
      xfrm_init_state already has been called (else private data accessed
      by type->get_mtu() would not be set up).
      
      So just remove the lock -- the race on the state (DEAD?) doesn't
      matter (could change right after dropping the lock too).
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      b3b73b8e
  5. 04 1月, 2017 1 次提交
  6. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  7. 25 12月, 2016 1 次提交
  8. 30 9月, 2016 1 次提交
  9. 21 9月, 2016 1 次提交
  10. 19 9月, 2016 1 次提交
  11. 24 8月, 2016 1 次提交
  12. 10 8月, 2016 6 次提交
  13. 29 4月, 2015 1 次提交
  14. 23 4月, 2015 2 次提交
  15. 01 4月, 2015 1 次提交
  16. 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
  17. 23 4月, 2014 1 次提交
  18. 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
  19. 07 3月, 2014 1 次提交
  20. 21 2月, 2014 1 次提交
  21. 20 2月, 2014 3 次提交
  22. 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
  23. 13 2月, 2014 1 次提交
  24. 15 1月, 2014 1 次提交
  25. 14 1月, 2014 1 次提交
  26. 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
  27. 02 1月, 2014 1 次提交