* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Christoph Lameter @ 2007-08-16 18:48 UTC (permalink / raw)
To: Paul Mackerras
Cc: Herbert Xu, Satyam Sharma, Paul E. McKenney, Stefan Richter,
Chris Snook, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <18115.49946.522011.832468@cargo.ozlabs.ibm.com>
On Thu, 16 Aug 2007, Paul Mackerras wrote:
>
> It seems that there could be a lot of places where atomic_t is used in
> a non-atomic fashion, and that those uses are either buggy, or there
> is some lock held at the time which guarantees that other CPUs aren't
> changing the value. In both cases there is no point in using
> atomic_t; we might as well just use an ordinary int.
The point of atomic_t is to do atomic *changes* to the variable.
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Christoph Lameter @ 2007-08-16 18:50 UTC (permalink / raw)
To: Paul Mackerras
Cc: Herbert Xu, Satyam Sharma, Paul E. McKenney, Stefan Richter,
Chris Snook, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <18115.59365.268987.406001@cargo.ozlabs.ibm.com>
On Thu, 16 Aug 2007, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > It doesn't matter. The memory pressure flag is an *advisory*
> > flag. If we get it wrong the worst that'll happen is that we'd
> > waste some time doing work that'll be thrown away.
>
> Ah, so it's the "racy but I don't care because it's only an
> optimization" case. That's fine. Somehow I find it hard to believe
> that all the racy uses of atomic_read in the kernel are like that,
> though. :)
My use of atomic_read in SLUB is like that. Volatile does not magically
sync up reads somehow.
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Christoph Lameter @ 2007-08-16 18:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: Satyam Sharma, Herbert Xu, Paul E. McKenney, Stefan Richter,
Chris Snook, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <18115.52863.638655.658466@cargo.ozlabs.ibm.com>
On Thu, 16 Aug 2007, Paul Mackerras wrote:
> The uses of atomic_read where one might want it to allow caching of
> the result seem to me to fall into 3 categories:
>
> 1. Places that are buggy because of a race arising from the way it's
> used.
>
> 2. Places where there is a race but it doesn't matter because we're
> doing some clever trick.
>
> 3. Places where there is some locking in place that eliminates any
> potential race.
>
> In case 1, adding volatile won't solve the race, of course, but it's
> hard to argue that we shouldn't do something because it will slow down
> buggy code. Case 2 is hopefully pretty rare and accompanied by large
> comment blocks, and in those cases caching the result of atomic_read
> explicitly in a local variable would probably make the code clearer.
> And in case 3 there is no reason to use atomic_t at all; we might as
> well just use an int.
In 2 + 3 you may increment the atomic variable in some places. The value
of the atomic variable may not matter because you only do optimizations.
Checking a atomic_t for a definite state has to involve either
some side conditions (lock only taken if refcount is <= 0 or so) or done
by changing the state (see f.e. atomic_inc_unless_zero).
> 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 you want to make it less complex then drop volatile which causes weird
side effects without solving any problems as you just pointed out.
^ permalink raw reply
* Re: Proposed interface for per-packet mesh-ttl
From: Luis Carlos Cobo @ 2007-08-16 19:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Javier Cardona, Dan Williams, Christoph Hellwig, netdev
In-Reply-To: <20070730215316.5c236e18@oldman>
On 7/30/07, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> it would need an IP ttl to mesh mapping. The fundamental thing is to try
> and avoid topology specific options bleeding all the way up the socket layer,
> especially since the network layer is involved and may need to multipath.
I think the cleanest way would be to add a ll_ttl (ll for link layer)
field to struct sock and a SO_LL_TTL socket option that sets both the
field and a flag in sk->flags. This way it is useful for any driver
that can do mesh or any other protocol that involves a ttl at link
layer (not that I'm aware of any).
However I guess you are not supposed to add new socket options nor
modify struct socket too often so I'd appreciate feedback on whether
this would be considered a good approach.
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool @ 2007-08-16 19:32 UTC (permalink / raw)
To: Nick Piggin
Cc: heiko.carstens, horms, linux-kernel, rpjday, ak, netdev, cfriesen,
akpm, torvalds, jesper.juhl, linux-arch, zlynx, satyam, clameter,
schwidefsky, Chris Snook, Herbert Xu, davem, wensong, wjiang
In-Reply-To: <46C3B50E.7010702@yahoo.com.au>
>>>> 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.
>> Almost everything is a tradeoff; and so is this. I don't
>> believe most people would find disabling all compiler
>> optimisations an acceptable price to pay for some peace
>> of mind.
>
> So why is this a good tradeoff?
It certainly is better than disabling all compiler optimisations!
> I also think that just adding things to APIs in the hope it might fix
> up some bugs isn't really a good road to go down. Where do you stop?
I look at it the other way: keeping the "volatile" semantics in
atomic_XXX() (or adding them to it, whatever) helps _prevent_ bugs;
certainly most people expect that behaviour, and also that behaviour
is *needed* in some places and no other interface provides that
functionality.
[some confusion about barriers wrt atomics snipped]
Segher
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool @ 2007-08-16 19:33 UTC (permalink / raw)
To: paulmck
Cc: heiko.carstens, horms, linux-kernel, rpjday, ak, netdev, cfriesen,
akpm, torvalds, jesper.juhl, linux-arch, zlynx, satyam, clameter,
schwidefsky, Chris Snook, Herbert Xu, davem, wensong, wjiang
In-Reply-To: <20070816023050.GC14613@linux.vnet.ibm.com>
>> The only thing volatile on an asm does is create a side effect
>> on the asm statement; in effect, it tells the compiler "do not
>> remove this asm even if you don't need any of its outputs".
>>
>> It's not disabling optimisation likely to result in bugs,
>> heisen- or otherwise; _not_ putting the volatile on an asm
>> that needs it simply _is_ a bug :-)
>
> Yep. And the reason it is a bug is that it fails to disable
> the relevant compiler optimizations. So I suspect that we might
> actually be saying the same thing here.
We're not saying the same thing, but we do agree :-)
Segher
^ permalink raw reply
* e1000 autotuning doesn't get along with itself
From: Rick Jones @ 2007-08-16 19:42 UTC (permalink / raw)
To: Linux Network Development list
Folks -
I was trying to look at bonding vs discrete links and so put a couple dual-port
e1000-driven NICs:
4a:01.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet
Controller (rev 03)
Subsystem: Hewlett-Packard Company HP Dual Port 1000Base-T [A9900A]
into a pair of 8 core systems running a 2.6.22.2 kernel. This gave me:
hpcpc109:~/netperf2_trunk# ethtool -i eth2
driver: e1000
version: 7.3.20-k2-NAPI
firmware-version: N/A
bus-info: 0000:49:02.0
for the e1000 driver. I connected the two systems back-to-back and started
running some tests. In the course of trying to look at something else
(verifying the results reported by bwm-ng) I enabled demo-mode in netperf
(./configure --enable-demo) and noticed a considerable oscillation. I undid the
bond and repeated the experiment with a discrete NIC:
hpcpc109:~/netperf2_trunk# src/netperf -t TCP_RR -H 192.168.2.105 -D 1.0 -l 15
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.105
(192.168.2.105) port 0 AF_INET : demo : first burst 0
Interim result: 10014.93 Trans/s over 1.00 seconds
Interim result: 10015.79 Trans/s over 1.00 seconds
Interim result: 10014.30 Trans/s over 1.00 seconds
Interim result: 10016.29 Trans/s over 1.00 seconds
Interim result: 10085.80 Trans/s over 1.00 seconds
Interim result: 17526.61 Trans/s over 1.00 seconds
Interim result: 20007.60 Trans/s over 1.00 seconds
Interim result: 19626.46 Trans/s over 1.02 seconds
Interim result: 10616.44 Trans/s over 1.85 seconds
Interim result: 10014.88 Trans/s over 1.06 seconds
Interim result: 10015.79 Trans/s over 1.00 seconds
Interim result: 10014.80 Trans/s over 1.00 seconds
Interim result: 10035.30 Trans/s over 1.00 seconds
Interim result: 13974.69 Trans/s over 1.00 seconds
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 15.00 12225.77
16384 87380
On a slightly informed whim I tried disabling the interrupt thottle on both
sides (modprobe e1000 InterruptThrottleRate=0,0,0,0,0,0,0,0) and re-ran:
hpcpc109:~/netperf2_trunk# src/netperf -t TCP_RR -H 192.168.2.105 -D 1.0 -l
15TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.2.105 (192.168.2.105) port 0 AF_INET : demo : first burst 0
Interim result: 18673.68 Trans/s over 1.00 seconds
Interim result: 18685.01 Trans/s over 1.00 seconds
Interim result: 18682.30 Trans/s over 1.00 seconds
Interim result: 18681.05 Trans/s over 1.00 seconds
Interim result: 18680.25 Trans/s over 1.00 seconds
Interim result: 18742.44 Trans/s over 1.00 seconds
Interim result: 18739.45 Trans/s over 1.00 seconds
Interim result: 18723.52 Trans/s over 1.00 seconds
Interim result: 18736.53 Trans/s over 1.00 seconds
Interim result: 18737.61 Trans/s over 1.00 seconds
Interim result: 18744.76 Trans/s over 1.00 seconds
Interim result: 18728.54 Trans/s over 1.00 seconds
Interim result: 18738.91 Trans/s over 1.00 seconds
Interim result: 18735.53 Trans/s over 1.00 seconds
Interim result: 18741.03 Trans/s over 1.00 seconds
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 15.00 18717.94
16384 87380
and then just for grins I tried just disabling it on one side, leaving the other
at defaults:
hpcpc109:~/netperf2_trunk# src/netperf -t TCP_RR -H 192.168.2.105 -D 1.0 -l
15TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.2.105 (192.168.2.105) port 0 AF_INET : demo : first burst 0
Interim result: 19980.84 Trans/s over 1.00 seconds
Interim result: 19997.60 Trans/s over 1.00 seconds
Interim result: 19995.60 Trans/s over 1.00 seconds
Interim result: 20002.60 Trans/s over 1.00 seconds
Interim result: 20011.58 Trans/s over 1.00 seconds
Interim result: 19985.66 Trans/s over 1.00 seconds
Interim result: 20002.60 Trans/s over 1.00 seconds
Interim result: 20010.58 Trans/s over 1.00 seconds
Interim result: 20012.60 Trans/s over 1.00 seconds
Interim result: 19993.63 Trans/s over 1.00 seconds
Interim result: 19979.63 Trans/s over 1.00 seconds
Interim result: 19991.58 Trans/s over 1.00 seconds
Interim result: 20011.60 Trans/s over 1.00 seconds
Interim result: 19948.84 Trans/s over 1.00 seconds
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 15.00 19990.14
16384 87380
It looks like the e1000 interrupt throttle autotuning works very nicely when the
other side isn't doing any, but if the other side is also trying to autotune it
doesn't seem to stablize. At least not during a netperf TCP_RR test.
Does anyone else see this? To try to eliminate netperf demo mode I re-ran
without it and got the same end results.
rick jones
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool @ 2007-08-16 19:44 UTC (permalink / raw)
To: Paul Mackerras
Cc: Christoph Lameter, heiko.carstens, horms, Stefan Richter,
Satyam Sharma, Linux Kernel Mailing List, Paul E. McKenney,
netdev, ak, cfriesen, rpjday, jesper.juhl, linux-arch,
Andrew Morton, zlynx, schwidefsky, Chris Snook, Herbert Xu, davem,
Linus Torvalds, wensong, wjiang
In-Reply-To: <18115.49946.522011.832468@cargo.ozlabs.ibm.com>
> I'd go so far as to say that anywhere where you want a non-"volatile"
> atomic_read, either your code is buggy, or else an int would work just
> as well.
Even, the only way to implement a "non-volatile" atomic_read() is
essentially as a plain int (you can do some tricks so you cannot
assign to the result and stuff like that, but that's not the issue
here).
So if that would be the behaviour we wanted, just get rid of that
whole atomic_read() thing, so no one can misuse it anymore.
Segher
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Chris Snook @ 2007-08-16 19:55 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Herbert Xu, Paul Mackerras, Satyam Sharma, Christoph Lameter,
Paul E. McKenney, Stefan Richter, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, Netdev, Andrew Morton, ak,
heiko.carstens, David Miller, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <Pine.LNX.4.64.0708161743500.13267@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Thu, 16 Aug 2007, Herbert Xu wrote:
>
>> We've been through that already. If it's a busy-wait it
>> should use cpu_relax.
>
> I looked around a bit by using some command lines and ended up wondering
> if these are equal to busy-wait case (and should be fixed) or not:
>
> ./drivers/telephony/ixj.c
> 6674: while (atomic_read(&j->DSPWrite) > 0)
> 6675- atomic_dec(&j->DSPWrite);
>
> ...besides that, there are couple of more similar cases in the same file
> (with braces)...
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, unless there's a compelling
reason not to. I'll allow that for some hardware drivers (possibly this
one) such a compelling reason may exist, but hardware-independent core
subsystems probably have no excuse.
If the maintainer of this code doesn't see a compelling reason to add
cpu_relax() in this loop, then it should be patched.
-- Chris
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Chris Snook @ 2007-08-16 19:48 UTC (permalink / raw)
To: Herbert Xu
Cc: Stefan Richter, Paul Mackerras, Satyam Sharma, Christoph Lameter,
Paul E. McKenney, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <20070816081049.GA1431@gondor.apana.org.au>
Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
>>> Do you (or anyone else for that matter) have an example of this?
>> The only code I somewhat know, the ieee1394 subsystem, was perhaps
>> authored and is currently maintained with the expectation that each
>> occurrence of atomic_read actually results in a load operation, i.e. is
>> not optimized away. This means all atomic_t (bus generation, packet and
>> buffer refcounts, and some other state variables)* and likewise all
>> atomic bitops in that subsystem.
>
> Can you find an actual atomic_read code snippet there that is
> broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start removing barriers that aren't needed if volatile
behavior is guaranteed.
barrier() clobbers all your registers. volatile atomic_read() only
clobbers one register, and more often than not it's a register you
wanted to clobber anyway.
-- Chris
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Chris Snook @ 2007-08-16 19:55 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Herbert Xu, Paul Mackerras, Satyam Sharma, Christoph Lameter,
Paul E. McKenney, Stefan Richter, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, Netdev, Andrew Morton, ak,
heiko.carstens, David Miller, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <Pine.LNX.4.64.0708161743500.13267@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Thu, 16 Aug 2007, Herbert Xu wrote:
>
>> We've been through that already. If it's a busy-wait it
>> should use cpu_relax.
>
> I looked around a bit by using some command lines and ended up wondering
> if these are equal to busy-wait case (and should be fixed) or not:
>
> ./drivers/telephony/ixj.c
> 6674: while (atomic_read(&j->DSPWrite) > 0)
> 6675- atomic_dec(&j->DSPWrite);
>
> ...besides that, there are couple of more similar cases in the same file
> (with braces)...
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, unless there's a compelling
reason not to. I'll allow that for some hardware drivers (possibly this
one) such a compelling reason may exist, but hardware-independent core
subsystems probably have no excuse.
If the maintainer of this code doesn't see a compelling reason not to
add cpu_relax() in this loop, then it should be patched.
-- Chris
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney @ 2007-08-16 20:07 UTC (permalink / raw)
To: Christoph Lameter
Cc: Paul Mackerras, Satyam Sharma, Herbert Xu, Stefan Richter,
Chris Snook, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <Pine.LNX.4.64.0708161151270.17049@schroedinger.engr.sgi.com>
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 you want to make it less complex then drop volatile which causes weird
> side effects without solving any problems as you just pointed out.
The other set of problems are communication between process context
and interrupt/NMI handlers. Volatile does help here. And the performance
impact of volatile is pretty near zero, so why have the non-volatile
variant?
Thanx, Paul
^ permalink raw reply
* Re: [Bugme-new] [Bug 8895] New: An ioctl to delete an ipv6 tunnel leads to a kernel panic
From: Andrew Morton @ 2007-08-16 20:09 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, clowncoder
In-Reply-To: <bug-8895-10286@http.bugzilla.kernel.org/>
On Thu, 16 Aug 2007 12:24:05 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8895
>
> Summary: An ioctl to delete an ipv6 tunnel leads to a kernel
> panic
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.22.3 and also 2.6.21.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV6
> AssignedTo: yoshfuji@linux-ipv6.org
> ReportedBy: clowncoder@clownix.net
>
>
> Most recent kernel where this bug did not occur: ?
> Distribution: lfs and fedora
> Hardware Environment:user mode linux and vmware
> Software Environment:an evolution of mip6d (ip mobility daemon)
> Problem Description: The mip6d HA was modified to make a redondancy evolution,
> when an HA is interrupted, the other takes over, this leads to some
> creation/deletion of routes and tunnels.
> Note: The HA ip address known by the mobile (MR) stays the same, the slave HA
> takes it with an override neighbor advertisement message. So the tunnel between
> the mobile router and the HA(s) keep the same end adresses.
> The problem occurs when a Ctrl C is done on the master HA, the slave takes over
> but sometimes, the master gets a kernel panic.
>
> Here is the dump of the master:
>
> ICMPv6 NA: someone advertises our address on eth1!
> Slab corruption: ip6_dst_cache start=0867ed00, len=224
> Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> Last user: [<08157c46>](dst_destroy+0x79/0xad)
> 0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6c 6b 6b 6b
> Prev obj: start=0867ec08, len=224
> Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Last user: [<08157b05>](dst_alloc+0x26/0x62)
> 000: 00 00 00 00 00 00 00 00 00 00 00 00 40 41 6f 08
> 010: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> Next obj: start=0867edf8, len=224
> Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> Last user: [<08157b05>](dst_alloc+0x26/0x62)
> 000: 00 00 00 00 00 00 00 00 00 00 00 00 60 41 99 0b
> 010: 00 00 ff ff 00 00 00 00 7d df ff ff 00 00 00 00
> BUG: failure at net/ipv6/ip6_fib.c:1151/fib6_del_route()!
> Kernel panic - not syncing: BUG!
>
> EIP: 0073:[<080e10b4>] CPU: 0 Not tainted ESP: 007b:bf6d0398 EFLAGS: 00000246
> Not tainted
> EAX: ffffffda EBX: 00000006 ECX: 000089f2 EDX: bf6d0428
> ESI: 00000000 EDI: 0815c150 EBP: bf6d0458 DS: 007b ES: 007b
> 08a37ae4: [<0806ba80>] show_regs+0xb4/0xb9
> 08a37b10: [<0805a044>] panic_exit+0x25/0x3f
> 08a37b24: [<0807b088>] notifier_call_chain+0x21/0x46
> 08a37b44: [<0807b123>] __atomic_notifier_call_chain+0x17/0x19
> 08a37b60: [<0807b13a>] atomic_notifier_call_chain+0x15/0x17
> 08a37b7c: [<0806fff6>] panic+0x52/0xdd
> 08a37b9c: [<081bb8d2>] fib6_del_route+0x112/0x175
> 08a37bc0: [<081bb9c6>] fib6_del+0x91/0xcc
> 08a37bdc: [<081bbba8>] fib6_clean_node+0x26/0x73
> 08a37bf4: [<081bba8a>] fib6_walk_continue+0x89/0x11f
> 08a37c04: [<081bbb57>] fib6_walk+0x37/0x62
> 08a37c18: [<081bbc23>] fib6_clean_tree+0x2e/0x31
> 08a37c4c: [<081bbc83>] fib6_prune_clones+0x15/0x1a
> 08a37c64: [<081bb9de>] fib6_del+0xa9/0xcc
> 08a37c7c: [<081bbba8>] fib6_clean_node+0x26/0x73
> 08a37c94: [<081bba8a>] fib6_walk_continue+0x89/0x11f
> 08a37ca4: [<081bbb57>] fib6_walk+0x37/0x62
> 08a37cb8: [<081bbc23>] fib6_clean_tree+0x2e/0x31
> 08a37cec: [<081bbc51>] fib6_clean_all+0x2b/0x48
> 08a37d10: [<081b9d15>] rt6_ifdown+0x12/0x17
> 08a37d24: [<081b56e3>] addrconf_ifdown+0x54/0x275
> 08a37d40: [<081b562d>] addrconf_notify+0x18a/0x1ec
> 08a37d5c: [<0807b088>] notifier_call_chain+0x21/0x46
> 08a37d7c: [<0807b257>] __raw_notifier_call_chain+0x17/0x19
> 08a37d98: [<0807b26e>] raw_notifier_call_chain+0x15/0x17
> 08a37db4: [<08153c18>] dev_close+0x5e/0x68
> 08a37dcc: [<0815619e>] unregister_netdevice+0xb7/0x1bc
> 08a37ddc: [<081d75d7>] ip6_tnl_ioctl+0x1a9/0x1d2
> 08a37e34: [<0815578c>] dev_ifsioc+0x3b9/0x3d9
> 08a37e54: [<08155a71>] dev_ioctl+0x2c5/0x300
> 08a37e9c: [<0814b435>] sock_ioctl+0x230/0x243
> 08a37ebc: [<080b0801>] do_ioctl+0x21/0x5a
> 08a37ed8: [<080b0ba8>] vfs_ioctl+0x1ec/0x209
> 08a37f00: [<080b0bf3>] sys_ioctl+0x2e/0x4b
> 08a37f28: [<0805a7ae>] handle_syscall+0x86/0xa0
> 08a37f74: [<08068d00>] handle_trap+0xd8/0xe1
> 08a37f90: [<080690f3>] userspace+0x138/0x180
> 08a37fdc: [<0805a4d1>] fork_handler+0x74/0x7c
> 08a37ffc: [<a55a5a5a>] 0xa55a5a5a
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e58761 in abort () from /lib/tls/i686/cmov/libc.so.6
> (gdb)
>
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e58761 in abort () from /lib/tls/i686/cmov/libc.so.6
> (gdb) bt
> #0 0xb7e58761 in abort () from /lib/tls/i686/cmov/libc.so.6
> #1 0x080676df in os_dump_core () at arch/um/os-Linux/util.c:109
> #2 0x0805a05a in panic_exit (self=0x825d674, unused1=0, unused2=0x8277ee0)
> at arch/um/kernel/um_arch.c:477
> #3 0x0807b088 in notifier_call_chain (nl=0x8277ec0, val=0, v=0x8277ee0,
> nr_to_call=-2, nr_calls=0x0) at kernel/sys.c:163
> #4 0x0807b123 in __atomic_notifier_call_chain (nh=0x8277ec0, val=0,
> v=0x8277ee0, nr_to_call=-1, nr_calls=0x0) at kernel/sys.c:256
> #5 0x0807b13a in atomic_notifier_call_chain (nh=0x8277ec0, val=0, v=0x8277ee0)
> at kernel/sys.c:266
> #6 0x0806fff6 in panic (fmt=0x8217b25 "BUG!") at kernel/panic.c:99
> #7 0x081bb8d2 in fib6_del_route (fn=0x0, rtp=0x8abd568, info=0x0)
> at net/ipv6/ip6_fib.c:1151
> #8 0x081bb9c6 in fib6_del (rt=0x867ed00, info=0x0) at net/ipv6/ip6_fib.c:1193
> #9 0x081bbba8 in fib6_clean_node (w=0x8a37c20) at net/ipv6/ip6_fib.c:1322
> #10 0x081bba8a in fib6_walk_continue (w=0x8a37c20) at net/ipv6/ip6_fib.c:1264
> #11 0x081bbb57 in fib6_walk (w=0x8a37c20) at net/ipv6/ip6_fib.c:1306
> #12 0x081bbc23 in fib6_clean_tree (root=0x8abd440,
> func=0x81bbc88 <fib6_prune_clone>, prune=1, arg=0x867edf8)
> at net/ipv6/ip6_fib.c:1360
> #13 0x081bbc83 in fib6_prune_clones (fn=0x8abd440, rt=0x867edf8)
> at net/ipv6/ip6_fib.c:1394
> #14 0x081bb9de in fib6_del (rt=0x867edf8, info=0x0) at net/ipv6/ip6_fib.c:1184
> #15 0x081bbba8 in fib6_clean_node (w=0x8a37cc0) at net/ipv6/ip6_fib.c:1322
> #16 0x081bba8a in fib6_walk_continue (w=0x8a37cc0) at net/ipv6/ip6_fib.c:1264
> #17 0x081bbb57 in fib6_walk (w=0x8a37cc0) at net/ipv6/ip6_fib.c:1306
> #18 0x081bbc23 in fib6_clean_tree (root=0x8272dac,
> func=0x81b9ce2 <fib6_ifdown>, prune=0, arg=0xb994160)
> at net/ipv6/ip6_fib.c:1360
> #19 0x081bbc51 in fib6_clean_all (func=0x81b9ce2 <fib6_ifdown>, prune=0,
> arg=0xb994160) at net/ipv6/ip6_fib.c:1372
> #20 0x081b9d15 in rt6_ifdown (dev=0xb994160) at net/ipv6/route.c:1944
> #21 0x081b56e3 in addrconf_ifdown (dev=0xb994160, how=0)
> at net/ipv6/addrconf.c:2400
> #22 0x081b562d in addrconf_notify (this=0x82721c4, event=2, data=0xb994160)
> at net/ipv6/addrconf.c:2358
> #23 0x0807b088 in notifier_call_chain (nl=0x8283e94, val=2, v=0xb994160,
> nr_to_call=-10, nr_calls=0x0) at kernel/sys.c:163
> #24 0x0807b257 in __raw_notifier_call_chain (nh=0x8283e94, val=2, v=0xb994160,
> nr_to_call=-1, nr_calls=0x0) at kernel/sys.c:451
> #25 0x0807b26e in raw_notifier_call_chain (nh=0x8283e94, val=2, v=0xb994160)
> at kernel/sys.c:459
> #26 0x08153c18 in dev_close (dev=0xb994160) at net/core/dev.c:1015
> #27 0x0815619e in unregister_netdevice (dev=0xb994160) at net/core/dev.c:3451
> #28 0x081d75d7 in ip6_tnl_ioctl (dev=0xb994160, ifr=0x8a37e6c, cmd=35314)
> at net/ipv6/ip6_tunnel.c:1266
> #29 0x0815578c in dev_ifsioc (ifr=0x8a37e6c, cmd=35314) at net/core/dev.c:2816
> #30 0x08155a71 in dev_ioctl (cmd=35314, arg=0xbf6d0428) at net/core/dev.c:2995
> #31 0x0814b435 in sock_ioctl (file=0x832a348, cmd=35314, arg=3211592744)
> at net/socket.c:909
> #32 0x080b0801 in do_ioctl (filp=0x16, cmd=35314, arg=3211592744)
> ---Type <return> to continue, or q <return> to quit---
>
> at fs/ioctl.c:30
> #33 0x080b0ba8 in vfs_ioctl (filp=0x832a348, fd=6, cmd=6, arg=3211592744)
> at fs/ioctl.c:159
> #34 0x080b0bf3 in sys_ioctl (fd=6, cmd=35314, arg=3211592744) at fs/ioctl.c:179
> #35 0x0805a7ae in handle_syscall (r=0x867a894)
> at arch/um/kernel/skas/syscall.c:38
> #36 0x08068d00 in handle_trap (pid=10640, regs=0x867a894, local_using_sysemu=2)
> at arch/um/os-Linux/skas/process.c:173
> #37 0x080690f3 in userspace (regs=0x867a894)
> at arch/um/os-Linux/skas/process.c:330
> #38 0x0805a4d1 in fork_handler () at arch/um/kernel/skas/process.c:96
> #39 0xa55a5a5a in ?? ()
> (gdb)
>
>
>
> Steps to reproduce:
>
>
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Christoph Lameter @ 2007-08-16 20:20 UTC (permalink / raw)
To: Chris Snook
Cc: Ilpo Järvinen, Herbert Xu, Paul Mackerras, Satyam Sharma,
Paul E. McKenney, Stefan Richter, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, Netdev, Andrew Morton, ak,
heiko.carstens, David Miller, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <46C4ABA5.9010804@redhat.com>
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, unless there's a compelling reason not to. I'll
> allow that for some hardware drivers (possibly this one) such a compelling
> reason may exist, but hardware-independent core subsystems probably have no
> excuse.
No it does not have any volatile semantics. atomic_dec() can be reordered
at will by the compiler within the current basic unit if you do not add a
barrier.
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool @ 2007-08-16 19:39 UTC (permalink / raw)
To: Paul Mackerras
Cc: Christoph Lameter, heiko.carstens, horms, Stefan Richter,
Satyam Sharma, Linux Kernel Mailing List, Paul E. McKenney,
netdev, ak, cfriesen, rpjday, jesper.juhl, linux-arch,
Andrew Morton, zlynx, schwidefsky, Chris Snook, Herbert Xu, davem,
Linus Torvalds, wensong, wjiang
In-Reply-To: <18115.48863.331246.638826@cargo.ozlabs.ibm.com>
>> I can't speak for this particular case, but there could be similar
>> code
>> examples elsewhere, where we do the atomic ops on an atomic_t object
>> inside a higher-level locking scheme that would take care of the kind
>> of
>> problem you're referring to here. It would be useful for such or
>> similar
>> code if the compiler kept the value of that atomic object in a
>> register.
>
> If there is a higher-level locking scheme then there is no point to
> using atomic_t variables. Atomic_t is specifically for the situation
> where multiple CPUs are updating a variable without locking.
And don't forget about the case where it is an I/O device that is
updating the memory (in buffer descriptors or similar). The driver
needs to do a "volatile" atomic read to get at the most recent version
of that data, which can be important for optimising latency (or
throughput
even). There is no other way the kernel can get that info -- doing an
MMIO read is way way too expensive.
Segher
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool @ 2007-08-16 20:50 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, heiko.carstens, horms, Stefan Richter,
Bill Fink, Linux Kernel Mailing List, Paul E. McKenney, netdev,
ak, cfriesen, rpjday, jesper.juhl, linux-arch, Andrew Morton,
zlynx, schwidefsky, Chris Snook, Herbert Xu, davem,
Linus Torvalds, wensong, wjiang
In-Reply-To: <alpine.LFD.0.999.0708161045360.25951@enigma.security.iitk.ac.in>
> Note that "volatile"
> is a type-qualifier, not a type itself, so a cast of the _object_
> itself
> to a qualified-type i.e. (volatile int) would not make the access
> itself
> volatile-qualified.
There is no such thing as "volatile-qualified access" defined
anywhere; there only is the concept of a "volatile-qualified
*object*".
> To serve our purposes, it is necessary for us to take the address of
> this
> (non-volatile) object, cast the resulting _pointer_ to the
> corresponding
> volatile-qualified pointer-type, and then dereference it. This makes
> that
> particular _access_ be volatile-qualified, without the object itself
> being
> such. Also note that the (dereferenced) result is also a valid lvalue
> and
> hence can be used in "*(volatile int *)&a = b;" kind of construction
> (which we use for the atomic_set case).
There is a quite convincing argument that such an access _is_ an
access to a volatile object; see GCC PR21568 comment #9. This
probably isn't the last word on the matter though...
Segher
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Segher Boessenkool @ 2007-08-16 21:00 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, heiko.carstens, horms, Stefan Richter,
Bill Fink, Linux Kernel Mailing List, Paul E. McKenney, netdev,
ak, cfriesen, rpjday, jesper.juhl, linux-arch, Andrew Morton,
zlynx, schwidefsky, Chris Snook, Herbert Xu, davem,
Linus Torvalds, wensong, wjiang
In-Reply-To: <alpine.LFD.0.999.0708161115370.25951@enigma.security.iitk.ac.in>
> Here, I should obviously admit that the semantics of *(volatile int *)&
> aren't any neater or well-defined in the _language standard_ at all.
> The
> standard does say (verbatim) "precisely what constitutes as access to
> object of volatile-qualified type is implementation-defined", but GCC
> does help us out here by doing the right thing.
Where do you get that idea? GCC manual, section 6.1, "When
is a Volatile Object Accessed?" doesn't say anything of the
kind. PR33053 and some others.
> Honestly, given such confusion, and the propensity of the "volatile"
> type-qualifier keyword to be ill-defined (or at least poorly
> understood,
> often inconsistently implemented), I'd (again) express my opinion that
> it
> would be best to avoid its usage, given other alternatives do exist.
Yeah. Or we can have an email thread like this every time
someone proposes a patch that uses an atomic variable ;-)
Segher
^ permalink raw reply
* Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
From: Karl Meyer @ 2007-08-16 21:03 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, netdev
In-Reply-To: <20070816141122.GA6625@electric-eye.fr.zoreil.com>
I did some testing today and found that the error occurs after
applying some of the patches. However I did not figure out the exact
patch in which the error "starts" since it sometimes occurs immediatly
when moving some data over the net and sometimes it takes 30 min till
I get the transmit timeout. I will be away till sunday and do some
more testing then.
2007/8/16, Francois Romieu <romieu@fr.zoreil.com>:
> (please do not remove the netdev Cc:)
>
> Francois Romieu <romieu@fr.zoreil.com> :
> [...]
> > If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944
> > tomorrow.
>
> You will find a tgz archive in attachment which contains a serie of patches
> (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2
> to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps.
>
> Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it
> still works, apply 0002 on top of 0001, etc.
>
> --
> Ueimor
>
>
^ permalink raw reply
* RE: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Luck, Tony @ 2007-08-16 21:08 UTC (permalink / raw)
To: Chris Snook, Ilpo Järvinen
Cc: Herbert Xu, Paul Mackerras, Satyam Sharma, Christoph Lameter,
Paul E. McKenney, Stefan Richter, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, Netdev, Andrew Morton, ak,
heiko.carstens, David Miller, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <46C4ABA5.9010804@redhat.com>
>> 6674: while (atomic_read(&j->DSPWrite) > 0)
>> 6675- atomic_dec(&j->DSPWrite);
>
> If the maintainer of this code doesn't see a compelling reason to add
> cpu_relax() in this loop, then it should be patched.
Shouldn't it be just re-written without the loop:
if ((tmp = atomic_read(&j->DSPWrite)) > 0)
atomic_sub(&j->DSPWrite, tmp);
Has all the same bugs, but runs much faster :-)
-Tony
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
From: David Miller @ 2007-08-16 21:17 UTC (permalink / raw)
To: tom; +Cc: jeff, netdev, rdreier, linux-kernel, general
In-Reply-To: <1187271791.4685.9.camel@trinity.ogc.int>
From: Tom Tucker <tom@opengridcomputing.com>
Date: Thu, 16 Aug 2007 08:43:11 -0500
> Isn't RDMA _part_ of the "software net stack" within Linux?
It very much is not so.
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've grown to love and use over the years.
I'm glad this is a surprise to you, because it illustrates the
point some of us keep trying to make about technologies like
this.
Imagine if you didn't know any of this, you purchase and begin to
deploy a huge piece of RDMA infrastructure, you then get the mandate
from IT that you need to add firewalling on the RDMA connections at
the host level, and "oh shit" you can't?
This is why none of us core networking developers like RDMA at all.
It's totally not integrated with the rest of the Linux stack and on
top of that it even gets in the way. It's an abberation, an eye sore,
and a constant source of consternation.
^ permalink raw reply
* Re: Proposed interface for per-packet mesh-ttl
From: Stephen Hemminger @ 2007-08-16 21:19 UTC (permalink / raw)
To: Luis Carlos Cobo; +Cc: Javier Cardona, Dan Williams, Christoph Hellwig, netdev
In-Reply-To: <8e8340660708161221t1c0bee01g9d0cb1835f7026f0@mail.gmail.com>
On Thu, 16 Aug 2007 12:21:14 -0700
"Luis Carlos Cobo" <luisca@cozybit.com> wrote:
> On 7/30/07, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > it would need an IP ttl to mesh mapping. The fundamental thing is to try
> > and avoid topology specific options bleeding all the way up the socket layer,
> > especially since the network layer is involved and may need to multipath.
>
> I think the cleanest way would be to add a ll_ttl (ll for link layer)
> field to struct sock and a SO_LL_TTL socket option that sets both the
> field and a flag in sk->flags. This way it is useful for any driver
> that can do mesh or any other protocol that involves a ttl at link
> layer (not that I'm aware of any).
>
> However I guess you are not supposed to add new socket options nor
> modify struct socket too often so I'd appreciate feedback on whether
> this would be considered a good approach.
>
> --
> Luis Carlos Cobo Rus GnuPG ID: 44019B60
> cozybit Inc.
The problem with socket options is how does the application know
the correct policy? Pushing configuration to application is just deferring
the problem, not solving it. You want some policy to be done by the
infrastructure; that means kernel, libraries, daemons, etc. Doing it in
the application is often inflexible and unusable.
^ permalink raw reply
* Re: Proposed interface for per-packet mesh-ttl
From: Luis Carlos Cobo @ 2007-08-16 22:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Javier Cardona, Dan Williams, Christoph Hellwig, netdev
In-Reply-To: <20070816171913.2ad87e47@oldman>
On 8/16/07, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> The problem with socket options is how does the application know
> the correct policy? Pushing configuration to application is just deferring
> the problem, not solving it. You want some policy to be done by the
> infrastructure; that means kernel, libraries, daemons, etc. Doing it in
> the application is often inflexible and unusable.
The policy will usually be done by the kernel. If the flag is not set,
which will happen most of the time, the driver will use a sensible
default ttl. The socket option would only be used by applications that
are specifically interested in a configurable ttl (like an application
to plot neighbors within an specific diameter). A per-interface
setting is not good enough, since we do not want the neighbor-plotting
tool to affect the ttl of other connections (e.g. a ssh session) that
might be going on at the same time.
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
^ permalink raw reply
* Re: [RFC] net/core/dst.c : Should'nt dst_run_gc() be more scalable and friendly ?
From: Herbert Xu @ 2007-08-16 23:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <20070816174044.43c90ff4.dada1@cosmosbay.com>
On Thu, Aug 16, 2007 at 05:40:44PM +0200, Eric Dumazet wrote:
>
> So do you think this patch is enough or should we convert dst_run_gc processing from softirq to workqueue too ?
I think a workqueue would be the best solution since with
that you wouldn't have to worry about processing things in
chunks.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Herbert Xu @ 2007-08-16 23:59 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Stefan Richter, Paul Mackerras, Satyam Sharma, Christoph Lameter,
Chris Snook, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <20070816163441.GB16957@linux.vnet.ibm.com>
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
>
> This patch uses an ORDERED_WRT_IRQ() in rcu_read_lock() and
> rcu_read_unlock() to ensure that accesses aren't reordered with respect
> to interrupt handlers and NMIs/SMIs running on that same CPU.
Good, finally we have some code to discuss (even though it's
not actually in the kernel yet).
First of all, I think this illustrates that what you want
here has nothing to do with atomic ops. The ORDERED_WRT_IRQ
macro occurs a lot more times in your patch than atomic
reads/sets. So *assuming* that it was necessary at all,
then having an ordered variant of the atomic_read/atomic_set
ops could do just as well.
However, I still don't know which atomic_read/atomic_set in
your patch would be broken if there were no volatile. Could
you please point them out?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Herbert Xu @ 2007-08-17 0:02 UTC (permalink / raw)
To: Chris Snook
Cc: Stefan Richter, Paul Mackerras, Satyam Sharma, Christoph Lameter,
Paul E. McKenney, Linux Kernel Mailing List, linux-arch,
Linus Torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <46C4AA26.4060707@redhat.com>
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
>
> >Can you find an actual atomic_read code snippet there that is
> >broken without the volatile modifier?
>
> A whole bunch of atomic_read uses will be broken without the volatile
> modifier once we start removing barriers that aren't needed if volatile
> behavior is guaranteed.
Could you please cite the file/function names so we can
see whether removing the barrier makes sense?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox