* Re: [SOCK] Avoid integer divides where not necessary in include/net/sock.h
From: David Miller @ 2007-12-21 9:55 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <476B5AC0.9060604@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 21 Dec 2007 07:18:40 +0100
> Because sk_wmem_queued, sk_sndbuf are signed, a divide per two
> forces compiler to use an integer divide. We can instead use
> a right shift.
>
> SK_STREAM_MEM_QUANTUM deserves to be declared as an unsigned
> quantity, so that sk_stream_pages() and __sk_stream_mem_reclaim()
> can use right shifts instead of integer divides.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Everything that works with SK_STREAM_MEM_QUANTUM is an int.
We do a DIV_ROUND_UP() using SK_STREAM_MEM_QUANTUM and an int.
We do sk->sk_forward_alloc modifications using multiplies on
SK_STREAM_MEM_QUANTUM and an int, sk_forward_alloc is an int
too.
Changing the type of SK_STREAM_MEM_QUANTUM does nothing more than
create an exception in the typing used in these operations for no real
gain, in fact it makes this code's correctness harder to verify.
I'm fine with the rest of your change, so please resubmit this patch
with the type change removed.
Thanks.
^ permalink raw reply
* Re: [PATCH] OOPS with NETLINK_FIB_LOOKUP netlink socket
From: David Miller @ 2007-12-21 9:59 UTC (permalink / raw)
To: den; +Cc: den, devel, netdev, kaber, kuznet
In-Reply-To: <476B89D8.2060602@sw.ru>
From: "Denis V. Lunev" <den@sw.ru>
Date: Fri, 21 Dec 2007 12:39:36 +0300
> David Miller wrote:
> > What introduced this bug? This code didn't have this
> > problem previously.
>
> commit cd40b7d3983c708aabe3d3008ec64ffce56d33b0
> Author: Denis V. Lunev <den@openvz.org>
> Date: Wed Oct 10 21:15:29 2007 -0700
Thank you, I'm going to add this reference to the changeset
comments so that it will help others who look at this fix.
Consider your patch applied, thanks! :-)
^ permalink raw reply
* [DCCP] [Patch 1/1] [Bug-Fix]: Need to ignore Ack Vectors on request sockets
From: Gerrit Renker @ 2007-12-21 10:22 UTC (permalink / raw)
To: Arnaldo; +Cc: dccp, netdev
[ACKVEC]: Need to ignore Ack Vectors on request sockets
This fixes an oversight (mine) from an earlier patch and is in principle a
bug-fix, although the bug will with the current code not become visible.
The issue is that Ack Vectors must not be parsed on request sockets, since
the Ack Vector feature depends on the selection of the (TX) CCID. During the
initial handshake the CCIDs are undefined, and so RFC 4340, 10.3 applies:
"Using CCID-specific options and feature options during a negotiation
for the corresponding CCID feature is NOT RECOMMENDED [...]"
Worse, it is not even possible: when the server receives the Request from the
client, the CCID and Ack vector features are undefined; when the Ack finalising
the 3-way hanshake arrives, the request socket has not been cloned yet into a
new (full) socket. This order is necessary, since otherwise the newly created
socket would have to be destroyed whenever an option error occurred (a malicious
hacker could simply send garbage options and exploit this).
As a result, it is not feasible to parse Ack Vectors on request sockets, since
their destination (the CCIDs interested in using Ack Vector information) is
undefined. Hence disabled by this patch.
Two more changes suggested itself:
* replaced magic numbers for CCID-specific options with symbolic constants;
* replaced local variables `idx' with computation in argument list.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
include/linux/dccp.h | 6 ++++--
net/dccp/options.c | 19 +++++++------------
2 files changed, 11 insertions(+), 14 deletions(-)
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -104,9 +104,10 @@ int dccp_parse_options(struct sock *sk,
*
* CCID-specific options are ignored during connection setup, as
* negotiation may still be in progress (see RFC 4340, 10.3).
- *
+ * The same applies to Ack Vectors, as these depend on the CCID.
*/
- if (dreq != NULL && opt >= 128)
+ if (dreq != NULL && (opt >= DCCPO_MIN_RX_CCID_SPECIFIC ||
+ opt == DCCPO_ACK_VECTOR_0 || opt == DCCPO_ACK_VECTOR_1))
goto ignore_option;
switch (opt) {
@@ -222,23 +223,17 @@ int dccp_parse_options(struct sock *sk,
dccp_pr_debug("%s rx opt: ELAPSED_TIME=%d\n",
dccp_role(sk), elapsed_time);
break;
- case 128 ... 191: {
- const u16 idx = value - options;
-
+ case DCCPO_MIN_RX_CCID_SPECIFIC ... DCCPO_MAX_RX_CCID_SPECIFIC:
if (ccid_hc_rx_parse_options(dp->dccps_hc_rx_ccid, sk,
- opt, len, idx,
+ opt, len, value - options,
value) != 0)
goto out_invalid_option;
- }
break;
- case 192 ... 255: {
- const u16 idx = value - options;
-
+ case DCCPO_MIN_TX_CCID_SPECIFIC ... DCCPO_MAX_TX_CCID_SPECIFIC:
if (ccid_hc_tx_parse_options(dp->dccps_hc_tx_ccid, sk,
- opt, len, idx,
+ opt, len, value - options,
value) != 0)
goto out_invalid_option;
- }
break;
default:
DCCP_CRIT("DCCP(%p): option %d(len=%d) not "
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -165,8 +165,10 @@ enum {
DCCPO_TIMESTAMP_ECHO = 42,
DCCPO_ELAPSED_TIME = 43,
DCCPO_MAX = 45,
- DCCPO_MIN_CCID_SPECIFIC = 128,
- DCCPO_MAX_CCID_SPECIFIC = 255,
+ DCCPO_MIN_RX_CCID_SPECIFIC = 128, /* from sender to receiver */
+ DCCPO_MAX_RX_CCID_SPECIFIC = 191,
+ DCCPO_MIN_TX_CCID_SPECIFIC = 192, /* from receiver to sender */
+ DCCPO_MAX_TX_CCID_SPECIFIC = 255,
};
/* DCCP CCIDS */
--
^ permalink raw reply
* Re: Evgeniy Polyakov
From: Evgeniy Polyakov @ 2007-12-21 10:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071220.203459.245970705.davem@davemloft.net>
On Thu, Dec 20, 2007 at 08:34:59PM -0800, David Miller (davem@davemloft.net) wrote:
>
> If someone has a way other than email to contact Evgeniy, could
> you please let him know that his email is bouncing in strange
> ways.
Yep, I saw him couple of times and will try to contact.
> I'll have to unsubscribe him if this goes on much longer, which
> I don't want to do.
>
> Thanks.
>
> Here is some example bounce text:
>
> 451 4.0.0 readqf: cannot open ./dflBL48UH3032179: No such file or directory
> 552 5.3.4 Message is too large; 15000000 bytes max
> 554 5.0.0 Service unavailable
This looks really strange for me - I will forward it to system admin of
the university server where I have a mail.
Likely is is because of some troubles with the mail queue or FS...
Do not unsubscribe me :)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Evgeniy Polyakov
From: David Miller @ 2007-12-21 10:38 UTC (permalink / raw)
To: johnpol; +Cc: netdev
In-Reply-To: <20071221103412.GA17465@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 21 Dec 2007 13:34:12 +0300
> Yep, I saw him couple of times and will try to contact.
:-)
> Do not unsubscribe me :)
Ok!
^ permalink raw reply
* Re: [SOCK] Avoid integer divides where not necessary in include/net/sock.h
From: Eric Dumazet @ 2007-12-21 10:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071221.015543.19719154.davem@davemloft.net>
On Fri, 21 Dec 2007 01:55:43 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Fri, 21 Dec 2007 07:18:40 +0100
>
> > Because sk_wmem_queued, sk_sndbuf are signed, a divide per two
> > forces compiler to use an integer divide. We can instead use
> > a right shift.
> >
> > SK_STREAM_MEM_QUANTUM deserves to be declared as an unsigned
> > quantity, so that sk_stream_pages() and __sk_stream_mem_reclaim()
> > can use right shifts instead of integer divides.
> >
> > Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> Everything that works with SK_STREAM_MEM_QUANTUM is an int.
>
> We do a DIV_ROUND_UP() using SK_STREAM_MEM_QUANTUM and an int.
>
> We do sk->sk_forward_alloc modifications using multiplies on
> SK_STREAM_MEM_QUANTUM and an int, sk_forward_alloc is an int
> too.
>
> Changing the type of SK_STREAM_MEM_QUANTUM does nothing more than
> create an exception in the typing used in these operations for no real
> gain, in fact it makes this code's correctness harder to verify.
>
> I'm fine with the rest of your change, so please resubmit this patch
> with the type change removed.
I cannot remove underlying divide without telling compiler *something* is unsigned,
or adding a new _SHIFT macro
We currently do
int_value / int_constant
I was suggesting
int_value / uint_constant
Since you prefer to keep sk_forward_alloc as signed,
the only clean (without casts) way is to do :
int_value >> SK_STREAM_MEM_QUANTUM_SHIFT
Please tell me if you are OK with this solution, or if you prefer
I change sk_forward_alloc to be unsigned :)
Thank you
Here is the patch handling the change on sk_wmem_queued, sk_sndbuf.
Keeping small patches may help future bisection anyway...
[SOCK] Avoid integer divides where not necessary in include/net/sock.h
Because sk_wmem_queued, sk_sndbuf are signed, a divide per two
may force compiler to use an integer divide.
We can instead use a right shift.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
diff --git a/include/net/sock.h b/include/net/sock.h
index 803d8f2..4456453 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -445,7 +445,7 @@ static inline int sk_acceptq_is_full(struct sock *sk)
*/
static inline int sk_stream_min_wspace(struct sock *sk)
{
- return sk->sk_wmem_queued / 2;
+ return sk->sk_wmem_queued >> 1;
}
static inline int sk_stream_wspace(struct sock *sk)
@@ -1187,7 +1187,7 @@ static inline void sk_wake_async(struct sock *sk, int how, int band)
static inline void sk_stream_moderate_sndbuf(struct sock *sk)
{
if (!(sk->sk_userlocks & SOCK_SNDBUF_LOCK)) {
- sk->sk_sndbuf = min(sk->sk_sndbuf, sk->sk_wmem_queued / 2);
+ sk->sk_sndbuf = min(sk->sk_sndbuf, sk->sk_wmem_queued >> 1);
sk->sk_sndbuf = max(sk->sk_sndbuf, SOCK_MIN_SNDBUF);
}
}
@@ -1211,7 +1211,7 @@ static inline struct page *sk_stream_alloc_page(struct sock *sk)
*/
static inline int sock_writeable(const struct sock *sk)
{
- return atomic_read(&sk->sk_wmem_alloc) < (sk->sk_sndbuf / 2);
+ return atomic_read(&sk->sk_wmem_alloc) < (sk->sk_sndbuf >> 1);
}
static inline gfp_t gfp_any(void)
^ permalink raw reply related
* Re: TSO trimming question
From: Bill Fink @ 2007-12-21 10:58 UTC (permalink / raw)
To: David Miller; +Cc: herbert, ilpo.jarvinen, netdev, jheffner
In-Reply-To: <20071221.013642.29817274.davem@davemloft.net>
On Fri, 21 Dec 2007, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Fri, 21 Dec 2007 17:29:27 +0800
>
> > On Fri, Dec 21, 2007 at 01:27:20AM -0800, David Miller wrote:
> > >
> > > It's two shifts, and this gets scheduled along with the other
> > > instructions on many cpus so it's effectively free.
> > >
> > > I don't see why this is even worth mentioning and discussing.
> >
> > I totally agree. Two shifts are way better than a branch.
>
> We take probably a thousand+ 100+ cycle cache misses in the TCP stack
> on big window openning ACKs.
>
> Instead of discussing ways to solve that huge performance killer we're
> wanking about two friggin' integer shifts.
>
> It's hilarious isn't it? :-)
I don't think obfuscated code is hilarious. Instead of the convoluted
and dense code:
/* Defer for less than two clock ticks. */
if (tp->tso_deferred &&
((jiffies << 1) >> 1) - (tp->tso_deferred >> 1) > 1)
You can have the much simpler and more easily understandable:
/* Defer for less than two clock ticks. */
if (tp->tso_deferred && (jiffies - tp->tso_deferred) > 1)
And instead of:
/* Ok, it looks like it is advisable to defer. */
tp->tso_deferred = 1 | (jiffies<<1);
return 1;
You could do as Ilpo suggested:
/* Ok, it looks like it is advisable to defer. */
tp->tso_deferred = max_t(u32, jiffies, 1);
return 1;
Or perhaps more efficiently:
/* Ok, it looks like it is advisable to defer. */
tp->tso_deferred = jiffies;
if (unlikely(jiffies == 0))
tp->tso_deferred = 1;
return 1;
Or perhaps even:
/* Ok, it looks like it is advisable to defer. */
tp->tso_deferred = jiffies;
/* need to return a non-zero value to defer, which means won't
* defer if jiffies == 0 but it's only a 1 in 4 billion event
* (and avoids a compare/branch by not checking jiffies)
/
return jiffies;
Since it really only needs a non-zero return value to defer.
See, no branches needed and much clearer code. That seems worthwhile
to me from a code maintenance standpoint, even if it isn't any speed
improvement.
And what about the 64-bit jiffies versus 32-bit tp->tso_deferred issue?
Should tso_deferred be made unsigned long to match jiffies?
-Bill
^ permalink raw reply
* Re: [SOCK] Avoid integer divides where not necessary in include/net/sock.h
From: David Miller @ 2007-12-21 11:06 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <20071221114051.f8310a6d.dada1@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 21 Dec 2007 11:40:51 +0100
> On Fri, 21 Dec 2007 01:55:43 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
> Please tell me if you are OK with this solution, or if you prefer
> I change sk_forward_alloc to be unsigned :)
When I was playing with this crap a long time ago I
think I remember that sk->sk_forward_alloc can become
negative in some circumstances.
Or maybe that was just a bug :-)
> Here is the patch handling the change on sk_wmem_queued, sk_sndbuf.
> Keeping small patches may help future bisection anyway...
>
> [SOCK] Avoid integer divides where not necessary in include/net/sock.h
>
> Because sk_wmem_queued, sk_sndbuf are signed, a divide per two
> may force compiler to use an integer divide.
>
> We can instead use a right shift.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
I'll apply this, thanks Eric.
^ permalink raw reply
* Re: [PATCH/RFC] [v2] TCP: use non-delayed ACK for congestion control RTT
From: David Miller @ 2007-12-21 11:14 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: Gavin.McCullagh, netdev
In-Reply-To: <Pine.LNX.4.64.0712191511120.14629@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 19 Dec 2007 15:30:03 +0200 (EET)
> On Wed, 19 Dec 2007, Gavin McCullagh wrote:
>
> > Will do. I gather I should use the latest net- tree in future when
> > submitting patches.
>
> Doh, I owe you apology as I was probably too hasty to point you towards
> net-2.6.25. I suppose this could by considered as fix as well and
> therefore could probably be accepted to net-2.6 as well, which is for
> bugfixes only after merge window is closed. But it's Dave how will make
> such decisions, not me :-), and it's he who gets to deal with all
> the resulting conflicts ;-) (I added Cc to him).
When Gavin respins the patch I'll look at in the context of submitting
it as a bug fix. So Gavin please generate the patch against Linus's
vanilla GIT tree or net-2.6, your choise.
^ permalink raw reply
* Re: [PATCH] [IPROUTE]: A workaround to make larger rto_min printed correctly
From: Bill Fink @ 2007-12-21 11:18 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ____________; +Cc: satoru.satoh, shemminger, netdev
In-Reply-To: <20071221.175352.77874691.yoshfuji@linux-ipv6.org>
On Fri, 21 Dec 2007, YOSHIFUJI Hideaki wrote:
> In article <d72b7ace0712201824k3754962cse377256cb5452b8a@mail.gmail.com> (at Fri, 21 Dec 2007 11:24:54 +0900), "Satoru SATOH" <satoru.satoh@gmail.com> says:
>
> > 2007/12/21, Jarek Poplawski <jarkao2@gmail.com>:
> > > Jarek Poplawski wrote, On 12/20/2007 09:24 PM:
> > > ...
> > >
> > > > but since it's your patch, I hope you do some additional checking
> > > > if it's always like this...
> > >
> > >
> > > ...or maybe only changing this all a little bit will make it look safer!
> > >
> > > Jarek P.
> >
> >
> > OK, how about this?
> >
> > Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com>
> >
> > ip/iproute.c | 12 ++++++++----
> > 1 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/ip/iproute.c b/ip/iproute.c
> > index f4200ae..c771b34 100644
> > --- a/ip/iproute.c
> > +++ b/ip/iproute.c
> > @@ -510,16 +510,20 @@ int print_route(const struct sockaddr_nl *who,
> > struct nlmsghdr *n, void *arg)
> > fprintf(fp, " %u", *(unsigned*)RTA_DATA(mxrta[i]));
> > else {
> > unsigned val = *(unsigned*)RTA_DATA(mxrta[i]);
> > + unsigned hz1 = hz;
> > + if (hz1 > 1000)
>
> Why don't you simply use unsigned long long (or maybe uint64_t) here?
I was wondering that too. And maybe change the "(float)" cast
to "(double)" in the fprintf.
-Bill
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> ---
> diff --git a/ip/iproute.c b/ip/iproute.c
> index f4200ae..db9a3b6 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -509,16 +509,21 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
> i != RTAX_RTO_MIN)
> fprintf(fp, " %u", *(unsigned*)RTA_DATA(mxrta[i]));
> else {
> - unsigned val = *(unsigned*)RTA_DATA(mxrta[i]);
> + unsigned long long val = *(unsigned*)RTA_DATA(mxrta[i]);
> + unsigned div = 1;
>
> - val *= 1000;
> if (i == RTAX_RTT)
> - val /= 8;
> + div = 8;
> else if (i == RTAX_RTTVAR)
> - val /= 4;
> - if (val >= hz)
> - fprintf(fp, " %ums", val/hz);
> + div = 4;
> else
> + div = 1;
> +
> + val = val * 1000ULL / div;
> +
> + if (val >= hz) {
> + fprintf(fp, " %llums", val/hz);
> + } else
> fprintf(fp, " %.2fms", (float)val/hz);
> }
> }
^ permalink raw reply
* Re: [TCP] IPV6 : Change a divide into a right shift in tcp_v6_send_ack()
From: Jeff Garzik @ 2007-12-21 11:26 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: dada1, davem, netdev
In-Reply-To: <20071221.155030.131184865.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <476B574E.80601@cosmosbay.com> (at Fri, 21 Dec 2007 07:03:58 +0100), Eric Dumazet <dada1@cosmosbay.com> says:
>
>> Because tot_len is signed in tcp_v6_send_ack(), tot_len/4 forces compiler
>> to emit an integer divide, while we can help it to use a right shift,
>> less expensive.
>
> Are you really sure?
> At least, gcc-4.1.2-20061115 (debian) does not make any difference.
Quite true -- thus it is a matter of taste to the programmer. Constant
folding inside the compiler ensures that "foo / 4" asm output is just as
optimal as a shift.
> And, IMHO, because shift for signed variable is fragile, so we should
> avoid using it.
I respectfully disagree, but this is an unrelated matter. As you say,
"/4" is fine as-is.
Jeff
^ permalink raw reply
* Top 10 kernel oopses/warnings for the week of December 21st 2007
From: Arjan van de Ven @ 2007-12-21 11:51 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, torvalds, netdev, Marcel Holtmann, Pallipadi, Venkatesh
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in collecting the top 10)
This week a total of 100 oopses have been collected, up from 59 last week.
(This does not mean that the kernel quality has gone down; rather it means
that there's more effective data collection)
Rank 1: ieee80211_tx
Warning at net/mac80211/tx.c:1093 in ieee80211_tx()
Reported 30 times
Only reported for 2.6.24-rc5 so far
Probably specific to the rt2x00pci driver
More info: http://www.kerneloops.org/search.php?search=ieee80211_tx
Rank 2: uart_flush_buffer
Warning at drivers/serial/serial_core.c:544 in uart_flush_buffer()
Reported 16 times
No specific version information reported; bug present in 2.6.24-rc5
Caused by a bug in the Bluetooth line discipline/tty code
More info: http://lkml.org/lkml/2007/12/20/314 (analysis)
More info: http://lkml.org/lkml/2007/12/20/414 (patch)
More info: http://www.kerneloops.org/search.php?search=uart_flush_buffer
Rank 3: anon_vma_link
Kernel page fault
Reported 4 times
Reported for 2.6.23.9 and 2.6.23.11
So far only reported for reiserfs4 patched kernels
More info: http://www.kerneloops.org/search.php?search=anon_vma_link
Rank 4: acpi_idle_enter_bm
Soft lockup / crash
Reported 3 times
Reported for 2.6.23.8 (FC8) and 2.6.24-rc4
Idle path: could be a hardware issue
More info: http://www.kerneloops.org/search.php?search=acpi_idle_enter_bm
Rank 5: iput
Null pointer
Reported 3 times
No specific version information
ISOFS specific; could be caused by an invalid iso formatted disk (security issue)
More info: http://www.kerneloops.org/oops.php?number=2493
More info: http://www.kerneloops.org/guilty.php?version=<unknown>&guilty=iput&start=0&end=0
Rank 6: acpi_idle_enter_simple
Soft lockup
Reported 2 times
Reported only for 2.6.23.8 (FC8)
Idle path: could be a hardware issue
Possibly related to this weeks Rank 4 issue
More info: http://www.kerneloops.org/search.php?search=acpi_idle_enter_simple
Rank 7: uart_write
Warning at drivers/serial/serial_core.c:490 in uart_write()
Reported 2 times
No specific version information
Appears to be a similar bug to the one in this weeks Rank 2
More info: http://www.kerneloops.org/search.php?search=uart_write
Rank 8: __change_page_attr
BUG at arch/x86/mm/pageattr_64.c:176
Reported 2 times
Reported this week for 2.6.24-rc5; history goes back to 2.6.15
More info: http://www.kerneloops.org/guilty.php?version=2.6.24-rc5&guilty=__change_page_attr&start=1574144&end=1574144
Rank 9: r_show
Kernel NULL pointer
Reported 2 times
Reported only for the -mm tree: 2.6.24-rc5-mm1
More info: http://www.kerneloops.org/search.php?search=r_show
Rank 10: set_dentry_child_flags
Warning at fs/inotify.c:172 in set_dentry_child_flags()
Reported 2 times
No specific version information
Inotify related
More info: http://www.kerneloops.org/search.php?search=set_dentry_child_flags
Website news / improvements:
* Various user feedback is now incorportated; keep this coming!
* Improved banner
* BUG/WARN_ON's now have a direct link to the specific line of code in git-web
* The oops submit client is now included in the Debian (unstable) and Gentoo distributions
^ permalink raw reply
* Re: [TCP] IPV6 : Change a divide into a right shift in tcp_v6_send_ack()
From: David Miller @ 2007-12-21 11:57 UTC (permalink / raw)
To: jeff; +Cc: yoshfuji, dada1, netdev
In-Reply-To: <476BA2F8.1090102@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Fri, 21 Dec 2007 06:26:48 -0500
> YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > In article <476B574E.80601@cosmosbay.com> (at Fri, 21 Dec 2007 07:03:58 +0100), Eric Dumazet <dada1@cosmosbay.com> says:
> >
> >> Because tot_len is signed in tcp_v6_send_ack(), tot_len/4 forces compiler
> >> to emit an integer divide, while we can help it to use a right shift,
> >> less expensive.
> >
> > Are you really sure?
> > At least, gcc-4.1.2-20061115 (debian) does not make any difference.
>
> Quite true -- thus it is a matter of taste to the programmer.
Not true, the code output does change, check your optimize-for-size
kernel config setting.
This was discussed and explained later in this thread, and I also
explained it to you on IRC Jeff ;-)
^ permalink raw reply
* Re: [TCP] IPV6 : Change a divide into a right shift in tcp_v6_send_ack()
From: Jeff Garzik @ 2007-12-21 12:18 UTC (permalink / raw)
To: David Miller; +Cc: yoshfuji, dada1, netdev
In-Reply-To: <20071221.035717.243469952.davem@davemloft.net>
David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Fri, 21 Dec 2007 06:26:48 -0500
>
>> YOSHIFUJI Hideaki / 吉藤英明 wrote:
>>> In article <476B574E.80601@cosmosbay.com> (at Fri, 21 Dec 2007 07:03:58 +0100), Eric Dumazet <dada1@cosmosbay.com> says:
>>>
>>>> Because tot_len is signed in tcp_v6_send_ack(), tot_len/4 forces compiler
>>>> to emit an integer divide, while we can help it to use a right shift,
>>>> less expensive.
>>> Are you really sure?
>>> At least, gcc-4.1.2-20061115 (debian) does not make any difference.
>> Quite true -- thus it is a matter of taste to the programmer.
>
> Not true, the code output does change, check your optimize-for-size
> kernel config setting.
>
> This was discussed and explained later in this thread, and I also
> explained it to you on IRC Jeff ;-)
[looks]
For signed integers, this is true.
For unsigned integers, the code output is the same, regardless of
optimization setting.
Jeff
^ permalink raw reply
* Re: [TCP] tcp_write_timeout.c cleanup
From: Arnaldo Carvalho de Melo @ 2007-12-21 12:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <476B5581.6040603@cosmosbay.com>
Em Fri, Dec 21, 2007 at 06:56:17AM +0100, Eric Dumazet escreveu:
> Before submiting a patch to change a divide to a right shift, I felt
> necessary to create a helper function tcp_mtu_probing() to reduce length of
> lines exceeding 100 chars in tcp_write_timeout().
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index d8970ec..8f14808 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -114,13 +114,31 @@ static int tcp_orphan_retries(struct sock *sk, int alive)
> return retries;
> }
>
> +static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
> +{
> + int mss;
- int mss;
> +
> + /* Black hole detection */
> + if (sysctl_tcp_mtu_probing) {
> + if (!icsk->icsk_mtup.enabled) {
> + icsk->icsk_mtup.enabled = 1;
> + tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
> + } else {
> + struct tcp_sock *tp = tcp_sk(sk);
+ int mss;
> + mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)/2;
> + mss = min(sysctl_tcp_base_mss, mss);
> + mss = max(mss, 68 - tp->tcp_header_len);
> + icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, mss);
> + tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
> + }
> + }
> +}
:-)
- Arnaldo
^ permalink raw reply
* Re: [TCP] tcp_write_timeout.c cleanup
From: David Miller @ 2007-12-21 12:30 UTC (permalink / raw)
To: acme; +Cc: dada1, netdev
In-Reply-To: <20071221122316.GU6264@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Fri, 21 Dec 2007 10:23:16 -0200
> Em Fri, Dec 21, 2007 at 06:56:17AM +0100, Eric Dumazet escreveu:
> > +static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
> > +{
> > + int mss;
> - int mss;
>
> > +
> > + /* Black hole detection */
> > + if (sysctl_tcp_mtu_probing) {
> > + if (!icsk->icsk_mtup.enabled) {
> > + icsk->icsk_mtup.enabled = 1;
> > + tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
> > + } else {
> > + struct tcp_sock *tp = tcp_sk(sk);
> + int mss;
> > + mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)/2;
I've checked in this, ummm... patch :-)
commit 323f3f2f31840f94e540ec5a0ce33593d05dd8d9
Author: David S. Miller <davem@sunset.davemloft.net>
Date: Fri Dec 21 04:29:16 2007 -0800
[TCP]: Move mss variable in tcp_mtu_probing()
Down into the only scope where it is used.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 8f14808..ea111e9 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -116,8 +116,6 @@ static int tcp_orphan_retries(struct sock *sk, int alive)
static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
{
- int mss;
-
/* Black hole detection */
if (sysctl_tcp_mtu_probing) {
if (!icsk->icsk_mtup.enabled) {
@@ -125,6 +123,8 @@ static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
} else {
struct tcp_sock *tp = tcp_sk(sk);
+ int mss;
+
mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)/2;
mss = min(sysctl_tcp_base_mss, mss);
mss = max(mss, 68 - tp->tcp_header_len);
^ permalink raw reply related
* Re: [SOCK] Avoid integer divides where not necessary in include/net/sock.h
From: Herbert Xu @ 2007-12-21 12:58 UTC (permalink / raw)
To: David Miller; +Cc: dada1, netdev
In-Reply-To: <20071221.030640.100066714.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
>
> When I was playing with this crap a long time ago I
> think I remember that sk->sk_forward_alloc can become
> negative in some circumstances.
>
> Or maybe that was just a bug :-)
Yeah we had a few bugs there in the early days of TSO but it's
been quiet for the last 18 months.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/10] sysfs network namespace support
From: Eric W. Biederman @ 2007-12-21 13:04 UTC (permalink / raw)
To: Greg KH
Cc: Greg Kroah-Hartman, Tejun Heo, Linux Containers, netdev,
cornelia.huck, stern, kay.sievers, linux-kernel, Andrew Morton,
Herbert Xu, David Miller
In-Reply-To: <20071221030732.GA16122@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Sat, Dec 01, 2007 at 02:06:58AM -0700, Eric W. Biederman wrote:
>>
>> Now that we have network namespace support merged it is time to
>> revisit the sysfs support so we can remove the dependency on !SYSFS.
>
> <snip>
>
> Oops, I forgot to apply this to my tree. Eric, you still want this
> submitted, right?
Yes.
I'm am just about to head out of town to visit my parents over Christmas.
So I'm not going to be very responsive until I after the New Year.
Eric
^ permalink raw reply
* Re: [TCP] tcp_write_timeout.c cleanup
From: Arnaldo Carvalho de Melo @ 2007-12-21 13:14 UTC (permalink / raw)
To: David Miller; +Cc: dada1, netdev
In-Reply-To: <20071221.043026.19571736.davem@davemloft.net>
Em Fri, Dec 21, 2007 at 04:30:26AM -0800, David Miller escreveu:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date: Fri, 21 Dec 2007 10:23:16 -0200
>
> > Em Fri, Dec 21, 2007 at 06:56:17AM +0100, Eric Dumazet escreveu:
> > > +static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
> > > +{
> > > + int mss;
> > - int mss;
> >
> > > +
> > > + /* Black hole detection */
> > > + if (sysctl_tcp_mtu_probing) {
> > > + if (!icsk->icsk_mtup.enabled) {
> > > + icsk->icsk_mtup.enabled = 1;
> > > + tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
> > > + } else {
> > > + struct tcp_sock *tp = tcp_sk(sk);
> > + int mss;
> > > + mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)/2;
>
> I've checked in this, ummm... patch :-)
Thanks!
- Arnaldo
^ permalink raw reply
* Re: [PATCH 2/3] XFRM: RFC4303 compliant auditing
From: Paul Moore @ 2007-12-21 13:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-audit, latten
In-Reply-To: <20071221.014310.155404661.davem@davemloft.net>
On Friday 21 December 2007 4:43:10 am David Miller wrote:
> From: Paul Moore <paul.moore@hp.com>
> Date: Thu, 20 Dec 2007 16:42:25 -0500
>
> > This patch adds a number of new IPsec audit events to meet the auditing
> > requirements of RFC4303. This includes audit hooks for the following
> > events:
> >
> > * Could not find a valid SA [sections 2.1, 3.4.2]
> > . xfrm_audit_state_notfound()
> > . xfrm_audit_state_notfound_simple()
> >
> > * Sequence number overflow [section 3.3.3]
> > . xfrm_audit_state_replay_overflow()
> >
> > * Replayed packet [section 3.4.3]
> > . xfrm_audit_state_replay()
> >
> > * Integrity check failure [sections 3.4.4.1, 3.4.4.2]
> > . xfrm_audit_state_icvfail()
> >
> > While RFC4304 deals only with ESP most of the changes in this patch apply
> > to IPsec in general, i.e. both AH and ESP. The one case, integrity check
> > failure, where ESP specific code had to be modified the same was done to
> > the AH code for the sake of consistency.
> >
> > Signed-off-by: Paul Moore <paul.moore@hp.com>
>
> This doesn't apply at all to net-2.6.25, in particular
> xfrm6_input_addr() doesn't even have a local variable
> named "xfrm_vec_one" let alone the conditional where you're
> adding the state notfound audit hook.
>
> Please respin this and the third patch, thanks.
Sorry about that, I must have missed something (or probably just updated the
wrong tree on accident). I'll respin the patches and send them out today.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [PATCH/RFC] [v2] TCP: use non-delayed ACK for congestion control RTT
From: Gavin McCullagh @ 2007-12-21 13:31 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, netdev
In-Reply-To: <20071221.031400.194877955.davem@davemloft.net>
On Fri, 21 Dec 2007, David Miller wrote:
> When Gavin respins the patch I'll look at in the context of submitting
> it as a bug fix. So Gavin please generate the patch against Linus's
> vanilla GIT tree or net-2.6, your choise.
The existing patch was against Linus' linux-2.6.git from a few days ago so
I've updated my tree and regenerated the patch (below). Is that the right
one?
I'm just checking through the existing CA modules. I don't see the rtt
used for RTO anywhere. This is what I gather they're each using rtt for.
tcp_highspeed.c doesn't implement .pkts_acked
tcp_hybla.c doesn't implement .pkts_acked
tcp_scalable.c doesn't implement .pkts_acked
tcp_bic.c ignores rtt value from .pkts_acked
tcp_lp.c seems to ignore rtt value from .pkts_acked (despite setting
TCP_CONG_RTT_STAMP for high res rtts -- why?)
tcp_vegas.c uses high res rtt to measure congestion signal, increase,
backoff -- TCP_CONG_RTT_STAMP set so doesn't use seq_rtt
tcp_veno.c uses high res rtt to measure congestion signal, increase,
backoff -- TCP_CONG_RTT_STAMP set so doesn't use seq_rtt
tcp_yeah.c uses high res rtt to measure congestion signal, increase,
backoff -- TCP_CONG_RTT_STAMP set so doesn't use seq_rtt
tcp_illinois.c uses rtt to scale increase, backoff
-- TCP_CONG_RTT_STAMP set so doesn't use seq_rtt
tcp_htcp.c uses rtt to scale increase, backoff
tcp_cubic.c uses rtt to scale increase, backoff
tcp_westwood.c scales backoff using rtt
So as far as I can tell, timeout stuff is not ever altered using
pkts_acked() so I guess this fix only affects westwood, htcp and cubic just
now.
I need to re-read properly, but I think the same problem affects the
microsecond values where TCP_CONG_RTT_STAMP is set (used by vegas, veno,
yeah, illinois). I might follow up with another patch which changes the
behaviour where TCP_CONG_RTT_STAMP when I'm more sure of that.
Thanks,
Gavin
Signed-off-by: Gavin McCullagh <gavin.mccullagh@nuim.ie>
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 889c893..6fb7989 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2651,6 +2651,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
u32 cnt = 0;
u32 reord = tp->packets_out;
s32 seq_rtt = -1;
+ s32 ca_seq_rtt = -1;
ktime_t last_ackt = net_invalid_timestamp();
while ((skb = tcp_write_queue_head(sk)) && skb != tcp_send_head(sk)) {
@@ -2686,13 +2687,15 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
if (sacked & TCPCB_SACKED_RETRANS)
tp->retrans_out -= packets_acked;
flag |= FLAG_RETRANS_DATA_ACKED;
+ ca_seq_rtt = -1;
seq_rtt = -1;
if ((flag & FLAG_DATA_ACKED) ||
(packets_acked > 1))
flag |= FLAG_NONHEAD_RETRANS_ACKED;
} else {
+ ca_seq_rtt = now - scb->when;
if (seq_rtt < 0) {
- seq_rtt = now - scb->when;
+ seq_rtt = ca_seq_rtt;
if (fully_acked)
last_ackt = skb->tstamp;
}
@@ -2709,8 +2712,9 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
!before(end_seq, tp->snd_up))
tp->urg_mode = 0;
} else {
+ ca_seq_rtt = now - scb->when;
if (seq_rtt < 0) {
- seq_rtt = now - scb->when;
+ seq_rtt = ca_seq_rtt;
if (fully_acked)
last_ackt = skb->tstamp;
}
@@ -2772,8 +2776,8 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
net_invalid_timestamp()))
rtt_us = ktime_us_delta(ktime_get_real(),
last_ackt);
- else if (seq_rtt > 0)
- rtt_us = jiffies_to_usecs(seq_rtt);
+ else if (ca_seq_rtt > 0)
+ rtt_us = jiffies_to_usecs(ca_seq_rtt);
}
ca_ops->pkts_acked(sk, pkts_acked, rtt_us);
^ permalink raw reply related
* [TCP] Avoid a divide in tcp_mtu_probing()
From: Eric Dumazet @ 2007-12-21 13:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
tcp_mtu_to_mss() being signed, compiler might emit an integer divide
to compute tcp_mtu_to_mss()/2 .
Using a right shift is OK here and less expensive.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index ea111e9..ea85bc0 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -125,7 +125,7 @@ static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
struct tcp_sock *tp = tcp_sk(sk);
int mss;
- mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low)/2;
+ mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low) >> 1;
mss = min(sysctl_tcp_base_mss, mss);
mss = max(mss, 68 - tp->tcp_header_len);
icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, mss);
^ permalink raw reply related
* Re: [PATCH] [IPROUTE]: A workaround to make larger rto_min printed correctly
From: Satoru SATOH @ 2007-12-21 13:49 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: shemminger, netdev
In-Reply-To: <20071221.175352.77874691.yoshfuji@linux-ipv6.org>
I agree.
I mistakenly thought hz in that context must be larger than 1000..
As it's uncertain, your's looks much simpler and better.
(btw, the lines "else .... div = 1" is not needed, is it?)
Thanks,
Satoru SATOH
2007/12/21, YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>:
(snip)
> Why don't you simply use unsigned long long (or maybe uint64_t) here?
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> ---
> diff --git a/ip/iproute.c b/ip/iproute.c
> index f4200ae..db9a3b6 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -509,16 +509,21 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
> i != RTAX_RTO_MIN)
> fprintf(fp, " %u", *(unsigned*)RTA_DATA(mxrta[i]));
> else {
> - unsigned val = *(unsigned*)RTA_DATA(mxrta[i]);
> + unsigned long long val = *(unsigned*)RTA_DATA(mxrta[i]);
> + unsigned div = 1;
>
> - val *= 1000;
> if (i == RTAX_RTT)
> - val /= 8;
> + div = 8;
> else if (i == RTAX_RTTVAR)
> - val /= 4;
> - if (val >= hz)
> - fprintf(fp, " %ums", val/hz);
> + div = 4;
> else
> + div = 1;
> +
> + val = val * 1000ULL / div;
> +
> + if (val >= hz) {
> + fprintf(fp, " %llums", val/hz);
> + } else
> fprintf(fp, " %.2fms", (float)val/hz);
> }
> }
>
> --yoshfuji
^ permalink raw reply
* Re: [PATCH 2/3] XFRM: RFC4303 compliant auditing
From: Paul Moore @ 2007-12-21 13:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-audit, latten
In-Reply-To: <200712210827.24063.paul.moore@hp.com>
On Friday 21 December 2007 8:27:23 am Paul Moore wrote:
> On Friday 21 December 2007 4:43:10 am David Miller wrote:
> > From: Paul Moore <paul.moore@hp.com>
> > Date: Thu, 20 Dec 2007 16:42:25 -0500
> >
> > > This patch adds a number of new IPsec audit events to meet the auditing
> > > requirements of RFC4303. This includes audit hooks for the following
> > > events:
> > >
> > > * Could not find a valid SA [sections 2.1, 3.4.2]
> > > . xfrm_audit_state_notfound()
> > > . xfrm_audit_state_notfound_simple()
> > >
> > > * Sequence number overflow [section 3.3.3]
> > > . xfrm_audit_state_replay_overflow()
> > >
> > > * Replayed packet [section 3.4.3]
> > > . xfrm_audit_state_replay()
> > >
> > > * Integrity check failure [sections 3.4.4.1, 3.4.4.2]
> > > . xfrm_audit_state_icvfail()
> > >
> > > While RFC4304 deals only with ESP most of the changes in this patch
> > > apply to IPsec in general, i.e. both AH and ESP. The one case,
> > > integrity check failure, where ESP specific code had to be modified the
> > > same was done to the AH code for the sake of consistency.
> > >
> > > Signed-off-by: Paul Moore <paul.moore@hp.com>
> >
> > This doesn't apply at all to net-2.6.25, in particular
> > xfrm6_input_addr() doesn't even have a local variable
> > named "xfrm_vec_one" let alone the conditional where you're
> > adding the state notfound audit hook.
> >
> > Please respin this and the third patch, thanks.
>
> Sorry about that, I must have missed something (or probably just updated
> the wrong tree on accident). I'll respin the patches and send them out
> today.
Ah, looks like I may not be crazy after all! It looks like the XFRM patches
from Masahide NAKAMURA were pulled into net-2.6.25 just before mine last
night which caused my patches to conflict ...
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: James Nichols @ 2007-12-21 13:57 UTC (permalink / raw)
To: Glen Turner; +Cc: Jan Engelhardt, Eric Dumazet, linux-kernel, Linux Netdev List
In-Reply-To: <1198212686.5904.17.camel@andromache>
> Huh? Do you mean a PIX blade in a Cisco switch-router chassis? It
> would be very useful if you could be less vague about the
> equipment in use.
Right it's a PIX blade in Cisco chassis. The PIX is running ASA version 7.0(6)
> That depends more on your customers' networking attributes
> then you are sharing or perhaps even know. Perhaps your customer
> base is very Window-skewed and you simply aren't seeing any Sack
> Permitted negotiations for the first 37.999 hours. Or
> perhaps you've had a network glitch, and all of your
> connections have done a Selective Ack, which the firewall
> has trashed, leaving all the connections in a wacko state,
> not just a few which you haven't noticed.
I definitely see SACKs over the course of the 38 hours. I don't have
any Windows hosts, they are all running Linux except for a very small
number that run a proprietary OS and webserver. If the firewall were
to get trashed and hose the currently active connections, I would
expect that newly initiated connections would work.
> The actual failure mode needs a packet trace to determine,
> but you should be able to do this yourself (or ask your
> local network engineering staff).
>
> If your firewall is trashing the Sack field, then it needs
> to be fixed. Time to raise a case with the Cisco TAC and
> ask them directly if your PIX version has bug CSCse14419.
> You can't expect Sack to work when it's being fed trash,
> so it is important to make sure that is not happening.
I've pinged our dude that handles the PIX stuff to see about getting
an upgrade to 7.0(7). I should be able to get a packet trace, but it
may take some time. At this point I'm getting a lot of resistance and
people here telling me to just turn SACK off and not worry about what
is causing this issue, but I'd really like to get to the bottom of it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox