1. 08 10月, 2015 1 次提交
  2. 18 8月, 2015 2 次提交
  3. 26 5月, 2015 1 次提交
    • E
      net: fix inet_proto_csum_replace4() sparse errors · 05c98543
      Eric Dumazet 提交于
      make C=2 CF=-D__CHECK_ENDIAN__ net/core/utils.o
      ...
      net/core/utils.c:307:72: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:307:72:    expected restricted __wsum [usertype] addend
      net/core/utils.c:307:72:    got restricted __be32 [usertype] from
      net/core/utils.c:308:34: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:308:34:    expected restricted __wsum [usertype] addend
      net/core/utils.c:308:34:    got restricted __be32 [usertype] to
      net/core/utils.c:310:70: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:310:70:    expected restricted __wsum [usertype] addend
      net/core/utils.c:310:70:    got restricted __be32 [usertype] from
      net/core/utils.c:310:77: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:310:77:    expected restricted __wsum [usertype] addend
      net/core/utils.c:310:77:    got restricted __be32 [usertype] to
      net/core/utils.c:312:72: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:312:72:    expected restricted __wsum [usertype] addend
      net/core/utils.c:312:72:    got restricted __be32 [usertype] from
      net/core/utils.c:313:35: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:313:35:    expected restricted __wsum [usertype] addend
      net/core/utils.c:313:35:    got restricted __be32 [usertype] to
      
      Note we can use csum_replace4() helper
      
      Fixes: 58e3cac5 ("net: optimise inet_proto_csum_replace4()")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05c98543
  4. 12 11月, 2014 1 次提交
    • J
      net: Convert LIMIT_NETDEBUG to net_dbg_ratelimited · ba7a46f1
      Joe Perches 提交于
      Use the more common dynamic_debug capable net_dbg_ratelimited
      and remove the LIMIT_NETDEBUG macro.
      
      All messages are still ratelimited.
      
      Some KERN_<LEVEL> uses are changed to KERN_DEBUG.
      
      This may have some negative impact on messages that were
      emitted at KERN_INFO that are not not enabled at all unless
      DEBUG is defined or dynamic_debug is enabled.  Even so,
      these messages are now _not_ emitted by default.
      
      This also eliminates the use of the net_msg_warn sysctl
      "/proc/sys/net/core/warnings".  For backward compatibility,
      the sysctl is not removed, but it has no function.  The extern
      declaration of net_msg_warn is removed from sock.h and made
      static in net/core/sysctl_net_core.c
      
      Miscellanea:
      
      o Update the sysctl documentation
      o Remove the embedded uses of pr_fmt
      o Coalesce format fragments
      o Realign arguments
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba7a46f1
  5. 27 9月, 2014 1 次提交
    • L
      net: optimise inet_proto_csum_replace4() · 58e3cac5
      LEROY Christophe 提交于
      csum_partial() is a generic function which is not optimised for small fixed
      length calculations, and its use requires to store "from" and "to" values in
      memory while we already have them available in registers. This also has impact,
      especially on RISC processors. In the same spirit as the change done by
      Eric Dumazet on csum_replace2(), this patch rewrites inet_proto_csum_replace4()
      taking into account RFC1624.
      
      I spotted during a NATted tcp transfert that csum_partial() is one of top 5
      consuming functions (around 8%), and the second user of csum_partial() is
      inet_proto_csum_replace4().
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58e3cac5
  6. 14 5月, 2014 1 次提交
    • H
      net: avoid dependency of net_get_random_once on nop patching · 3d440522
      Hannes Frederic Sowa 提交于
      net_get_random_once depends on the static keys infrastructure to patch up
      the branch to the slow path during boot. This was realized by abusing the
      static keys api and defining a new initializer to not enable the call
      site while still indicating that the branch point should get patched
      up. This was needed to have the fast path considered likely by gcc.
      
      The static key initialization during boot up normally walks through all
      the registered keys and either patches in ideal nops or enables the jump
      site but omitted that step on x86 if ideal nops where already placed at
      static_key branch points. Thus net_get_random_once branches not always
      became active.
      
      This patch switches net_get_random_once to the ordinary static_key
      api and thus places the kernel fast path in the - by gcc considered -
      unlikely path.  Microbenchmarks on Intel and AMD x86-64 showed that
      the unlikely path actually beats the likely path in terms of cycle cost
      and that different nop patterns did not make much difference, thus this
      switch should not be noticeable.
      
      Fixes: a48e4292 ("net: introduce new macro net_get_random_once")
      Reported-by: NTuomas Räsänen <tuomasjjrasanen@tjjr.fi>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d440522
  7. 26 10月, 2013 1 次提交
  8. 20 10月, 2013 1 次提交
    • H
      net: introduce new macro net_get_random_once · a48e4292
      Hannes Frederic Sowa 提交于
      net_get_random_once is a new macro which handles the initialization
      of secret keys. It is possible to call it in the fast path. Only the
      initialization depends on the spinlock and is rather slow. Otherwise
      it should get used just before the key is used to delay the entropy
      extration as late as possible to get better randomness. It returns true
      if the key got initialized.
      
      The usage of static_keys for net_get_random_once is a bit uncommon so
      it needs some further explanation why this actually works:
      
      === In the simple non-HAVE_JUMP_LABEL case we actually have ===
      no constrains to use static_key_(true|false) on keys initialized with
      STATIC_KEY_INIT_(FALSE|TRUE). So this path just expands in favor of
      the likely case that the initialization is already done. The key is
      initialized like this:
      
      ___done_key = { .enabled = ATOMIC_INIT(0) }
      
      The check
      
                      if (!static_key_true(&___done_key))                     \
      
      expands into (pseudo code)
      
                      if (!likely(___done_key > 0))
      
      , so we take the fast path as soon as ___done_key is increased from the
      helper function.
      
      === If HAVE_JUMP_LABELs are available this depends ===
      on patching of jumps into the prepared NOPs, which is done in
      jump_label_init at boot-up time (from start_kernel). It is forbidden
      and dangerous to use net_get_random_once in functions which are called
      before that!
      
      At compilation time NOPs are generated at the call sites of
      net_get_random_once. E.g. net/ipv6/inet6_hashtable.c:inet6_ehashfn (we
      need to call net_get_random_once two times in inet6_ehashfn, so two NOPs):
      
            71:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
            76:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
      
      Both will be patched to the actual jumps to the end of the function to
      call __net_get_random_once at boot time as explained above.
      
      arch_static_branch is optimized and inlined for false as return value and
      actually also returns false in case the NOP is placed in the instruction
      stream. So in the fast case we get a "return false". But because we
      initialize ___done_key with (enabled != (entries & 1)) this call-site
      will get patched up at boot thus returning true. The final check looks
      like this:
      
                      if (!static_key_true(&___done_key))                     \
                              ___ret = __net_get_random_once(buf,             \
      
      expands to
      
                      if (!!static_key_false(&___done_key))                     \
                              ___ret = __net_get_random_once(buf,             \
      
      So we get true at boot time and as soon as static_key_slow_inc is called
      on the key it will invert the logic and return false for the fast path.
      static_key_slow_inc will change the branch because it got initialized
      with .enabled == 0. After static_key_slow_inc is called on the key the
      branch is replaced with a nop again.
      
      === Misc: ===
      The helper defers the increment into a workqueue so we don't
      have problems calling this code from atomic sections. A seperate boolean
      (___done) guards the case where we enter net_get_random_once again before
      the increment happend.
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a48e4292
  9. 06 6月, 2013 1 次提交
  10. 28 3月, 2013 1 次提交
  11. 13 10月, 2012 2 次提交
  12. 30 8月, 2012 1 次提交
  13. 13 4月, 2012 1 次提交
  14. 29 3月, 2012 1 次提交
  15. 28 5月, 2011 1 次提交
  16. 10 5月, 2011 1 次提交
    • A
      net: add mac_pton() for parsing MAC address · 4940fc88
      Alexey Dobriyan 提交于
      mac_pton() parses MAC address in form XX:XX:XX:XX:XX:XX and only in that form.
      
      mac_pton() doesn't dirty result until it's sure string representation is valid.
      
      mac_pton() doesn't care about characters _after_ last octet,
      it's up to caller to deal with it.
      
      mac_pton() diverges from 0/-E return value convention.
      Target usage:
      
      	if (!mac_pton(str, whatever->mac))
      		return -EINVAL;
      	/* ->mac being u8 [ETH_ALEN] is filled at this point. */
      	/* optionally check str[3 * ETH_ALEN - 1] for termination */
      
      Use mac_pton() in pktgen and netconsole for start.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4940fc88
  17. 24 9月, 2010 1 次提交
  18. 22 9月, 2010 1 次提交
  19. 13 7月, 2010 1 次提交
  20. 22 9月, 2009 1 次提交
    • I
      printk: Remove ratelimit.h from kernel.h · 3fff4c42
      Ingo Molnar 提交于
      Decouple kernel.h from ratelimit.h: the global declaration of
      printk's ratelimit_state is not needed, and it leads to messy
      circular dependencies due to ratelimit.h's (new) adding of a
      spinlock_types.h include.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3fff4c42
  21. 26 3月, 2009 1 次提交
  22. 26 7月, 2008 1 次提交
    • D
      printk ratelimiting rewrite · 717115e1
      Dave Young 提交于
      All ratelimit user use same jiffies and burst params, so some messages
      (callbacks) will be lost.
      
      For example:
      a call printk_ratelimit(5 * HZ, 1)
      b call printk_ratelimit(5 * HZ, 1) before the 5*HZ timeout of a, then b will
      will be supressed.
      
      - rewrite __ratelimit, and use a ratelimit_state as parameter.  Thanks for
        hints from andrew.
      
      - Add WARN_ON_RATELIMIT, update rcupreempt.h
      
      - remove __printk_ratelimit
      
      - use __ratelimit in net_ratelimit
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      717115e1
  23. 29 1月, 2008 2 次提交
  24. 08 8月, 2007 1 次提交
  25. 31 5月, 2007 1 次提交
    • J
      [NET]: parse ip:port strings correctly in in4_pton · 83f03fa5
      Jerome Borsboom 提交于
      in4_pton converts a textual representation of an ip4 address
      into an integer representation. However, when the textual representation
      is of in the form ip:port, e.g. 192.168.1.1:5060, and 'delim' is set to
      -1, the function bails out with an error when reading the colon.
      
      It makes sense to allow the colon as a delimiting character without
      explicitly having to set it through the 'delim' variable as there can be
      no ambiguity in the point where the ip address is completely parsed. This
      function is indeed called from nf_conntrack_sip.c in this way to parse
      textual ip:port combinations which fails due to the reason stated above.
      Signed-off-by: NJerome Borsboom <j.borsboom@erasmusmc.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83f03fa5
  26. 26 4月, 2007 2 次提交
  27. 11 2月, 2007 1 次提交
  28. 03 12月, 2006 1 次提交
  29. 17 10月, 2006 1 次提交
  30. 29 9月, 2006 1 次提交
  31. 23 9月, 2006 2 次提交
  32. 18 8月, 2006 1 次提交
  33. 11 4月, 2006 1 次提交
  34. 06 2月, 2006 1 次提交
  35. 07 1月, 2006 1 次提交