* Re: TSO trimming question
From: Ilpo Järvinen @ 2007-12-19 22:02 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0712192336130.27945@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1717 bytes --]
On Wed, 19 Dec 2007, Ilpo Järvinen wrote:
> I'm not fully sure what's purpose of this code in tcp_write_xmit:
>
> if (skb->len < limit) {
> unsigned int trim = skb->len % mss_now;
>
> if (trim)
> limit = skb->len - trim;
> }
>
> Is it used to make sure we send only multiples of mss_now here and leave
> the left-over into another skb? Or does it try to make sure that
> tso_fragment result honors multiple of mss_now boundaries when snd_wnd
> is the limitting factor? For latter IMHO this would be necessary:
>
> if (skb->len > limit)
> limit -= limit % mss_now;
...Anyway, here's an untested patch to just do it :-):
--
i.
[PATCH] [TCP]: Force tso skb split to mss_now boundary (if snd_wnd limits)
If snd_wnd was limitting factor, the tso_fragment might not
create full-sized skbs but would include the window left-overs
as well.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_output.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 1c7ef17..8dafda9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1453,6 +1453,8 @@ static int tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle)
if (trim)
limit = skb->len - trim;
+ } else if (skb->len > limit) {
+ limit -= limit % mss_now;
}
}
@@ -1525,6 +1527,8 @@ void tcp_push_one(struct sock *sk, unsigned int mss_now)
if (trim)
limit = skb->len - trim;
+ } else if (skb->len > limit) {
+ limit -= limit % mss_now;
}
}
--
1.5.0.6
^ permalink raw reply related
* TSO trimming question
From: Ilpo Järvinen @ 2007-12-19 21:46 UTC (permalink / raw)
To: Netdev, David Miller
Hi all,
I'm not fully sure what's purpose of this code in tcp_write_xmit:
if (skb->len < limit) {
unsigned int trim = skb->len % mss_now;
if (trim)
limit = skb->len - trim;
}
Is it used to make sure we send only multiples of mss_now here and leave
the left-over into another skb? Or does it try to make sure that
tso_fragment result honors multiple of mss_now boundaries when snd_wnd
is the limitting factor? For latter IMHO this would be necessary:
if (skb->len > limit)
limit -= limit % mss_now;
--
i.
^ permalink raw reply
* Re: [PATCH] e1000: Use deferrable timer for watchdog
From: Kok, Auke @ 2007-12-19 21:38 UTC (permalink / raw)
To: Parag Warudkar; +Cc: netdev, linux-kernel, akpm, Arjan van de Ven
In-Reply-To: <82e4877d0712191139k4dbae463icf2a59c8c0104010@mail.gmail.com>
Parag Warudkar wrote:
> On 12/19/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> [snip]
>
>> I can't possibly see any benefit from this other than that you just add up to a
>> whole second to the initialization cycle, which is bad.
>>
> Well, Ok but it can't be bad - I've been using this patch sometime and
> haven't seen any problem at all and powertop shows it reduces the
> wakeups-from-idle.
>
> But whatever - no big deal since it already uses round_jiffies().
why would this patch reduce wakeups even more than round_jiffies()? Does it make
our ~2 second update interval not reliable? can you quantify "shows it reduces" ?
Or timer only runs once every two seconds...
maybe I just don't understand the effect of timer_set_deferrable() - we're already
deferring it ourselves when we want to. If that is not working then I suggest that
we fix that first instead of postponing the critical first run of the e1000
watchdog task.
People in the datacenter really don't want to see more delays when bringing up
link, and we get frequent calls about it already being long on gigabit (not even
minding spanning tree). Adding 25% to that time isn't going to down very nicely
with them.
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: Ilpo Järvinen @ 2007-12-19 21:27 UTC (permalink / raw)
To: James Nichols; +Cc: Jan Engelhardt, Eric Dumazet, LKML, Linux Netdev List
In-Reply-To: <47695CEF.4090908@cosmosbay.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 972 bytes --]
On Wed, 19 Dec 2007, Eric Dumazet wrote:
> James Nichols a écrit :
> > On 12/19/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
> > > James Nichols a écrit :
> > > > > So you see outgoing SYN packets, but no SYN replies coming from the
> > > > > remote
> > > > > peer ? (you mention ACKS, but the first packet received from the
> > > > > remote
> > > > > peer should be a SYN+ACK),
> > > > Right, I meant to say SYN+ACK. I don't see them coming back.
> > > So... Really unlikely a linux problem, but ...
> > >
> >
> >
> > I don't know how you can be so sure. Turning tcp_sack off instantly
> > resovles the problem and all connections are succesful. I can't
> > imagine even the most far-fetched scenario where a router or every
> > single remote endpoints would suddenly stop causing the problem just
> > by removing a single TCP option.
You could also check if you can pull same trick off by touching
tcp_timestamps. It affects the TCP header as well.
--
i.
^ permalink raw reply
* Re: [PATCH 2.6.25 0/9]: SCTP: Update ADD-IP implementation to conform to spec
From: Vlad Yasevich @ 2007-12-19 20:53 UTC (permalink / raw)
To: netdev; +Cc: lksctp-developers, David Miller
In-Reply-To: <1197927169-5106-1-git-send-email-vladislav.yasevich@hp.com>
Hi David
Vlad Yasevich wrote:
> The following is a set of patches that updates the SCTP ADD-IP implementation
> to conform to the recently published RFC.
>
> ADD-IP is a SCTP Dynamic Address Configuration extensions, whereby
> the two end systems can dynamically modify the address lists for a given
> connection. One of the applications of this is mobility. The systems
> exchange Address Configuration (ASCONF) and Address Configuration
> Acknowlegement (ASCONF-ACK) messages which contain the info. If you
> want more info the operation, read RFC 5061.
>
> The implementation in lksctp was a few years old and implemented draft-05
> of the specification. So this long overdue.
>
> -vlad
>
Not sure if you got the PATCH 7/9 resend, but it looks like netdev ate that
too.
I made this patch set available here:
master.kernel.org:/pub/scm/linux/kernel/git/vxy/lksctp-dev.git addip
Vlad Yasevich (9):
SCTP: Discard unauthenticated ASCONF and ASCONF ACK chunks
SCTP: Handle the wildcard ADD-IP Address parameter
SCTP: Add the handling of "Set Primary IP Address" parameter to INIT
SCTP: Update association lookup to look at ASCONF chunks as well
SCTP: ADD-IP updates the states where ASCONFs can be sent
SCTP: Update ASCONF processing to conform to spec.
SCTP: Change use_as_src into a full address state
SCTP: Implement ADD-IP special case processing for ABORT chunk
SCTP: Follow Add-IP security consideratiosn wrt INIT/INIT-ACK
include/net/sctp/structs.h | 39 ++++++++----
net/sctp/associola.c | 75 +++++++++++++++++++++++-
net/sctp/bind_addr.c | 35 ++++++++++-
net/sctp/input.c | 124 ++++++++++++++++++++++++++++++++-------
net/sctp/ipv6.c | 2 +-
net/sctp/outqueue.c | 29 ++++++++-
net/sctp/protocol.c | 8 +-
net/sctp/sm_make_chunk.c | 132 +++++++++++++++++++++++++++++++++++------
net/sctp/sm_statefuns.c | 141 ++++++++++++++++++++++++++++++++++---------
net/sctp/sm_statetable.c | 18 +++---
net/sctp/socket.c | 8 +-
11 files changed, 503 insertions(+), 108 deletions(-)
You may pull from there is you wish.
-vlad
^ permalink raw reply
* [PATCH 2/4] [POWERPC][NET] ucc_geth_mii and users: get rid of device_type
From: Anton Vorontsov @ 2007-12-19 20:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jeff Garzik, Li Yang, netdev
In-Reply-To: <20071219203447.GA18285@localhost.localdomain>
device_type property is bogus, better use proper compatible property.
Also change compatible to "fsl,ucc-mdio".
Per http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 3 +--
arch/powerpc/boot/dts/mpc832x_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc836x_mds.dts | 3 +--
arch/powerpc/boot/dts/mpc8568mds.dts | 2 +-
drivers/net/ucc_geth_mii.c | 3 +--
5 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index ef8cd1e..97757ed 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -254,8 +254,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2320 18>;
- device_type = "mdio";
- compatible = "ucc_geth_phy";
+ compatible = "fsl,ucc-mdio";
phy3: ethernet-phy@03 {
interrupt-parent = < &ipic >;
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 7c4f028..b1c73f1 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -235,8 +235,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <3120 18>;
- device_type = "mdio";
- compatible = "ucc_geth_phy";
+ compatible = "fsl,ucc-mdio";
phy00:ethernet-phy@00 {
interrupt-parent = <&pic>;
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 5c73786..330212d 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -287,8 +287,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2120 18>;
- device_type = "mdio";
- compatible = "ucc_geth_phy";
+ compatible = "fsl,ucc-mdio";
phy0: ethernet-phy@00 {
interrupt-parent = < &ipic >;
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 7ad4b9f..c00aec9 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -355,7 +355,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2120 18>;
- compatible = "ucc_geth_phy";
+ compatible = "fsl,ucc-mdio";
/* These are the same PHYs as on
* gianfar's MDIO bus */
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index df884f0..de8ba1f 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -253,8 +253,7 @@ int uec_mdio_remove(struct of_device *ofdev)
static struct of_device_id uec_mdio_match[] = {
{
- .type = "mdio",
- .compatible = "ucc_geth_phy",
+ .compatible = "fsl,ucc-mdio",
},
{},
};
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] e1000: Use deferrable timer for watchdog
From: Parag Warudkar @ 2007-12-19 19:39 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, linux-kernel, akpm, Arjan van de Ven
In-Reply-To: <47696AC9.90204@intel.com>
On 12/19/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
[snip]
> I can't possibly see any benefit from this other than that you just add up to a
> whole second to the initialization cycle, which is bad.
>
Well, Ok but it can't be bad - I've been using this patch sometime and
haven't seen any problem at all and powertop shows it reduces the
wakeups-from-idle.
But whatever - no big deal since it already uses round_jiffies().
Parag
> >
> > Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
> >
> > --- linux-2.6/drivers/net/e1000/e1000_main.c 2007-12-07
> > 10:04:39.000000000 -0500
> > +++ linux-2.6-work/drivers/net/e1000/e1000_main.c 2007-12-18
> > 20:38:38.000000000 -0500
> > @@ -1030,7 +1030,7 @@
> > adapter->tx_fifo_stall_timer.function = &e1000_82547_tx_fifo_stall;
> > adapter->tx_fifo_stall_timer.data = (unsigned long) adapter;
> >
> > - init_timer(&adapter->watchdog_timer);
> > + init_timer_deferrable(&adapter->watchdog_timer);
> > adapter->watchdog_timer.function = &e1000_watchdog;
> > adapter->watchdog_timer.data = (unsigned long) adapter;
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] One more XFRM audit fix
From: Paul Moore @ 2007-12-19 19:29 UTC (permalink / raw)
To: netdev, linux-audit
The following patch is backed against David's net-2.6 tree and is pretty
trivial. I know we're late in the 2.6.24 cycle but I think this is worth
merging, if you guys don't feel that way let me know and I'll resubmit it
for 2.6.25.
As a side note, I'm unable to actually test the patch because I can't get
the kernel to compile (M=net/xfrm works just fine). The problem I keep
seeing is below:
make[3]: *** No rule to make target \
`/blah/kernels/net-2.6_xfrm-auid-secid-fix/include/linux/ticable.h', \
needed by \
`/blah/kernels/net-2.6_xfrm-auid-secid-fix/usr/include/linux/ticable.h'. \
Stop.
--
paul moore
linux security @ hp
^ permalink raw reply
* [PATCH] XFRM: Audit function arguments misordered
From: Paul Moore @ 2007-12-19 19:29 UTC (permalink / raw)
To: netdev, linux-audit
In-Reply-To: <20071219192309.15561.9843.stgit@flek.americas.hpqcorp.net>
In several places the arguments to the xfrm_audit_start() function are in the
wrong order resulting in incorrect user information being reported. This
patch corrects this by pacing the arguments in the correct order.
Signed-off-by: Paul Moore <paul.moore@hp.com>
---
net/xfrm/xfrm_policy.c | 4 ++--
net/xfrm/xfrm_state.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index b91b166..26b846e 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2162,7 +2162,7 @@ xfrm_audit_policy_add(struct xfrm_policy *xp, int result, u32 auid, u32 sid)
if (audit_enabled == 0)
return;
- audit_buf = xfrm_audit_start(sid, auid);
+ audit_buf = xfrm_audit_start(auid, sid);
if (audit_buf == NULL)
return;
audit_log_format(audit_buf, " op=SPD-add res=%u", result);
@@ -2179,7 +2179,7 @@ xfrm_audit_policy_delete(struct xfrm_policy *xp, int result, u32 auid, u32 sid)
if (audit_enabled == 0)
return;
- audit_buf = xfrm_audit_start(sid, auid);
+ audit_buf = xfrm_audit_start(auid, sid);
if (audit_buf == NULL)
return;
audit_log_format(audit_buf, " op=SPD-delete res=%u", result);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 1af522b..ee1e697 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2033,7 +2033,7 @@ xfrm_audit_state_add(struct xfrm_state *x, int result, u32 auid, u32 sid)
if (audit_enabled == 0)
return;
- audit_buf = xfrm_audit_start(sid, auid);
+ audit_buf = xfrm_audit_start(auid, sid);
if (audit_buf == NULL)
return;
audit_log_format(audit_buf, " op=SAD-add res=%u",result);
@@ -2053,7 +2053,7 @@ xfrm_audit_state_delete(struct xfrm_state *x, int result, u32 auid, u32 sid)
if (audit_enabled == 0)
return;
- audit_buf = xfrm_audit_start(sid, auid);
+ audit_buf = xfrm_audit_start(auid, sid);
if (audit_buf == NULL)
return;
audit_log_format(audit_buf, " op=SAD-delete res=%u",result);
^ permalink raw reply related
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Stevens @ 2007-12-19 19:28 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <47696DCF.3000009@hp.com>
>
> We would still have to check np->mcast_oif is set in the link-local case
> since we shouldn't be getting here with a zero.
Actually, that's one of the things I wanted to look into. I'm not
sure if there's a path through here with (even non-linklocal) multicasts
that end up without an interface set. And I'd to do some testing of
different cases to see if they behave as expected; also compare to the
similar sendmsg() cases.
>
> Don't worry about that, they can wait, and I'm leaving for 10 days
> anyways...
Good, thanks. It has been this way for years now, and I'm out
too. :-) Enjoy,
+-DLS
^ permalink raw reply
* Re: [PATCH] e1000: Use deferrable timer for watchdog
From: Kok, Auke @ 2007-12-19 19:02 UTC (permalink / raw)
To: parag.warudkar; +Cc: netdev, linux-kernel, akpm, Arjan van de Ven
In-Reply-To: <Pine.LNX.4.64.0712182040470.3616@mini.warudkars.net>
Parag Warudkar wrote:
>
> Use deferrable timer for watchdog. Reduces wakeups from idle per second.
no, we don't want this. We already allow the re-scheduling of the watchdog to be
round_jiffies() modified so that it coincides with other interrupts.
but at load time we don't want the timer to be postponed at all for up to a whole
second. Since we're doing all sorts of initialization work anyway this is
counterproductive anyway, and you really want the link to come up as soon as
possible, which is exactly what the watchdog handles when it runs first.
I can't possibly see any benefit from this other than that you just add up to a
whole second to the initialization cycle, which is bad.
Auke
>
> Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
>
> --- linux-2.6/drivers/net/e1000/e1000_main.c 2007-12-07
> 10:04:39.000000000 -0500
> +++ linux-2.6-work/drivers/net/e1000/e1000_main.c 2007-12-18
> 20:38:38.000000000 -0500
> @@ -1030,7 +1030,7 @@
> adapter->tx_fifo_stall_timer.function = &e1000_82547_tx_fifo_stall;
> adapter->tx_fifo_stall_timer.data = (unsigned long) adapter;
>
> - init_timer(&adapter->watchdog_timer);
> + init_timer_deferrable(&adapter->watchdog_timer);
> adapter->watchdog_timer.function = &e1000_watchdog;
> adapter->watchdog_timer.data = (unsigned long) adapter;
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: Brian Haley @ 2007-12-19 19:15 UTC (permalink / raw)
To: David Stevens
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <OF27B7DA9C.52E5380F-ON882573B6.00650422-882573B6.0068581B@us.ibm.com>
David Stevens wrote:
> Brian Haley <brian.haley@hp.com> wrote on 12/19/2007 07:35:46 AM:
> ...
>>> if (usin->sin6_scope_id)
>>> sk->sk_bound_dev_if = usin->sin6_scope_id;
>>> if (!sk->sk_bound_dev_if &&
>>> (addr_type & IPV6_ADDR_MULTICAST))
>>> fl.oif = np->mcast_oif;
>> This assignment will not get us past the next check...
>
> Yeah, that's what I get for typing in off-the-cuff code. What
> I was thinking was the fl.oif assignment instead was:
> if (!sk->sk_bound_dev_if &&
> (addr_type & IPV6_ADDR_MULTICAST))
> sk->sk_bound_dev_if = np->mcast_oif;
>
> Which it is not, but maybe it could be, since this is a connect().
My original patch did this, but also checked for a possible mis-match
with sk_bound_dev_if - it would actually wind-up setting it to the same
value if it was already set correctly.
> That patch looks better, but I'm wondering if we could just remove the
> requirement that sin6_scope_id be set here if it's multicast, since it
> is doing the following later in the code:
>
> if (!fl.oif && (addr_type&IPV6_ADDR_MULTICAST))
> fl.oif = np->mcast_oif;
We would still have to check np->mcast_oif is set in the link-local case
since we shouldn't be getting here with a zero.
> So, really, all we need to do is get through the LINKLOCAL section
> without error in the multicast case and we can remove the redundant
> multicast check there. I think that'd be simpler.
>
> I also note that sin6_scope_id appears not to be honored at all in
> the non-linklocal case, which may be correct, but surprises me.
>
> I want to look a little more at this; I know you have a customer
> issue, so I'll make it quick.
Don't worry about that, they can wait, and I'm leaving for 10 days
anyways...
-Brian
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: Brian Haley @ 2007-12-19 19:14 UTC (permalink / raw)
To: David Stevens
Cc: Vlad Yasevich, David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <OF367F9F64.87ED9167-ON882573B6.0063B893-882573B6.0064BE22@us.ibm.com>
David Stevens wrote:
> Vlad Yasevich <vladislav.yasevich@hp.com> wrote on 12/19/2007 07:20:53 AM:
>
>> But this still requires either a SO_BINDTODEVICE or sin6_scope_id. This
>> means the an application can call BINDTODEVICE(eth0), MULTICAST_IF(eth1)
>> issue a connect on a UDP socket an succeed? Seems wrong to me.
>>
>> Can you check section 6.7 of RFC 3542.
>
> No, it requires one of SO_BINDTODEVICE, sin6_scope_id, or
> IPV6_MULTICAST_IF.
> If you do an SO_BINDTODEVICE(eth0) and then an IPV6_MULTICAST_IF(eth1),
> the
> IPV6_MULTICAST_IF will fail in setsockopt (EINVAL), because it requires a
> match
> for bound sockets. I'm not sure if SO_BINDTODEVICE resets mcast_oif if you
> do
> them in the reverse order, but that would be a bug in SO_BINDTODEVICE.
It doesn't, that was one way I tested my first patch by forcing a mis-match.
> The precedence order as implemented already is:
>
> SO_BINDTODEVICE is highest and always wins
> sin6_scope_id next
> IPV6_MULTICAST_IF
>
> and the existing code has the rule that all link-local addresses require a
> sin6_scope_id. The change (intended) is to relax the sin6_scope_id rule
> only
> for link-local multicasts that have done either an SO_BINDTODEVICE or
> IPV6_MULTICAST_IF already.
Yes, that was the intention of my patch.
-Brian
^ permalink raw reply
* Re: [PATCH] e1000e: Use deferrable timer for watchdog
From: Kok, Auke @ 2007-12-19 19:04 UTC (permalink / raw)
To: parag.warudkar; +Cc: netdev, linux-kernel, akpm
In-Reply-To: <Pine.LNX.4.64.0712182046560.3616@mini.warudkars.net>
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c 2007-12-07
> 10:04:39.000000000 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c 2007-12-18
> 20:45:59.000000000 -0500
> @@ -3899,7 +3899,7 @@
> goto err_eeprom;
> }
>
> - init_timer(&adapter->watchdog_timer);
> + init_timer_deferrable(&adapter->watchdog_timer);
> adapter->watchdog_timer.function = &e1000_watchdog;
> adapter->watchdog_timer.data = (unsigned long) adapter;
>
see my reply to "Re: [PATCH] e1000: Use deferrable timer for watchdog" - IOW no,
we don't want this
Auke
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: Vlad Yasevich @ 2007-12-19 19:02 UTC (permalink / raw)
To: David Stevens
Cc: Brian Haley, David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <OF367F9F64.87ED9167-ON882573B6.0063B893-882573B6.0064BE22@us.ibm.com>
David Stevens wrote:
> Vlad Yasevich <vladislav.yasevich@hp.com> wrote on 12/19/2007 07:20:53 AM:
>
>> But this still requires either a SO_BINDTODEVICE or sin6_scope_id. This
>> means the an application can call BINDTODEVICE(eth0), MULTICAST_IF(eth1)
>> issue a connect on a UDP socket an succeed? Seems wrong to me.
>>
>> Can you check section 6.7 of RFC 3542.
>
> No, it requires one of SO_BINDTODEVICE, sin6_scope_id, or
> IPV6_MULTICAST_IF.
> If you do an SO_BINDTODEVICE(eth0) and then an IPV6_MULTICAST_IF(eth1),
> the
> IPV6_MULTICAST_IF will fail in setsockopt (EINVAL), because it requires a
> match
> for bound sockets.
I should have checked that... so the case I thought off is not possible...
> I'm not sure if SO_BINDTODEVICE resets mcast_oif if you
> do
> them in the reverse order, but that would be a bug in SO_BINDTODEVICE.
I don't think that would be needed since SO_BINDTODEVICE always wins over
IPV6_MULTICAST_IF, so even if they mismatch, SO_BINDTODEVICE is still used.
> The precedence order as implemented already is:
>
> SO_BINDTODEVICE is highest and always wins
> sin6_scope_id next
> IPV6_MULTICAST_IF
>
> and the existing code has the rule that all link-local addresses require a
> sin6_scope_id. The change (intended) is to relax the sin6_scope_id rule
> only
> for link-local multicasts that have done either an SO_BINDTODEVICE or
> IPV6_MULTICAST_IF already.
>
Ok, but I don't think your patch accomplishes that, as Brian pointed out.
-vlad
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Stevens @ 2007-12-19 18:57 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <47693A52.5020301@hp.com>
Brian Haley <brian.haley@hp.com> wrote on 12/19/2007 07:35:46 AM:
...
> > if (usin->sin6_scope_id)
> > sk->sk_bound_dev_if = usin->sin6_scope_id;
> > if (!sk->sk_bound_dev_if &&
> > (addr_type & IPV6_ADDR_MULTICAST))
> > fl.oif = np->mcast_oif;
>
> This assignment will not get us past the next check...
Yeah, that's what I get for typing in off-the-cuff code. What
I was thinking was the fl.oif assignment instead was:
if (!sk->sk_bound_dev_if &&
(addr_type & IPV6_ADDR_MULTICAST))
sk->sk_bound_dev_if = np->mcast_oif;
Which it is not, but maybe it could be, since this is a connect().
That patch looks better, but I'm wondering if we could just remove the
requirement that sin6_scope_id be set here if it's multicast, since it
is doing the following later in the code:
if (!fl.oif && (addr_type&IPV6_ADDR_MULTICAST))
fl.oif = np->mcast_oif;
So, really, all we need to do is get through the LINKLOCAL section
without error in the multicast case and we can remove the redundant
multicast check there. I think that'd be simpler.
I also note that sin6_scope_id appears not to be honored at all in
the non-linklocal case, which may be correct, but surprises me.
I want to look a little more at this; I know you have a customer
issue, so I'll make it quick.
+-DLS
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: Ilpo Järvinen @ 2007-12-19 18:32 UTC (permalink / raw)
To: James Nichols; +Cc: Netdev
In-Reply-To: <83a51e120712190938j7c7a2c23xbe5c9da050d9956@mail.gmail.com>
On Wed, 19 Dec 2007, James Nichols wrote:
> > > And the problem almost instanteaously resolved itself and outbound
> > > connection attempts were succesful.
> >
> > New or the pending ones?
>
> I'm fairly sure that sockets that were already open in SYN_SENT state
> when I turned tcp_sack off started to work as the count of sockets in
> SYN_SENT state drops very rapidly.
Heh, "very rapidly" :-/, considering that you have 200 x SYN_SENT flows
and if tcp_syn_retries is set to default, you will see something happening
quite quickly for sure and the whole situation is over in ~3 mins if I
counted correctly.
> > > Is there a kernel buffer or some data structure that tcp_sack uses
> > > that gets filled up after an extended period of operation?
> >
> > SACK has pretty little meaning in context of SYNs, there's only the
> > sackperm(itted) TCP option which is sent along with the SYN/SYN-ACK.
> >
> > The SACK scoreboard is currently included to the skbs (has been like
> > this for very long time), so no additional data structures should be
> > there because of SACK...
>
> I've been seeing this problem for about 4 years, so could it be
> related to the scoreboard implementation somehow?
Scoreboard has no meaning in this context, it is used while _input_
packets are processed. If you don't get SYN-ACKs at all, it doesn't
have any meaning.
> > /proc/net/tcp couple of times in a row, try something something like
> > this:
> >
> > for i in (seq 1 40); do cat /proc/net/tcp; echo "-----"; sleep 10; done
>
> I can set up to do this the next time the problem occurs.
for i in $(seq 1 40); ... is the right way to do the loop. :-)
> > > I'm running kernel 2.6.18 on RedHat, but have had this problem occur
> > > on earlier kernel versions (all 2.4 and 2.6).
> >
> > I've done some fixes to SACK processing since 2.6.18 (not sure if RedHat
> > has backported them). Though they're not that critical nor anything in
> > them should affect in SYN_SENT state.
>
> Ok, unless there is direct evidence that there is a fix to this
> problem in a later kernel I won't be able to upgrade. If there is a
> redhat provided patch I can probably do that.
...They won't affect in SYN_SENT.
--
i.
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Stevens @ 2007-12-19 18:18 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Brian Haley, David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <476936D5.4070606@hp.com>
Vlad Yasevich <vladislav.yasevich@hp.com> wrote on 12/19/2007 07:20:53 AM:
> But this still requires either a SO_BINDTODEVICE or sin6_scope_id. This
> means the an application can call BINDTODEVICE(eth0), MULTICAST_IF(eth1)
> issue a connect on a UDP socket an succeed? Seems wrong to me.
>
> Can you check section 6.7 of RFC 3542.
No, it requires one of SO_BINDTODEVICE, sin6_scope_id, or
IPV6_MULTICAST_IF.
If you do an SO_BINDTODEVICE(eth0) and then an IPV6_MULTICAST_IF(eth1),
the
IPV6_MULTICAST_IF will fail in setsockopt (EINVAL), because it requires a
match
for bound sockets. I'm not sure if SO_BINDTODEVICE resets mcast_oif if you
do
them in the reverse order, but that would be a bug in SO_BINDTODEVICE.
The precedence order as implemented already is:
SO_BINDTODEVICE is highest and always wins
sin6_scope_id next
IPV6_MULTICAST_IF
and the existing code has the rule that all link-local addresses require a
sin6_scope_id. The change (intended) is to relax the sin6_scope_id rule
only
for link-local multicasts that have done either an SO_BINDTODEVICE or
IPV6_MULTICAST_IF already.
+-DLS
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: James Nichols @ 2007-12-19 18:12 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Eric Dumazet, linux-kernel, Linux Netdev List
In-Reply-To: <Pine.LNX.4.64.0712191857270.12329@fbirervta.pbzchgretzou.qr>
> The router could be sooo crappy that it drops all packets from
> TCP streams that have SACK enabled and the client has opened
> 200+ SACK connections previously... something like that?
I don't know, maybe. My router is a fairly new model Cisco and is
pretty major (i.e. pretty expensive), so it's not just a total piece
of crap. Plus, I never restart it when I see these issues. I just
turn tcp_sack off, the problem goes away, and I'm able to renable
tcp_sack a few hours later and it works fine until many hours later
when I see the SYN_SENT problem again.
^ permalink raw reply
* [PATCH][IPV4] ip_gre: set mac_header correctly in receive path
From: Timo Teräs @ 2007-12-19 18:10 UTC (permalink / raw)
To: Alexey Kuznetsov, davem, netdev
In-Reply-To: <4767D249.5050602@iki.fi>
From: Timo Teras <timo.teras@iki.fi>
mac_header update in ipgre_recv() was incorrectly changed to
skb_reset_mac_header() when it was introduced.
Signed-off-by: Timo Teras <timo.teras@iki.fi>
---
This replaces my earlier patch titled "ip_gre: use skb->{mac,
network}_header consistently". Apparently I hadn't done my homework how
to use *_header correctly. And I should have done a bit more testing to
figure out the previous patch does not work.
But the main problem was the receive path in the first place, and this
patch fixes it.
The bug was introduced in commit 459a98ed881802dee55897441bc7f77af614368e.
There might be other similar incorrect replaces.
net/ipv4/ip_gre.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 02b02a8..4b93f32 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -613,7 +613,7 @@ static int ipgre_rcv(struct sk_buff *skb)
offset += 4;
}
- skb_reset_mac_header(skb);
+ skb->mac_header = skb->network_header;
__pskb_pull(skb, offset);
skb_reset_network_header(skb);
skb_postpull_rcsum(skb, skb_transport_header(skb), offset);
--
1.5.2.5
^ permalink raw reply related
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: Eric Dumazet @ 2007-12-19 18:03 UTC (permalink / raw)
To: James Nichols; +Cc: Jan Engelhardt, linux-kernel, Linux Netdev List
In-Reply-To: <83a51e120712190943m3bf0e2e4v2ea6b660142e9a5a@mail.gmail.com>
James Nichols a écrit :
> On 12/19/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
>> James Nichols a écrit :
>>>> So you see outgoing SYN packets, but no SYN replies coming from the remote
>>>> peer ? (you mention ACKS, but the first packet received from the remote
>>>> peer should be a SYN+ACK),
>>> Right, I meant to say SYN+ACK. I don't see them coming back.
>> So... Really unlikely a linux problem, but ...
>>
>
>
> I don't know how you can be so sure. Turning tcp_sack off instantly
> resovles the problem and all connections are succesful. I can't
> imagine even the most far-fetched scenario where a router or every
> single remote endpoints would suddenly stop causing the problem just
> by removing a single TCP option.
>
>
>>> I can take these captures and take a look at the results.
>>> Unfortunately, I don't think I'll be able to make the captures
>>> available to the general public.
>> I dont understand, why dont you change IPs to mask them with 192.168.X.Y, or
>> just ME, and peer1, peer2, peer...
>
> I will see if I can do that, but it's major pain with 2000 hosts.
> Plus, there is application data in the packets that I can't allow into
> the public domain. I really don't think I can pull it off... I
> literally would have to go through our legal department.
I still dont understand.
"tcpdump -p -n -s 1600 -c 10000" doesnt reveal User data at all.
Without any exact data from you, I am afraid nobody can help.
>
>> Random ideas :
>>
>> 1) Is your server behind a NET router or something ?
>
> What's a NET router? I am behind a Cisco router and a firewall, but
> these network components have completely been replaced/rebuilt several
> times in the 4+ years that we've had this problem. I've looked at the
> logs there and neither are doing anything other than passing the
> traffic along.
Typo error, I meant NAT. Most routers doing NAT have some limits, timers, hacks...
>
>> 2) Are you sure you are not using connection tracking, and hit a limit on it ?
>
> I'm using ip_conntrack, but the limit I have for max entries is 65K.
> The most I've seen in there are a couple thousand- that was one of the
> first things I monitored very closely.
Now please try without conn tracking module. I saw many failures in the past
that were trigered by conntrack.
Do you have some firewall rules, using some netfilter modules like hashlimit ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: Jan Engelhardt @ 2007-12-19 17:58 UTC (permalink / raw)
To: James Nichols; +Cc: Eric Dumazet, linux-kernel, Linux Netdev List
In-Reply-To: <83a51e120712190943m3bf0e2e4v2ea6b660142e9a5a@mail.gmail.com>
On Dec 19 2007 12:43, James Nichols wrote:
>On 12/19/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
>> James Nichols a écrit :
>> >> So you see outgoing SYN packets, but no SYN replies coming from the remote
>> >> peer ? (you mention ACKS, but the first packet received from the remote
>> >> peer should be a SYN+ACK),
>> >
>> > Right, I meant to say SYN+ACK. I don't see them coming back.
>>
>> So... Really unlikely a linux problem, but ...
>
>I don't know how you can be so sure. Turning tcp_sack off instantly
>resovles the problem and all connections are succesful. I can't
>imagine even the most far-fetched scenario where a router or every
>single remote endpoints would suddenly stop causing the problem just
>by removing a single TCP option.
The router could be sooo crappy that it drops all packets from
TCP streams that have SACK enabled and the client has opened
200+ SACK connections previously... something like that?
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: James Nichols @ 2007-12-19 17:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jan Engelhardt, linux-kernel, Linux Netdev List
In-Reply-To: <47694FCC.1020507@cosmosbay.com>
On 12/19/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
> James Nichols a écrit :
> >> So you see outgoing SYN packets, but no SYN replies coming from the remote
> >> peer ? (you mention ACKS, but the first packet received from the remote
> >> peer should be a SYN+ACK),
> >
> > Right, I meant to say SYN+ACK. I don't see them coming back.
>
> So... Really unlikely a linux problem, but ...
>
I don't know how you can be so sure. Turning tcp_sack off instantly
resovles the problem and all connections are succesful. I can't
imagine even the most far-fetched scenario where a router or every
single remote endpoints would suddenly stop causing the problem just
by removing a single TCP option.
> > I can take these captures and take a look at the results.
> > Unfortunately, I don't think I'll be able to make the captures
> > available to the general public.
>
> I dont understand, why dont you change IPs to mask them with 192.168.X.Y, or
> just ME, and peer1, peer2, peer...
I will see if I can do that, but it's major pain with 2000 hosts.
Plus, there is application data in the packets that I can't allow into
the public domain. I really don't think I can pull it off... I
literally would have to go through our legal department.
>
> Random ideas :
>
> 1) Is your server behind a NET router or something ?
What's a NET router? I am behind a Cisco router and a firewall, but
these network components have completely been replaced/rebuilt several
times in the 4+ years that we've had this problem. I've looked at the
logs there and neither are doing anything other than passing the
traffic along.
> 2) Are you sure you are not using connection tracking, and hit a limit on it ?
I'm using ip_conntrack, but the limit I have for max entries is 65K.
The most I've seen in there are a couple thousand- that was one of the
first things I monitored very closely.
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: James Nichols @ 2007-12-19 17:38 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0712191424360.31652@kivilampi-30.cs.helsinki.fi>
> > When I stop and start the Java application, all the new outbound
> > connections still get stuck in SYN_SENT state.
>
> Is it so that they don't timeout at all? You can collect some of their
> state from /proc/net/tcp (shows at least timers and attempt counters)....
The outbound connections to timeout. I've watched that they send
tcp_syn_retries SYN packets before eventually timing out.
> Are you sure that you just don't get unlucky at some point of time and
> all 200 available threads are just temporarily stuck and your application
> is just very slowly progressing then?
Yeah, I'm sure that it isn't an unlucky point of time. If I restart
the application when this problem occurs, all the outbound connections
still fail.
> > For a long time, the only thing that would resolve this was rebooting
> > the entire machine. Once I did this, the outbound connections could
> > be made succesfully.
>
> To the very same hosts? Or to another set of hosts?
Yes, to the same exact set of hosts.
> > And the problem almost instanteaously resolved itself and outbound
> > connection attempts were succesful.
>
> New or the pending ones?
I'm fairly sure that sockets that were already open in SYN_SENT state
when I turned tcp_sack off started to work as the count of sockets in
SYN_SENT state drops very rapidly.
> > In my case, it worked fine for about 38 hours before hitting a
> > wall where no outbound connections could be made.
>
> How accurate number? Is the lockup somehow related to daytime cycle?
It is 38 hours +/- a half hour or so. It isn't related to the time of
day, as it happens through out day/night depending on when the server
was restarted. A new developement in this area is that after the
first 38 hours of system time the problem would occur, so I disable
tcp_sack and the problem clears itself up and outbound connections are
succesful. After a couple of hours I re-enable tcp_sack and the next
SYN_SENT issue doesn't occur until more than 50 hours later (so like
90 hours after system start). It's as if the first time it occurs and
I turn tcp_sack off, it doesn't just reset the clock another 38 hours,
but gives even more time until the problem occurs again.
> > Is there a kernel buffer or some data structure that tcp_sack uses
> > that gets filled up after an extended period of operation?
>
> SACK has pretty little meaning in context of SYNs, there's only the
> sackperm(itted) TCP option which is sent along with the SYN/SYN-ACK.
>
> The SACK scoreboard is currently included to the skbs (has been like
> this for very long time), so no additional data structures should be
> there because of SACK...
I've been seeing this problem for about 4 years, so could it be
related to the scoreboard implementation somehow?
> /proc/net/tcp couple of times in a row, try something something like
> this:
>
> for i in (seq 1 40); do cat /proc/net/tcp; echo "-----"; sleep 10; done
I can set up to do this the next time the problem occurs.
> > I'm running kernel 2.6.18 on RedHat, but have had this problem occur
> > on earlier kernel versions (all 2.4 and 2.6).
>
> I've done some fixes to SACK processing since 2.6.18 (not sure if RedHat
> has backported them). Though they're not that critical nor anything in
> them should affect in SYN_SENT state.
Ok, unless there is direct evidence that there is a fix to this
problem in a later kernel I won't be able to upgrade. If there is a
redhat provided patch I can probably do that.
^ permalink raw reply
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Ralf Baechle @ 2007-12-19 17:27 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Jeff Garzik, netdev, linux-mips
In-Reply-To: <20071219124235.GA7550@alpha.franken.de>
On Wed, Dec 19, 2007 at 01:42:36PM +0100, Thomas Bogendoerfer wrote:
> - Use inline functions for dma_sync_* instead of macros
> - added Kconfig change to make selection for similair SGI boxes easier
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ 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