On Thu, 9 Aug 2007, David Miller wrote:
> I applied everything up until the SACK validator to net-2.6.24
Ok, thanks.
> Everything I hit today which had not been posted before was trivial
> fix or a reasonable small cleanup.
...Yeah, I know that but don't want to give impression that something
Dear Auke
Sorry I sent the wrong patch.
I resubmit the patch.
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000.h
linux-2.6.22/drivers/net/e1000/e1000.h
--- linux-2.6.22.org/drivers/net/e1000/e1000.h 2007-07-09 08:32:17.
Dear Auke
http://lkml.org/lkml/2007/5/16/275
> I'm ok with the bottom part of the patch, but I do not like the modification
> of
> the pci device ID table in this way. As Arjan van der Ven previously commented
> as well, this makes it hard for future device ID's to be bound to the driver.
>
> On
- Default to IntA interrupt type when there are less than 4 CPUs in the system.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -Nurp 2.0.26.2/drivers/net/s2io.c 2.0.26.3/drivers/net/s2io.c
--- 2.0.26.2/drivers/net/s2io.c 2007-08-0
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007
> 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says:
>
>> YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes:
>>
>> > Would you explain why it does not work properly
>> > for thos
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL
PROTECTED] (Eric W. Biederman) says:
> YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes:
>
> > Would you explain why it does not work properly
> > for those cases?
>
> Mostly no appropriate strategy routine was setup
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes:
> Would you explain why it does not work properly
> for those cases?
Mostly no appropriate strategy routine was setup to
report the data to the caller of sys_sysctl.
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL
PROTECTED] (Eric W. Biederman) says:
>
> - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> sysctl names for a function that works with proc.
:
Well, retrans_time_ms and base_reachable_time_ms superc
Andrew Morton <[EMAIL PROTECTED]> writes:
> But it is good to remove bad interfaces, if we possibly can.
>
> It is worth making the attempt. Does anyone know of anything which will
> break? I fed NET_NEIGH_ANYCAST_DELAY at random into
> http://www.google.com/codesearch and came up with nothing..
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
> Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST)
>
> > I disagree. It is bad to remove existing interface.
> > Ditto for other patc
On Fri, 10 Aug 2007 10:47:10 +0900 (JST) YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL
PROTECTED]> wrote:
> Hello.
>
> In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL
> PROTECTED] (Eric W. Biederman) says:
>
> >
> > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on bi
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST)
> I disagree. It is bad to remove existing interface.
> Ditto for other patches.
I think perhaps you misunderstand what Eric is doing.
sys_sysctl() isn't working properly for these cases and it is bot
Hello.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL
PROTECTED] (Eric W. Biederman) says:
>
> - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> sysctl names for a function that works with proc.
>
> - In neighbour.c reorder the table to put the
On Thursday August 9, [EMAIL PROTECTED] wrote:
> Here is a small part of missing pieces of IPv6 support for the server.
> It deals with the ip_map caching code part.
>
> It changes the ip_map structure to be able to store INET6 addresses.
> It adds also the changes in address hashing, and mapping
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 dependi
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 9 Aug 2007 17:40:07 +0300 (EEST)
> Next step:
>
> http://www.cs.helsinki.fi/u/ijjarvin/tcp-rebase/after-reorder/
>
> ...I put some effort to reorganization and there's the result, please
> _don't_ take the new SACK block-validator yet as I ha
On Thursday August 9, [EMAIL PROTECTED] wrote:
> >>
> >> How have you tested the effectiveness of the new hash function?
> >
> > I have not tested that point but I can easily imagine there are better
> > solutions.
> > Perhaps we can keep the same function for an IPv4 address (only taking
> > th
I've recently been trying to use tc with u32 classifiers to filter
ethernet traffic based on ethertype. Although we found and fixed an
issue in the sch_prio call to tc_classify() (thanks Patrick!), this
didn't fix the actual filtering issue. For those of you who are curious
or are tc-savy, I'm re
This is debug code so no need to support binary sysctl,
and the binary sysctls as they were written were not
consistent with what showed up in /proc so remove
the binary sysctl support.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/sunrpc/sysctl.c |4
1 files changed, 0 i
Currently tcp_available_congestion_control does not even
attempt being read from sys_sysctl, and ipfrag_max_dist
while it works allows setting of invalid values using
sys_sysctl.
So just kill the binary sys_sysctl support for these
sysctls. If the support is not important enough to
test and get
>From ddf280c9de903f1fb5d4ecf9c68df0c479d7c7d2 Mon Sep 17 00:00:00 2001
From: Eric W. Biederman <[EMAIL PROTECTED]>
Date: Thu, 9 Aug 2007 16:00:00 -0600
Subject:
This is debug code so no need to support binary sysctl,
and the binary sysctls as they were written were not
consistent with what showe
We don't preoperly support the sysctl binary path for flushing
the ipv6 routes. So remove support for a binary path.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/ipv6/route.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/rou
- In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
sysctl names for a function that works with proc.
- In neighbour.c reorder the table to put the possibly unused entries
at the end so we can remove them by terminating the table early.
- In neighbour.c kill the entries with q
Hello,
=
[ INFO: inconsistent lock state ]
2.6.23-rc2-mm1 #7
-
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&tp->lock){+...}, at: [] rtl8139_interrupt+0x27/0x46b [8139too]
{in-har
How about we just remove the RDMA stack altogether? I am not at all
kidding. If you guys can't stay in your sand box and need to cause
problems for the normal network stack, it's unacceptable. We were
told all along the if RDMA went into the tree none of this kind of
stuff would be an issue.
On Thu, 9 Aug 2007, Chris Snook wrote:
> Segher Boessenkool wrote:
> > > > The only safe way to get atomic accesses is to write
> > > > assembler code. Are there any downsides to that? I don't
> > > > see any.
> > >
> > > The assumption that aligned word reads and writes are atomic, and that
> >
Chuck Ebbert wrote:
On 08/08/2007 07:15 PM, Auke Kok wrote:
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/82571.c |4
drivers/net/e1000e/e1000.h |7 ---
drivers/net/e1000e/es2lan.c |5 +
drivers/net/e1000e/ethtool.c |3 ++-
drivers/net/e10
On 08/08/2007 07:15 PM, Auke Kok wrote:
> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
> ---
>
> drivers/net/e1000e/82571.c |4
> drivers/net/e1000e/e1000.h |7 ---
> drivers/net/e1000e/es2lan.c |5 +
> drivers/net/e1000e/ethtool.c |3 ++-
> drivers/net/e1000e/hw.
So, why not use the well-defined alternative?
Because we don't need to, and it hurts performance.
It hurts performance by implementing 32-bit atomic reads in assembler?
No, I misunderstood the question. Implementing 32-bit atomic reads in
assembler is redundant, because any sane compiler, *p
Anyway, what's the supposed advantage of *(volatile *) vs. using
a real volatile object? That you can access that same object in
a non-volatile way?
You'll have to take that up with Linus and the minds behind Volatile
Considered Harmful, but the crux of it is that volatile objects are
prone t
Anyway, what's the supposed advantage of *(volatile *) vs. using
a real volatile object? That you can access that same object in
a non-volatile way?
That's my understanding. That way accesses where you don't care about
volatility may be optimised.
But those accesses might be done non-atomic
Hi!
> I've been working on this for quite some time. And should post again
> soon. Please see the patches:
>
> http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/
>
> For now it requires one uses SLUB, I hope that SLAB will go away (will
> save me the trouble of adding support
From: Auke Kok <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 09:41:17 -0700
> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
I think this is definitely how we should handle LRO
configuration instead of the ad-hoc module parameters
current LRO drivers use now.
I'll put this infrastructure into net-2.6.
From: Sean Hefty <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 14:40:16 -0700
> Steve Wise wrote:
> > Any more comments?
>
> Does anyone have ideas on how to reserve the port space without using a
> struct socket?
How about we just remove the RDMA stack altogether? I am not at all
kidding. If yo
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using a
struct socket?
- Sean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/
This patch adds support for 2 new board variants:
- A Quad port fiber 82571 board
- A blade version of the 82571 quad copper board
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c |2 ++
drivers/net/e1000/e1000_hw.c |5 +
drivers/net/e1000/e1000_
Glenn Grundstrom wrote:
This code is far from a TCP stack. It's main purpose is to exchange
RDMA MPA request/response messages that are required by the iWarp specs
and therefore needed by our hardware. All RNIC hardware vendors need
this MPA message exchange, including those already accepted
> +#define atomic_read(v) (*(volatile __s32 *)&(v)->counter)
> +#define atomic64_read(v) (*(volatile __s64 *)&(v)->counter)
>
> #define atomic_set(v,i) (((v)->counter) = (i))
> #define atomic64_set(v,i)(((v)->counter) = (i))
Losing the volatile from the "set"
Brandon Philips wrote:
On 17:30 Wed 08 Aug 2007, Ramkrishna Vepa wrote:
Before slot_reset event is called io_error_detected could be called
(where pci_disable_device() is called), right?
Oops! Right, the documentation says .error_detected is _always_ called
before .slot_reset. So, this patc
On 17:30 Wed 08 Aug 2007, Ramkrishna Vepa wrote:
> Before slot_reset event is called io_error_detected could be called
> (where pci_disable_device() is called), right?
Oops! Right, the documentation says .error_detected is _always_ called
before .slot_reset. So, this patch is not correct. Plea
Segher Boessenkool wrote:
Anyway, what's the supposed advantage of *(volatile *) vs. using
a real volatile object? That you can access that same object in
a non-volatile way?
That's my understanding. That way accesses where you don't care about
volatility may be optimised.
For instance, i
Segher Boessenkool wrote:
Explicit
+casting in atomic_read() ensures consistent behavior across
architectures
+and compilers.
Even modulo compiler bugs, what makes you believe that?
When you declare a variable volatile, you don't actually tell the
compiler where you want to override its def
Geert Uytterhoeven wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
Segher Boessenkool wrote:
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words are a
Explicit
+casting in atomic_read() ensures consistent behavior across
architectures
+and compilers.
Even modulo compiler bugs, what makes you believe that?
When you declare a variable volatile, you don't actually tell the
compiler where you want to override its default optimization behavior,
Segher Boessenkool 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 really
does permit this.
Yes, but we don't write code for the
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 writes
being visible to other CPUs, you're screwed either way
Andrew Morton wrote:
umm, I was hoping to find out which of those two patches was the cuplrit.
Almost surely it was 9ee6b32a47b9abc565466a9c3b127a5246b452e5?
Highly likely it is my patch in #ALL.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of
If you need to guarantee that the value is written to memory at a
particular time in your execution sequence, you either have to read it
from memory to force the compiler to store it first
That isn't enough. The CPU will happily read the datum back from
its own store queue before it ever hit m
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and
that words are aligned unless explicitly packed otherwise, is
endemic in the kernel. No sane compiler viol
On Thu, 9 Aug 2007 21:04:35 +0200
"Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
> On 09/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Thu, 09 Aug 2007 15:23:41 +0200
> > Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew Morton pisze:
> > > > ftp://ftp.kernel.org/pub/linux/ker
Segher Boessenkool wrote:
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words are aligned unless explicitly packed otherwise, is endemic in
the ker
On 09/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 09 Aug 2007 15:23:41 +0200
> Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton pisze:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/
> >
> > I am experiencing some problems
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
really
does permit this.
Yes, but we don't write code for these compilers. There are
Do not enable timestamps automatically on mmap'ed AF_PACKET sockets.
---
commit d1d6e6bf196e31b6306fd0fef95f4190983c8a86
tree 22637506c0aafeabfbe05faf5352d0358c4d9460
parent 6a302358d87fedaf7bda12b8e909265ebf1ce674
author Unai Uribarri <[EMAIL PROTECTED]> Tue, 31 Jul 2007 20:38:42 +0200
committer
Any more comments?
Steve Wise wrote:
Networking experts,
I'd like input on the patch below, and help in solving this bug
properly. iWARP devices that support both native stack TCP and iWARP
(aka RDMA over TCP/IP/Ethernet) connections on the same interface need
the fix below or some similar
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
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words are aligned unless explicitly packed otherwise, is endemic in
the kernel. No sane compiler viol
There is another option:
1. Move timestampt activation to packet_set_ring(), so it's activated
only once at setup instead of every time a packet arrives.
2. Fix sock_setsockopt() so setting SO_TIMESTAMP to 0 effectively
disables timestamp.
My first patch set did that. I sent that patches in mime
On Thu, 09 Aug 2007 15:23:41 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton pisze:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/
>
> I am experiencing some problems with 8139too
>
> [ 28.847004] 8139too :02:0d.0: region #0
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 can
hold that data in cache as long as it wants before it writes it
On Thu, Aug 09, 2007 at 08:13:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
wrote:
> On jue, 2007-08-09 at 18:33 +0400, Evgeniy Polyakov wrote:
> > On Thu, Aug 09, 2007 at 04:21:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
> > wrote:
> > > The attached patch removes the automatic timestamp activ
On Thu, 2007-08-09 at 10:55 -0700, Linus Torvalds wrote:
> > You can use this forget() macro to make the compiler reread a variable:
> >
> > #define forget(var) asm volatile ("" : "=m"(var))
>
> No. That will also make the compiler "forget" any previous writes to it,
> so it changes behaviour.
>
Hello Roland,
> Shirley, I think it would still be useful to run benchmarks of IPoIB
> on ehca with Dave's NAPI patches, both V5 that changed the "missed
> event" behavior and V6 that didn't. At least I'm curious to know how
> much the difference is.
>
> - R.
The performance difference was hug
On jue, 2007-08-09 at 18:33 +0400, Evgeniy Polyakov wrote:
> On Thu, Aug 09, 2007 at 04:21:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
> wrote:
> > The attached patch removes the automatic timestamp activation, that
> > only mmap'ed AF_PACKET sockets perform. I known it can break user
> > applic
On Thu, 9 Aug 2007, Chuck Ebbert wrote:
>
> You can use this forget() macro to make the compiler reread a variable:
>
> #define forget(var) asm volatile ("" : "=m"(var))
No. That will also make the compiler "forget" any previous writes to it,
so it changes behaviour.
You'd have to use "+m".
On Thu, 2007-08-09 at 13:36 -0400, Chuck Ebbert wrote:
> > Fair enough. Casting to (volatile int *) will give us the behavior
> > people expect when using atomic_t without needing to use inefficient
> > barriers.
> >
>
> You can use this forget() macro to make the compiler reread a
> variable:
>
> > Dave, could you please hold this portion of the patch for a moment. I will
> > test this patch ASAP. According to our previous experience, this changes
> > significant changes some IPoIB driver performance.
>
> I reverted everything Roland had an issue with, I got tired of arguing
> my p
On 08/09/2007 03:31 AM, Chris Snook wrote:
>
> Fair enough. Casting to (volatile int *) will give us the behavior
> people expect when using atomic_t without needing to use inefficient
> barriers.
>
You can use this forget() macro to make the compiler reread a variable:
#define forget(var) asm
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 w
> > +atomic_t cm_connects;
> > +atomic_t cm_accepts;
> > +atomic_t cm_disconnects;
> > +atomic_t cm_closes;
> > +atomic_t cm_connecteds;
> > +atomic_t cm_connect_reqs;
> > +atomic_t cm_rejects;
>
> do you really want to take the hit of a LOCK prefix each time you
> increment a stat???
I
> +ifdef CONFIG_INFINIBAND_NES_DEBUG
> +EXTRA_CFLAGS += -DNES_DEBUG
> +endif
I would just use the CONFIG_INFINIBAND_NES_DEBUG symbol directly in
your code.
> +EXTRA_CFLAGS += -DNES_MINICM
If you're defining this unconditionally, can you just get rid of all
the tests of this symbol?
- R.
-
> +config INFINIBAND_NES
> +tristate "NetEffect RNIC Driver"
> +depends on PCI && INET && INFINIBAND
You don't need the dependency on INFINIBAND any more, because the
whole drivers/infiniband/Kconfig file is guarded by an "if INFINIBAND"
- R.
-
To unsubscribe from this list: send the
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 to help pummel any
compiler writer that pulls such a dirty tric
On Thursday 09 August 2007, Chris Snook wrote:
> a) chicken and egg: asm-generic/atomic.h depends on definitions in
> asm/atomic.h
Ok, I see.
> If you can find a way to reshuffle the code and make it simpler, I personally
> am
> all for it. I'm skeptical that you'll get much to show for the e
Adrian Bunk wrote:
On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote:
...
- There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure
the developers would like it tested. Please cc netdev@vger.kernel.org on
any reports.
...
Changes since 2.6.23-rc2-mm1:
...
git-ne
Chris Snook wrote:
From: Chris Snook <[EMAIL PROTECTED]>
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
To head off the criticism, I admit this is an o
> > Dave, could you please hold this portion of the patch for a moment. I
> > will test this patch ASAP. According to our previous experience, this
> > changes significant changes some IPoIB driver performance.
> If you adjust your quantum while doing that testing you may find an
> optimal va
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 stan
On Thu, Aug 09, 2007 at 09:30:28AM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Purify volatile use for atomic_t on arm.
>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Acked-by: Russell King <[EMAIL PROTECTED]>
--
Russell King
Linux kernel2.6 ARM Linux - htt
On Thu, Aug 09, 2007 at 10:01:54AM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Purify volatile use for atomic[64]_t on parisc.
>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
>
Sure, why not.
ACKed-by: Kyle McMartin <[EMAIL PROTECTED]>
-
To unsubscribe from this li
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 really
does permit this.
Yes, but we don't write code for these
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
include/linux/ethtool.h |8 +++
include/linux/netdevice.h |1 +
net/core/ethtool.c| 53 +
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/i
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
ethtool-copy.h |8
ethtool.8 |8 ++--
ethtool.c | 39 +--
3 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3a63224..ab9d688 100
On Thu, Aug 09, 2007 at 10:09:08AM -0400, Chris Snook wrote:
> Purify volatile use for atomic_t on sh64.
>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
On Thu, Aug 09, 2007 at 10:10:34AM -0400, Chris Snook wrote:
> Purify volatile use for atomic_t on sh.
>
> Signed-off-by: Chris Snook <[EMAI
Segher Boessenkool wrote:
Historically this has been
+accomplished by declaring the counter itself to be volatile, but the
+ambiguity of the C standard on the semantics of volatile make this
practice
+vulnerable to overly creative interpretation by compilers.
It's even worse when accessing th
Segher Boessenkool wrote:
We can't have split stores because we don't use atomic64_t on 32-bit
architectures.
That's not true; the compiler is free to split all stores
(and reads) from memory however it wants. It is debatable
whether "volatile" would prevent this as well, certainly
it is unsaf
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
Historically this has been
+accomplished by declaring the counter itself to be volatile, but the
+ambiguity of the C standard on the semantics of volatile make this
practice
+vulnerable to overly creative interpretation by compilers.
It's even worse when accessing through a volatile casted poi
We can't have split stores because we don't use atomic64_t on 32-bit
architectures.
That's not true; the compiler is free to split all stores
(and reads) from memory however it wants. It is debatable
whether "volatile" would prevent this as well, certainly
it is unsafe if you want to be portabl
On Thu, Aug 09, 2007 at 11:03:03AM -0400, John Stoffel wrote:
>
> Hi,
Hi, read below, please...
>
> I'm opening this ticket as a new subject, even though it looks like it
> might be related to the thread "Networking dies after random time".
> Sorry for the wide CC list, but since my network has
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
architecture-specific compiler-induced bugs due to the fact that
a
On Thu, Aug 09, 2007 at 06:04:34PM +0200, Andi Kleen wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> writes:
>
> > It seems, we can start to think about some preferred solutions,
> > already. Here are some of my preliminary conclusions and suggestions.
> >
> > The problem of timeouts with some 'olde
Hi,
I'm opening this ticket as a new subject, even though it looks like it
might be related to the thread "Networking dies after random time".
Sorry for the wide CC list, but since my network hasn't died since I
rebooted into 2.6.23-rc2 (after 30+ days at 2.6.22-rc7), I'm wondering
if the problem
Aurélien Charbon wrote:
@@ -112,12 +112,16 @@
return (hash ^ (hash>>8)) & 0xff;
}
#endif
+static inline int hash_ip6(struct in6_addr ip)
+{
+return (hash_ip(ip.s6_addr32[0]) ^ hash_ip(ip.s6_addr32[1])
^ hash_ip(ip.s6_addr32[2]) ^ hash_ip(ip.s6_addr32[3])) ;
+}
How have you tes
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() us
Thanks for these comments.
Chuck Lever wrote:
Some naive questions:
1. If IPv6 support is not configured into the kernel, how does an
IPv6-only cache work?
Yes it should work.
The INET6 structures are only used as containers for both type of address.
I have tested by unabling IPv6 options
On Thu, 9 Aug 2007, Jerry Jiang wrote:
>
> and still not to said "Why the *volatile-accesses-in-code* is
> acceptable"
I don't think volatile is necessarily wonderful in code _either_. So I
think the "atomic_read()" issue would be even better off if we just made
sure everybody behaves well an
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 to imply volatile behavior but no longer does.
When we make the vola
It seems, we can start to think about some preferred solutions,
already. Here are some of my preliminary conclusions and suggestions.
The problem of timeouts with some 'older' network cards seems to hit
mainly x86_64 arch, and after diagnosing and testing (still beeing
done) it's caused by resend
On Thu, 9 Aug 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Thu, 9 Aug 2007 12:50:51 +0300 (EEST)
>
> Ok, in order to get this started I merged the above patches
> into net-2.6.24
>
> I'm exhausted and done for today. :-)
:-)
> We can work on the other bits next
1 - 100 of 161 matches
Mail list logo
