From: "Eric Molitor" <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 22:39:16 -0600
> Its pretty bad on both. But most Java developers debug via localhost.
> The slowdowns don't occur on Windows, Solaris, or the unoficial JDK
> port to BSD. But I dont know what kernels support ABC. For now I will
> see
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 16:21:05 -0800
> well, there are stacks which do "stretch acks" (after a fashion) that
> make sure when they see packet loss to "do the right thing" wrt sending
> enough acks to allow cwnds to open again in a timely fashion.
Once a los
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Fri, 10 Mar 2006 02:10:31 +0200
> But with the change we are discussing, could an ack now be sent even
> sooner than we have at least two full sized segments? Or does
> __tcp_ack_snd_check delay until we have at least two full sized
> segments?
Its pretty bad on both. But most Java developers debug via localhost.
The slowdowns don't occur on Windows, Solaris, or the unoficial JDK
port to BSD. But I dont know what kernels support ABC. For now I will
see what sun does with the bug report and then chase after IBM. IBM
tends to be more willin
On Thu, 9 Mar 2006, Catherine Zhang wrote:
> As per request from Stephen, I have enclosed the patch for Unix Datagram
> getpeersec.
>
> As always, comments are welcome!
Looks fine to me.
Acked-by: James Morris <[EMAIL PROTECTED]>
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from th
On Wednesday 08 March 2006 11:45, Eric Dumazet wrote:
> Andi Kleen a écrit :
>
> >
> > Can you send tested patches with proper descriptions and signed off lines
> > please?
> >
> > -Andi
> >
> >
>
> You are welcome Andi :)
Applied. Please put the description next time into the attachment to
Baruch Even <[EMAIL PROTECTED]> wrote:
>
> + case NETDEV_UNREGISTER:
>case NETDEV_GOING_DOWN:
>case NETDEV_DOWN:
>/* Find every socket on this device and kill it. */
This brings up the question as to why we need to flush it on
NETDEV_GOING_DOWN and NETDEV_DOW
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Or does __tcp_ack_snd_check delay until we have at least two full sized
> segments?
What I'm trying to say, since RFC 2525, 2.13 talks about
"every second full-sized segment", so following the code from
__tcp_ack_snd_check, why does it do
On Thu, Mar 09, 2006 at 10:06:29AM -0600, Kumar Gala wrote:
> I was hoping someone might have some ideas on what might have happened
> with the following oops/BUG(). This is on an embedded PPC running
> 2.6.16-rc5. From the description I got from my coworker who say this, he
> was doing NFS on
David S. Miller wrote:
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Wed, 8 Mar 2006 14:53:11 +0200
What I was trying to figure out was, how can we re-enable the trick
without hurting TSO? Could a solution be to simply look at the frame
size, and call tcp_send_delayed_ack if the frame s
Quoting David S. Miller <[EMAIL PROTECTED]>:
>Description
> To improve efficiency (both computer and network) a data receiver
> may refrain from sending an ACK for each incoming segment,
> according to [RFC1122]. However, an ACK should not be delayed an
> inordinate amo
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 15:51:14 -0800
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
X wants the packets to go out immediately, in fact as Ji
On Thu, 09 Mar 2006 15:54:50 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Thu, 09 Mar 2006 15:51:14 -0800
>
> > Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
> > of small packets? What happens to it with this A
Also X on Linux doesn't use TCP over loopback. It seems to use AF_UNIX.
is this problem only over loopback? or is it just harder to see it over
a "real" link?
rick
onlist no need for cc
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PR
Hi,
As per request from Stephen, I have enclosed the patch for Unix Datagram
getpeersec.
As always, comments are welcome!
thanks,
Catherine
--
From: [EMAIL PROTECTED]
This patch implements an API whereby an application can determine the
label of its peer's Unix datagram sockets via the au
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 15:51:14 -0800
> Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
> of small packets? What happens to it with this ABC stuff going?
X wants the packets to go out immediately, in fact as Jim
Getty's mentioned duri
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 15:45:05 -0800
> Maybe Solaris (and Windows?) have special-case handling for local TCP. It
> seems a bit odd to me that loopback would use normal handling for things
> like slow-start and congestion, but I'm sure there's a good reason
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Wed, 8 Mar 2006 14:53:11 +0200
> What I was trying to figure out was, how can we re-enable the trick
> without hurting TSO? Could a solution be to simply look at the frame
> size, and call tcp_send_delayed_ack if the frame size is small?
The ch
"David S. Miller" <[EMAIL PROTECTED]> wrote:
>
> > Like Sun is going to give me the source?...
>
> And if Sun doesn't support their userland products well that is
> somehow the Linux kernel's problem?
Presumably they tested this on Solaris and it ran OK.
Maybe Solaris (and Windows?) have special
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Tue, 7 Mar 2006 14:59:10 -0800
> The patch below merges the use of the wait queue lock and socket spinlock
> into one. This gains us ~100-150Mbit/s on netperf, mostly due to the fact
> that because we know how the spinlock is used, we can avoid t
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 15:34:33 -0800
> David S. Miller wrote:
> > I had to do some minor fixups, and kill some trailing whitespace
> > added by this patch, but looks good, applied.
> >
> > Thanks a lot Rick.
>
> You're welcome. If the fixups were related to
This patch is correct, these two variables are unused in this driver. Thanks for
catching this!
Signed-off-by: Scott Bardone <[EMAIL PROTECTED]>
Adrian Bunk wrote:
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
us
David S. Miller wrote:
I had to do some minor fixups, and kill some trailing whitespace
added by this patch, but looks good, applied.
Thanks a lot Rick.
You're welcome. If the fixups were related to things I may have botched
in the patch process, please let me know so I might be able to avoi
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 14:20:06 +0100
> Sorry, thats just as broken as before. Better patch attached.
Applied, thanks Patrick.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
From: Xiaolan Zhang <[EMAIL PROTECTED]>
Date: Wed, 8 Mar 2006 22:02:31 -0500
> I am working on a separate patch for Unix datagram, instead of mixing the
> two into one patch.
James, is this Ok with you?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
I had to do some minor fixups, and kill some trailing whitespace
added by this patch, but looks good, applied.
Thanks a lot Rick.
-
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/majord
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 15:11:47 -0800
> Then the dst would get changed, no breakage.
Not with a TC action rewrite on input, that would happen after
loopback does the netif_rx().
Interface specific hard-coded metrics are wrong from every single
possible
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/chelsio/espi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
--- linux
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 13:35:16 -0800
> On Thu, Mar 09, 2006 at 01:12:20PM -0800, David S. Miller wrote:
> > So Ben can you work to figure out what the bind(0.0.0.0)
> > problem was? Once that is fully resolved, I think I'll apply
> > your RCU patch to ne
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Fri, 10 Mar 2006 00:06:50 +0100
> The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
> is already handled above).
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe from this list: send th
On Thu, 09 Mar 2006 15:06:22 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Thu, 9 Mar 2006 14:56:43 -0800
>
> > This patch is changes the initial TCP congestion window for connections that
> > are over the loopback device. This give
The Coverity checker noted that the call to prism2_hw_reset() was dead
code.
Does this patch change the code to what was intended?
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_hw.c.old
2006-03-09 23:28:30.0 +0100
The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
is already handled above).
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c.old 2006-03-09
23:25:25.0 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c 2006-03
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 14:56:43 -0800
> This patch is changes the initial TCP congestion window for connections that
> are over the loopback device. This gives better for performance for
> applications
> that do lots of small writes. It might also help f
This patch is changes the initial TCP congestion window for connections that
are over the loopback device. This gives better for performance for applications
that do lots of small writes. It might also help for idiotic benchmarks.
See: http://bugzilla.kernel.org/show_bug.cgi?id=6177
Signed-off-b
Geert Uytterhoeven <[EMAIL PROTECTED]> :
[...]
> So when compiling for Cobalt, we work around the hardware bug, while for other
> platforms, we just disable MWI?
>
> Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
> work around the bug?
Of course it is possible but it i
Stephen Hemminger <[EMAIL PROTECTED]> :
> On Thu, 9 Mar 2006 00:06:33 +0100
> Francois Romieu <[EMAIL PROTECTED]> wrote:
[...]
> > So instead of #1..#6 from 07/03/2006, #1..#3 from 08/03/2003
> > which actually cover (with minor differences) #4..#6 from 07/03/2006
> > should be pushed ?
> >
>
>
Jiri Benc wrote :
> On Thu, 09 Mar 2006 11:39:06 +0800, Zhu Yi wrote:
> > On Wed, 2006-03-08 at 13:23 +0100, Jiri Benc wrote:
> > > I don't think it's a good idea to misuse 'iwconfig sens' for this.
> >
> > This has been discussed on ipw2100-devel ML. Jean will change the manual
> > for 'iwconfig
From: Baruch Even <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 23:56:39 +0200
> We need to remove all references to the device when we receive the
> NETDEV_UNREGISTER notification.
>
> Signed-off-by: Baruch Even <[EMAIL PROTECTED]>
Good spotting Baruch. Once this gets a positive test result
I'll a
* Andrew Morton <[EMAIL PROTECTED]> [060309 12:19]:
>
>
> Begin forwarded message:
>
> Date: Thu, 9 Mar 2006 01:24:06 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [Bugme-new] [Bug 6197] New: unregister_netdevice: waiting for ppp9
> to become free. Usage count = 658
>
>
>
On Thu, Mar 09, 2006 at 01:12:20PM -0800, David S. Miller wrote:
> Once we have RCU in place for the TCP hash tables, we have the chance
> to code up dynamically sized hash tables. With the current locking,
> this is basically impossible, with RCU it can be done.
Nice!
> So Ben can you work to f
On Thu, 9 Mar 2006 15:13:39 -0600
"Eric Molitor" <[EMAIL PROTECTED]> wrote:
> I did open up a bug with SUN about this. It looks like most clients
> dont set TCP_NODELAY on debug sockets but the JDK itself has
> TCP_NODELAY hardcoded.
>
> In the meantime is there a way to set or disable Appropriat
I did open up a bug with SUN about this. It looks like most clients
dont set TCP_NODELAY on debug sockets but the JDK itself has
TCP_NODELAY hardcoded.
In the meantime is there a way to set or disable Appropriate Byte
Counting on a per interface basis? (I know that its a protocal but the
abiltiy t
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 20:32:16 +0100
> #define PTRS_PER_CACHELINE ((L1_CACHE_BYTES - sizeof(rwlock_t))/sizeof(struct
> hlist_head))
>
> struct hash_agg_bucket {
> rwlock_t wlock;
> struct hlist_head chains[PTRS_PER_CACHELINE];
> };
>
> A divi
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 12:50:44 -0800
> Hrm, maybe use cmpxchg? That gets rid of the lock and automatically
> provides us with hashed spinlocks on archs without a cmpxchg
> implementation.
I don't think we even need to go there, here's why.
Once we have
On Thu, Mar 09, 2006 at 07:25:25PM +0100, Eric Dumazet wrote:
> On a second thought, do you think we still need one rwlock per hash chain ?
>
> TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
>
> On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
>
> With R
On Thu, 2006-03-09 at 14:36 -0600, Larry Finger wrote:
> Dan Williams wrote:
> > Completely untested, not entirely sure it compiles. For whatever
> > reason, softmac is sending custom events to userspace already, but it
> > should _really_ be sending the right WEXT events instead. Comments? If
>
Dan Williams wrote:
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Signed-off-by: Dan Williams <[EMA
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
--- a
Jean Tourrilhes wrote:
Dan Williams wrote :
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 08:33:15 -0800
> A possible solution would be to set cwnd bigger for loopback.
> If there was a clean way to know that connection was over loopback,
> then doing something in tcp_init_metrics() to set INIT_CWND
>
> if (IsLoo
On Thu, 9 Mar 2006 12:29:08 -0600
"Eric Molitor" <[EMAIL PROTECTED]> wrote:
> Just out of curiosity was the window size changed in 2.6.15? Just
> trying to get an idea of what might have changed in 2.6.15 that
> triggered this. (In 2.6.14 and 2.4.27 things run very fast)
No, window size hasn't ch
Rick Jones a écrit :
On a second thought, do you think we still need one rwlock per hash
chain ?
>
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we touch these rwlocks only on TCP connectio
--- linux-2.6-2.6.15/net/ipv4/tcp_output.c.orig 2006-01-02 19:21:10.0
-0800
+++ linux-2.6-2.6.15/net/ipv4/tcp_output.c 2006-03-09 10:41:46.0
-0800
@@ -45,6 +45,11 @@
/* People can turn this off for buggy TCP's found in printers etc. */
int sysctl_tcp_retrans_collapse = 1;
Ok, I've heard your arguments, let's allow full 16-bit
windows by default in 2.6.17, but please pick a better
name for the sysctl knob :-) How about something like
"tcp_workaround_signed_windows"?
So make the naming change, and allow full 16-bit windows
by default, and I'll apply this patch.
O
Dan Williams wrote :
>
> Completely untested, not entirely sure it compiles. For whatever
> reason, softmac is sending custom events to userspace already, but it
> should _really_ be sending the right WEXT events instead. Comments? If
> this looks good, please apply it.
Good catch ! Th
On Thu, Mar 09, 2006 at 07:41:08PM +1100, Nick Piggin wrote:
> Considering that local_t has been broken so that basically nobody
> is using it, now is a great time to rethink the types before it
> gets fixed and people start using it.
I'm starting to get more concerned as the per-cpu changes that
On Thu, Mar 09, 2006 at 09:43:00AM -0800, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
> On Thu, Mar 09, 2006 at 01:18:26PM +0300, Evgeniy Polyakov wrote:
> > Ok, I hacked quite a bit in the patch, but I think nothing major was
> > changed, basically patch rejects.
> > And I'm now unable to bind to
On a second thought, do you think we still need one rwlock per hash chain ?
>
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we touch these rwlocks only on TCP connection
creation/deletion, m
Completely untested, not entirely sure it compiles. For whatever
reason, softmac is sending custom events to userspace already, but it
should _really_ be sending the right WEXT events instead. Comments? If
this looks good, please apply it.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
--- a/
Just out of curiosity was the window size changed in 2.6.15? Just
trying to get an idea of what might have changed in 2.6.15 that
triggered this. (In 2.6.14 and 2.4.27 things run very fast)
On 3/9/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Wed, 08 Mar 2006 23:29:48 -0800 (PST)
> "David
Benjamin LaHaise a écrit :
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit whe
On Thu, Mar 09, 2006 at 01:18:26PM +0300, Evgeniy Polyakov wrote:
> Ok, I hacked quite a bit in the patch, but I think nothing major was
> changed, basically patch rejects.
> And I'm now unable to bind to 0.0.0.0 address, i.e. bind() does not
> fail, but all connections are refused.
> Bind to machi
After several days of operation of Netgear MA311 card, the card becomes
to seek improperly and needs reset. This patch tries to reset the card
when this situation occurs.
Mar 9 06:45:16 berkeley kernel: wlan0: Error -5 writing packet to BAP
Mar 9 06:45:16 berkeley kernel: hermes @ f992a000: BAP0
On Wed, 08 Mar 2006 23:29:48 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 08 Mar 2006 23:24:22 -0800
>
> > I have gotten massive strace's and the java VM is:
> > 1) Turning on TCP_NODELAY
> > 2) Sending small packets.
I was hoping someone might have some ideas on what might have happened
with the following oops/BUG(). This is on an embedded PPC running
2.6.16-rc5. From the description I got from my coworker who say this, he
was doing NFS on the system and at the time the oops occured his desktop
linux box
Balbir Singh wrote:
Hello, Jamal,
Please find the latest version of the patch for review. The genetlink
code has been updated as per your review comments. The changelog is provided
below
1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
2. Provide generic functions called genlmsg_d
Just to clarify this should be reproducable with any Java Debug tool
(IntelliJ, Eclipse, etc) The slow down increases with the scope of the
current Frame. If you have a simple scope of say 5 basic objects then
things are slow but liveable. If you have a large scope of say 22
objects several of whic
> Thanks for the clarification of the usage model. While our needs are
> certainly much less complex,
> it is useful to know the range of options.
>
> >There are no hard rules on what you need to be multicasting and as an
> >example you could send periodic(aka time based) samples from the kernel
Andi Kleen wrote:
> What happens if there are multiple producers? Could happen when
> this would be used for the socket queue.
Then just serialize the producers against each other or try to decouple more.
In reality every communication can be modelled
with a simple unidirectional pipe or set of
Hello Stephen,
2) How to setup the same environment (for non-java savvy people) with
freely available software (Sun JDK okay). I can figure out how to get JDK
IDEA is available for download at http://www.jetbrains.com/idea
You can use either evaluation license or download an EA build and use f
On Thursday 09 March 2006 09:06, Ravikiran G Thirumalai wrote:
> On Wed, Mar 08, 2006 at 04:32:58PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
> > > > Benjamin LaHaise <[EMAIL PROTECTED
On Wed, Mar 08, 2006 at 09:11:49AM -0800, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
> On Wed, Mar 08, 2006 at 02:01:04PM +0300, Evgeniy Polyakov wrote:
> > When I tested RCU for similar change for kevent, but postponed more work
> > to RCU callback, including socket closing and some attempts to
On Thu, 09 Mar 2006 11:39:06 +0800, Zhu Yi wrote:
> On Wed, 2006-03-08 at 13:23 +0100, Jiri Benc wrote:
> > I don't think it's a good idea to misuse 'iwconfig sens' for this.
>
> This has been discussed on ipw2100-devel ML. Jean will change the manual
> for 'iwconfig sens'.
> http://marc.theaimsgr
On Wed, 8 Mar 2006, Francois Romieu wrote:
> Geert Uytterhoeven <[EMAIL PROTECTED]> :
> > On Tue, 7 Mar 2006, Ralf Baechle wrote:
> [...]
> > > I'm just not convinced of having such a workaround as a build option.
> > > The average person building a a kernel will probably not know if the
> > > opti
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 7 Mar 2006 13:50:59 -0800 (PST)
> Since such stacks are rapidly fading into the mists of time, and since
> it is perfectly legal and not entirely uncommon to use a TCP window up
> to 65535 bytes when window scaling is not in use, we want to allow an
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Tue, 7 Mar 2006 13:19:10 -0800
> At this point I'd just like to stir up some discussion, so please
> comment away with any ideas and concerns.
I don't like this :-)
Not because you put x86_64 stuff in there, I know we can abstract
all of that stuf
From: Dave Jones <[EMAIL PROTECTED]>
Date: Wed, 8 Mar 2006 22:50:00 -0500
> We're leaking an skb in a failure path in this function.
>
> Coverity #632
> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
I'll apply this, thanks a lot Dave.
-
To unsubscribe from this list: send the line "unsubscribe n
Ravikiran G Thirumalai wrote:
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches lat
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
> Ravikiran G Thirumalai wrote:
>
> >Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
> >This keeps local_t unsigned long. (We can change it to signed value
> >along with other arches later in one go I guess)
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches later in one go I guess)
Why not just keep naming and structure of interfaces consistent with
On Wed, Mar 08, 2006 at 04:32:58PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Mar 08, 2006 at 03:43:21PM -0800, Andrew Morton wrote:
> > > Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I think it may make more sense to simply conver
83 matches
Mail list logo
