1. 21 Oct, 2013 31 commits
  2. 19 Oct, 2013 9 commits
    • David S. Miller's avatar
      Merge tag 'batman-adv-for-davem' of git://git.open-mesh.org/linux-merge · 5bf47256
      David S. Miller authored
      Antonio Quartulli says:
      
      ====================
      this is another batch intended for net-next/linux-3.13.
      
      This pull request is a bit bigger than usual, but 6 patches are very small
      (three of them are about email updates)..
      
      Patch 1 is fixing a previous merge conflict resolution that went wrong
      (I realised that only now while checking other patches..).
      Patches from 2 to 4 that are updating our emails in all the proper files
      (Documentation/, headers and MAINTAINERS).
      
      Patches 5, 6 and 7 are bringing a big improvement to the TranslationTable
      component: it is now able to group non-mesh clients based on the VLAN they
      belong to. In this way a lot a new enhancements are now possible thanks to the
      fact that each batman-adv behaviour can be applied on a per VLAN basis.
      
      And, of course, in patches from 8 to 12 you have some of the enhancements I was
      talking about:
      - make the batman-Gateway selection VLAN dependent
      - make DAT (Distributed ARP Table) group ARP entries on a VLAN basis (this
        allows DAT to work even when the admin decided to use the same IP subnet on
        different VLANs)
      - make the AP-Isolation behaviour switchable on each VLAN independently
      - export VLAN specific attributes via sysfs. Switches like the AP-Isolation are
        now exported once per VLAN (backward compatibility of the sysfs interface has
        been preserved)
      
      Patches 13 and 14 are small code cleanups.
      Patch 15 is a minor improvement in the TT locking mechanism.
      
      Patches 16 and 17 are other enhancements to the TT component. Those allow a
      node to parse a "non-mesh client announcement message" and accept only those
      TT entries belonging to certain VLANs.
      
      Patch 18 exploits this parse&accept mechanism to make the Bridge Loop Avoidance
      component reject only TT entries connected to the VLAN where it is operating.
      Previous to this change, BLA was rejecting all the entries coming from any other
      Backbone node, regardless of the VLAN (for more details about how the Bridge
      Loop Avoidance works please check [1]).
      
      [1] http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-II
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5bf47256
    • David S. Miller's avatar
      Merge branch 'net_get_random_once' · 7dcade39
      David S. Miller authored
      Hannes Frederic Sowa says:
      
      ====================
      This series implements support for delaying the initialization of secret
      keys, e.g. used for hashing, for as long as possible. This functionality
      is implemented by a new macro, net_get_random_bytes.
      
      I already used it to protect the socket hashes, the syncookie secret
      (most important) and the tcp_fastopen secrets.
      
      Changelog:
      v2) Use static_keys in net_get_random_once to have as minimal impact to
          the fast-path as possible.
      v3) added patch "static_key: WARN on usage before jump_label_init was called":
          Patch "x86/jump_label: expect default_nop if static_key gets enabled
          on boot-up" relaxes the checks for using static_key primitives before
          jump_label_init. So tighten them first.
      v4) Update changelog on the patch "static_key: WARN on usage before
          jump_label_init was called"
      
      Included patches:
       ipv4: split inet_ehashfn to hash functions per compilation unit
       ipv6: split inet6_ehashfn to hash functions per compilation unit
       static_key: WARN on usage before jump_label_init was called
       x86/jump_label: expect default_nop if static_key gets enabled on boot-up
       net: introduce new macro net_get_random_once
       inet: split syncookie keys for ipv4 and ipv6 and initialize with net_get_random_once
       inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once
       tcp: switch tcp_fastopen key generation to net_get_random_once
       net: switch net_secret key generation to net_get_random_once
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7dcade39
    • Hannes Frederic Sowa's avatar
      net: switch net_secret key generation to net_get_random_once · e34c9a69
      Hannes Frederic Sowa authored
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e34c9a69
    • Hannes Frederic Sowa's avatar
      tcp: switch tcp_fastopen key generation to net_get_random_once · 222e83d2
      Hannes Frederic Sowa authored
      Changed key initialization of tcp_fastopen cookies to net_get_random_once.
      
      If the user sets a custom key net_get_random_once must be called at
      least once to ensure we don't overwrite the user provided key when the
      first cookie is generated later on.
      
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      222e83d2
    • Hannes Frederic Sowa's avatar
      inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once · 1bbdceef
      Hannes Frederic Sowa authored
      Initialize the ehash and ipv6_hash_secrets with net_get_random_once.
      
      Each compilation unit gets its own secret now:
        ipv4/inet_hashtables.o
        ipv4/udp.o
        ipv6/inet6_hashtables.o
        ipv6/udp.o
        rds/connection.o
      
      The functions still get inlined into the hashing functions. In the fast
      path we have at most two (needed in ipv6) if (unlikely(...)).
      
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1bbdceef
    • Hannes Frederic Sowa's avatar
      inet: split syncookie keys for ipv4 and ipv6 and initialize with net_get_random_once · b23a002f
      Hannes Frederic Sowa authored
      This patch splits the secret key for syncookies for ipv4 and ipv6 and
      initializes them with net_get_random_once. This change was the reason I
      did this series. I think the initialization of the syncookie_secret is
      way to early.
      
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b23a002f
    • Hannes Frederic Sowa's avatar
      net: introduce new macro net_get_random_once · a48e4292
      Hannes Frederic Sowa authored
      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: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a48e4292
    • Hannes Frederic Sowa's avatar
      x86/jump_label: expect default_nop if static_key gets enabled on boot-up · a8fab074
      Hannes Frederic Sowa authored
      net_get_random_once(intrduced in the next patch) uses static_keys in
      a way that they get enabled on boot-up instead of replaced with an
      ideal_nop. So check for default_nop on initial enabling.
      
      Other architectures don't check for this.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.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>
      Cc: x86@kernel.org
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8fab074
    • Hannes Frederic Sowa's avatar
      static_key: WARN on usage before jump_label_init was called · c4b2c0c5
      Hannes Frederic Sowa authored
      Usage of the static key primitives to toggle a branch must not be used
      before jump_label_init() is called from init/main.c. jump_label_init
      reorganizes and wires up the jump_entries so usage before that could
      have unforeseen consequences.
      
      Following primitives are now checked for correct use:
      * static_key_slow_inc
      * static_key_slow_dec
      * static_key_slow_dec_deferred
      * jump_label_rate_limit
      
      The x86 architecture already checks this by testing if the default_nop
      was already replaced with an optimal nop or with a branch instruction. It
      will panic then. Other architectures don't check for this.
      
      Because we need to relax this check for the x86 arch to allow code to
      transition from default_nop to the enabled state and other architectures
      did not check for this at all this patch introduces checking on the
      static_key primitives in a non-arch dependent manner.
      
      All checked functions are considered slow-path so the additional check
      does no harm to performance.
      
      The warnings are best observed with earlyprintk.
      
      Based on a patch from Andi Kleen.
      
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andi Kleen <andi@firstfloor.org>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4b2c0c5