From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 1 Dec 2006 15:37:55 +1100
> So in general when allocating packets we have two scenarios:
>
> 1) The dst is known and fixed, i.e., all datagram protocols. This is
> the easy case where the headroom is known exactly beforehand.
>
> 2) The dst is
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 1 Dec 2006 15:37:55 +1100
So in general when allocating packets we have two scenarios:
1) The dst is known and fixed, i.e., all datagram protocols. This is
the easy case where the headroom is known exactly beforehand.
2) The dst is unknown or
On Thu, Nov 30, 2006 at 08:22:06PM -0800, David Miller wrote:
>
> What MAX_HEADER's setting is trying to do is optimistically allocate
> enough for a single level of tunnelling. It does not handle nested
> tunneling at all, of course.
Agreed, I should've said MAX_HEADER.
> Actually, I wonder
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 17:51:46 +1100
> I'm just emphasising that LL_MAX_HEADER is by no means the *maximum*
> header size in a Linux system.
But it is the maximum "link level" singular header size.
It is MAX_HEADER which is the hack and the main issue.
On Wed, Nov 29, 2006 at 04:16:06PM +0100, Krzysztof Halasa wrote:
> Krzysztof Halasa <[EMAIL PROTECTED]> writes:
>
> > I wound't care less btw.
>
> s/wound/couldn/, eh those foreign languages...
So, you say, you don't care about David Miller's credits?
It isn't nice. He could be very
On Wed, Nov 29, 2006 at 04:16:06PM +0100, Krzysztof Halasa wrote:
Krzysztof Halasa [EMAIL PROTECTED] writes:
I wound't care less btw.
s/wound/couldn/, eh those foreign languages...
So, you say, you don't care about David Miller's credits?
It isn't nice. He could be very disappointed...
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 17:51:46 +1100
I'm just emphasising that LL_MAX_HEADER is by no means the *maximum*
header size in a Linux system.
But it is the maximum link level singular header size.
It is MAX_HEADER which is the hack and the main issue.
What
On Thu, Nov 30, 2006 at 08:22:06PM -0800, David Miller wrote:
What MAX_HEADER's setting is trying to do is optimistically allocate
enough for a single level of tunnelling. It does not handle nested
tunneling at all, of course.
Agreed, I should've said MAX_HEADER.
Actually, I wonder how
Krzysztof Halasa <[EMAIL PROTECTED]> writes:
> I wound't care less btw.
s/wound/couldn/, eh those foreign languages...
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jarek Poplawski <[EMAIL PROTECTED]> writes:
> And if we talk about names:
>
> + Spotted by Krzysztof Halasa.
I wound't care less btw.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Jarek Poplawski [EMAIL PROTECTED] writes:
And if we talk about names:
+ Spotted by Krzysztof Halasa.
I wound't care less btw.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Krzysztof Halasa [EMAIL PROTECTED] writes:
I wound't care less btw.
s/wound/couldn/, eh those foreign languages...
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 29-11-2006 05:25, David Miller wrote:
...
> commit 93e3a20d6c67a09b867431e7d5b3e7bc97154fab
> Author: David S. Miller <[EMAIL PROTECTED]>
> Date: Tue Nov 28 20:24:10 2006 -0800
>
> [NET]: Fix MAX_HEADER setting.
>
> MAX_HEADER is either set to LL_MAX_HEADER or LL_MAX_HEADER +
On Tue, Nov 28, 2006 at 09:04:16PM -0800, David Miller wrote:
>
> > Definitely. I'm not sure whether 48 is enough even for recursive
> > tunnels. This should really just be a hint. It's OK to spend a
> > bit of time reallocating skb's if it's too small, but it's not OK
> > to die.
>
> The
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 15:56:57 +1100
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > Longer term this is really messy, we should handle this some
> > other way.
>
> Definitely. I'm not sure whether 48 is enough even for recursive
> tunnels. This should
David Miller <[EMAIL PROTECTED]> wrote:
>
> Longer term this is really messy, we should handle this some
> other way.
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be a hint. It's OK to spend a
bit of time reallocating skb's if it's too
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 15:38:29 +1100
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 9264139..95e86ac 100644
> > --- a/include/linux/netdevice.h
> > +++
David Miller <[EMAIL PROTECTED]> wrote:
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 9264139..95e86ac 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -94,7 +94,9 @@ #endif
> #endif
>
> #if !defined(CONFIG_NET_IPIP) && \
> -
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 03:28:25 +0100
> [NETFILTER]: ipt_REJECT: fix memory corruption
>
> On devices with hard_header_len > LL_MAX_HEADER ip_route_me_harder()
> reallocates the skb, leading to memory corruption when using the stale
> tcph pointer to
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>It might be the case that your network device has a
>>hard_header_len > LL_MAX_HEADER, which could trigger
>>a corruption.
>
>
> Hmm... GRE tunnels add 24 bytes... I just noticed the following code in
>
Patrick McHardy <[EMAIL PROTECTED]> writes:
> It might be the case that your network device has a
> hard_header_len > LL_MAX_HEADER, which could trigger
> a corruption.
Hmm... GRE tunnels add 24 bytes... I just noticed the following code in
include/linux/netdevice.h:
/*
* Compute the
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>How sure are you about this? I can see nothing wrong with that
>>commit and can't reproduce the slab corruption. Please post
>>the rule that triggers this.
>
>
> 99% sure. Past this commit I get corruptions after 5
Patrick McHardy <[EMAIL PROTECTED]> writes:
>> The following commit breaks ipt_REJECT on my machine. Tested with latest
>> 2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
>> All details available on request, of course.
>>
>> commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
>
>
Krzysztof Halasa wrote:
> Hi,
>
> The following commit breaks ipt_REJECT on my machine. Tested with latest
> 2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
> All details available on request, of course.
>
> commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
How sure are you
Hi,
The following commit breaks ipt_REJECT on my machine. Tested with latest
2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
All details available on request, of course.
commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon
Hi,
The following commit breaks ipt_REJECT on my machine. Tested with latest
2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
All details available on request, of course.
commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
Author: Patrick McHardy [EMAIL PROTECTED]
Date: Mon Oct
Krzysztof Halasa wrote:
Hi,
The following commit breaks ipt_REJECT on my machine. Tested with latest
2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
All details available on request, of course.
commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
How sure are you about
Patrick McHardy [EMAIL PROTECTED] writes:
The following commit breaks ipt_REJECT on my machine. Tested with latest
2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
All details available on request, of course.
commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
How sure are
Krzysztof Halasa wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
How sure are you about this? I can see nothing wrong with that
commit and can't reproduce the slab corruption. Please post
the rule that triggers this.
99% sure. Past this commit I get corruptions after 5 minutes at most
Patrick McHardy [EMAIL PROTECTED] writes:
It might be the case that your network device has a
hard_header_len LL_MAX_HEADER, which could trigger
a corruption.
Hmm... GRE tunnels add 24 bytes... I just noticed the following code in
include/linux/netdevice.h:
/*
* Compute the worst case
Krzysztof Halasa wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
It might be the case that your network device has a
hard_header_len LL_MAX_HEADER, which could trigger
a corruption.
Hmm... GRE tunnels add 24 bytes... I just noticed the following code in
include/linux/netdevice.h:
From: Patrick McHardy [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 03:28:25 +0100
[NETFILTER]: ipt_REJECT: fix memory corruption
On devices with hard_header_len LL_MAX_HEADER ip_route_me_harder()
reallocates the skb, leading to memory corruption when using the stale
tcph pointer to update the
David Miller [EMAIL PROTECTED] wrote:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9264139..95e86ac 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -94,7 +94,9 @@ #endif
#endif
#if !defined(CONFIG_NET_IPIP) \
-
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 15:38:29 +1100
David Miller [EMAIL PROTECTED] wrote:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9264139..95e86ac 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -94,7
David Miller [EMAIL PROTECTED] wrote:
Longer term this is really messy, we should handle this some
other way.
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be a hint. It's OK to spend a
bit of time reallocating skb's if it's too small,
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 15:56:57 +1100
David Miller [EMAIL PROTECTED] wrote:
Longer term this is really messy, we should handle this some
other way.
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be
On Tue, Nov 28, 2006 at 09:04:16PM -0800, David Miller wrote:
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be a hint. It's OK to spend a
bit of time reallocating skb's if it's too small, but it's not OK
to die.
The recursive
On 29-11-2006 05:25, David Miller wrote:
...
commit 93e3a20d6c67a09b867431e7d5b3e7bc97154fab
Author: David S. Miller [EMAIL PROTECTED]
Date: Tue Nov 28 20:24:10 2006 -0800
[NET]: Fix MAX_HEADER setting.
MAX_HEADER is either set to LL_MAX_HEADER or LL_MAX_HEADER + 48, and
38 matches
Mail list logo
