1. 03 Mar, 2017 2 commits
  2. 15 Feb, 2017 1 commit
    • Jason Baron's avatar
      jump_label: Reduce the size of struct static_key · 3821fd35
      Jason Baron authored
      The static_key->next field goes mostly unused. The field is used for
      associating module uses with a static key. Most uses of struct static_key
      define a static key in the core kernel and make use of it entirely within
      the core kernel, or define the static key in a module and make use of it
      only from within that module. In fact, of the ~3,000 static keys defined,
      I found only about 5 or so that did not fit this pattern.
      
      Thus, we can remove the static_key->next field entirely and overload
      the static_key->entries field. That is, when all the static_key uses
      are contained within the same module, static_key->entries continues
      to point to those uses. However, if the static_key uses are not contained
      within the module where the static_key is defined, then we allocate a
      struct static_key_mod, store a pointer to the uses within that
      struct static_key_mod, and have the static key point at the static_key_mod.
      This does incur some extra memory usage when a static_key is used in a
      module that does not define it, but since there are only a handful of such
      cases there is a net savings.
      
      In order to identify if the static_key->entries pointer contains a
      struct static_key_mod or a struct jump_entry pointer, bit 1 of
      static_key->entries is set to 1 if it points to a struct static_key_mod and
      is 0 if it points to a struct jump_entry. We were already using bit 0 in a
      similar way to store the initial value of the static_key. This does mean
      that allocations of struct static_key_mod and that the struct jump_entry
      tables need to be at least 4-byte aligned in memory. As far as I can tell
      all arches meet this criteria.
      
      For my .config, the patch increased the text by 778 bytes, but reduced
      the data + bss size by 14912, for a net savings of 14,134 bytes.
      
         text	   data	    bss	    dec	    hex	filename
      8092427	5016512	 790528	13899467	 d416cb	vmlinux.pre
      8093205	5001600	 790528	13885333	 d3df95	vmlinux.post
      
      Link: http://lkml.kernel.org/r/1486154544-4321-1-git-send-email-jbaron@akamai.com
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      3821fd35
  3. 19 Jan, 2017 1 commit
  4. 07 Sep, 2016 1 commit
  5. 05 Sep, 2016 1 commit
  6. 04 Aug, 2016 1 commit
  7. 24 Jun, 2016 1 commit
    • Paolo Bonzini's avatar
      locking/static_key: Fix concurrent static_key_slow_inc() · 4c5ea0a9
      Paolo Bonzini authored
      The following scenario is possible:
      
          CPU 1                                   CPU 2
          static_key_slow_inc()
           atomic_inc_not_zero()
            -> key.enabled == 0, no increment
           jump_label_lock()
           atomic_inc_return()
            -> key.enabled == 1 now
                                                  static_key_slow_inc()
                                                   atomic_inc_not_zero()
                                                    -> key.enabled == 1, inc to 2
                                                   return
                                                  ** static key is wrong!
           jump_label_update()
           jump_label_unlock()
      
      Testing the static key at the point marked by (**) will follow the
      wrong path for jumps that have not been patched yet.  This can
      actually happen when creating many KVM virtual machines with userspace
      LAPIC emulation; just run several copies of the following program:
      
          #include <fcntl.h>
          #include <unistd.h>
          #include <sys/ioctl.h>
          #include <linux/kvm.h>
      
          int main(void)
          {
              for (;;) {
                  int kvmfd = open("/dev/kvm", O_RDONLY);
                  int vmfd = ioctl(kvmfd, KVM_CREATE_VM, 0);
                  close(ioctl(vmfd, KVM_CREATE_VCPU, 1));
                  close(vmfd);
                  close(kvmfd);
              }
              return 0;
          }
      
      Every KVM_CREATE_VCPU ioctl will attempt a static_key_slow_inc() call.
      The static key's purpose is to skip NULL pointer checks and indeed one
      of the processes eventually dereferences NULL.
      
      As explained in the commit that introduced the bug:
      
        706249c2 ("locking/static_keys: Rework update logic")
      
      jump_label_update() needs key.enabled to be true.  The solution adopted
      here is to temporarily make key.enabled == -1, and use go down the
      slow path when key.enabled <= 0.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@vger.kernel.org> # v4.3+
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 706249c2 ("locking/static_keys: Rework update logic")
      Link: http://lkml.kernel.org/r/1466527937-69798-1-git-send-email-pbonzini@redhat.com
      [ Small stylistic edits to the changelog and the code. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4c5ea0a9
  8. 23 Nov, 2015 1 commit
    • Peter Zijlstra's avatar
      treewide: Remove old email address · 90eec103
      Peter Zijlstra authored
      There were still a number of references to my old Red Hat email
      address in the kernel source. Remove these while keeping the
      Red Hat copyright notices intact.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      90eec103
  9. 18 Sep, 2015 1 commit
  10. 15 Sep, 2015 1 commit
  11. 08 Sep, 2015 1 commit
  12. 03 Aug, 2015 5 commits
    • Jason Baron's avatar
      jump label, locking/static_keys: Update docs · 412758cb
      Jason Baron authored
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: benh@kernel.crashing.org
      Cc: bp@alien8.de
      Cc: davem@davemloft.net
      Cc: ddaney@caviumnetworks.com
      Cc: heiko.carstens@de.ibm.com
      Cc: linux-kernel@vger.kernel.org
      Cc: liuj97@gmail.com
      Cc: luto@amacapital.net
      Cc: michael@ellerman.id.au
      Cc: rabin@rab.in
      Cc: ralf@linux-mips.org
      Cc: rostedt@goodmis.org
      Cc: vbabka@suse.cz
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/6b50f2f6423a2244f37f4b1d2d6c211b9dcdf4f8.1438227999.git.jbaron@akamai.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      412758cb
    • Peter Zijlstra's avatar
      locking/static_keys: Add a new static_key interface · 11276d53
      Peter Zijlstra authored
      There are various problems and short-comings with the current
      static_key interface:
      
       - static_key_{true,false}() read like a branch depending on the key
         value, instead of the actual likely/unlikely branch depending on
         init value.
      
       - static_key_{true,false}() are, as stated above, tied to the
         static_key init values STATIC_KEY_INIT_{TRUE,FALSE}.
      
       - we're limited to the 2 (out of 4) possible options that compile to
         a default NOP because that's what our arch_static_branch() assembly
         emits.
      
      So provide a new static_key interface:
      
        DEFINE_STATIC_KEY_TRUE(name);
        DEFINE_STATIC_KEY_FALSE(name);
      
      Which define a key of different types with an initial true/false
      value.
      
      Then allow:
      
         static_branch_likely()
         static_branch_unlikely()
      
      to take a key of either type and emit the right instruction for the
      case.
      
      This means adding a second arch_static_branch_jump() assembly helper
      which emits a JMP per default.
      
      In order to determine the right instruction for the right state,
      encode the branch type in the LSB of jump_entry::key.
      
      This is the final step in removing the naming confusion that has led to
      a stream of avoidable bugs such as:
      
        a833581e ("x86, perf: Fix static_key bug in load_mm_cr4()")
      
      ... but it also allows new static key combinations that will give us
      performance enhancements in the subsequent patches.
      
      Tested-by: Rabin Vincent <rabin@rab.in> # arm
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> # ppc
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # s390
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      11276d53
    • Peter Zijlstra's avatar
      locking/static_keys: Add static_key_{en,dis}able() helpers · e33886b3
      Peter Zijlstra authored
      Add two helpers to make it easier to treat the refcount as boolean.
      Suggested-by: default avatarJason Baron <jasonbaron0@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e33886b3
    • Peter Zijlstra's avatar
      jump_label, locking/static_keys: Rename JUMP_LABEL_TYPE_* and related helpers... · a1efb01f
      Peter Zijlstra authored
      jump_label, locking/static_keys: Rename JUMP_LABEL_TYPE_* and related helpers to the static_key* pattern
      
      Rename the JUMP_LABEL_TYPE_* macros to be JUMP_TYPE_* and move the
      inline helpers into kernel/jump_label.c, since that's the only place
      they're ever used.
      
      Also rename the helpers where it's all about static keys.
      
      This is the second step in removing the naming confusion that has led to
      a stream of avoidable bugs such as:
      
        a833581e ("x86, perf: Fix static_key bug in load_mm_cr4()")
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a1efb01f
    • Peter Zijlstra's avatar
      jump_label: Rename JUMP_LABEL_{EN,DIS}ABLE to JUMP_LABEL_{JMP,NOP} · 76b235c6
      Peter Zijlstra authored
      Since we've already stepped away from ENABLE is a JMP and DISABLE is a
      NOP with the branch_default bits, and are going to make it even worse,
      rename it to make it all clearer.
      
      This way we don't mix multiple levels of logic attributes, but have a
      plain 'physical' name for what the current instruction patching status
      of a jump label is.
      
      This is a first step in removing the naming confusion that has led to
      a stream of avoidable bugs such as:
      
        a833581e ("x86, perf: Fix static_key bug in load_mm_cr4()")
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      [ Beefed up the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      76b235c6
  13. 09 Apr, 2015 1 commit
    • Anton Blanchard's avatar
      jump_label: Allow jump labels to be used in assembly · c0ccf6f9
      Anton Blanchard authored
      To use jump labels in assembly we need the HAVE_JUMP_LABEL
      define, so we select a fallback version if the toolchain does
      not support them.
      
      Modify linux/jump_label.h so it can be included by assembly
      files. We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: benh@kernel.crashing.org
      Cc: catalin.marinas@arm.com
      Cc: davem@davemloft.net
      Cc: heiko.carstens@de.ibm.com
      Cc: jbaron@akamai.com
      Cc: linux@arm.linux.org.uk
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: liuj97@gmail.com
      Cc: mgorman@suse.de
      Cc: mmarek@suse.cz
      Cc: mpe@ellerman.id.au
      Cc: paulus@samba.org
      Cc: ralf@linux-mips.org
      Cc: rostedt@goodmis.org
      Cc: schwidefsky@de.ibm.com
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1428551492-21977-2-git-send-email-anton@samba.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c0ccf6f9
  14. 10 Aug, 2014 1 commit
    • Ingo Molnar's avatar
      jump_label: Fix small typos in the documentation · fd3cbdc0
      Ingo Molnar authored
      Was reading through the documentation of this code and noticed
      a few typos, missing commas, etc.
      
      Cc: Jason Baron <jbaron@akamai.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      fd3cbdc0
  15. 04 Jun, 2014 1 commit
  16. 08 Jan, 2014 1 commit
  17. 13 Nov, 2013 1 commit
  18. 19 Oct, 2013 1 commit
    • 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
  19. 09 Aug, 2013 1 commit
  20. 06 Jul, 2012 1 commit
  21. 28 Feb, 2012 1 commit
  22. 24 Feb, 2012 1 commit
    • Ingo Molnar's avatar
      static keys: Introduce 'struct static_key', static_key_true()/false() and... · c5905afb
      Ingo Molnar authored
      static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]()
      
      So here's a boot tested patch on top of Jason's series that does
      all the cleanups I talked about and turns jump labels into a
      more intuitive to use facility. It should also address the
      various misconceptions and confusions that surround jump labels.
      
      Typical usage scenarios:
      
              #include <linux/static_key.h>
      
              struct static_key key = STATIC_KEY_INIT_TRUE;
      
              if (static_key_false(&key))
                      do unlikely code
              else
                      do likely code
      
      Or:
      
              if (static_key_true(&key))
                      do likely code
              else
                      do unlikely code
      
      The static key is modified via:
      
              static_key_slow_inc(&key);
              ...
              static_key_slow_dec(&key);
      
      The 'slow' prefix makes it abundantly clear that this is an
      expensive operation.
      
      I've updated all in-kernel code to use this everywhere. Note
      that I (intentionally) have not pushed through the rename
      blindly through to the lowest levels: the actual jump-label
      patching arch facility should be named like that, so we want to
      decouple jump labels from the static-key facility a bit.
      
      On non-jump-label enabled architectures static keys default to
      likely()/unlikely() branches.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarJason Baron <jbaron@redhat.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: a.p.zijlstra@chello.nl
      Cc: mathieu.desnoyers@efficios.com
      Cc: davem@davemloft.net
      Cc: ddaney.cavm@gmail.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20120222085809.GA26397@elte.huSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c5905afb
  23. 27 Jan, 2012 1 commit
  24. 06 Dec, 2011 2 commits
  25. 25 Oct, 2011 4 commits
  26. 26 Jul, 2011 1 commit
  27. 04 Apr, 2011 1 commit
    • Jason Baron's avatar
      jump label: Introduce static_branch() interface · d430d3d7
      Jason Baron authored
      Introduce:
      
      static __always_inline bool static_branch(struct jump_label_key *key);
      
      instead of the old JUMP_LABEL(key, label) macro.
      
      In this way, jump labels become really easy to use:
      
      Define:
      
              struct jump_label_key jump_key;
      
      Can be used as:
      
              if (static_branch(&jump_key))
                      do unlikely code
      
      enable/disale via:
      
              jump_label_inc(&jump_key);
              jump_label_dec(&jump_key);
      
      that's it!
      
      For the jump labels disabled case, the static_branch() becomes an
      atomic_read(), and jump_label_inc()/dec() are simply atomic_inc(),
      atomic_dec() operations. We show testing results for this change below.
      
      Thanks to H. Peter Anvin for suggesting the 'static_branch()' construct.
      
      Since we now require a 'struct jump_label_key *key', we can store a pointer into
      the jump table addresses. In this way, we can enable/disable jump labels, in
      basically constant time. This change allows us to completely remove the previous
      hashtable scheme. Thanks to Peter Zijlstra for this re-write.
      
      Testing:
      
      I ran a series of 'tbench 20' runs 5 times (with reboots) for 3
      configurations, where tracepoints were disabled.
      
      jump label configured in
      avg: 815.6
      
      jump label *not* configured in (using atomic reads)
      avg: 800.1
      
      jump label *not* configured in (regular reads)
      avg: 803.4
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20110316212947.GA8792@redhat.com>
      Signed-off-by: default avatarJason Baron <jbaron@redhat.com>
      Suggested-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Tested-by: default avatarDavid Daney <ddaney@caviumnetworks.com>
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      d430d3d7
  28. 29 Oct, 2010 1 commit
    • Steven Rostedt's avatar
      jump label: Add work around to i386 gcc asm goto bug · 45f81b1c
      Steven Rostedt authored
      On i386 (not x86_64) early implementations of gcc would have a bug
      with asm goto causing it to produce code like the following:
      
      (This was noticed by Peter Zijlstra)
      
         56 pushl 0
         67 nopl         jmp 0x6f
            popl
            jmp 0x8c
      
         6f              mov
                         test
                         je 0x8c
      
         8c mov
            call *(%esp)
      
      The jump added in the asm goto skipped over the popl that matched
      the pushl 0, which lead up to a quick crash of the system when
      the jump was enabled. The nopl is defined in the asm goto () statement
      and when tracepoints are enabled, the nop changes to a jump to the label
      that was specified by the asm goto. asm goto is suppose to tell gcc that
      the code in the asm might jump to an external label. Here gcc obviously
      fails to make that work.
      
      The bug report for gcc is here:
      
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226
      
      The bug only appears on x86 when not compiled with
      -maccumulate-outgoing-args. This option is always set on x86_64 and it
      is also the work around for a function graph tracer i386 bug.
      (See commit: 746357d6)
      This explains why the bug only showed up on i386 when function graph
      tracer was not enabled.
      
      This patch now adds a CONFIG_JUMP_LABEL option that is default
      off instead of using jump labels by default. When jump labels are
      enabled, the -maccumulate-outgoing-args will be used (causing a
      slightly larger kernel image on i386). This option will exist
      until we have a way to detect if the gcc compiler in use is safe
      to use on all configurations without the work around.
      
      Note, there exists such a test, but for now we will keep the enabling
      of jump label as a manual option.
      
      Archs that know the compiler is safe with asm goto, may choose to
      select JUMP_LABEL and enable it by default.
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Cause-discovered-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Richard Henderson <rth@redhat.com>
      LKML-Reference: <1288028746.3673.11.camel@laptop>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      45f81b1c
  29. 28 Oct, 2010 1 commit
  30. 18 Oct, 2010 2 commits