Linux Arch

• Thread Index

• Re: [PATCH RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: [PATCH RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: [PATCH RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: [PATCH RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Waiman Long <waiman.long@xxxxxx>
• [BUG] Build error due -fstack-protector-strong not supported by compiler
  • From: Juan Emilio Ledesma Torres <jueleto@xxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Richard Guy Briggs <rgb@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Michael Matz <matz@xxxxxxx>
• Re: [PATCH RESEND 14/14] x86: locks: remove redundant arch_*_relax operations
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• [PATCH RESEND 07/14] m32r: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 04/14] blackfin: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 06/14] ia64: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 10/14] hppa: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 14/14] x86: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 09/14] mips: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 12/14] sh: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 08/14] metag: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 13/14] sparc: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 11/14] s390: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 05/14] cris: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 00/14] spinlock: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 03/14] arm64: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 02/14] ARM: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH RESEND 01/14] ARC: locks: remove redundant arch_*_relax operations
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/4] Sparc: sparc_cpu_model isn't in asm/system.h any more [ver #2]
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/4] Sparc: sparc_cpu_model isn't in asm/system.h any more [ver #2]
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/4] Sparc: sparc_cpu_model isn't in asm/system.h any more
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 02/52] CPU hotplug: Provide lockless versions of callback registration functions
  • From: Toshi Kani <toshi.kani@xxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: David Lang <david@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH 3/6] dma-buf: use reservation objects
  • From: Thomas Hellstrom <thellstrom@xxxxxxxxxx>
• Re: [PATCH 4/6] android: convert sync to fence api, v4
  • From: Thomas Hellstrom <thellstrom@xxxxxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
• Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v2 0/2] generic CPU feature based udev module autoprobing
  • From: "gregkh@xxxxxxxxxxxxxxxxxxx" <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Eric Paris <eparis@xxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Mark Batty <Mark.Batty@xxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Sewell <Peter.Sewell@xxxxxxxxxxxx>
• Re: [PATCH v2 00/52] CPU hotplug: Fix issues with callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Alec Teal <a.teal@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Re: [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• [PATCH v4 2/3] qspinlock, x86: Enable x86-64 to use queue spinlock
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v4 1/3] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v4 3/3] qspinlock, x86: Add x86 specific optimization for 2 contending tasks
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v4 0/3] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <Waiman.Long@xxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Richard Biener <richard.guenther@xxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Re: [PATCH] asm-generic: add sched_setattr/sched_getattr syscalls
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Christian König <deathsimple@xxxxxxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Rob Clark <robdclark@xxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Christian König <deathsimple@xxxxxxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Rob Clark <robdclark@xxxxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Christian König <deathsimple@xxxxxxxxxxx>
• Re: [PATCH 1/6] fence: dma-buf cross-device synchronization (v17)
  • From: Rob Clark <robdclark@xxxxxxxxx>
• Re: [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Rob Clark <robdclark@xxxxxxxxx>
• Re: [PATCH 5/6] reservation: add support for fences to enable cross-device synchronisation
  • From: Rob Clark <robdclark@xxxxxxxxx>
• Re: [PATCH 3/6] dma-buf: use reservation objects
  • From: Rob Clark <robdclark@xxxxxxxxx>
• Re: [PATCH 6/6] dma-buf: add poll support, v2
  • From: Rob Clark <robdclark@xxxxxxxxx>
• [PATCH 6/6] dma-buf: add poll support, v2
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• [PATCH 5/6] reservation: add support for fences to enable cross-device synchronisation
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• [PATCH 4/6] android: convert sync to fence api, v4
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• [PATCH 3/6] dma-buf: use reservation objects
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• [PATCH 1/6] fence: dma-buf cross-device synchronization (v17)
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• [PATCH 0/6] dma-buf synchronization patches
  • From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
• Re: [UPDATED][PATCH v2 46/52] xen, balloon: Fix CPU hotplug callback registration
  • From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
• Re: [PATCH v2 02/52] CPU hotplug: Provide lockless versions of callback registration functions
  • From: Gautham R Shenoy <ego@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] generic CPU feature based udev module autoprobing
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH v2 0/2] generic CPU feature based udev module autoprobing
  • From: "gregkh@xxxxxxxxxxxxxxxxxxx" <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] generic CPU feature based udev module autoprobing
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH v2 38/52] drivers/base/topology.c: Fix CPU hotplug callback registration
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH 19/73] arm: mach-s3c64xx mach-crag6410-module.c is not modular
  • From: Kukjin Kim <kgene.kim@xxxxxxxxxxx>
• [UPDATED][PATCH v2 46/52] xen, balloon: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v2 52/52] net/iucv/iucv.c: Fix CPU hotplug callback registration
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 51/52] net/core/flow.c: Fix CPU hotplug callback registration
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 13/52] sparc, sysfs: Fix CPU hotplug callback registration
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 27/52] x86, pci, amd-bus: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 27/52] x86, pci, amd-bus: Fix CPU hotplug callback registration
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 46/52] xen, balloon: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 46/52] xen, balloon: Fix CPU hotplug callback registration
  • From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
• Re: [PATCH v2 49/52] mm, vmstat: Fix CPU hotplug callback registration
  • From: Rik van Riel <riel@xxxxxxxxxx>
• Re: [PATCH v2 10/52] arm, kvm: Fix CPU hotplug callback registration
  • From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
• Re: [PATCH v2 29/52] x86, kvm: Fix CPU hotplug callback registration
  • From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH v2 06/52] ia64, palinfo: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 09/52] arm, hw-breakpoint: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 04/52] CPU hotplug, perf: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 10/52] arm, kvm: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 11/52] s390, cacheinfo: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 14/52] powerpc, sysfs: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 15/52] x86, msr: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 16/52] x86, cpuid: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 19/52] x86, mce: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 20/52] x86, therm_throt.c: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 24/52] x86, intel, rapl: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 25/52] x86, amd, uncore: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 28/52] x86, oprofile, nmi: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 27/52] x86, pci, amd-bus: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 29/52] x86, kvm: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 30/52] arm64, hw_breakpoint.c: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 31/52] arm64, debug-monitors: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 32/52] powercap, intel-rapl: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 33/52] scsi, bnx2i: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 34/52] scsi, bnx2fc: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 36/52] zsmalloc: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 37/52] acpi-cpufreq: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 40/52] intel-idle: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 41/52] oprofile, nmi-timer: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 42/52] octeon, watchdog: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 43/52] thermal, x86-pkg-temp: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 44/52] hwmon, coretemp: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 45/52] hwmon, via-cputemp: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 46/52] xen, balloon: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 47/52] trace, ring-buffer: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 48/52] profile: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 49/52] mm, vmstat: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 50/52] mm, zswap: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 52/52] net/iucv/iucv.c: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 51/52] net/core/flow.c: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 39/52] clocksource, dummy-timer: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 38/52] drivers/base/topology.c: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 35/52] scsi, fcoe: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 26/52] x86, hpet: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 23/52] x86, intel, cacheinfo: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 22/52] x86, amd, ibs: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 21/52] x86, therm_throt.c: Remove unused therm_cpu_lock
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 17/52] x86, vsyscall: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 18/52] x86, intel, uncore: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 12/52] s390, smp: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 13/52] sparc, sysfs: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 08/52] ia64, err-inject: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 07/52] ia64, topology: Fix CPU hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 05/52] ia64, salinfo: Fix hotplug callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 03/52] Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 02/52] CPU hotplug: Provide lockless versions of callback registration functions
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 01/52] CPU hotplug: Add lockdep annotations to get/put_online_cpus()
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 00/52] CPU hotplug: Fix issues with callback registration
  • From: "Srivatsa S. Bhat" <srivatsa.bhat@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 48/73] drivers/ata: delete non-required instances of include <linux/init.h>
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 4/4] ARM: Delete asm/system.h
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• [PATCH 4/4] ARM: Delete asm/system.h
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 1/4] Clean asm/system.h from docs
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 2/4] Sparc: sparc_cpu_model isn't in asm/system.h any more
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 3/4] UM: arch_align_stack() moved to asm/exec.h
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 0/4] Final asm/system.h cleanups
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH] jump label: constify lookup functions
  • From: Sasha Levin <sasha.levin@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 58/73] drivers/mfd: delete non-required instances of include <linux/init.h>
  • From: Lee Jones <lee.jones@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs
  • From: Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>
• Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs
  • From: Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs
  • From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
• Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH v2 1/2] cpu: add generic support for CPU feature based module autoloading
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH v2 2/2] x86: align x86 arch with generic CPU modalias handling
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH v2 0/2] generic CPU feature based udev module autoprobing
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 01/73] init: delete the __cpuinit related stubs
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 72/73] drivers: delete remaining non-required instances of <linux/init.h>
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Jonas Bonn <jonas.bonn@xxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 3/5] arch: s/smp_mb__(before|after)_(atomic|clear)_(dec,inc,bit)/smp_mb__\1/g
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Torvald Riegel <triegel@xxxxxxxxxx>
• Re: [PATCH 54/73] drivers/leds: delete non-required instances of include <linux/init.h>
  • From: Bryan Wu <cooloney@xxxxxxxxx>
• Re: [PATCH 54/73] drivers/leds: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 54/73] drivers/leds: delete non-required instances of include <linux/init.h>
  • From: Bryan Wu <cooloney@xxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Ramana Radhakrishnan <ramrad01@xxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 0/5] arch: atomic rework
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 4/5] arch: Generic atomic.h cleanup
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [RFC][PATCH 2/5] arc,hexagon: Delete asm/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [RFC][PATCH 1/5] ia64: Fix up smp_mb__{before,after}_clear_bit
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [RFC][PATCH 5/5] arch: Sanitize atomic_t bitwise ops
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [RFC][PATCH 0/5] arch: atomic rework
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: mips octeon memory model questions
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 0/2] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: mips octeon memory model questions
  • From: David Daney <ddaney@xxxxxxxxxxxxxxxxxx>
• Re: mips octeon memory model questions
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: mips octeon memory model questions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: mips octeon memory model questions
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: mips octeon memory model questions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• mips octeon memory model questions
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH] ia64: Fix atomic ops vs memory barriers
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC][PATCH] ia64: Fix atomic ops vs memory barriers
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC][PATCH] ia64: Fix atomic ops vs memory barriers
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [RFC][PATCH] ia64: Fix atomic ops vs memory barriers
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH] asm-generic: add sched_setattr/sched_getattr syscalls
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 0/2] qspinlock: Introducing a 4-byte queue spinlock
  • From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Davidlohr Bueso <davidlohr@xxxxxx>
• Re: [PATCH 27/73] drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
  • From: Mike Turquette <mturquette@xxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• [PATCH 1/3] kconfig: consolidate arch-specific seccomp options
  • From: Dave Hansen <dave@xxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH] kconfig: consolidate arch-specific seccomp options
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH v3 2/2] qspinlock, x86: Enable x86-64 to use queue spinlock
  • From: Rik van Riel <riel@xxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Rik van Riel <riel@xxxxxxxxxx>
• Re: [PATCH] kconfig: consolidate arch-specific seccomp options
  • From: Dave Hansen <dave@xxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v3 0/2] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH] kconfig: consolidate arch-specific seccomp options
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] kconfig: consolidate arch-specific seccomp options
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v3 0/2] qspinlock: Introducing a 4-byte queue spinlock
  • From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3] arch: use ASM_NL instead of ';' for assembler new line character in the macro
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• [PATCH] kconfig: consolidate arch-specific seccomp options
  • From: Dave Hansen <dave@xxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH 49/73] drivers/mtd: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs
  • From: Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH 49/73] drivers/mtd: delete non-required instances of include <linux/init.h>
  • From: Brian Norris <computersforpeace@xxxxxxxxx>
• [PATCH v3 2/2] qspinlock, x86: Enable x86-64 to use queue spinlock
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v3 0/2] qspinlock: Introducing a 4-byte queue spinlock
  • From: Waiman Long <Waiman.Long@xxxxxx>
• Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3] arch: use ASM_NL instead of ';' for assembler new line character in the macro
  • From: Michal Marek <mmarek@xxxxxxx>
• [PATCH] jump label: constify lookup functions
  • From: Sasha Levin <sasha.levin@xxxxxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 01/13] sched: Add 3 new scheduler syscalls to support an extended scheduling parameters ABI
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3] arch: use ASM_NL instead of ';' for assembler new line character in the macro
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH v11 1/4] qrwlock: A queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v11 4/4] qrwlock: Use the mcs_spinlock helper functions for MCS queuing
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH 51/73] drivers/i2c: delete non-required instances of include <linux/init.h>
  • From: Wolfram Sang <wsa@xxxxxxxxxxxxx>
• Re: [PATCH 30/73] drivers/i2c: busses/i2c-acorn.c is tristate and should use module.h
  • From: Wolfram Sang <wsa@xxxxxxxxxxxxx>
• Re: [PATCH 51/73] drivers/i2c: delete non-required instances of include <linux/init.h>
  • From: Jean Delvare <khali@xxxxxxxxxxxx>
• Re: [PATCH v9 6/6] MCS Lock: Allow architecture specific asm files to be used for contended case
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v9 6/6] MCS Lock: Allow architecture specific asm files to be used for contended case
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH v11 4/4] qrwlock: Use the mcs_spinlock helper functions for MCS queuing
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v11 1/4] qrwlock: A queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH v11 2/4] qrwlock, x86: Enable x86 to use queue read/write lock
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v11 1/4] qrwlock: A queue read/write lock implementation
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v11 4/4] qrwlock: Use the mcs_spinlock helper functions for MCS queuing
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v11 3/4] qrwlock, x86: Add char and short as atomic data type in x86
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v11 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <Waiman.Long@xxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH 50/73] drivers/hwmon: delete non-required instances of include <linux/init.h>
  • From: Jean Delvare <khali@xxxxxxxxxxxx>
• Re: [PATCH 19/73] arm: mach-s3c64xx mach-crag6410-module.c is not modular
  • From: Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH 52/73] drivers/pinctrl: delete non-required instances of include <linux/init.h>
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [RFC][PATCH] MIPS: VPE: Remove vpe_getuid and vpe_getgid
  • From: Deng-Cheng Zhu <dengcheng.zhu@xxxxxxxxxx>
• [PATCH v10 2/4] qrwlock, x86: Enable x86 to use queue read/write lock
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v10 1/4] qrwlock: A queue read/write lock implementation
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v10 4/4] qrwlock: Use the mcs_spinlock helper functions for MCS queuing
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v10 3/4] qrwlock, x86: Add char and short as atomic data type in x86
  • From: Waiman Long <Waiman.Long@xxxxxx>
• [PATCH v10 0/4] Introducing a queue read/write lock implementation
  • From: Waiman Long <Waiman.Long@xxxxxx>
• Re: [PATCH 65/73] drivers/edac: delete non-required instances of include <linux/init.h>
  • From: Borislav Petkov <bp@xxxxxxxxx>
• [PATCH RFC 1/4] drivers: of: add initialization code for reserved memory
  • From: Josh Cartwright <joshc@xxxxxxxxxxxxxx>
• [PATCH RFC 0/4] reserved-memory regions/CMA in devicetree, again
  • From: Josh Cartwright <joshc@xxxxxxxxxxxxxx>
• Re: [PATCH v9 6/6] MCS Lock: Allow architecture specific asm files to be used for contended case
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH] bitops: fix signedness of compile-time hweight implementations
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH] bitops: fix signedness of compile-time hweight implementations
  • From: Paul Walmsley <pwalmsley@xxxxxxxxxx>
• Re: [PATCH 1/1] Per socket value for max datagram queue length
  • From: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] Per socket value for max datagram queue length
  • From: Daniel Borkmann <dborkman@xxxxxxxxxx>
• Re: [PATCH 1/1] Per socket value for max datagram queue length
  • From: Eric Dumazet <eric.dumazet@xxxxxxxxx>
• Re: [PATCH 1/1] Per socket value for max datagram queue length
  • From: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
• [PATCH 1/1] Per socket value for max datagram queue length
  • From: Dan Ballard <dan@xxxxxxxxxxxx>
• Re: [PATCH 0/8] Update kernel uabi header files for x32
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 01/73] init: delete the __cpuinit related stubs
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxx>
• Re: [PATCH 68/73] drivers/cpufreq: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: [PATCH 68/73] drivers/cpufreq: delete non-required instances of <linux/init.h>
  • From: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: Waiman Long <waiman.long@xxxxxx>
• Re: [PATCH 10/73] powerpc: use device_initcall for registering rtc devices
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 31/73] module: relocate module_init from init.h to module.h
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 31/73] module: relocate module_init from init.h to module.h
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [PATCH 37/73] alpha: delete non-required instances of <linux/init.h>
  • From: Richard Henderson <rth@xxxxxxxxxxx>
• Re: [PATCH 22/73] alpha: don't use module_init for non-modular core code
  • From: Richard Henderson <rth@xxxxxxxxxxx>
• Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 31/73] module: relocate module_init from init.h to module.h
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 10/73] powerpc: use device_initcall for registering rtc devices
  • From: Geoff Levand <geoff@xxxxxxxxxxxxx>
• [PATCH v9 5/6] MCS Lock: Order the header files in Kbuild of each architecture in alphabetical order
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• [PATCH v9 3/6] MCS Lock: Optimizations and extra comments
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• [PATCH v9 6/6] MCS Lock: Allow architecture specific asm files to be used for contended case
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• [PATCH v9 4/6] MCS Lock: Allow architectures to hook in to contended paths
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• [PATCH v9 2/6] MCS Lock: Restructure the MCS lock defines and locking code into its own file
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• [PATCH v9 1/6] MCS Lock: Barrier corrections
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• [PATCH v9 0/6] MCS Lock: MCS lock code cleanup and optimizations
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• Re: [PATCH 45/73] acpi: delete non-required instances of include <linux/init.h>
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• Re: [PATCH 67/73] drivers/base: delete non-required instances of include <linux/init.h>
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• Re: [PATCH 35/73] sparc: delete non-required instances of include <linux/init.h>
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 53/73] drivers/isdn: delete non-required instances of include <linux/init.h>
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 23/73] sparc: don't use module_init in non-modular pci.c code
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 50/73] drivers/hwmon: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 60/73] drivers/bluetooth: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH v8 6/6] MCS Lock: Allow architecture specific asm files to be used for contended case
  • From: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
