* Re: RFC3927 ARP patch status?
From: Herbert Xu @ 2006-06-02 23:12 UTC (permalink / raw)
To: David Daney; +Cc: wildfire, netdev
In-Reply-To: <44806926.1050509@avtrex.com>
David Daney <ddaney@avtrex.com> wrote:
>
> There were some discussions about whether it made sense for the kernel
> to support the behavior required by the RFC. Other comments debated the
> wisdom of using a tightly targeted patch specific to the RFC, or whether
> a more general but intrusive solution would be better.
I think we've made it quite clear what needs to be done for it to be
accepted. All that remains is for someone to implement it. If anyone
really cares about this, then please write the code instead of talking
about it.
Thanks,
--
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
* TCP Limited slow start
From: Stephen Hemminger @ 2006-06-02 23:13 UTC (permalink / raw)
To: Xiaoliang Wei, John Heffner; +Cc: netdev
Has anyone done an implementation of RFC3742 for Linux? It looks interesting, but
would need some integration with current ABC code.
There was some evidence of a version in old Web100 code, but it's gone now. Was
it deemed a mistake?
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Anand Kumria @ 2006-06-03 0:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Daney, netdev
In-Reply-To: <E1FmIoI-0007nK-00@gondolin.me.apana.org.au>
Herbert,
On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> David Daney <ddaney@avtrex.com> wrote:
> >
> > There were some discussions about whether it made sense for the kernel
> > to support the behavior required by the RFC. Other comments debated the
> > wisdom of using a tightly targeted patch specific to the RFC, or whether
> > a more general but intrusive solution would be better.
>
> I think we've made it quite clear what needs to be done for it to be
> accepted. All that remains is for someone to implement it. If anyone
> really cares about this, then please write the code instead of talking
> about it.
Okay, to confirm: you want a patch which looks at the scope value and if
the scope is link-local then we broadcast rather than do a directed ARP?
One I have where IPv6 encodes what address mask is link-local,
I'd like to follow the same style as. Should the kernel also set the
scope on IPv4 addresses like it does for IPv6 ones?
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Miller @ 2006-06-03 0:47 UTC (permalink / raw)
To: wildfire; +Cc: herbert, ddaney, netdev
In-Reply-To: <20060603003955.GJ549@progsoc.uts.edu.au>
RFC3927 seem to be an intellectual property mine field, I really don't
see how we can include this in the Linux kernel.
Go to "http://www.ietf.org/ipr", click on "Search the IPR
disclosures", then enter "3927" in the "Enter RFC number" field and
click SEARCH.
^ permalink raw reply
* Re: The AI parameter of tcp_highspeed.c (in 2.6.18)
From: David Miller @ 2006-06-03 0:51 UTC (permalink / raw)
To: shemminger; +Cc: davidwei79, jheffner, netdev
In-Reply-To: <20060602120507.7e1206d8@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 2 Jun 2006 12:05:07 -0700
> Went backed and looked at the RFC. The problem was just a simple
> translation of table to C array (0 based). Added this to the TCP
> testing repository.
Patch applied, thanks a lot.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Daney @ 2006-06-03 0:55 UTC (permalink / raw)
To: David Miller; +Cc: wildfire, herbert, netdev
In-Reply-To: <20060602.174756.08320251.davem@davemloft.net>
David Miller wrote:
> RFC3927 seem to be an intellectual property mine field, I really don't
> see how we can include this in the Linux kernel.
>
> Go to "http://www.ietf.org/ipr", click on "Search the IPR
> disclosures", then enter "3927" in the "Enter RFC number" field and
> click SEARCH.
RFC3927 may be a mine field, but the only thing that has to be changed
in the kernel to support it is to somehow configure the arp driver to
broadcast unconditionally on certain interfaces. The majority of the
rfc3927 protocol is done by userspace applications, so should *not*
really effect the kernel.
David Daney.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Daney @ 2006-06-03 0:58 UTC (permalink / raw)
To: Anand Kumria; +Cc: Herbert Xu, netdev
In-Reply-To: <20060603003955.GJ549@progsoc.uts.edu.au>
Anand Kumria wrote:
> Herbert,
>
> On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
>
>>David Daney <ddaney@avtrex.com> wrote:
>>
>>>There were some discussions about whether it made sense for the kernel
>>>to support the behavior required by the RFC. Other comments debated the
>>>wisdom of using a tightly targeted patch specific to the RFC, or whether
>>>a more general but intrusive solution would be better.
>>
>>I think we've made it quite clear what needs to be done for it to be
>>accepted. All that remains is for someone to implement it. If anyone
>>really cares about this, then please write the code instead of talking
>>about it.
>
>
> Okay, to confirm: you want a patch which looks at the scope value and if
> the scope is link-local then we broadcast rather than do a directed ARP?
>
I don't think that was the plan. In an earlier e-mail Herbert Xu said
(and I concur):
------------------------------
I like the idea of allowing user-space to control what addresses cause
broadcasts. However, I'm uncomfortable with overloading existing flags
even though they might appear to fit the bill on the face of it.
People may be using this for completely different reasons (address
selection) and it's not polite to suddenly turn all their ARPs into
broadcasts.
So how about a new address flag? We still have some vacancies there.
------------------------------
The idea was to add a new flag, *not* reuse the scope value.
David Daney
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Miller @ 2006-06-03 1:00 UTC (permalink / raw)
To: ddaney; +Cc: wildfire, herbert, netdev
In-Reply-To: <4480DDF5.2080002@avtrex.com>
From: David Daney <ddaney@avtrex.com>
Date: Fri, 02 Jun 2006 17:55:17 -0700
> RFC3927 may be a mine field, but the only thing that has to be changed
> in the kernel to support it is to somehow configure the arp driver to
> broadcast unconditionally on certain interfaces.
Ok, I'd have to see the final patch after Herbert's suggestions
are taken into account.
^ permalink raw reply
* [RFC] TCP limited slow start
From: Stephen Hemminger @ 2006-06-03 1:54 UTC (permalink / raw)
To: David Miller, John Heffner; +Cc: netdev
In-Reply-To: <20060602161312.3cb2ea66@localhost.localdomain>
Rolled my sleeve's up and gave this a try...
This is a implementation of Sally Floyd's Limited Slow Start
for Large Congestion Windows.
Summary from RFC:
Limited Slow-Start introduces a parameter, "max_ssthresh", and
modifies the slow-start mechanism for values of the congestion window
where "cwnd" is greater than "max_ssthresh". That is, during Slow-
Start, when
cwnd <= max_ssthresh,
cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every
arriving ACK (acknowledgement) during slow-start, as is always the
case. During Limited Slow-Start, when
max_ssthresh < cwnd <= ssthresh,
the invariant is maintained so that the congestion window is
increased during slow-start by at most max_ssthresh/2 MSS per round-
trip time. This is done as follows:
For each arriving ACK in slow-start:
If (cwnd <= max_ssthresh)
cwnd += MSS;
else
K = int(cwnd/(0.5 max_ssthresh));
cwnd += int(MSS/K);
Thus, during Limited Slow-Start the window is increased by 1/K MSS
for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead
of by 1 MSS as in standard slow-start [RFC2581].
---
Documentation/networking/ip-sysctl.txt | 8 +++++-
include/linux/sysctl.h | 1 +
include/net/tcp.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 8 ++++++
net/ipv4/tcp_cong.c | 46 ++++++++++++++++++++------------
net/ipv4/tcp_input.c | 1 +
6 files changed, 47 insertions(+), 18 deletions(-)
0884f45c9f21c50dd9117b2fc02bf5436be3c3bf
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f12007b..9869298 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -103,9 +103,15 @@ TCP variables:
tcp_abc - INTEGER
Controls Appropriate Byte Count defined in RFC3465. If set to
- 0 then does congestion avoid once per ack. 1 is conservative
+ 0 then does congestion avoid once per ack. 1 (default) is conservative
value, and 2 is more agressive.
+tcp_limited_ssthresh - INTEGER
+ Controls the increase of the congestion window during slow start as
+ defined in RFC3742. The purpose is to slow the growth of the congestion
+ window on high delay networks where agressive growth can cause losses
+ of 1000's of packets. Default is 100 packets.
+
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 76eaeff..a455165 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -403,6 +403,7 @@ enum
NET_TCP_MTU_PROBING=113,
NET_TCP_BASE_MSS=114,
NET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS=115,
+ NET_TCP_LIMITED_SSTHRESH=116,
};
enum {
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 575636f..3a14861 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -225,6 +225,7 @@ extern int sysctl_tcp_abc;
extern int sysctl_tcp_mtu_probing;
extern int sysctl_tcp_base_mss;
extern int sysctl_tcp_workaround_signed_windows;
+extern int sysctl_tcp_limited_ssthresh;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 6b6c3ad..d1358d3 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -688,6 +688,14 @@ #endif
.mode = 0644,
.proc_handler = &proc_dointvec
},
+ {
+ .ctl_name = NET_TCP_LIMITED_SSTHRESH,
+ .procname = "tcp_max_ssthresh",
+ .data = &sysctl_tcp_limited_ssthresh,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 857eefc..a27c792 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -180,25 +180,37 @@ int tcp_set_congestion_control(struct so
*/
void tcp_slow_start(struct tcp_sock *tp)
{
- if (sysctl_tcp_abc) {
- /* RFC3465: Slow Start
- * TCP sender SHOULD increase cwnd by the number of
- * previously unacknowledged bytes ACKed by each incoming
- * acknowledgment, provided the increase is not more than L
- */
- if (tp->bytes_acked < tp->mss_cache)
- return;
-
- /* We MAY increase by 2 if discovered delayed ack */
- if (sysctl_tcp_abc > 1 && tp->bytes_acked > 2*tp->mss_cache) {
- if (tp->snd_cwnd < tp->snd_cwnd_clamp)
- tp->snd_cwnd++;
- }
+ /* RFC3465: Apprpriate Byte Coute Slow Start
+ * TCP sender SHOULD increase cwnd by the number of
+ * previously unacknowledged bytes ACKed by each incoming
+ * acknowledgment, provided the increase is not more than L
+ */
+ if (sysctl_tcp_abc && tp->bytes_acked < tp->mss_cache)
+ return;
+
+ /* RFC3742: limited slow start
+ * the window is increased by 1/K MSS for each arriving ACK,
+ * for K = int(cwnd/(0.5 max_ssthresh))
+ */
+ if (sysctl_tcp_limited_ssthresh
+ && tp->snd_cwnd > sysctl_tcp_limited_ssthresh) {
+ u32 k = max(tp->snd_cwnd / (sysctl_tcp_limited_ssthresh >> 1), 1U);
+ if (++tp->snd_cwnd_cnt >= k) {
+ if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
+ tp->snd_cwnd_cnt = 0;
+ }
+ } else {
+ /* ABC: We MAY increase by 2 if discovered delayed ack */
+ if (sysctl_tcp_abc > 1
+ && tp->bytes_acked > 2*tp->mss_cache
+ && tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
+
+ if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
}
tp->bytes_acked = 0;
-
- if (tp->snd_cwnd < tp->snd_cwnd_clamp)
- tp->snd_cwnd++;
}
EXPORT_SYMBOL_GPL(tcp_slow_start);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 718d0f2..80dd5e4 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -90,6 +90,7 @@ int sysctl_tcp_nometrics_save;
int sysctl_tcp_moderate_rcvbuf = 1;
int sysctl_tcp_abc = 1;
+int sysctl_tcp_limited_ssthresh = 100;
#define FLAG_DATA 0x01 /* Incoming frame contained data. */
#define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */
--
1.3.3
^ permalink raw reply related
* Re: [PATCH 2.6.16.18] MSI: Proposed fix for MSI/MSI-X load failure
From: Paul Mackerras @ 2006-06-03 2:09 UTC (permalink / raw)
To: Rajesh Shah
Cc: Ravinandan Arakali, linux-kernel, netdev, leonid.grossman,
ananda.raju, rapuru.sriram
In-Reply-To: <20060602145512.A13024@unix-os.sc.intel.com>
Rajesh Shah writes:
> The current MSI code actually does this deliberately, not by
> accident. It's got a lot of complex code to track devices and
> vectors and make sure an enable_msi -> disable -> enable sequence
> gives a driver the same vector. It also has policies about
> reserving vectors based on potential hotplug activity etc.
> Frankly, I've never understood the need for such policies, and
> am in the process of removing all of them.
Good. We will not be able to support a policy of giving the driver
the same vector across an enable_msi/disable/enable sequence on IBM
System p machines (64-bit PowerPC), because the firmware controls the
MSI allocation, and it doesn't give us the necessary guarantees.
Paul.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Anand Kumria @ 2006-06-03 2:50 UTC (permalink / raw)
To: David Daney; +Cc: Herbert Xu, netdev
In-Reply-To: <4480DEB3.2060806@avtrex.com>
On Fri, Jun 02, 2006 at 05:58:27PM -0700, David Daney wrote:
> Anand Kumria wrote:
> >Herbert,
> >
> >On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> >
> >>David Daney <ddaney@avtrex.com> wrote:
> >>
> >>>There were some discussions about whether it made sense for the kernel
> >>>to support the behavior required by the RFC. Other comments debated the
> >>>wisdom of using a tightly targeted patch specific to the RFC, or whether
> >>>a more general but intrusive solution would be better.
> >>
> >>I think we've made it quite clear what needs to be done for it to be
> >>accepted. All that remains is for someone to implement it. If anyone
> >>really cares about this, then please write the code instead of talking
> >>about it.
> >
> >
> >Okay, to confirm: you want a patch which looks at the scope value and if
> >the scope is link-local then we broadcast rather than do a directed ARP?
> >
>
> I don't think that was the plan. In an earlier e-mail Herbert Xu said
> (and I concur):
>
> ------------------------------
> I like the idea of allowing user-space to control what addresses cause
> broadcasts. However, I'm uncomfortable with overloading existing flags
> even though they might appear to fit the bill on the face of it.
>
[...]
Sorry, I can't find any email with any of those words in it by Herbert.
Could you tell me the message-id, so I can read some of the surrounding
context?
>
> The idea was to add a new flag, *not* reuse the scope value.
>
I guess it would be something set during RTM_NEWADDR (and returned by
RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
defaulting to 1. When set to 0, generate a broadcast ARP for the
address.
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* link-local address via ifconfig
From: Anand Kumria @ 2006-06-03 2:57 UTC (permalink / raw)
To: netdev
Hi,
There are plenty of people who still use ifconfig to list the addresses
assigned to their network interfaces (I know, ifconfig is broken) and
who then parse the output.
However the kernel puts link-local scoped address first if the address
list of an interface, so an interface like:
eve:[~]% ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:12:f0:03:d9:e7 brd ff:ff:ff:ff:ff:ff
inet 169.254.182.108/16 brd 169.254.255.255 scope link wlan0
inet 192.168.2.2/24 brd 192.168.2.255 scope global wlan0
inet6 fe80::212:f0ff:fe03:d9e7/64 scope link
valid_lft forever preferred_lft forever
appears as:
eve:[~]% ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:12:F0:03:D9:E7
inet addr:169.254.182.108 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::212:f0ff:fe03:d9e7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[... elided ...]
Is there any reason to put the link-local address first in the list?
I've had a number of bugreports (or outright panic attacks) where the
problem turned out to be that ifconfig was reporting the link-local
address first, rather than the global/site one.
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Herbert Xu @ 2006-06-03 4:52 UTC (permalink / raw)
To: Anand Kumria; +Cc: David Daney, netdev
In-Reply-To: <20060603025001.GK549@progsoc.uts.edu.au>
On Sat, Jun 03, 2006 at 12:50:02PM +1000, Anand Kumria wrote:
>
> I guess it would be something set during RTM_NEWADDR (and returned by
> RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
> defaulting to 1. When set to 0, generate a broadcast ARP for the
> address.
Address flags start with IFA_F and are in ifa_flags.
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: link-local address via ifconfig
From: Herbert Xu @ 2006-06-03 4:55 UTC (permalink / raw)
To: Anand Kumria; +Cc: netdev
In-Reply-To: <20060603025743.GL549@progsoc.uts.edu.au>
Anand Kumria <wildfire@progsoc.uts.edu.au> wrote:
>
> There are plenty of people who still use ifconfig to list the addresses
> assigned to their network interfaces (I know, ifconfig is broken) and
> who then parse the output.
If people insist on using hammers on screws, the answer is not to improve
the hammer.
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
* driver for pptp
From: xeb @ 2006-06-03 7:06 UTC (permalink / raw)
To: netdev
Hello.
I have developed the driver for Point-to-Point Tunneling Protocol (PPTP).
This driver works in pair with plugin for pppd.
It is enough to use pppd's plugin for start of the client.
Also there is a server (based on pptpd) which uses this driver.
By results of my testing the speed of transfer has increased on >50% and cpu usage has decreased on >50% in comparison with original pptpd and pptpclient.
I have published the project on http://accel-pptp.sourceforge.net/
There is more then 65 downloads but no any bug report (and no any positive result report).
I think the driver still requires testing.
Hope this driver will go to a kernel tree and will make linux more productive.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Stefan Rompf @ 2006-06-03 8:45 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Francois Romieu, netdev
In-Reply-To: <200606021630.34544.IvDoorn@gmail.com>
Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
> > Or actually, I don't think the radiobtn/ won't be actually needed as
> > prefix. The name passed to the radiobtn driver by the driver should be
> > sufficient.
>
> Updated version,
>
> Signed-off-by Ivo van Doorn <IvDoorn@gmail.com>
I don't like the patch in it's current form. Many notebooks have a number of
additional keys that need to be queried/polled using the same interface, but
just one button is to control the radio, the rest are multimedia keys that
just need to be forwarded to userspace. Or maybe a bluetooth key.
Some systems require suspend/resume support, others remember state of the
wireless button automatically. For a perfect example, look at
drivers/input/misc/wistron_btns.c.
So you should create an "extra laptop buttons" interface. Though it may be
hard to assure that this generalization layer between input system and
hardware is still a win for the driver developer.
Stefan
^ permalink raw reply
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-06-03 9:54 UTC (permalink / raw)
To: bugme-daemon; +Cc: David S. Miller, netdev
In-Reply-To: <200605271731.k4RHVJTb018158@fire-2.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Sat, May 27, 2006 at 10:31:19AM -0700, bugme-daemon@bugzilla.kernel.org wrote:
>
> Ok, see the attachment (ALL.txt.gz) for the tcpdump output. If you would like
> the hexdump or more, please give the tcpdump filter rule to me.
Thanks a lot. So it wasn't as uncommon as I thought. In fact, partial
odd acks like yours happen all the time as part of FIN handling. So this
is something that we want to address.
BTW, we should also fix arch/alpha/kernel/io.c to not crash on
unaligned data. Most other common architectures will grin and
bear it.
[TCP]: Avoid skb_pull if possible when trimming head
Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd. Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.
Unaligned data is not the end of the world, but we should avoid it if
it's easily done. In this case it is trivial. Since we're discarding
all of the head data it doesn't matter whether we move skb->data forward
or back.
However, it is still possible to have unaligned skb->data in general.
So network drivers should be prepared to handle it instead of crashing.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
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
[-- Attachment #2: tcp-trim-head.patch --]
[-- Type: text/plain, Size: 435 bytes --]
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 743016b..bd7c89b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -676,7 +676,7 @@ int tcp_trim_head(struct sock *sk, struc
pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
- if (len <= skb_headlen(skb)) {
+ if (len < skb_headlen(skb)) {
__skb_pull(skb, len);
} else {
if (__pskb_trim_head(skb, len-skb_headlen(skb)) == NULL)
^ permalink raw reply related
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-03 10:51 UTC (permalink / raw)
To: herbert; +Cc: bugme-daemon, davem, netdev, yoshfuji
In-Reply-To: <20060603095442.GA373@gondor.apana.org.au>
In article <20060603095442.GA373@gondor.apana.org.au> (at Sat, 3 Jun 2006 19:54:42 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> [TCP]: Avoid skb_pull if possible when trimming head
>
> Trimming the head of an skb by calling skb_pull can cause the packet
> to become unaligned if the length pulled is odd. Since the length is
> entirely arbitrary for a FIN packet carrying data, this is actually
> quite common.
I think that people will start thinking why we cannot
skb_pull(skb, len) if skb_headlen(skb) == len; some comment needed...
--yoshfuji
^ permalink raw reply
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-06-03 11:07 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: bugme-daemon, davem, netdev
In-Reply-To: <20060603.195123.77471511.yoshfuji@linux-ipv6.org>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On Sat, Jun 03, 2006 at 07:51:23PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> I think that people will start thinking why we cannot
> skb_pull(skb, len) if skb_headlen(skb) == len; some comment needed...
Good idea. Here is a better one.
[TCP]: Avoid skb_pull if possible when trimming head
Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd. Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.
Unaligned data is not the end of the world, but we should avoid it if
it's easily done. In this case it is trivial. Since we're discarding
all of the head data it doesn't matter whether we move skb->data forward
or back.
However, it is still possible to have unaligned skb->data in general.
So network drivers should be prepared to handle it instead of crashing.
This patch also adds an unlikely marking on len < headlen since partial
ACKs on head data are extremely rare in the wild. As the return value
of __pskb_trim_head is no longer ever NULL that has been removed.
Signed-off-by: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Thanks,
--
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
[-- Attachment #2: tcp-trim-head-2.patch --]
[-- Type: text/plain, Size: 1203 bytes --]
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 743016b..f33c9dd 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -642,7 +642,7 @@ int tcp_fragment(struct sock *sk, struct
* eventually). The difference is that pulled data not copied, but
* immediately discarded.
*/
-static unsigned char *__pskb_trim_head(struct sk_buff *skb, int len)
+static void __pskb_trim_head(struct sk_buff *skb, int len)
{
int i, k, eat;
@@ -667,7 +667,6 @@ static unsigned char *__pskb_trim_head(s
skb->tail = skb->data;
skb->data_len -= len;
skb->len = skb->data_len;
- return skb->tail;
}
int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
@@ -676,12 +675,11 @@ int tcp_trim_head(struct sock *sk, struc
pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
- if (len <= skb_headlen(skb)) {
+ /* If len == headlen, we avoid __skb_pull to preserve alignment. */
+ if (unlikely(len < skb_headlen(skb)))
__skb_pull(skb, len);
- } else {
- if (__pskb_trim_head(skb, len-skb_headlen(skb)) == NULL)
- return -ENOMEM;
- }
+ else
+ __pskb_trim_head(skb, len - skb_headlen(skb));
TCP_SKB_CB(skb)->seq += len;
skb->ip_summed = CHECKSUM_HW;
^ permalink raw reply related
* [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Daniel Drake @ 2006-06-03 11:20 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Ulrich Kunitz, USB development list
I tried to submit this patch yesterday, but it doesn't appear to have
been delivered. The patch is probably a bit on the large side, so I'll
try again over http:
http://dev.gentoo.org/~dsd/kernel/zd1211rw.patch
Any comments appreciated.
[PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
There are 60+ USB wifi adapters available on the market based on the
ZyDAS ZD1211 chip.
Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so
most data operations are coordinated by the device driver. The ZD1211
chip sits alongside an RF transceiver which is also controlled by the
driver. Our driver currently supports 2 RF types, we know of one other
available in a few marketed products which we will be supporting soon.
Our driver also supports the newer revision of ZD1211, called ZD1211B.
The initialization and RF operations are slightly different for the new
revision, but the main difference is 802.11e support. Our driver does
not support the QoS features yet, but we think we know how to use them.
This driver is based on ZyDAS's own GPL driver available from
www.zydas.com.tw. ZyDAS engineers have been responsive and supportive of
our efforts, so thumbs up to them. Additionally, the firmware is
redistributable and they have provided device specs.
This driver has been written primarily by Ulrich Kunitz and myself.
Graham Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed.
The developers of ieee80211 and softmac have made our lives so much
easier- thanks!
We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
If there is enough time for review, we would like to aim for inclusion
in 2.6.18. The driver works nicely as a STA, and can connect to both
open and encrypted networks (we are using software-based encryption for
now). We will work towards supporting more advanced features in the
future (ad-hoc, master mode, 802.11a, ...).
Signed-off-by: Daniel Drake <dsd@gentoo.org>
^ permalink raw reply
* Re: OLPC (One Laptop Per Child) Developer's program.
From: David Woodhouse @ 2006-06-03 11:49 UTC (permalink / raw)
To: jg; +Cc: netdev, OLPC Developer's List
In-Reply-To: <1149025377.30703.141.camel@localhost.localdomain>
On Tue, 2006-05-30 at 17:42 -0400, Jim Gettys wrote:
> As you know, we've said we were going to have a developer's program. You
> can find more information, including how to apply for boards at:
>
> http://wiki.laptop.org/index.php/Developers_Program
>
> Note that these are bare PC prototype boards, not packaged machines.
> Jim Gettys
ObNetdev:
One thing we really need is NAT-PT or an equivalent for allowing access
to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
with JFFS2 improvements, I plan to start looking at that.
Not that we really need the actual prototype boards for working on that,
of course.
--
dwmw2
^ permalink raw reply
* Fwd: notice
From: Callie Thurman @ 2006-06-03 13:28 UTC (permalink / raw)
To: netdev
Life Should be Full of Luxuries....
http://blessthathomepleasee.com/
Yet, only a handful of people can afford the finest products, the luxuries of the elite.
But, here at "Luxury Replica" we are committed to bringing you the finest products, at prices incomparably lower.
All of the top designer brands for Watches, Ties, Handbags and even Mont Blanc.
http://newgunforsalejoke.com/
The finest of products, at the lowest of prices, only a click away:
http://newgunforsalejoke.com/
Regards,
Callie Thurman
^ permalink raw reply
* Re: r8169+NAPI soft lockup
From: Richard Gregory @ 2006-06-03 15:05 UTC (permalink / raw)
To: Francois Romieu, netdev
In-Reply-To: <20060510215004.GA25395@electric-eye.fr.zoreil.com>
A little more info to the dead thread...
The machine died this morning, network and serial console were
unresponsive. On rebooting, the only unusual message in logs were the
last two:
Jun 3 01:58:39 loft -- MARK --
Jun 3 02:03:39 loft -- MARK --
Jun 3 02:08:40 loft -- MARK --
Jun 3 02:10:26 loft smartd[18830]: Device: /dev/hda, starting scheduled
Short Self-Test.
Jun 3 02:10:27 loft smartd[18830]: Device: /dev/hdc, starting scheduled
Short Self-Test.
Jun 3 02:10:27 loft smartd[18830]: Device: /dev/hde, starting scheduled
Short Self-Test.
Jun 3 02:10:28 loft smartd[18830]: Device: /dev/hdg, starting scheduled
Short Self-Test.
Jun 3 02:10:28 loft smartd[18830]: Device: /dev/hdi, starting scheduled
Short Self-Test.
Jun 3 02:10:29 loft smartd[18830]: Device: /dev/hdk, starting scheduled
Short Self-Test.
Jun 3 02:10:30 loft smartd[18830]: Device: /dev/hdm, starting scheduled
Short Self-Test.
Jun 3 02:10:31 loft smartd[18830]: Device: /dev/hdo, starting scheduled
Short Self-Test.
Jun 3 02:10:32 loft smartd[18830]: Device: /dev/hdq, starting scheduled
Short Self-Test.
Jun 3 02:10:32 loft smartd[18830]: Device: /dev/hds, starting scheduled
Short Self-Test.
Jun 3 02:13:26 loft kernel: hdo: lost interrupt
Jun 3 02:13:46 loft kernel: hdo: dma_timer_expiry: dma status == 0x21
'lost interrupt' has never been seen before in the logs.
I guess this more strongly implicates the it821x driver.
Richard
^ permalink raw reply
* Re: [RFC] TCP limited slow start
From: John Heffner @ 2006-06-03 16:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20060602185403.1549e3c6@localhost.localdomain>
Stephen Hemminger wrote:
> Rolled my sleeve's up and gave this a try...
>
> This is a implementation of Sally Floyd's Limited Slow Start
> for Large Congestion Windows.
Limited slow start is useful as a work-around for bottleneck queues that
are inappropriately short. I don't think it's good to run it all the
time by default (with a max_ssthresh < infinity), because it slows down
flows on healthy paths, and introduces another non-scalable parameter to
TCP.
I see it as potentially useful as a per-route parameter, where you set
it deliberately to work around some known problematic path. A sysctl
with a default value of infinity might be okay as well.
Practically speaking, we've had this in the Web100 patch for a long time
(and still do, look for WAD_MaxSsthresh), but I've never found it all
that useful. If the bottleneck queue is too short, you usually end up
getting screwed other ways too.
-John
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-03 17:51 UTC (permalink / raw)
To: linux-usb-devel; +Cc: Daniel Drake, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <44817083.508@gentoo.org>
Am Samstag, 3. Juni 2006 13:20 schrieb Daniel Drake:
> I tried to submit this patch yesterday, but it doesn't appear to have
> been delivered. The patch is probably a bit on the large side, so I'll
> try again over http:
>
> http://dev.gentoo.org/~dsd/kernel/zd1211rw.patch
>
> Any comments appreciated.
+static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
+{
+ static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
+ return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
+}
Why on the stack?
+static int zd1211_hw_reset_phy(struct zd_chip *chip)
+{
+ static const struct zd_ioreq16 ioreqs[] = {
+ { CR0, 0x0a }, { CR1, 0x06 }, { CR2, 0x26 },
+ { CR3, 0x38 }, { CR4, 0x80 }, { CR9, 0xa0 },
+ { CR10, 0x81 }, { CR11, 0x00 }, { CR12, 0x7f },
+ { CR13, 0x8c }, { CR14, 0x80 }, { CR15, 0x3d },
+ { CR16, 0x20 }, { CR17, 0x1e }, { CR18, 0x0a },
+ { CR19, 0x48 }, { CR20, 0x0c }, { CR21, 0x0c },
+ { CR22, 0x23 }, { CR23, 0x90 }, { CR24, 0x14 },
+ { CR25, 0x40 }, { CR26, 0x10 }, { CR27, 0x19 },
+ { CR28, 0x7f }, { CR29, 0x80 }, { CR30, 0x4b },
+ { CR31, 0x60 }, { CR32, 0x43 }, { CR33, 0x08 },
+ { CR34, 0x06 }, { CR35, 0x0a }, { CR36, 0x00 },
+ { CR37, 0x00 }, { CR38, 0x38 }, { CR39, 0x0c },
+ { CR40, 0x84 }, { CR41, 0x2a }, { CR42, 0x80 },
+ { CR43, 0x10 }, { CR44, 0x12 }, { CR46, 0xff },
+ { CR47, 0x1E }, { CR48, 0x26 }, { CR49, 0x5b },
+ { CR64, 0xd0 }, { CR65, 0x04 }, { CR66, 0x58 },
+ { CR67, 0xc9 }, { CR68, 0x88 }, { CR69, 0x41 },
+ { CR70, 0x23 }, { CR71, 0x10 }, { CR72, 0xff },
+ { CR73, 0x32 }, { CR74, 0x30 }, { CR75, 0x65 },
+ { CR76, 0x41 }, { CR77, 0x1b }, { CR78, 0x30 },
+ { CR79, 0x68 }, { CR80, 0x64 }, { CR81, 0x64 },
+ { CR82, 0x00 }, { CR83, 0x00 }, { CR84, 0x00 },
+ { CR85, 0x02 }, { CR86, 0x00 }, { CR87, 0x00 },
+ { CR88, 0xff }, { CR89, 0xfc }, { CR90, 0x00 },
+ { CR91, 0x00 }, { CR92, 0x00 }, { CR93, 0x08 },
+ { CR94, 0x00 }, { CR95, 0x00 }, { CR96, 0xff },
+ { CR97, 0xe7 }, { CR98, 0x00 }, { CR99, 0x00 },
+ { CR100, 0x00 }, { CR101, 0xae }, { CR102, 0x02 },
+ { CR103, 0x00 }, { CR104, 0x03 }, { CR105, 0x65 },
+ { CR106, 0x04 }, { CR107, 0x00 }, { CR108, 0x0a },
+ { CR109, 0xaa }, { CR110, 0xaa }, { CR111, 0x25 },
+ { CR112, 0x25 }, { CR113, 0x00 }, { CR119, 0x1e },
+ { CR125, 0x90 }, { CR126, 0x00 }, { CR127, 0x00 },
+ { },
+ { CR5, 0x00 }, { CR6, 0x00 }, { CR7, 0x00 },
+ { CR8, 0x00 }, { CR9, 0x20 }, { CR12, 0xf0 },
+ { CR20, 0x0e }, { CR21, 0x0e }, { CR27, 0x10 },
+ { CR44, 0x33 }, { CR47, 0x1E }, { CR83, 0x24 },
+ { CR84, 0x04 }, { CR85, 0x00 }, { CR86, 0x0C },
+ { CR87, 0x12 }, { CR88, 0x0C }, { CR89, 0x00 },
+ { CR90, 0x10 }, { CR91, 0x08 }, { CR93, 0x00 },
+ { CR94, 0x01 }, { CR95, 0x00 }, { CR96, 0x50 },
+ { CR97, 0x37 }, { CR98, 0x35 }, { CR101, 0x13 },
+ { CR102, 0x27 }, { CR103, 0x27 }, { CR104, 0x18 },
+ { CR105, 0x12 }, { CR109, 0x27 }, { CR110, 0x27 },
+ { CR111, 0x27 }, { CR112, 0x27 }, { CR113, 0x27 },
+ { CR114, 0x27 }, { CR115, 0x26 }, { CR116, 0x24 },
+ { CR117, 0xfc }, { CR118, 0xfa }, { CR120, 0x4f },
+ { CR123, 0x27 }, { CR125, 0xaa }, { CR127, 0x03 },
+ { CR128, 0x14 }, { CR129, 0x12 }, { CR130, 0x10 },
+ { CR131, 0x0C }, { CR136, 0xdf }, { CR137, 0x40 },
+ { CR138, 0xa0 }, { CR139, 0xb0 }, { CR140, 0x99 },
+ { CR141, 0x82 }, { CR142, 0x54 }, { CR143, 0x1c },
+ { CR144, 0x6c }, { CR147, 0x07 }, { CR148, 0x4c },
+ { CR149, 0x50 }, { CR150, 0x0e }, { CR151, 0x18 },
+ { CR160, 0xfe }, { CR161, 0xee }, { CR162, 0xaa },
+ { CR163, 0xfa }, { CR164, 0xfa }, { CR165, 0xea },
+ { CR166, 0xbe }, { CR167, 0xbe }, { CR168, 0x6a },
+ { CR169, 0xba }, { CR170, 0xba }, { CR171, 0xba },
+ /* Note: CR204 must lead the CR203 */
+ { CR204, 0x7d },
+ { },
+ { CR203, 0x30 },
+ };
This is too much to allocate on the stack.
+static void disconnect(struct usb_interface *intf)
+{
+ struct net_device *netdev = zd_intf_to_netdev(intf);
+ struct zd_mac *mac = zd_netdev_mac(netdev);
+ struct zd_usb *usb = &mac->chip.usb;
+
+ dev_dbg_f(zd_usb_dev(usb), "\n");
+
+ zd_netdev_disconnect(netdev);
+
+ /* Just in case something has gone wrong! */
+ zd_usb_disable_rx(usb);
+ zd_usb_disable_int(usb);
+
+ /* If the disconnect has been caused by a removal of the
+ * driver module, the reset allows reloading of the driver. If the
+ * reset will not be executed here, the upload of the firmware in the
+ * probe function caused by the reloading of the driver will fail.
+ */
+ usb_reset_device(interface_to_usbdev(intf));
+
+ /* If somebody still waits on this lock now, this is an error. */
+ zd_netdev_free(netdev);
+ dev_dbg(&intf->dev, "disconnected\n");
+}
This is racy. It allows io to disconnected devices. You must take the
lock and set a flag that you test after you've taken the lock elsewhere.
Regards
Oliver
^ 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