...
Thanx, Paul
Best regards,
Oliver
Paul E. McKenney wrote:
On Wed, May 16, 2007 at 04:51:02PM +0200, Urs Thuermann wrote:
This patch adds the CAN core functionality but no protocols or drivers.
No protocol implementations are included here. They come
On Mon, Jun 19, 2006 at 03:20:10PM -0700, Andrew Morton wrote:
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=6682
Summary: BUG: soft lockup detected on CPU#0! / ksoftirqd takse
100% CPU
Kernel Version: 2.6.15.6
was declared guilty for a breakage or in any other way involved
with one or more of these issues.
[ . . . ]
Subject: BUG: spinlock recursion on 2.6.14-mm2 when oprofiling
References : http://lkml.org/lkml/2005/11/18/95
Submitter : Wu Fengguang [EMAIL PROTECTED]
Handled-By : Paul E. McKenney
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest
entry cannot still be in use by another CPU. This might sounds as a
violation
of RCU rules,
On Fri, Jan 06, 2006 at 06:19:15PM +0100, Eric Dumazet wrote:
Paul E. McKenney a écrit :
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot
On Sat, Jan 07, 2006 at 12:36:25AM -0800, David S. Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:53:52 +0100
I have no problem with this, since the biggest server I have is 4
way, but are you sure big machines wont suffer from this single
spinlock ?
It
On Tue, Feb 27, 2007 at 09:56:57AM -0800, David Miller wrote:
From: Patrick McHardy [EMAIL PROTECTED]
Date: Tue, 27 Feb 2007 18:48:19 +0100
[NET]: Handle disabled preemption in gfp_any()
ctnetlink uses netlink_unicast from an atomic_notifier_chain
(which is called within a RCU read
On Fri, Mar 16, 2007 at 01:38:31PM +0100, Robert Olsson wrote:
Hello, Just discussed this Patrick...
We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete
both are holding RTNL. So there shouldn't be need for this preempt stuff.
This is assumed to a leftover from an
On Wed, Aug 09, 2006 at 11:31:42AM -0700, Stephen Hemminger wrote:
Replace the gross custom locking done in socket code for net_family[]
with simple RCU usage. Some reordering necessary to avoid sleep
issues with sock_alloc.
Definitely a good use of RCU from a read-intensive standpoint -- does
On Thu, Aug 10, 2006 at 01:28:27PM -0700, Stephen Hemminger wrote:
On Wed, Aug 09, 2006 at 11:31:42AM -0700, Stephen Hemminger wrote:
Replace the gross custom locking done in socket code for net_family[]
with simple RCU usage. Some reordering necessary to avoid sleep
issues with
On Thu, Jul 26, 2007 at 11:49:42AM +0100, Stephen Hemminger wrote:
Whitespace cleanup run code through lindent then cleanup results.
Applys after other two patches.
--- a/net/ipv4/fib_trie.c 2007-07-26 10:17:21.0 +0100
+++ b/net/ipv4/fib_trie.c 2007-07-26 11:47:52.0
On Thu, Jul 26, 2007 at 09:56:30PM -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 08:44:21 -0700 Paul E. McKenney [EMAIL PROTECTED]
wrote:
On Thu, Jul 26, 2007 at 11:49:42AM +0100, Stephen Hemminger wrote:
Whitespace cleanup run code through lindent then cleanup results.
Applys after
On Wed, Aug 08, 2007 at 06:48:24PM -0700, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Thu, 09 Aug 2007 09:03:27 +0800
Such loops should always use something like cpu_relax() which comes
with a barrier.
This is an excellent point.
And it needs to be weighed with the
On Thu, Aug 09, 2007 at 09:24:42AM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on alpha.
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific
On Thu, Aug 09, 2007 at 10:53:14AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact that
atomic_set() used
On Thu, Aug 09, 2007 at 11:24:22AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 10:53:14AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty trick, but the C standard
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
If you're depending on volatile writes
being visible to other CPUs, you're screwed either way, because the CPU
On Thu, Aug 09, 2007 at 03:24:40PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
If you're depending on volatile
On Fri, Aug 10, 2007 at 11:08:20AM +0200, Andi Kleen wrote:
On Friday 10 August 2007 10:21:46 Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help
On Fri, Aug 10, 2007 at 03:49:03PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 03:24:40PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp architectures, I'm concerned about interacting with interrupt
handlers. Some drivers do use atomic_*
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Paul E. McKenney wrote:
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote
On Wed, Aug 15, 2007 at 12:01:54AM +0200, Arnd Bergmann wrote:
On Tuesday 14 August 2007, Paul E. McKenney wrote:
#define order(x) asm volatile( : +m (x))
There was something very similar discussed earlier in this thread,
with quite a bit of debate as to exactly what the m flag should
On Wed, Aug 15, 2007 at 04:38:54AM +0530, Satyam Sharma wrote:
On Tue, 14 Aug 2007, Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t
On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
On Wed, 15 Aug 2007, Stefan Richter wrote:
Satyam Sharma wrote:
On Wed, 15 Aug 2007, Stefan Richter wrote:
Doesn't atomic WRT all processors require volatility?
No, it definitely doesn't. Why should it?
Atomic
On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
Do we really need another set of APIs? Can you give even one example
where the pre-existing volatile semantics are causing enough of a problem
to justify adding
On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
Herbert Xu wrote:
On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
I don't know if this here is affected:
[...something like]
b = atomic_read(a);
for (i = 0; i 4; i++) {
On Wed, Aug 15, 2007 at 10:48:28PM +0530, Satyam Sharma wrote:
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
Do we really need another set of APIs? Can you
On Wed, Aug 15, 2007 at 07:19:57PM +0100, David Howells wrote:
Herbert Xu [EMAIL PROTECTED] wrote:
Let's turn this around. Can you give a single example where
the volatile semantics is needed in a legitimate way?
Accessing H/W registers? But apart from that...
Communicating between
On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
How does the compiler know that msleep() has got barrier()s?
Because msleep_interruptible() is in a separate compilation unit,
the compiler has to assume that it might modify any arbitrary global.
No; compilation units
On Wed, Aug 15, 2007 at 11:25:05PM +0530, Satyam Sharma wrote:
Hi Paul,
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
[...]
No, I'd actually prefer something like what Christoph Lameter suggested,
i.e. users
On Wed, Aug 15, 2007 at 08:51:58PM +0200, Segher Boessenkool wrote:
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use it.
rmb() orders *any* two reads; that includes two reads from the same
location.
On Thu, Aug 16, 2007 at 01:24:42AM +0530, Satyam Sharma wrote:
[ The Cc: list scares me. Should probably trim it. ]
Trim away! ;-)
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
How does the compiler know that msleep
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
Paul E. McKenney wrote:
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
I prefer burying barriers into other
On Wed, Aug 15, 2007 at 09:46:55PM +0200, Segher Boessenkool wrote:
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
On Wed, Aug 15, 2007 at 10:13:49PM +0200, Segher Boessenkool wrote:
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
On Wed, Aug 15, 2007 at 10:52:53PM +0200, Segher Boessenkool wrote:
I think this was just terminology confusion here again. Isn't any
code
that it cannot currently see the same as another compilation unit,
and wouldn't the compilation unit itself expand if we ask gcc to
compile more than one
On Wed, Aug 15, 2007 at 11:05:35PM +0200, Segher Boessenkool wrote:
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit boundaries just fine, if you tell it to
compile more than one compilation unit at once.
Last I checked, the Linux kernel build system
On Thu, Aug 16, 2007 at 07:40:21AM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 12:13:12PM -0400, Chris Snook wrote:
Part of the motivation here is to fix heisenbugs. If I knew where they
By the same token we should probably disable optimisations
altogether since that too can create
On Thu, Aug 16, 2007 at 07:41:46AM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 11:45:20AM -0700, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 07:19:57PM +0100, David Howells wrote:
Herbert Xu [EMAIL PROTECTED] wrote:
Let's turn this around. Can you give a single example
On Thu, Aug 16, 2007 at 08:12:48AM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 04:53:35PM -0700, Paul E. McKenney wrote:
Communicating between process context and interrupt/NMI handlers using
per-CPU variables.
Remeber we're talking about atomic_read/atomic_set. Please
On Thu, Aug 16, 2007 at 08:30:23AM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 05:23:10PM -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 08:12:48AM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 04:53:35PM -0700, Paul E. McKenney wrote:
Communicating between process
On Wed, Aug 15, 2007 at 05:42:07PM -0700, Christoph Lameter wrote:
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
Seems to me that we face greater chance of confusion without the
volatile than with, particularly as compiler optimizations become
more aggressive. Yes, we could simply disable
On Wed, Aug 15, 2007 at 05:26:34PM -0700, Christoph Lameter wrote:
On Thu, 16 Aug 2007, Paul Mackerras wrote:
In the kernel we use atomic variables in precisely those situations
where a variable is potentially accessed concurrently by multiple
CPUs, and where each CPU needs to see updates
On Thu, Aug 16, 2007 at 08:53:16AM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 05:49:50PM -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 08:30:23AM +0800, Herbert Xu wrote:
Thanks. But I don't need a summary of the thread, I'm asking
for an extant code snippet in our
On Wed, Aug 15, 2007 at 05:59:41PM -0700, Christoph Lameter wrote:
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
The volatile cast should not disable all that many optimizations,
for example, it is much less hurtful than barrier(). Furthermore,
the main optimizations disabled (pulling
On Thu, Aug 16, 2007 at 03:23:28AM +0200, Segher Boessenkool wrote:
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit boundaries just fine, if you tell it to
compile more than one compilation unit at once.
Last I checked, the Linux kernel build system
On Thu, Aug 16, 2007 at 11:09:25AM +1000, Nick Piggin wrote:
Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
Especially since several big architectures don't have volatile in their
atomic_get and _set, I think it would be a step backwards to add them
On Thu, Aug 16, 2007 at 03:30:44AM +0200, Segher Boessenkool wrote:
Part of the motivation here is to fix heisenbugs. If I knew where
they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Precisely the point -- use of volatile
On Wed, Aug 15, 2007 at 06:41:40PM -0700, Christoph Lameter wrote:
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
Understood. My point is not that the impact is precisely zero, but
rather that the impact on optimization is much less hurtful than the
problems that could arise otherwise
On Thu, Aug 16, 2007 at 10:11:05AM +0800, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 12:05:56PM +1000, Paul Mackerras wrote:
Herbert Xu writes:
See sk_stream_mem_schedule in net/core/stream.c:
/* Under limit. */
if (atomic_read(sk-sk_prot-memory_allocated)
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
There seem to be some unbalanced rcu_read_{,un}lock() issues of late,
how about doing something like this:
This will break when rcu_read_lock() and rcu_read_unlock() are invoked
from NMI/SMI handlers -- the raw_local_irq_save()
On Thu, Aug 16, 2007 at 06:42:50PM +0800, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 12:31:03PM +0200, Stefan Richter wrote:
PS: Just to clarify, I'm not speaking for the volatile modifier. I'm
not speaking for any particular implementation of atomic_t and its
accessors at all. All I
On Thu, Aug 16, 2007 at 11:54:54AM -0700, Christoph Lameter wrote:
On Thu, 16 Aug 2007, Paul Mackerras wrote:
So I don't see any good reason to make the atomic API more complex by
having volatile and non-volatile versions of atomic_read. It
should just have the volatile behaviour.
If
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
The compiler can also reorder non-volatile accesses. For an example
patch that cares about this, please see:
http://lkml.org/lkml/2007/8/7/280
On Thu, Aug 16, 2007 at 01:20:26PM -0700, Christoph Lameter wrote:
On Thu, 16 Aug 2007, Chris Snook wrote:
atomic_dec() already has volatile behavior everywhere, so this is
semantically
okay, but this code (and any like it) should be calling cpu_relax() each
iteration through the loop,
On Fri, Aug 17, 2007 at 09:28:00AM +0800, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
Yep. Or you can use atomic_dec_return() instead of using a barrier.
Or you could use smp_mb__{before,after}_atomic_dec.
Yep. That would be an example
On Thu, Aug 16, 2007 at 08:42:23PM -0700, Linus Torvalds wrote:
On Fri, 17 Aug 2007, Paul Mackerras wrote:
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions) for a G5 config.
One of the things that volatile generally
On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
The compiler can also reorder non-volatile
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
There seem to be some unbalanced rcu_read_{,un}lock() issues of late,
how about doing something
On Fri, Aug 17, 2007 at 08:53:57AM -0700, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
There seem to be some
On Sat, Aug 18, 2007 at 12:01:38AM +0530, Satyam Sharma wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote
On Fri, Aug 17, 2007 at 11:54:33AM -0700, Arjan van de Ven wrote:
On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:
Linus Torvalds wrote:
- in other words, the *only* possible meaning for volatile is a purely
single-CPU meaning. And if you only have a single CPU involved
On Thu, Aug 16, 2007 at 08:50:30PM -0700, Linus Torvalds wrote:
Just try it yourself:
volatile int i;
int j;
int testme(void)
{
return i = 1;
}
int testme2(void)
{
return j = 1;
}
and compile with all
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten that I'd already filed that bug more
than six years ago until
On Fri, Aug 17, 2007 at 09:13:35PM -0700, Linus Torvalds wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
No code does (or would do, or should do):
x.counter++;
on an atomic_t x; anyway.
That's just an example of a general problem.
No, you don't use x.counter++. But
On Fri, Aug 17, 2007 at 06:24:15PM -0700, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever
On Fri, Aug 17, 2007 at 01:48:09PM -0500, Corey Minyard wrote:
Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote
On Sat, Aug 18, 2007 at 03:41:13PM -0700, Linus Torvalds wrote:
On Sat, 18 Aug 2007, Paul E. McKenney wrote:
One of the gcc guys claimed that he thought that the two-instruction
sequence would be faster on some x86 machines. I pointed out that
there might be a concern about code
On Tue, Aug 21, 2007 at 01:02:01AM +0200, Segher Boessenkool wrote:
And no, RMW on MMIO isn't problematic at all, either.
An RMW op is a read op, a modify op, and a write op, all rolled
into one opcode. But three actual operations.
Maybe for some CPUs, but not all. ARM for instance can't
On Tue, Aug 21, 2007 at 04:48:51PM +0200, Segher Boessenkool wrote:
Let me say it more clearly: On ARM, it is impossible to perform atomic
operations on MMIO space.
Actually, no one is suggesting that we try to do that at all.
The discussion about RMW ops on MMIO space started with a
On Tue, Aug 21, 2007 at 06:51:16PM -0400, [EMAIL PROTECTED] wrote:
On Tue, 21 Aug 2007 09:16:43 PDT, Paul E. McKenney said:
I agree that instant gratification is hard to come by when synching
up compiler and kernel versions. Nonetheless, it should be possible
to create APIs
On Mon, Aug 27, 2007 at 08:36:35AM +0200, Jarek Poplawski wrote:
On 22-08-2007 19:03, Paul E. McKenney wrote:
On Wed, Aug 22, 2007 at 05:41:11PM +0200, Adrian Bunk wrote:
On Wed, Aug 22, 2007 at 05:30:13PM +0200, Gabriel C wrote:
Got it with a randconfig (
http://194.231.229.228/kernel
On Fri, Sep 07, 2007 at 03:27:15PM +0200, Johannes Berg wrote:
On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
Looks good to me from an RCU viewpoint. I cannot claim familiarity with
this code. I therefore especially like the indications of where RTNL
is held
On Sat, Sep 08, 2007 at 03:15:34PM -0600, Eric W. Biederman wrote:
This is the basic infrastructure needed to support network
namespaces. This infrastructure is:
- Registration functions to support initializing per network
namespace data when a network namespaces is created or destroyed.
On Sun, Sep 09, 2007 at 04:04:45AM -0600, Eric W. Biederman wrote:
Paul E. McKenney [EMAIL PROTECTED] writes:
On Sat, Sep 08, 2007 at 03:15:34PM -0600, Eric W. Biederman wrote:
This is the basic infrastructure needed to support network
namespaces. This infrastructure
On Mon, Sep 10, 2007 at 11:59:29AM -0700, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Segher Boessenkool wrote:
volatile has nothing to do with reordering. atomic_dec() writes
to memory, so it _does_ have volatile semantics, implicitly, as
long as the compiler cannot optimise the
On Mon, Sep 10, 2007 at 03:46:29PM -0400, Vlad Yasevich wrote:
sctp_localaddr_list is modified dynamically via NETDEV_UP
and NETDEV_DOWN events, but there is not synchronization
between writer (even handler) and readers. As a result,
the readers can access an entry that has been freed and
On Mon, Sep 10, 2007 at 02:36:26PM -0700, Christoph Lameter wrote:
On Mon, 10 Sep 2007, Paul E. McKenney wrote:
The one exception to this being the case where process-level code is
communicating to an interrupt handler running on that same CPU -- on
all CPUs that I am aware of, a given
On Mon, Sep 10, 2007 at 03:46:30PM -0400, Vlad Yasevich wrote:
Since the sctp_sockaddr_entry is now RCU enabled as part of
the patch to synchronize sctp_localaddr_list, it makes sense to
change all handling of these entries to RCU. This includes the
sctp_bind_addrs structure and it's list of
that
changes to atomic variables are visible in all contexts that need
to see them.
Acked-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- a/Documentation/atomic_ops.txt2007-07-08 19:32:17.0 -0400
+++ b/Documentation/atomic_ops.txt2007-09
On Tue, Sep 11, 2007 at 10:05:10AM -0400, Vlad Yasevich wrote:
Sridhar, Paul
Thanks for review. Some answers and questions below...
NP!
Sridhar Samudrala wrote:
Paul E. McKenney wrote:
[ . . . ]
if ((PF_INET == sk-sk_family)
(AF_INET6 == addr
On Tue, Sep 11, 2007 at 10:56:09AM -0400, Vlad Yasevich wrote:
Hi Paul
Thanks for review. I'll leave out the comments about
the -valid usage since there are the same as the first patch
in the series.
Fair enough.
Other questions/responses below...
Paul E. McKenney wrote:
diff
and
crash the sytem.
Looks much better!!! Typo in comment noted below.
Acked-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
---
include/net/sctp/sctp.h|1 +
include/net/sctp/structs.h |6 +
net/sctp/bind_addr.c |2 +
net/sctp/ipv6
via the socket lock, so they will
not step on each other. These are also relatively rare, so we
should be good with RCU.
The readers are varied and they are easily converted to RCU.
Looks good from an RCU viewpoint -- I must defer to others on
the networking aspects.
Acked-by: Paul E
the callers to use get_proc_net and handle the case case
where get_proc_net returns NULL. In that case I return -ENXIO because
effectively the network namespace has already gone away so the files
we are trying to access don't exist anymore.
Looks much better!
Acked-by: Paul E. McKenney [EMAIL PROTECTED
On Thu, Sep 13, 2007 at 04:22:59PM +0400, Evgeniy Polyakov wrote:
Hi Paul.
On Mon, Sep 10, 2007 at 03:14:45PM -0700, Paul E. McKenney ([EMAIL
PROTECTED]) wrote:
Further TODO list includes:
* implement optional saving of mirroring/linear information on the remote
nodes (simple
Hello!
net/decnet/dn_route.c in dn_rt_cache_get_next() is as follows:
static struct dn_route *dn_rt_cache_get_next(struct seq_file *seq, struct
dn_route *rt)
{
struct dn_rt_cache_iter_state *s = rcu_dereference(seq-private);
rt = rt-u.dst.dn_next;
while(!rt) {
here?
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
nf_nat_h323.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff -urpNa -X dontdiff linux-2.6.23/net/ipv4/netfilter/nf_nat_h323.c
linux-2.6.23-rcufix/net/ipv4/netfilter/nf_nat_h323.c
--- linux-2.6.23/net
On Tue, Oct 30, 2007 at 01:10:36AM -0700, David Miller wrote:
From: Paul E. McKenney [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 14:15:40 -0700
net/decnet/dn_route.c in dn_rt_cache_get_next() is as follows:
static struct dn_route *dn_rt_cache_get_next(struct seq_file *seq, struct
On Tue, Oct 30, 2007 at 03:06:20PM +0100, Patrick McHardy wrote:
Paul E. McKenney wrote:
Hello!
While reviewing rcu_dereference() uses, I came across a number of cases
where I couldn't see how the rcu_dereference() helped. One class of
cases is where the variable is never subsequently
On Tue, Oct 30, 2007 at 02:52:54PM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Looks good from an RCU perspective. A couple questions below about
hlist_for_each_entry_safe().
Thanx, Paul
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
On Mon, Nov 05, 2007 at 07:53:04PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
net/decnet/dn_route.c in dn_rt_cache_get_next() is as follows:
static struct dn_route *dn_rt_cache_get_next(struct seq_file *seq,
struct dn_route *rt)
{
struct
On Fri, Nov 30, 2007 at 12:04:20AM +1100, Herbert Xu wrote:
On Tue, Nov 27, 2007 at 07:21:08PM +0300, Pavel Emelyanov wrote:
This hook is protected with the RCU, so simple
if (br_should_route_hook)
br_should_route_hook(...)
is not enough on some architectures.
On Fri, Nov 30, 2007 at 10:49:00AM +1100, Herbert Xu wrote:
On Thu, Nov 29, 2007 at 06:36:50AM -0800, Paul E. McKenney wrote:
That certainly is an interesting tradeoff... Save a memory barrier
when assigning NULL, but pay an extra test and branch in all cases.
Though it does make
/non-NULL
and const/non-const) with gcc version 4.1.2, and hand-checked the
assembly output.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
rcupdate.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff -urpNa -X dontdiff linux-2.6.24-rc1-ego/include/linux/rcupdate.h
On Sat, Dec 01, 2007 at 12:07:52PM +1100, Herbert Xu wrote:
On Fri, Nov 30, 2007 at 04:37:21PM -0800, Paul E. McKenney wrote:
The rcu_assign_pointer() primitive currently unconditionally executes
a memory barrier, even when a NULL pointer is being assigned. This
has lead some to avoid
1 - 100 of 244 matches
Mail list logo