• Re: [PATCH 12/73] powerpc: kvm e500/44x is not modular, so don't use module_init
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 20/73] arm: use subsys_initcall in non-modular pl320 IPC code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 60/73] drivers/bluetooth: delete non-required instances of include <linux/init.h>
  • From: Marcel Holtmann <marcel@xxxxxxxxxxxx>
• [PATCH 03/73] fs/notify: don't use module_init for non-modular inotify_user code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 04/73] netfilter: don't use module_init/exit in core IPV4 code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 05/73] x86: don't use module_init in non-modular intel_mid_vrtc.c
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 07/73] x86: replace __init_or_module with __init in non-modular vsmp_64.c
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 06/73] x86: don't use module_init for non-modular core bootflag code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 08/73] drivers/tty/hvc: don't use module_init in non-modular hyp. console code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 09/73] staging: don't use module_init in non-modular ion_dummy_driver.c
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 12/73] powerpc: kvm e500/44x is not modular, so don't use module_init
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 11/73] powerpc: book3s KVM can be modular so it should use module.h
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 14/73] powerpc: don't use module_init for non-modular core hugetlb code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 15/73] powerpc: don't use module_init in non-modular 83xx suspend code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 13/73] powerpc: use subsys_initcall for Freescale Local Bus
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 25/73] ia64: don't use module_init for non-modular core kernel/mca.c code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 26/73] ia64: don't use module_init in non-modular sim/simscsi.c code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 20/73] arm: use subsys_initcall in non-modular pl320 IPC code
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• [PATCH 22/73] alpha: don't use module_init for non-modular core code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 73/73] include: remove needless instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 44/73] spi: delete non-required instances of include <linux/init.h>
  • From: Mark Brown <broonie@xxxxxxxxxx>
• [PATCH 24/73] m68k: don't use module_init in non-modular mvme16x/rtc.c code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 32/73] logo: emit "#include <linux/init.h> in autogenerated C file
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 31/73] module: relocate module_init from init.h to module.h
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 30/73] drivers/i2c: busses/i2c-acorn.c is tristate and should use module.h
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 67/73] drivers/base: delete non-required instances of include <linux/init.h>
  • From: Pavel Machek <pavel@xxxxxx>
• [PATCH 35/73] sparc: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 16/73] arm: include module.h in drivers/bus/omap_l3_smx.c
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 20/73] arm: use subsys_initcall in non-modular pl320 IPC code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 18/73] arm: fix implicit #include <linux/init.h> in entry asm.
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 37/73] alpha: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 44/73] spi: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 41/73] video: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 28/73] cpuidle: don't use modular platform register in non-modular ARM drivers
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 21/73] arm: don't use module_init in non-modular mach-vexpress/spc.c code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 48/73] drivers/ata: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 40/73] watchdog: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 73/73] include: remove needless instances of <linux/init.h>
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 50/73] drivers/hwmon: delete non-required instances of include <linux/init.h>
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 34/73] mips: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 52/73] drivers/pinctrl: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 19/73] arm: mach-s3c64xx mach-crag6410-module.c is not modular
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 33/73] arm: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 53/73] drivers/isdn: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 38/73] blackfin: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 17/73] arm: fix implicit module.h use in mach-at91 gpio.h
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 67/73] drivers/base: delete non-required instances of include <linux/init.h>
  • From: Mark Brown <broonie@xxxxxxxxxx>
• [PATCH 49/73] drivers/mtd: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 59/73] drivers/gpio: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 62/73] drivers/crypto: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 39/73] powerpc: delete another unrequired instance of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 57/73] drivers/infiniband: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 61/73] drivers/mmc: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 55/73] drivers/pcmcia: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 46/73] drivers/power: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 64/73] drivers/misc: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 54/73] drivers/leds: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 58/73] drivers/mfd: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 69/73] drivers/pci: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 60/73] drivers/bluetooth: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 63/73] drivers/platform: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 68/73] drivers/cpufreq: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 70/73] drivers/dma: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 67/73] drivers/base: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 72/73] drivers: delete remaining non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 73/73] include: remove needless instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 10/73] powerpc: use device_initcall for registering rtc devices
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 71/73] drivers/gpu: delete non-required instances of <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 56/73] drivers/char: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 51/73] drivers/i2c: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 43/73] scsi: delete non-required instances of include <linux/init.h>
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>