Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
* 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 rejected. > > 10 to 20 spam posts per day are prevented by this rule. > > And frankly it's totally rediculous to have such a huge CC: list > in the first place, even if the vger spam filter didn't exist. Absolutely agreed - in fact huge Cc: lists are a PITA when committing patches: I have to trim them down to something reasonable, without losing important Cc: entries ... So vger is doing us a service there, and not just by filtering spam. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
* 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 of the Cc list, it was rejected. 10 to 20 spam posts per day are prevented by this rule. And frankly it's totally rediculous to have such a huge CC: list in the first place, even if the vger spam filter didn't exist. Absolutely agreed - in fact huge Cc: lists are a PITA when committing patches: I have to trim them down to something reasonable, without losing important Cc: entries ... So vger is doing us a service there, and not just by filtering spam. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 list, then forwarding or bouncing the email to the remaining > > maintainers Would that work reasonably, or is there some better approach? > > Please use linux-arch, that's what that list is for, notifying arch > maintainers of changes that basically have an impact on every target. Thank you, I have updated that commit as you suggested. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 Would that work reasonably, or is there some better approach? Please use linux-arch, that's what that list is for, notifying arch maintainers of changes that basically have an impact on every target. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 because of the Cc list, it was rejected. > > 10 to 20 spam posts per day are prevented by this rule. > > And frankly it's totally rediculous to have such a huge CC: list > in the first place, even if the vger spam filter didn't exist. > > If you CC: something to netdev, it's going to reach me, you don't need > to CC: me. If just makes for a dup that I have to delete in my inbox, > so you're actually making more work for me in the end. > > That's just one example. Hello, David, 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 Would that work reasonably, or is there some better approach? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 prevented by this rule. And frankly it's totally rediculous to have such a huge CC: list in the first place, even if the vger spam filter didn't exist. If you CC: something to netdev, it's going to reach me, you don't need to CC: me. If just makes for a dup that I have to delete in my inbox, so you're actually making more work for me in the end. That's just one example. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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, spam that would have made it otherwise, but because of the Cc list, it was rejected. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
* 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 copy-and-pasted from this file. > > > > 2. Add long atomic examples alongside the existing atomics. > > > > 3. Prohibit architectures supporting the Linux kernel from > > speculating stores. > > Just me, or is the 3rd patch missing from lkml? It had a Cc: list from hell so vger probably rejected it as spam. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 examples alongside the existing atomics. > > 3.Prohibit architectures supporting the Linux kernel from > speculating stores. Just me, or is the 3rd patch missing from lkml? > 4.Document what ACCESS_ONCE() does along with a number of situations > requiring its use. This was very useful, thanks! :) -- Henrik Austad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 examples alongside the existing atomics. 3.Prohibit architectures supporting the Linux kernel from speculating stores. Just me, or is the 3rd patch missing from lkml? 4.Document what ACCESS_ONCE() does along with a number of situations requiring its use. This was very useful, thanks! :) -- Henrik Austad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
* 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 copy-and-pasted from this file. 2. Add long atomic examples alongside the existing atomics. 3. Prohibit architectures supporting the Linux kernel from speculating stores. Just me, or is the 3rd patch missing from lkml? It had a Cc: list from hell so vger probably rejected it as spam. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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. That is, spam that would have made it otherwise, but because of the Cc list, it was rejected. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 posts per day are prevented by this rule. And frankly it's totally rediculous to have such a huge CC: list in the first place, even if the vger spam filter didn't exist. If you CC: something to netdev, it's going to reach me, you don't need to CC: me. If just makes for a dup that I have to delete in my inbox, so you're actually making more work for me in the end. That's just one example. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 otherwise, but because of the Cc list, it was rejected. 10 to 20 spam posts per day are prevented by this rule. And frankly it's totally rediculous to have such a huge CC: list in the first place, even if the vger spam filter didn't exist. If you CC: something to netdev, it's going to reach me, you don't need to CC: me. If just makes for a dup that I have to delete in my inbox, so you're actually making more work for me in the end. That's just one example. Hello, David, 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 Would that work reasonably, or is there some better approach? Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 remaining maintainers Would that work reasonably, or is there some better approach? Please use linux-arch, that's what that list is for, notifying arch maintainers of changes that basically have an impact on every target. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 smallish CC list, then forwarding or bouncing the email to the remaining maintainers Would that work reasonably, or is there some better approach? Please use linux-arch, that's what that list is for, notifying arch maintainers of changes that basically have an impact on every target. Thank you, I have updated that commit as you suggested. Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 alongside the existing atomics. > > 3.Prohibit architectures supporting the Linux kernel from > speculating stores. > > 4.Document what ACCESS_ONCE() does along with a number of situations > requiring its use. For all four patches in v4: Reviewed-by: Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 supporting the Linux kernel from speculating stores. 4. Document what ACCESS_ONCE() does along with a number of situations requiring its use. Changes from v3: o Fix typos noted by Peter Zijlstra. o Added the documentation about ACCESS_ONCE(), which expands on http://thread.gmane.org/gmane.linux.kernel.mm/82891/focus=14696, ably summarized by Jon Corbet at http://lwn.net/Articles/508991/. Changes from v2: o Update examples so that that load against which the subsequent store is to be ordered is part of the "if" condition. o Add an example showing how the compiler can remove "if" conditions and how to prevent it from doing so. o Add ACCESS_ONCE() to the compiler-barrier section. o Add a sentence noting that transitivity requires smp_mb(). Changes from v1: o Combined with Peter Zijlstra's speculative-store-prohibition patch. o Added more pitfalls to avoid when prohibiting speculative stores, along with how to avoid them. o Applied Josh Triplett's review comments. Thanx, Paul b/Documentation/memory-barriers.txt | 666 1 file changed, 533 insertions(+), 133 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 supporting the Linux kernel from speculating stores. 4. Document what ACCESS_ONCE() does along with a number of situations requiring its use. Changes from v3: o Fix typos noted by Peter Zijlstra. o Added the documentation about ACCESS_ONCE(), which expands on http://thread.gmane.org/gmane.linux.kernel.mm/82891/focus=14696, ably summarized by Jon Corbet at http://lwn.net/Articles/508991/. Changes from v2: o Update examples so that that load against which the subsequent store is to be ordered is part of the if condition. o Add an example showing how the compiler can remove if conditions and how to prevent it from doing so. o Add ACCESS_ONCE() to the compiler-barrier section. o Add a sentence noting that transitivity requires smp_mb(). Changes from v1: o Combined with Peter Zijlstra's speculative-store-prohibition patch. o Added more pitfalls to avoid when prohibiting speculative stores, along with how to avoid them. o Applied Josh Triplett's review comments. Thanx, Paul b/Documentation/memory-barriers.txt | 666 1 file changed, 533 insertions(+), 133 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
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 alongside the existing atomics. 3.Prohibit architectures supporting the Linux kernel from speculating stores. 4.Document what ACCESS_ONCE() does along with a number of situations requiring its use. For all four patches in v4: Reviewed-by: Josh Triplett j...@joshtriplett.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
