From: Konstantin Sharlaimov [EMAIL PROTECTED]
Date: Wed, 20 Jun 2007 22:37:18 +1100
The mppe_decompress() function required a buffer that is 1 byte too small when
receiving a message of mru size. This fixes buffer allocation to prevent this
from occurring.
Signed-off-by: Konstantin
From: Shannon Nelson [EMAIL PROTECTED]
Date: Thu, 21 Jun 2007 09:34:55 -0700
This moves the local_irq_enable() call in net_rx_action() to before
calling the CONFIG_NET_DMA's dma_async_memcpy_issue_pending() rather
than after. This shortens the irq disabled window and allows for DMA
drivers
From: Olaf Kirch [EMAIL PROTECTED]
Date: Tue, 19 Jun 2007 09:56:24 +0200
From: Olaf Kirch [EMAIL PROTECTED]
Make skb_seq_read unmap the last fragment
Having walked through the entire skbuff, skb_seq_read would leave the
last fragment mapped. As a consequence, the unwary caller would leak
DM == David Miller [EMAIL PROTECTED] writes:
DM Containers are I believe a step backwards, and we're better than
DM that.
Are there any alternative proposals?
I guess it would be a start if you could run processes with a
different policy table as default. Ideally traffic from those
processes
PJ Waskiewicz wrote:
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index 09808b7..ec3a9a5 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -103,8 +103,8 @@ struct tc_prio_qopt
enum
{
- TCA_PRIO_UNPSEC,
- TCA_PRIO_TEST,
You
PJ Waskiewicz wrote:
+struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
+ void (*setup)(struct net_device *), int queue_count)
{
void *p;
struct net_device *dev;
@@ -3361,7 +3368,9 @@ struct net_device *alloc_netdev(int sizeof_priv, const
char
Currently NAT (and others) that want to modify cloned skbs copy them,
even if in the vast majority of cases its not necessary because the
skb is a clone made by TCP and the portion NAT wants to modify is
actually writable because TCP release the header reference before
cloning.
The problem is
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 16:56:49 -0600
If the only use was strong isolation which Dave complains about I would
concur that the namespace approach is inappropriate. However there are
a lot other uses.
By
It looks like the problem doesnt exist in the new ubuntu kernel version
2.6.20-16.29. I have been testing it for few days and network works fine.
The problem still exists for the 2.6.22-rc4 patched version which I compiled
before.
-
To unsubscribe from this list: send the line unsubscribe
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 15:41:16 -0600
If you want the argument to compile out. That is not a problem at all.
I dropped that part from my patch because it makes infrastructure more
complicated and there
Fixed by including linux/dma-mapping.h:
CC drivers/net/au1000_eth.o
drivers/net/au1000_eth.c: In function 'au1000_probe':
drivers/net/au1000_eth.c:661: warning: implicit declaration of function
'dma_alloc_noncoherent'
drivers/net/au1000_eth.c:802: warning: implicit declaration of function
On tor, 2007-06-21 at 21:13 -0700, Stephen Hemminger wrote:
On Fri, 22 Jun 2007 04:45:25 +0200
Ian Kumlien [EMAIL PROTECTED] wrote:
On tor, 2007-06-21 at 18:57 -0700, Stephen Hemminger wrote:
Redirected of LKML, netdev is the proper list.
Thanks =)
On Thu, 21 Jun 2007 22:51:32
Hello Patrick and Jamal,
as i felt a bit misunderstood in the discussion about the usage of
skb-iif and the idea behind the virtual CAN driver i created four
PDF-slides to clarify some issues. The slides may give you the
appropriate background why the incoming (receiving) interface is
relevant at
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones [EMAIL PROTECTED] wrote:
Hi,
I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
But I am hitting a max limit of 4000 IP address . Seems like there is a
limiting variable in linux kernel (which one? ) that prevents from
On Jun 24, 2007, at 13:20:01, David Jones wrote:
Hi, I am trying to add multiple IP addresses ( v6 ) to my FC7 box
on eth0. But I am hitting a max limit of 4000 IP address . Seems
like there is a limiting variable in linux kernel (which one? )
that prevents from adding more IP addresses
On Saturday 23 June 2007 03:17, Simon Arlott wrote:
Because then it requires yet another network daemon, RA in
the kernel means there's no need for one to manage adding
auto-configured IP addresses... what's wrong with doing the
same for DNS?
Actually I think an integrated network
Unrelated wishful thinking
I keep having hopeful dreams that one day netfilter will grow support
for cross-protocol NAT (IE: NAT a TCPv4 connection over TCPv6 to the
IPv6-only local web server, or vice versa). It would seem that would
require a merged xtables program.
You don't
On Jun 24 2007 15:08, Kyle Moffett wrote:
Do you really need that many IP addresses? When somebody finally gets
around to implementing REDIRECT support for ip6tables then you could
just redirect them all to the same port on the local system.
The way I see it, it's: if someone gets around to
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones [EMAIL PROTECTED] wrote:
I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
But I am hitting a max limit of 4000 IP address . Seems like there is a
limiting variable in linux kernel (which one? ) that prevents from
adding more
Hi,
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones [EMAIL PROTECTED] wrote:
I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
But I am hitting a max limit of 4000 IP address . Seems like there is a
limiting variable in linux kernel (which one? ) that prevents from
git tree a06381fec77bf88ec6c5eb6324457cb04e9ffd69 (last commit ID)
gives:
/ws/linux-2.6.22/net/dccp/ipv4.c:589: warning: initialization from
incompatible
/ws/linux-2.6.22/net/dccp/ipv6.c:387: warning: initialization from
incompatible
[pointer type - `less` cut it off from the 80 col screen]
git tree a06381fec77bf88ec6c5eb6324457cb04e9ffd69 (last commit ID)
gives:
/ws/linux-2.6.22/net/dccp/ipv4.c:589: warning: initialization from
incompatible
/ws/linux-2.6.22/net/dccp/ipv6.c:387: warning: initialization from
incompatible
Extra patches with quilt caused that. Sorry for the noise.
On Jun 24 2007 13:44, [EMAIL PROTECTED] wrote:
On Jun 24 2007 15:08, Kyle Moffett wrote:
Do you really need that many IP addresses? When somebody finally gets
around to implementing REDIRECT support for ip6tables then you could
just redirect them all to the same port on the local
On Sun, 24 Jun 2007, Jan Engelhardt wrote:
On Jun 24 2007 15:08, Kyle Moffett wrote:
Do you really need that many IP addresses? When somebody finally gets
around to implementing REDIRECT support for ip6tables then you could
just redirect them all to the same port on the local system.
The
Corey Hickey wrote:
Hello,
I haven't been keeping up with sending ESFQ [ANNOUNCE] messages to this
list, but I've still been working on the patch. If you're curious about
recent changes, take a look at the home page, ChangeLog, and README:
http://fatooh.org/esfq-2.6/
PJ Waskiewicz wrote:
+ /* If we're multiqueue, make sure the number of incoming bands
+ * matches the number of queues on the device we're associating with.
+ */
+ if (tb[TCA_PRIO_MQ - 1])
+ q-mq = *(unsigned char *)RTA_DATA(tb[TCA_PRIO_MQ - 1]);
+
+ if
On Sat, 2007-06-23 at 23:07 -0700, David Miller wrote:
The original version of this fix have made it to the 2.6.22-rc5 already
and should be replaced with this one, however the two can coexist in the
same code for a while.
--- linux-2.6.21.3/drivers/net/ppp_generic.c.orig 2007-06-20
Corey Hickey wrote:
Patrick McHardy wrote:
Should ESFQ be merged into SFQ or remain as a separate qdisc?
I've CCed netdev. I think merging parts of ESFQ (dynamic depth and
flow number) would make a lot of sense, but I'm intending to submit
an alternative to the ESFQ hashing scheme for
Patrick McHardy wrote:
Corey Hickey wrote:
Patrick McHardy wrote:
Should ESFQ be merged into SFQ or remain as a separate qdisc?
I've CCed netdev. I think merging parts of ESFQ (dynamic depth and
flow number) would make a lot of sense, but I'm intending to submit
an alternative to the
On Sat, 2007-06-23 at 10:47 -0400, C. Scott Ananian wrote:
Rémi and Simon give my responses very eloquently. Although you could
have yet-another-network-daemon redundantly process RA messages, the
kernel is doing it already and it makes sense to just push this
information to userland using
From: Patrick McHardy [EMAIL PROTECTED]
Date: Sun, 24 Jun 2007 14:53:36 +0200
- sendmsg eth0, no NAT: sys 0m2.508s
- sendmsg eth0, NAT: sys 0m2.539s
- sendmsg eth0, NAT + patch: sys 0m2.445s(no change)
This is probably because we're touching all the
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 24 Jun 2007 06:58:54 -0600
I am convinced I can keep network namespaces something that is so
trivial and obvious to get right you won't have to pay attention
to them.
Ok then, I'll hold you to this when you post the rest of your
Hi Jamal, Dave (and anyone else interested),
Could you review this patch ?
Thanks,
- KK
On Tue, 2007-06-19 at 12:15 -0400, jamal wrote:
On Mon, 2007-18-06 at 20:58 -0700, David Miller wrote:
From: Krishna Kumar2 [EMAIL PROTECTED]
Date: Tue, 19 Jun 2007 09:05:28 +0530
Dave, does it
From: Krishna Kumar [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 10:21:24 +0530
New changes :
- Incorporated Peter Waskiewicz's comments.
- Re-added back one warning message (on driver returning wrong value).
Previous changes :
- Converted to use switch/case code which looks neater.
-
From: Krishna Kumar [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 10:24:11 +0530
(Same from previous patch, resending for completion)
Changes :
- netif_queue_stopped need not be called inside qdisc_restart as
it has been called already in qdisc_run() before the first skb
is sent, and in
From: Patrick McHardy [EMAIL PROTECTED]
Date: Sun, 24 Jun 2007 14:53:36 +0200
I expect other users can see a similar performance improvement,
packet mangling iptables targets, ipip and ip_gre come to mind ..
Comments welcome.
Patrick please give me a suitable signed-off-by line, I'd
like to
From: Dan Williams [EMAIL PROTECTED]
Date: Sun, 24 Jun 2007 22:17:31 -0400
The glibc guys rejected things like periodically stat()-ing resolv.conf.
At least these days such a thing could be re-proposed using
something like inotify(), although it might be difficult
to get glibc to receive that
From: Krishna Kumar [EMAIL PROTECTED]
Date: Mon, 25 Jun 2007 08:18:32 +0530
Hi Jamal, Dave (and anyone else interested),
Could you review this patch ?
I definitely will.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
According to the RFC 4292 (IP Forwarding Table MIB) there is a need for an age
entry for all the routes in the routing table. The entry in the RFC is
inetCidrRouteAge and oid is inetCidrRouteAge.1.10.
Many snmp application require this age entry. So iam adding the age field in
the routing table
Robert Iakobashvili wrote:
Hi,
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones [EMAIL PROTECTED]
wrote:
I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
But I am hitting a max limit of 4000 IP address . Seems like there
is a
limiting variable in linux kernel (which
In article [EMAIL PROTECTED] (at Mon, 25 Jun 2007 10:28:38 +0530), Varun
Chandramohan [EMAIL PROTECTED] says:
According to the RFC 4292 (IP Forwarding Table MIB) there is a need for an
age entry for all the routes in the routing table. The entry in the RFC is
inetCidrRouteAge and oid is
YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Mon, 25 Jun 2007 10:28:38 +0530), Varun
Chandramohan [EMAIL PROTECTED] says:
According to the RFC 4292 (IP Forwarding Table MIB) there is a need for an
age entry for all the routes in the routing table. The entry in the
On Sun, 24 Jun 2007 21:57:19 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8668
Summary: HTB Deadlock
Product: Networking
Version: 2.5
KernelVersion: 2.6.19.7
Platform: All
OS/Version: Linux
On 6/23/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007 18:48:30 +0530 pradeep singh [EMAIL PROTECTED] wrote:
Hi,
My mistake.
Resending after reformatting the patch by hand.
Looks like gmail messes the plain text patches.
That's still mangled so I typed it in again.
Sorry
44 matches
Mail list logo
