Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-10 Thread Ingo Molnar
* David Miller wrote: > From: Steven Rostedt > Date: Thu, 5 Dec 2013 08:51:46 -0500 > > > I wish vger wouldn't do that. I wonder how much spam is really flagged > > by this one characteristic alone. That is, spam that would have made it > > otherwise, but because of the Cc list, it was

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-10 Thread Ingo Molnar
* David Miller da...@davemloft.net wrote: From: Steven Rostedt rost...@goodmis.org Date: Thu, 5 Dec 2013 08:51:46 -0500 I wish vger wouldn't do that. I wonder how much spam is really flagged by this one characteristic alone. That is, spam that would have made it otherwise, but because

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Paul E. McKenney
On Thu, Dec 05, 2013 at 01:44:06PM -0500, David Miller wrote: > From: "Paul E. McKenney" > Date: Thu, 5 Dec 2013 10:18:34 -0800 > > > The situation that leads me to use a large CC list is when I am doing > > something that affects all architectures. I could imagine keeping a > > smallish CC

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread David Miller
From: "Paul E. McKenney" Date: Thu, 5 Dec 2013 10:18:34 -0800 > The situation that leads me to use a large CC list is when I am doing > something that affects all architectures. I could imagine keeping a > smallish CC list, then forwarding or bouncing the email to the remaining > maintainers

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Paul E. McKenney
On Thu, Dec 05, 2013 at 01:05:24PM -0500, David Miller wrote: > From: Steven Rostedt > Date: Thu, 5 Dec 2013 08:51:46 -0500 > > > I wish vger wouldn't do that. I wonder how much spam is really flagged > > by this one characteristic alone. That is, spam that would have made it > > otherwise, but

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread David Miller
From: Steven Rostedt Date: Thu, 5 Dec 2013 08:51:46 -0500 > I wish vger wouldn't do that. I wonder how much spam is really flagged > by this one characteristic alone. That is, spam that would have made it > otherwise, but because of the Cc list, it was rejected. 10 to 20 spam posts per day are

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Steven Rostedt
On Thu, 5 Dec 2013 13:28:51 +0100 Ingo Molnar wrote: > > Just me, or is the 3rd patch missing from lkml? > > It had a Cc: list from hell so vger probably rejected it as spam. > I wish vger wouldn't do that. I wonder how much spam is really flagged by this one characteristic alone. That is,

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Ingo Molnar
* Henrik Austad wrote: > On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: > > Hello! > > Hi Paul, > > > This series applies some long-needed updates to memory-barriers.txt: > > > > 1. Add ACCESS_ONCE() calls where needed to ensure their inclusion > > in code

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Henrik Austad
On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: > Hello! Hi Paul, > This series applies some long-needed updates to memory-barriers.txt: > > 1.Add ACCESS_ONCE() calls where needed to ensure their inclusion > in code copy-and-pasted from this file. > > 2.Add long

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Henrik Austad
On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: Hello! Hi Paul, This series applies some long-needed updates to memory-barriers.txt: 1.Add ACCESS_ONCE() calls where needed to ensure their inclusion in code copy-and-pasted from this file. 2.Add long atomic

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Ingo Molnar
* Henrik Austad hen...@austad.us wrote: On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: Hello! Hi Paul, This series applies some long-needed updates to memory-barriers.txt: 1. Add ACCESS_ONCE() calls where needed to ensure their inclusion in code

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Steven Rostedt
On Thu, 5 Dec 2013 13:28:51 +0100 Ingo Molnar mi...@kernel.org wrote: Just me, or is the 3rd patch missing from lkml? It had a Cc: list from hell so vger probably rejected it as spam. I wish vger wouldn't do that. I wonder how much spam is really flagged by this one characteristic alone.

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread David Miller
From: Steven Rostedt rost...@goodmis.org Date: Thu, 5 Dec 2013 08:51:46 -0500 I wish vger wouldn't do that. I wonder how much spam is really flagged by this one characteristic alone. That is, spam that would have made it otherwise, but because of the Cc list, it was rejected. 10 to 20 spam

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Paul E. McKenney
On Thu, Dec 05, 2013 at 01:05:24PM -0500, David Miller wrote: From: Steven Rostedt rost...@goodmis.org Date: Thu, 5 Dec 2013 08:51:46 -0500 I wish vger wouldn't do that. I wonder how much spam is really flagged by this one characteristic alone. That is, spam that would have made it

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread David Miller
From: Paul E. McKenney paul...@linux.vnet.ibm.com Date: Thu, 5 Dec 2013 10:18:34 -0800 The situation that leads me to use a large CC list is when I am doing something that affects all architectures. I could imagine keeping a smallish CC list, then forwarding or bouncing the email to the

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-05 Thread Paul E. McKenney
On Thu, Dec 05, 2013 at 01:44:06PM -0500, David Miller wrote: From: Paul E. McKenney paul...@linux.vnet.ibm.com Date: Thu, 5 Dec 2013 10:18:34 -0800 The situation that leads me to use a large CC list is when I am doing something that affects all architectures. I could imagine keeping a

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-04 Thread Josh Triplett
On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: > Hello! > > This series applies some long-needed updates to memory-barriers.txt: > > 1.Add ACCESS_ONCE() calls where needed to ensure their inclusion > in code copy-and-pasted from this file. > > 2.Add long atomic

[PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-04 Thread Paul E. McKenney
Hello! This series applies some long-needed updates to memory-barriers.txt: 1. Add ACCESS_ONCE() calls where needed to ensure their inclusion in code copy-and-pasted from this file. 2. Add long atomic examples alongside the existing atomics. 3. Prohibit architectures

[PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-04 Thread Paul E. McKenney
Hello! This series applies some long-needed updates to memory-barriers.txt: 1. Add ACCESS_ONCE() calls where needed to ensure their inclusion in code copy-and-pasted from this file. 2. Add long atomic examples alongside the existing atomics. 3. Prohibit architectures

Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates

2013-12-04 Thread Josh Triplett
On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: Hello! This series applies some long-needed updates to memory-barriers.txt: 1.Add ACCESS_ONCE() calls where needed to ensure their inclusion in code copy-and-pasted from this file. 2.Add long atomic examples