d80211: Fix issues with QOS ops
This patch fixes various bitwise ops dealing with QOS that didn't get
converted properly during the transition to IEEE80211_ style names. Thanks to
Jouni Malinen for pointing this out.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Sat, 05 Aug 2006 22:42:18 -0700
> Thomas Graf wrote:
> > -/* The struct should be in sync with struct net_device_stats */
> > -struct rtnl_link_stats
> > -{
> > - __u32 rx_packets; /* total packets received */
> > - __u32
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Sat, 05 Aug 2006 02:34:52 +0200
> First batch of patches converting existing netlink code to use
> the new api. Fixing lots of unvalidated accesses to attributes.
Looks very nice, all applied to net-2.6.19, thanks Thomas.
I've also rebased the net-2.6.
Thomas Graf wrote:
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/linux/if.h
===
--- net-2.6.19.orig/include/linux/if.h
+++ net-2.6.19/include/linux/if.h
@@ -212,5 +212,134 @@ struct ifconf
#define ifc_bu
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> Hmm I remember fixing sk_clone before.. or was that skb_clone, I'd have ot
> check.
> Anyway I'll check this out either later today or tomorrow in more detail
> and will send a patch.
I vaguely recall you fixing it too. I just couldn't find anythi
Herbert Xu wrote:
[] sk_clone+0xd4/0x350
[] inet_csk_clone+0x11/0x70
[] tcp_create_openreq_child+0x24/0x480
[] tcp_v6_syn_recv_sock+0x2c2/0x6f0
[] tcp_check_req+0x229/0x3a0
[] tcp_v6_do_rcv+0x17d/0x400
[] tcp_v6_rcv+0x7e5/0x850
Yes this is a known problem. The lock validator needs to le
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/linux/if.h
===
--- net-2.6.19.orig/include/linux/if.h
+++ net-2.6.19/include/linux/if.h
@@ -212,5 +212,134 @@ struct ifconf
#defineifc_buf ifc_ifcu.ifc
Transforms netlink code to dump link tables to use the new
netlink api. Makes rtnl_getlink() available regardless of the
availability of the wireless extensions.
Adding copy_rtnl_link_stats() avoids the structural dependency
of struct rtnl_link_stats on struct net_device_stats and thus
avoids trou
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv4/devinet.c
===
--- net-2.6.19.orig/net/ipv4/devinet.c
+++ net-2.6.19/net/ipv4/devinet.c
@@ -1112,32 +1112,37 @@ static int inet_fill_ifaddr(struct sk_bu
{
Fixes a theoretical memory and locking leak when the size of
the netlink header would exceed the skb tailroom.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/netlink/af_netlink.c
===
--- net-2.6.19.orig/net/netl
Adds rtm_to_ifaddr() transforming a netlink message to a
struct in_ifaddr. Fixes various unvalidated netlink attributes
causing memory corruptions when left empty by userspace
applications.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv4/devinet.c
===
Transforms do_setlink() into rtnl_setlink() using the new
netlink api. A warning message printed to the console is
added in the event that a change request fails while part
of the change request has been comitted already. The ioctl()
based nature of net devices makes it almost impossible to
move on
Fixes various unvalidated netlink attributes causing
memory corruptions when left empty by userspace.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv4/devinet.c
===
--- net-2.6.19.orig/net/ipv4/devinet.c
+++
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/linux/if_addr.h
===
--- /dev/null
+++ net-2.6.19/include/linux/if_addr.h
@@ -0,0 +1,53 @@
+#ifndef __LINUX_IF_ADDR_H
+#define __LINUX_IF_ADDR_H
+
+#include
+
+s
First batch of patches converting existing netlink code to use
the new api. Fixing lots of unvalidated accesses to attributes.
-
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/majordomo-
Adds:
nlmsg_get_pos() return current position in message
nlmsg_trim()trim part of message
nla_reserve_nohdr(skb, len) reserve room for an attribute w/o hdr
nla_put_nohdr(skb, len, data) add attribute w/o hdr
nla_find_nested() find attribu
Petr Vandrovec <[EMAIL PROTECTED]> wrote:
>
> java_vm/7892 is trying to acquire lock:
> (slock-AF_INET6){-+..}, at: [] sk_clone+0xd4/0x350
>
> but task is already holding lock:
> (slock-AF_INET6){-+..}, at: [] tcp_v6_rcv+0x323/0x850
>
> other info that might help us debug this:
> 1 lock held by
From: "Jesper Juhl" <[EMAIL PROTECTED]>
Date: Sat, 5 Aug 2006 01:30:49 +0200
> On 31/07/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Jesper Juhl" <[EMAIL PROTECTED]>
> > Date: Sun, 30 Jul 2006 23:51:20 +0200
> >
> > > Looks ok to me.
> >
> > I've applied James's version of the fix, thank
From: Ilpo Järvinen <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 00:32:36 +0300
> Whenever a transfer is application limited, we are allowed at least
> initial window worth of data per window unless cwnd is previously
> less than that.
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Looks go
From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 4 Aug 2006 18:44:20 +0300 (EEST)
> Overflow can occur very easily with 32 bits, e.g., with 1 second
> us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue
> length. Since the EWMA exponent is typically around 9, queue
> lengths larg
On 31/07/06, David Miller <[EMAIL PROTECTED]> wrote:
From: "Jesper Juhl" <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 23:51:20 +0200
> Looks ok to me.
I've applied James's version of the fix, thanks everyone.
Hmm, if you are refering to commit
118075b3cdc90e0815362365f3fc64d672ace0d6 -
http://w
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 4 Aug 2006 11:08:29 -0700
> On Fri, 04 Aug 2006 10:28:52 -0700
> "Michael Chan" <[EMAIL PROTECTED]> wrote:
>
> > May be David can explain why it is undesirable to wake up the queue when
> > it is full?
Why does Michael ask all the difficult
On Friday 04 August 2006 12:20, Jouni Malinen wrote:
> On Tue, Aug 01, 2006 at 09:16:59PM +0200, Jiri Benc wrote:
> This kind of change is more than just search-and-replace since frame
> type and subtype macros were using different style (not shifted left in
> WLAN_FC_{TYPE,STYPE}_* and shifted lef
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> to some degree the in kernel balancer cannot really make the level of
> decisions that a userspace balancer can make, at least not without making all
> kernel developers vomit ;)
If you make the drivers set a flag if they know their interrupts should
Out of curiousity, how does the UDP socket's SO_SNDBUF compare to the
queue depth?
forgive my ignorance, how do i measure that?
getsockopt(SO_SNDBUF)? I was just casting about on the possiblity that
interactions between the depth of that queue and how much can be kept in
the SO_SNDBUF migh
Hi,
Since there's been lots of talk about multi-STA or multi-BSSID devices
(more than one client, more than one AP on the same PHY) and I was just
looking into some crypto stuff on bcm43xx, it got me wondering.
The bcm43xx has an elaborate group key matching thingie which will be
useful if it's a
On 8/4/06, Rick Jones <[EMAIL PROTECTED]> wrote:
> Problem we've seen is that setting this shorter queue causes a large spike
> in cpu when transmitting using UDP:
>
> 100Mb/s link
> txqueuelen: 1000 Throughput: 92.44 CPU: 5.00
> txqueuelen: 100 Throughput: 93.80 CPU: 61.59
>
> Is this expected?
On 8/4/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Fri, Aug 04, 2006 at 08:34:46AM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> So how many skb allocation schemes do you code into a single driver?
> Kmalloc everything, page alloc everything, combination of kmalloc and
> page buffers for
The following changes since commit efe78cda3596f8a6d1c2d4a6b1a221bafa3e1a48:
Linus Torvalds:
Merge branch 'upstream-linus' of
master.kernel.org:/.../jgarzik/libata-dev
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstrea
Hello,
I'm not sure whether this was reported already, but just in case...
Box has only link scope IPv6 addresses assigned. java_vm was running some webex
conferencing applet.
Thanks,
Petr
On Fri, Aug 04, 2006 at 08:34:46AM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> So how many skb allocation schemes do you code into a single driver?
> Kmalloc everything, page alloc everything, combination of kmalloc and
> page buffers for hardware that does header split? That's three
> version
On Tue, Aug 01, 2006 at 09:16:59PM +0200, Jiri Benc wrote:
> From: Michael Wu <[EMAIL PROTECTED]>
> This patch switches the WLAN_ definitions in d80211.h to IEEE80211_ style
> definitions found in ieee80211.h. It also switches to MAC_ARG and MAC_FMT.
This kind of change is more than just search-an
Stephen Hemminger wrote:
> applied
Have you had a chance to look at the time cleanup patches
and the increased number of routing rule patch? Please let
me know if you want me to resend.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTE
Jesse Brandeburg wrote:
So we've recently put a bit of code in our e1000 driver to decrease the
qlen based on the speed of the link.
On the surface it seems like a great idea. A driver knows when the link
speed changed, and having a 1000 packet deep queue (the default for most
kernels now) o
In article <[EMAIL PROTECTED]> (at Fri, 4 Aug 2006 19:41:20 +0200), Thomas Graf
<[EMAIL PROTECTED]> says:
> The patches are against the net-2.6.19 tree.
Oh sorry, you're absolutely right...
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messa
On Fri, 04 Aug 2006 10:28:52 -0700
"Michael Chan" <[EMAIL PROTECTED]> wrote:
> On Fri, 2006-08-04 at 20:10 +1000, Herbert Xu wrote:
>
> > 1) netif_wake_queue is about to occur. In this case it doesn't really
> > matter what we do as netif_wake_queue will always wake the queue for us.
> > In the
On Tue, 25 Jul 2006 05:58:36 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
applied
--
Stephen Hemminger <[EMAIL PROTECTED]>
"And in the Packet there writ down that doome"
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
On Wed, 26 Jul 2006 07:52:09 -0400
Jamal Hadi Salim <[EMAIL PROTECTED]> wrote:
>
> Stephen,
>
> Heres another on top of the others i sent. If you get the time, can
> update your git tree with these patches?
> If you are planning to make a release soon, please ping me - I have at
> least one more
On Tue, 18 Jul 2006 08:56:40 -0400
jamal <[EMAIL PROTECTED]> wrote:
> About two more or so to complete these..
>
> cheers,
> jamal
>
>
applied, go ahead and fix Andy's comment with another patch if you want.
--
Stephen Hemminger <[EMAIL PROTECTED]>
"And in the Packet there writ down that doom
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-08-05 00:58
> In article <[EMAIL PROTECTED]> (at Fri, 04 Aug 2006 12:23:08 +0200), Thomas
> Graf <[EMAIL PROTECTED]> says:
>
> > This patchset implements multiple IPv6 routing tables and
> > policy routing. Even though the code is almost
On Fri, 2006-08-04 at 20:10 +1000, Herbert Xu wrote:
> 1) netif_wake_queue is about to occur. In this case it doesn't really
> matter what we do as netif_wake_queue will always wake the queue for us.
> In the worst case, it'll wake up the queue with too little room but that's
> really uncommon an
On Fri, 4 Aug 2006 20:10:17 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 04, 2006 at 06:37:34PM +1000, herbert wrote:
> >
> > [NETDRV] e1000: Fix potential tx wake up race
>
> Oops, I completely looked through netpoll_trap. Hmm, someone should
> really move the ifdef into netpoll_t
I noticed this morning that I had the polarity wrong in my patch
yesterday for older chips in the pcnet32_suspend routine. Here is the
correct patch to test.
> A change I made for 2.6.17 and another for 2.6.18 do not work on older
> pcnet32 chips which I do not have access to. Please test this p
In article <[EMAIL PROTECTED]> (at Fri, 04 Aug 2006 12:23:08 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> This patchset implements multiple IPv6 routing tables and
> policy routing. Even though the code is almost rewritten
:
Thomas, there are some coflicts with current net-2.6 tree.
Would you
So we've recently put a bit of code in our e1000 driver to decrease the
qlen based on the speed of the link.
On the surface it seems like a great idea. A driver knows when the link
speed changed, and having a 1000 packet deep queue (the default for most
kernels now) on top of a 100Mb/s link (o
Overflow can occur very easily with 32 bits, e.g., with 1 second
us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue
length. Since the EWMA exponent is typically around 9, queue
lengths larger than 2^2 cause overflow. Whether the affected
branch is taken when us_idle is as high as 1 s
On Fri, Aug 04, 2006 at 10:46:03AM -0400, Jes Sorensen wrote:
> > "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
>
> Jeff> Just a reminder to folks out there... Don't send private driver
> Jeff> support emails.
>
> Jeff> I receive a lot of email. A lot. Not as much as Linus or
> Jeff> A
On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Fri, Aug 04, 2006 at 03:59:37PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Interesting. Could you guys post figures on alloc_page speed vs. kmalloc?
They probalby measured kmalloc cache access, which only falls to
alloc_pages when ca
On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> You're changing the size of the buffer without telling the hardware.
> In the interrupt context e1000 knows the size of what was DMAed into
> the skb, but that's after the fact. So e1000 could detect that memory
> was corrupted, but not pr
Andrew Morton wrote:
On Mon, 31 Jul 2006 10:35:26 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
We've recently seen a number of user bug reports against e1000 that the
in-kernel irqbalance code is detrimental to network latency. The algorithm
keeps swapping irq's for NICs from cpu to cpu causing e
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> Just a reminder to folks out there... Don't send private driver
Jeff> support emails.
Jeff> I receive a lot of email. A lot. Not as much as Linus or
Jeff> Andrew probably, but still sizable. And quite regularly, I will
Jeff> receiv
Andrew Morton wrote:
On Mon, 31 Jul 2006 10:35:26 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
We've recently seen a number of user bug reports against e1000 that the
in-kernel irqbalance code is detrimental to network latency. The algorithm
keeps swapping irq's for NICs from cpu to cpu causing e
Hi:
Doh! I can't count. This is the last one for now.
[CRYPTO] s390: Added missing driver name and priority
Accelerated versions of crypto algorithms must carry a distinct driver name
and priority in order to distinguish themselves from their generic counter-
part.
Signed-off-by: Herbert Xu <[
Hi:
[CRYPTO] api: Added asynchronous flag
This patch adds the asynchronous flag and changes all existing users to
only look up algorithms that are synchronous.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMA
Hi:
[CRYPTO] api: Split out low-level API
The crypto API is made up of the part facing users such as IPsec and the
low-level part which is used by cryptographic entities such as algorithms.
This patch splits out the latter so that the two APIs are more clearly
delineated. As a bonus the low-leve
Hi:
Here is a collection of patches before I introduce the new block cipher
type.
The first patch is because I got tired of recompiling net/ipv4/route.o
whenever I change crypto.h :)
[IPSEC]: Move linux/crypto.h inclusion out of net/xfrm.h
The header file linux/crypto.h is only needed by a few
On Fri, Aug 04, 2006 at 01:51:24PM +0200, Patrick McHardy wrote:
>
> + if (!x->props.mode)
> + mtu -= blksize - 4;
You probably want to check for overflows here since mtu is unsigned.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTE
On Fri, Aug 04, 2006 at 01:50:15PM +0200, Patrick McHardy wrote:
>
> Now I get it, thanks :) I missed that the IP header isn't part of the
> length when it is aligned. So the worst-case increases by block-size
> - 4 (- 8 for IPv6). How does this look?
That should work.
If you want to be fancy yo
Patrick McHardy wrote:
> Now I get it, thanks :) I missed that the IP header isn't part of the
> length when it is aligned. So the worst-case increases by block-size
> - 4 (- 8 for IPv6). How does this look?
Forgot the patch ..
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9c5ee9f
Herbert Xu wrote:
> I've reread your patches and your handling of ESP padding is spot on.
> It's anyone's guess whether the current code gets it right or not :)
>
> However, I believe that the transport mode handling does run into
> problems with IP options. Basically, your calculation returns a
In bug #6954, Norbert Reinartz reported the following issue:
"Function lapb_setparms() in file net/lapb/lapb_iface.c checks if the given
parameters are valid. If the given window size is in the range of 8 .. 127,
lapb_setparms() fails and returns an error value of LAPB_INVALUE, even if bit
LAPB_EX
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 04:20:24 -0700 (PDT)
> I totally agree, Intel driver maintainers generally act like complete
> idiots in these kinds of situations.
>
> If the EEPROM has a broken checksum, the user should have an option
> that allows him to try and us
On Fri, Aug 04, 2006 at 09:16:04PM +1000, herbert wrote:
>
> Are you talking about the ESP padding case, or transport mode in
> general?
I've reread your patches and your handling of ESP padding is spot on.
It's anyone's guess whether the current code gets it right or not :)
However, I believe th
Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 01:11:19PM +0200, Patrick McHardy wrote:
>
>>>Of course it gets hairier if you have ESP padding. I'm not even sure
>>>if the current code gets that right.
>>
>>Unless I'm missing something, the padding caused by IP options
>>is always less than the wors
From: Wei Yongjun <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 08:46:13 -0400
> This always correct except when do active open in tcp client, which will
> send a SYN, that segment will not be counted, even if it is not
> restrained. Maybe I can do following to fix this:
>
> int tcp_connect(struct s
From: "Molle Bestefich" <[EMAIL PROTECTED]>
Date: Fri, 4 Aug 2006 13:04:07 +0200
> You're trying to pull Linux end users into a war between Intel and
> it's vendors, so you can make end users scream at the vendors when
> they forget to run the checksum tool.
I totally agree, Intel driver maintain
On Fri, Aug 04, 2006 at 01:11:19PM +0200, Patrick McHardy wrote:
>
> > Of course it gets hairier if you have ESP padding. I'm not even sure
> > if the current code gets that right.
>
> Unless I'm missing something, the padding caused by IP options
> is always less than the worst case that can hap
Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 12:09:18PM +0200, Patrick McHardy wrote:
>
>>I was wondering why the old code distinguished between transport mode
>>and tunnel mode, I couldn't spot anything that would be affected. I'll
>>look into the transport mode case again.
>
>
> The problem is
Auke Kok wrote:
Charlie Brady wrote:
> Let's assume that these things are all true, and the NIC currently does
> not work perfectly, just imperfectly, but acceptably. With the recent
> driver change, it now does not work at all. That's surely a bug in the
> driver.
There is no logic in that sent
This always correct except when do active open in tcp client, which will
send a SYN, that segment will not be counted, even if it is not
restrained. Maybe I can do following to fix this:
int tcp_connect(struct sock *sk)
...
+ tp->snd_nxt = tp->write_seq;
TCP_SKB_CB(buff)->seq = tp->w
On Fri, 2006-04-08 at 20:25 +1000, Herbert Xu wrote:
> Well it's not that good since the current code only takes the
> lock in exceptional circumstances while my patch does the atomic
> op unconditionally.
yes, it would be nice to fix that. However, from a selfish angle, my
worries are more about
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 12:23:08 +0200
> This patchset implements multiple IPv6 routing tables and
> policy routing. Even though the code is almost rewritten
> entirely the work is based on the MIPL patch found on
> mobile-ipv6.org which is being jointly develo
Adds the framework to support multiple IPv6 routing tables.
Currently all automatically generated routes are put into the
same table. This could be changed at a later point after
considering the produced locking overhead.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/ne
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/net/ip_fib.h
===
--- net-2.6.19.orig/include/net/ip_fib.h
+++ net-2.6.19/include/net/ip_fib.h
@@ -18,6 +18,7 @@
#include
#include
+#include
/* WARNING:
Adds support for policy routing rules including a new
local table for routes with a local destination.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/fib6_rules.c
===
--- /dev/null
+++ net-2.6.19/net/ipv6/f
Derived from net/ipv/fib_rules.c
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/include/linux/fib_rules.h
===
--- /dev/null
+++ net-2.6.19/include/linux/fib_rules.h
@@ -0,0 +1,60 @@
+#ifndef __LINUX_FIB_RULES_H
+#de
Hello,
This patchset implements multiple IPv6 routing tables and
policy routing. Even though the code is almost rewritten
entirely the work is based on the MIPL patch found on
mobile-ipv6.org which is being jointly developed by Helsinki
University of Technology (HUT) and the USAGI/WIDE Project.
R
(Ab)using rt6_lock wouldn't work anymore if rt6_lock is
converted into a per table lock.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19/net/ipv6/route.c
===
--- net-2.6.19.orig/net/ipv6/route.c
+++ net-2.6.19/net/ip
On Fri, Aug 04, 2006 at 06:16:03AM -0400, jamal wrote:
>
> I still have my setup intact, so i will give this a whirl in about 3-4
> hours. It does look promising - an atomic should be a lot cheaper than a
> lock. Thanks Herbert.
Well it's not that good since the current code only takes the
lock i
On Fri, 2006-04-08 at 20:10 +1000, Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 06:37:34PM +1000, herbert wrote:
> >
> > [NETDRV] e1000: Fix potential tx wake up race
>
> Oops, I completely looked through netpoll_trap. Hmm, someone should
> really move the ifdef into netpoll_trap. Stephen?
>
>
On Fri, Aug 04, 2006 at 12:09:18PM +0200, Patrick McHardy wrote:
>
> I was wondering why the old code distinguished between transport mode
> and tunnel mode, I couldn't spot anything that would be affected. I'll
> look into the transport mode case again.
The problem is basically you don't know a
Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 11:27:11AM +0200, Patrick McHardy wrote:
>
>>-static u32 esp4_get_max_size(struct xfrm_state *x, int mtu)
>>+static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
>> {
>> struct esp_data *esp = x->data;
>>- u32 blksize = ALIGN(crypto_tfm_alg_bl
On Fri, Aug 04, 2006 at 06:37:34PM +1000, herbert wrote:
>
> [NETDRV] e1000: Fix potential tx wake up race
Oops, I completely looked through netpoll_trap. Hmm, someone should
really move the ifdef into netpoll_trap. Stephen?
BTW, who uses netpoll_set_trap anyway? There seems to be no user in
t
Balazs Scheidler wrote:
> The use-case is as follows:
>
> * I have two different subsystems creating interfaces dynamically (for
> example pptpd and serial pppd lines, each creating dynamic pppX
> interfaces),
> * I would like to assign a different set of iptables rules for these
> clients,
> * I
On Fri, Aug 04, 2006 at 11:27:11AM +0200, Patrick McHardy wrote:
>
> [XFRM]: Improve MTU estimation
>
> Replace the probing based MTU estimation, which usually takes 2-3
> iterations to find a fitting value and may underestimate the MTU,
> by an exact calculation.
Thanks Patrick, this is definite
Patrick McHardy wrote:
> int xfrm_state_mtu(struct xfrm_state *x, int mtu)
> {
> - int res = mtu;
> -
> - res -= x->props.header_len;
> -
> - for (;;) {
> - int m = res;
> -
> - if (m < 68)
> - return 68;
> -
> - spin_lock_bh(&x-
While trying to track down a PMTUD problem with IPsec, I
misread the current MTU estimation code and initially thought
it would overestimate the MTU. I then noticed that this was
wrong, but by that time had already replaced it by an exact
calculation. It fixes the common underestimation of the MTU
On Fri, Aug 04, 2006 at 11:10:27AM +1000, herbert wrote:
>
> So we need to fix e1000 anyway.
Here is a fix that also gets rid of the tx_lock on the wake up side.
Please scrutinise this as much as you can. Jamal, please run this
through your performance test to see if it has a similar effect as
y
On Fri, Aug 04, 2006 at 11:00:55AM +1000, Philip Craig wrote:
> >>> So now you _need_ bridging in the middle to send ethernet traffic over
> >>> a GRE tunnel? Ugh.
> >> Agreed that would not be nice. What is the usage scenario for this?
> >> At least one end of the tunnel will be bridged?
> >
>
89 matches
Mail list logo
