* Re: feature negotiation patch for linux
From: Arnaldo Carvalho de Melo @ 2006-02-01 14:18 UTC (permalink / raw)
To: dccp
On 1/31/06, Andrea Bittau <a.bittau@cs.ucl.ac.uk> wrote:
> http://128.16.66.93/acme-dccp-feat.diff
>
> [no domain name because it's expiring today =( ]
>
> It's my initial "mega-patch, rough" implementation of feature negotiation for
> linux, based on acme's tree.
>
> It supports CHANGE_L, CHANGE_R via setsockopt from userland.
> It will change / confirm.
> It supports mandatory options. [no support from userland yet though].
> It supports re-transmission of change options.
>
> TODO:
> * getsockopt to poll for option status.
> * setsockopt with a flag for mandatory options.
> * actually change the option in the protocol itself. Until now they are only
> negotiation and an empty function is called =D
>
>
> Any comments are welcome. I'll try to contact acme now, and hopefully stuff
> will start getting merged.
Excellent news! First round of comments:
+ list_for_each(cur, &dp->dccps_options.dccpo_pending) {
+ opt = list_entry(cur, struct dccp_opt_pend, dccpop_list);
Please use list_for_each_entry()
dccp_feat_change should receive a gfp_t for use in kmalloc,
as it is called from setsockopt and there we should just use GFP_KERNEL.
ACK_RATIO in dccp_feat_init()? CCID2 specific stuff?
- Arnaldo
^ permalink raw reply
* feature negotiation patch for linux
From: Andrea Bittau @ 2006-01-31 16:59 UTC (permalink / raw)
To: dccp
http://128.16.66.93/acme-dccp-feat.diff
[no domain name because it's expiring today =( ]
It's my initial "mega-patch, rough" implementation of feature negotiation for
linux, based on acme's tree.
It supports CHANGE_L, CHANGE_R via setsockopt from userland.
It will change / confirm.
It supports mandatory options. [no support from userland yet though].
It supports re-transmission of change options.
TODO:
* getsockopt to poll for option status.
* setsockopt with a flag for mandatory options.
* actually change the option in the protocol itself. Until now they are only
negotiation and an empty function is called =D
Any comments are welcome. I'll try to contact acme now, and hopefully stuff
will start getting merged.
^ permalink raw reply
* Re: [RFC] TCP MTU probing
From: Ian McDonald @ 2006-01-31 1:21 UTC (permalink / raw)
To: dccp
On 1/31/06, David S. Miller <davem@davemloft.net> wrote:
> From: John Heffner <jheffner@psc.edu>
> Date: Tue, 06 Dec 2005 14:42:53 -0500
>
> > I'd like to get a few people at least to look this over, and maybe give
> > it a try. One remaining item to consider is how best to cache the state
> > between connections. Are there any major concerns or reservations about
> > this approach, or the patch itself?
>
Just having a read of this now (missed first time round) and I see
that PMTUD as per this RFC is also allowed by DCCP in it's spec
(Section 14.1).
> and then I'll happily at this in for net-2.6.17
At some future stage we should merge this into the DCCP tree too.
Looking at the code there are quite a few places where it has TCP in
there where maybe it would be better to have IP in there to save
further changes when DCCP starts to use the code....
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* Re: service code bug in linux & tcpdump
From: Ian McDonald @ 2006-01-24 23:32 UTC (permalink / raw)
To: dccp
In-Reply-To: <20060124111016.GA1159@tribal.sorbonet.org>
> > did tcpdump get it wrong then?
> > print-dccp.c:315
> >
> > (void)printf("request (service=%d) ", dhr->dccph_req_service);
> >
> > should that be EXTRACT_32BITS(&dhr->dccph_req_service) ?
>
Feel free to submit to tcpdump workers list which is how I got the
code merged.... otherwise I will look at some time when I have time
(not soon!) as there are a couple of other DCCP bugs for tcpdump as
well....
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* Re: service code bug in linux & tcpdump
From: Yoshifumi Nishida @ 2006-01-24 14:24 UTC (permalink / raw)
To: dccp
In-Reply-To: <20060124111016.GA1159@tribal.sorbonet.org>
From: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Subject: Re: service code bug in linux & tcpdump
Date: Tue, 24 Jan 2006 11:37:15 +0000
Message-ID: <20060124113715.GA1953@tribal.sorbonet.org>
> On Tue, Jan 24, 2006 at 08:22:56PM +0900, Yoshifumi Nishida wrote:
> > I believe applications should do htonl(), like port number.
>
> did tcpdump get it wrong then?
> print-dccp.c:315
>
> (void)printf("request (service=%d) ", dhr->dccph_req_service);
>
> should that be EXTRACT_32BITS(&dhr->dccph_req_service) ?
In my opinion, yes.
Thanks,
--
Yoshifumi Nishida
nishida@csl.sony.co.jp
^ permalink raw reply
* Re: service code bug in linux & tcpdump
From: Andrea Bittau @ 2006-01-24 11:37 UTC (permalink / raw)
To: dccp
In-Reply-To: <20060124111016.GA1159@tribal.sorbonet.org>
On Tue, Jan 24, 2006 at 08:22:56PM +0900, Yoshifumi Nishida wrote:
> I believe applications should do htonl(), like port number.
did tcpdump get it wrong then?
print-dccp.c:315
(void)printf("request (service=%d) ", dhr->dccph_req_service);
should that be EXTRACT_32BITS(&dhr->dccph_req_service) ?
^ permalink raw reply
* Re: service code bug in linux & tcpdump
From: Yoshifumi Nishida @ 2006-01-24 11:22 UTC (permalink / raw)
To: dccp
In-Reply-To: <20060124111016.GA1159@tribal.sorbonet.org>
From: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Subject: service code bug in linux & tcpdump
Date: Tue, 24 Jan 2006 11:10:16 +0000
Message-ID: <20060124111016.GA1159@tribal.sorbonet.org>
> shouldn't the service code [u32] be in network byte order?
>
> If so, linux:
> net/dccp/output.c:105
> should have a htonl();
I believe applications should do htonl(), like port number.
--
Yoshifumi Nishida
nishida@csl.sony.co.jp
^ permalink raw reply
* service code bug in linux & tcpdump
From: Andrea Bittau @ 2006-01-24 11:10 UTC (permalink / raw)
To: dccp
shouldn't the service code [u32] be in network byte order?
If so, linux:
net/dccp/output.c:105
should have a htonl();
tcpdump:
print-dccp.c:~304
should have EXTRACT_32BITS();
if it really is an error, other places in the code probably have it.
^ permalink raw reply
* Re: Bug?? out of memory on receive for DCCP
From: Arnaldo Carvalho de Melo @ 2006-01-23 23:56 UTC (permalink / raw)
To: dccp
In-Reply-To: <cbec11ac0601231514g4d53131dl47bbaafb2997d110@mail.gmail.com>
On 1/23/06, Ian McDonald <imcdnzl@gmail.com> wrote:
> When I have been doing some stress testing on DCCP for my transmit
> changes using ttcp with a million packets I'm getting page allocation
> failures etc on the receive side (in code I haven't changed). I can
> also see memory going up dramatically when viewing through "top"
>
> Setup is two PCs on a LAN. I'm presuming this is because we don't put
> limit on receive buffers at present and ttcp is not pulling packets
> fast enough off buffers to stop memory exhausation.
>
> Is that correct?
Yes, this is possible, check the ccid3 packet history allocator, it
doesn't accounts the packet to the socket, try adding some basic upper
bound on the number of packets on a variable in the dccp_sock struct,
doing it in a similar way as TCP (memory moderation, etc) is in the
todo list.
- Arnaldo
^ permalink raw reply
* Bug?? out of memory on receive for DCCP
From: Ian McDonald @ 2006-01-23 23:14 UTC (permalink / raw)
To: dccp
When I have been doing some stress testing on DCCP for my transmit
changes using ttcp with a million packets I'm getting page allocation
failures etc on the receive side (in code I haven't changed). I can
also see memory going up dramatically when viewing through "top"
Setup is two PCs on a LAN. I'm presuming this is because we don't put
limit on receive buffers at present and ttcp is not pulling packets
fast enough off buffers to stop memory exhausation.
Is that correct?
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* Re: [Fwd: Re: loss detection and tfrc rate]
From: Arnaldo Carvalho de Melo @ 2006-01-23 20:20 UTC (permalink / raw)
To: dccp
In-Reply-To: <65209.84.56.242.24.1138047195.squirrel@mail2web.iu-bremen.de>
On 1/23/06, h.balan@iu-bremen.de <h.balan@iu-bremen.de> wrote:
>
> It´s the net-2.6 version from Dave Miller´s git at kernel.org (from a week
> or so ago, quite similar to 2.6.14). If this is not the ultimate source
> for it, I would appreciate a pointer in the right direction.
Right now it is, I haven't anything DCCP related in my net-2.6.17
queue yet, will announce here if I add something there.
That said, the CCID3 code is experimental at best now, doesn't
crashes, "works" in
some very basic scenarios but definetively needs mucho love and care, hope your
involvement helps in this area.
- Arnaldo
^ permalink raw reply
* [Fwd: Re: loss detection and tfrc rate]
From: h.balan @ 2006-01-23 20:13 UTC (permalink / raw)
To: dccp
It´s the net-2.6 version from Dave Miller´s git at kernel.org (from a week
or so ago, quite similar to 2.6.14). If this is not the ultimate source
for it, I would appreciate a pointer in the right direction.
Vlad
> On 1/24/06, h.balan@iu-bremen.de <h.balan@iu-bremen.de> wrote:
>>
>> I was using DCCP over a very lossy setup (more than 10% losses in each
>> direction) and I could not get the kernel to stop in the detect_loss()
>> function (using UML and setting breakpoints). I inserted a printk() in
>> dccp_li_hist_calc_i_mean() which should be called by all TFRC rate
>> calculations, but, according to the logs, this function is not called
>> either.
>> I would appreciate if someone could check this again, since there
>> are people on the list much more familiar with the implementation.
>>
>> My second question regards the loss intervals used by TFRC. In one of
>> the
>> defining documents it is mentioned that a loss interval should be at
>> least
>> one measured RTT long, however I could not see where this is implemented
>> in the source code. Could someone help me here?
>>
> Where have you obtained DCCP from and what version are you running?
>
> Ian
> --
> Ian McDonald
> http://wand.net.nz/~iam4
> WAND Network Research Group
> University of Waikato
> New Zealand
>
^ permalink raw reply
* Re: loss detection and tfrc rate
From: Ian McDonald @ 2006-01-23 19:33 UTC (permalink / raw)
To: dccp
In-Reply-To: <64065.84.56.242.24.1138041574.squirrel@mail2web.iu-bremen.de>
On 1/24/06, h.balan@iu-bremen.de <h.balan@iu-bremen.de> wrote:
>
> I was using DCCP over a very lossy setup (more than 10% losses in each
> direction) and I could not get the kernel to stop in the detect_loss()
> function (using UML and setting breakpoints). I inserted a printk() in
> dccp_li_hist_calc_i_mean() which should be called by all TFRC rate
> calculations, but, according to the logs, this function is not called
> either.
> I would appreciate if someone could check this again, since there
> are people on the list much more familiar with the implementation.
>
> My second question regards the loss intervals used by TFRC. In one of the
> defining documents it is mentioned that a loss interval should be at least
> one measured RTT long, however I could not see where this is implemented
> in the source code. Could someone help me here?
>
Where have you obtained DCCP from and what version are you running?
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* loss detection and tfrc rate
From: h.balan @ 2006-01-23 18:39 UTC (permalink / raw)
To: dccp
I was using DCCP over a very lossy setup (more than 10% losses in each
direction) and I could not get the kernel to stop in the detect_loss()
function (using UML and setting breakpoints). I inserted a printk() in
dccp_li_hist_calc_i_mean() which should be called by all TFRC rate
calculations, but, according to the logs, this function is not called
either.
I would appreciate if someone could check this again, since there
are people on the list much more familiar with the implementation.
My second question regards the loss intervals used by TFRC. In one of the
defining documents it is mentioned that a loss interval should be at least
one measured RTT long, however I could not see where this is implemented
in the source code. Could someone help me here?
Regards,
Vlad Balan
^ permalink raw reply
* printk in net/dccp/ackvec.c
From: Ian McDonald @ 2006-01-17 3:25 UTC (permalink / raw)
To: dccp
Arnaldo,
When tracking down something else I notice that you have some printk's
without priority level (e.g. no KERN_DEBUG).
You may wish to tidy up when working on this next...
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* Re: [PATCH 1/4][DCCP] ackvec: Fix spelling of "throw"
From: David S. Miller @ 2006-01-04 5:14 UTC (permalink / raw)
To: dccp
In-Reply-To: <39e6f6c70601032012v5c4b60bavdf8bdae4d8bb62ef@mail.gmail.com>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Wed, 4 Jan 2006 02:12:32 -0200
> Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.git
All pulled, thanks Arnaldo.
^ permalink raw reply
* [PATCH 4/4][IPVS]: Add missing include <linux/net.h>
From: Arnaldo Carvalho de Melo @ 2006-01-04 4:13 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.git
Best Regards,
- Arnaldo
[-- Attachment #2: 4.patch --]
[-- Type: text/x-patch, Size: 1387 bytes --]
tree 322e5309316ce619cb354c517186b35019026cbc
parent 80e40daa4797a156781d1594642b654eb1c461df
author Arnaldo Carvalho de Melo <acme@mandriva.com> 1136347340 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136347340 -0200
[IPVS]: Add missing include <linux/net.h>
CC [M] net/ipv4/ipvs/ip_vs_conn.o
/pub/scm/linux/kernel/git/acme/net-2.6/net/ipv4/ipvs/ip_vs_conn.c: In
function 'ip_vs_conn_new':
/pub/scm/linux/kernel/git/acme/net-2.6/net/ipv4/ipvs/ip_vs_conn.c:606:
warning: implicit declaration of function 'net_ratelimit'
/pub/scm/linux/kernel/git/acme/net-2.6/net/ipv4/ipvs/ip_vs_conn.c: In
function 'ip_vs_random_dropentry':
/pub/scm/linux/kernel/git/acme/net-2.6/net/ipv4/ipvs/ip_vs_conn.c:810:
warning: implicit declaration of function 'net_random'
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
ip_vs_conn.c | 1 +
1 file changed, 1 insertion(+)
------------------------------------------------------------------------------
diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
index ed5bd56..81d9035 100644
--- a/net/ipv4/ipvs/ip_vs_conn.c
+++ b/net/ipv4/ipvs/ip_vs_conn.c
@@ -25,6 +25,7 @@
*/
#include <linux/in.h>
+#include <linux/net.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/vmalloc.h>
^ permalink raw reply related
* [PATCH 3/4][TCP]: syn_flood_warning is only needed if CONFIG_SYN_COOKIES is selected
From: Arnaldo Carvalho de Melo @ 2006-01-04 4:13 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.git
Best Regards,
- Arnaldo
[-- Attachment #2: 3.patch --]
[-- Type: text/x-patch, Size: 1269 bytes --]
tree 31a9a37e00b690edf3e54d61393e364f203549c3
parent e4dfd449c80a41bb615b23d0fc198ba08360a1f8
author Arnaldo Carvalho de Melo <acme@mandriva.com> 1136347086 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136347086 -0200
[TCP]: syn_flood_warning is only needed if CONFIG_SYN_COOKIES is selected
CC net/ipv4/tcp_ipv4.o
/pub/scm/linux/kernel/git/acme/net-2.6/net/ipv4/tcp_ipv4.c:665: warning:
'syn_flood_warning' defined but not used
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
tcp_ipv4.c | 2 ++
1 file changed, 2 insertions(+)
------------------------------------------------------------------------------
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5c70493..e9f83e5 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -661,6 +661,7 @@ static void tcp_v4_reqsk_destructor(stru
kfree(inet_rsk(req)->opt);
}
+#ifdef CONFIG_SYN_COOKIES
static void syn_flood_warning(struct sk_buff *skb)
{
static unsigned long warntime;
@@ -672,6 +673,7 @@ static void syn_flood_warning(struct sk_
ntohs(skb->h.th->dest));
}
}
+#endif
/*
* Save and compile IPv4 options into the request_sock if needed.
^ permalink raw reply related
* [PATCH 2/4][DCCP] ackvec: use u8 for the buf offsets
From: Arnaldo Carvalho de Melo @ 2006-01-04 4:12 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.git
Best Regards,
- Arnaldo
[-- Attachment #2: 2.patch --]
[-- Type: text/x-patch, Size: 3924 bytes --]
tree cf5ca5bb82cc5e7ef01a368bf6b86029266bc146
parent 6742bbcbb8a0959e1dff0ce055768e3217d9967a
author Arnaldo Carvalho de Melo <acme@mandriva.com> 1136346394 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136346394 -0200
[DCCP] ackvec: use u8 for the buf offsets
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
ackvec.c | 27 +++++++++++++++++----------
ackvec.h | 12 ++++++------
2 files changed, 23 insertions(+), 16 deletions(-)
------------------------------------------------------------------------------
diff --git a/net/dccp/ackvec.c b/net/dccp/ackvec.c
index a979f4e..ce9cb77 100644
--- a/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -55,8 +55,8 @@ int dccp_insert_option_ackvec(struct soc
from = av->dccpav_buf + av->dccpav_buf_head;
/* Check if buf_head wraps */
- if (av->dccpav_buf_head + len > av->dccpav_vec_len) {
- const u32 tailsize = (av->dccpav_vec_len - av->dccpav_buf_head);
+ if ((int)av->dccpav_buf_head + len > av->dccpav_vec_len) {
+ const u32 tailsize = av->dccpav_vec_len - av->dccpav_buf_head;
memcpy(to, from, tailsize);
to += tailsize;
@@ -93,8 +93,14 @@ int dccp_insert_option_ackvec(struct soc
struct dccp_ackvec *dccp_ackvec_alloc(const unsigned int len,
const gfp_t priority)
{
- struct dccp_ackvec *av = kmalloc(sizeof(*av) + len, priority);
+ struct dccp_ackvec *av;
+ BUG_ON(len == 0);
+
+ if (len > DCCP_MAX_ACKVEC_LEN)
+ return NULL;
+
+ av = kmalloc(sizeof(*av) + len, priority);
if (av != NULL) {
av->dccpav_buf_len = len;
av->dccpav_buf_head =
@@ -117,13 +123,13 @@ void dccp_ackvec_free(struct dccp_ackvec
}
static inline u8 dccp_ackvec_state(const struct dccp_ackvec *av,
- const unsigned int index)
+ const u8 index)
{
return av->dccpav_buf[index] & DCCP_ACKVEC_STATE_MASK;
}
static inline u8 dccp_ackvec_len(const struct dccp_ackvec *av,
- const unsigned int index)
+ const u8 index)
{
return av->dccpav_buf[index] & DCCP_ACKVEC_LEN_MASK;
}
@@ -135,7 +141,7 @@ static inline u8 dccp_ackvec_len(const s
*/
static inline int dccp_ackvec_set_buf_head_state(struct dccp_ackvec *av,
const unsigned int packets,
- const unsigned char state)
+ const unsigned char state)
{
unsigned int gap;
signed long new_head;
@@ -223,7 +229,7 @@ int dccp_ackvec_add(struct dccp_ackvec *
* could reduce the complexity of this scan.)
*/
u64 delta = dccp_delta_seqno(ackno, av->dccpav_buf_ackno);
- unsigned int index = av->dccpav_buf_head;
+ u8 index = av->dccpav_buf_head;
while (1) {
const u8 len = dccp_ackvec_len(av, index);
@@ -301,9 +307,10 @@ static void dccp_ackvec_throw_away_ack_r
* draft-ietf-dccp-spec-11.txt Appendix A. -acme
*/
#if 0
- av->dccpav_buf_tail = av->dccpav_ack_ptr + 1;
- if (av->dccpav_buf_tail >= av->dccpav_vec_len)
- av->dccpav_buf_tail -= av->dccpav_vec_len;
+ u32 new_buf_tail = av->dccpav_ack_ptr + 1;
+ if (new_buf_tail >= av->dccpav_vec_len)
+ new_buf_tail -= av->dccpav_vec_len;
+ av->dccpav_buf_tail = new_buf_tail;
#endif
av->dccpav_vec_len -= av->dccpav_sent_len;
}
diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h
index d0fd6c6..f7dfb5f 100644
--- a/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -54,16 +54,16 @@
* @dccpav_buf - circular buffer of acknowledgeable packets
*/
struct dccp_ackvec {
- unsigned int dccpav_buf_head;
- unsigned int dccpav_buf_tail;
u64 dccpav_buf_ackno;
u64 dccpav_ack_seqno;
u64 dccpav_ack_ackno;
- unsigned int dccpav_ack_ptr;
- unsigned int dccpav_sent_len;
- unsigned int dccpav_vec_len;
- unsigned int dccpav_buf_len;
struct timeval dccpav_time;
+ u8 dccpav_buf_head;
+ u8 dccpav_buf_tail;
+ u8 dccpav_ack_ptr;
+ u8 dccpav_sent_len;
+ u8 dccpav_vec_len;
+ u8 dccpav_buf_len;
u8 dccpav_buf_nonce;
u8 dccpav_ack_nonce;
u8 dccpav_buf[0];
^ permalink raw reply related
* [PATCH 1/4][DCCP] ackvec: Fix spelling of "throw"
From: Arnaldo Carvalho de Melo @ 2006-01-04 4:12 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.git
Best Regards,
- Arnaldo
[-- Attachment #2: 1.patch --]
[-- Type: text/x-patch, Size: 1691 bytes --]
tree 999897434bf2f6e7ad905f28949bed30ae76e279
parent 40efc6fa179f440a008333ea98f701bc35a1f97f
author Andrea Bittau <a.bittau@cs.ucl.ac.uk> 1136346317 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136346317 -0200
[DCCP] ackvec: Fix spelling of "throw"
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
ackvec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
------------------------------------------------------------------------------
diff --git a/net/dccp/ackvec.c b/net/dccp/ackvec.c
index c9a62cc..a979f4e 100644
--- a/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -291,7 +291,7 @@ void dccp_ackvec_print(const struct dccp
}
#endif
-static void dccp_ackvec_trow_away_ack_record(struct dccp_ackvec *av)
+static void dccp_ackvec_throw_away_ack_record(struct dccp_ackvec *av)
{
/*
* As we're keeping track of the ack vector size (dccpav_vec_len) and
@@ -326,7 +326,7 @@ void dccp_ackvec_check_rcv_ackno(struct
debug_prefix, 1,
(unsigned long long)av->dccpav_ack_seqno,
(unsigned long long)av->dccpav_ack_ackno);
- dccp_ackvec_trow_away_ack_record(av);
+ dccp_ackvec_throw_away_ack_record(av);
av->dccpav_ack_seqno = DCCP_MAX_SEQNO + 1;
}
}
@@ -389,7 +389,7 @@ static void dccp_ackvec_check_rcv_ackvec
av->dccpav_ack_seqno,
(unsigned long long)
av->dccpav_ack_ackno);
- dccp_ackvec_trow_away_ack_record(av);
+ dccp_ackvec_throw_away_ack_record(av);
}
/*
* If dccpav_ack_seqno was not received, no problem
^ permalink raw reply related
* Re: [PATCH 1/3][DCCP]: Do not process a packet twice when it's
From: David S. Miller @ 2006-01-03 22:28 UTC (permalink / raw)
To: dccp
In-Reply-To: <39e6f6c70601020853u6c5345e5oae495bc3fa42c020@mail.gmail.com>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Mon, 2 Jan 2006 14:53:56 -0200
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.16.git
All 3 patches applied manually to the newly rebased net-2.6
tree at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
After going through the rest of today's patch queue I'll push
that to Linus.
Thanks.
^ permalink raw reply
* [PATCH 3/3][DCCP]: Notify CCID only after ACK vectors have been processed
From: Arnaldo Carvalho de Melo @ 2006-01-02 16:54 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.16.git
Best Regards,
- Arnaldo
[-- Attachment #2: 3.patch --]
[-- Type: text/x-patch, Size: 1586 bytes --]
tree 0ea2fae5f2e089c5c491869a12543c6791d10da1
parent 7d96f7a6a44a53029fb4d8540ce223e622527798
author Andrea Bittau <a.bittau@cs.ucl.ac.uk> 1136217403 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136217403 -0200
[DCCP]: Notify CCID only after ACK vectors have been processed.
The CCID should be notified of packet reception only when a packet is valid.
Therefore, the ACK vector needs to be processed before notifying the CCID.
Also, the CCID might need information provided by the ACK vector.
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
input.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
------------------------------------------------------------------------------
diff --git a/net/dccp/input.c b/net/dccp/input.c
index cb0f5c9..b6cba72 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -492,14 +492,14 @@ int dccp_rcv_state_process(struct sock *
if (dcb->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
dccp_event_ack_recv(sk, skb);
- ccid_hc_rx_packet_recv(dp->dccps_hc_rx_ccid, sk, skb);
- ccid_hc_tx_packet_recv(dp->dccps_hc_tx_ccid, sk, skb);
-
if (dp->dccps_options.dccpo_send_ack_vector &&
dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,
DCCP_SKB_CB(skb)->dccpd_seq,
DCCP_ACKVEC_STATE_RECEIVED))
goto discard;
+
+ ccid_hc_rx_packet_recv(dp->dccps_hc_rx_ccid, sk, skb);
+ ccid_hc_tx_packet_recv(dp->dccps_hc_tx_ccid, sk, skb);
}
/*
^ permalink raw reply related
* [PATCH 2/3][DCCP]: Send an ACK vector when ACKing a response packet
From: Arnaldo Carvalho de Melo @ 2006-01-02 16:54 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.16.git
Best Regards,
- Arnaldo
[-- Attachment #2: 2.patch --]
[-- Type: text/x-patch, Size: 1537 bytes --]
tree ea024a03f12dad7a2074f71afd2b3148347323f0
parent caf2e7480ba587b7cb6902e1bfcd6832dfd393bf
author Andrea Bittau <a.bittau@cs.ucl.ac.uk> 1136217289 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136217289 -0200
[DCCP]: Send an ACK vector when ACKing a response packet
If ACK vectors are used, each packet with an ACK should contain an ACK vector.
The only exception currently is response packets. It probably is not a good
idea to store ACK vector state before the connection is completed (to help
protect from syn floods).
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
input.c | 6 ++++++
1 file changed, 6 insertions(+)
------------------------------------------------------------------------------
diff --git a/net/dccp/input.c b/net/dccp/input.c
index 5e312b0..cb0f5c9 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -300,6 +300,12 @@ static int dccp_rcv_request_sent_state_p
goto out_invalid_packet;
}
+ if (dp->dccps_options.dccpo_send_ack_vector &&
+ dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,
+ DCCP_SKB_CB(skb)->dccpd_seq,
+ DCCP_ACKVEC_STATE_RECEIVED))
+ goto out_invalid_packet; /* FIXME: change error code */
+
dp->dccps_isr = DCCP_SKB_CB(skb)->dccpd_seq;
dccp_update_gsr(sk, dp->dccps_isr);
/*
^ permalink raw reply related
* [PATCH 1/3][DCCP]: Do not process a packet twice when it's received in a state != DCCP_OPEN
From: Arnaldo Carvalho de Melo @ 2006-01-02 16:53 UTC (permalink / raw)
To: dccp
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.16.git
Best Regards,
- Arnaldo
[-- Attachment #2: 1.patch --]
[-- Type: text/x-patch, Size: 4063 bytes --]
tree 66fbefd8cb4805458e537a3ea143006f8f242d8c
parent a90860f526898b77e91b6b38e8d266b0bcd6c443
author Arnaldo Carvalho de Melo <acme@mandriva.com> 1136217256 -0200
committer Arnaldo Carvalho de Melo <acme@mandriva.com> 1136217256 -0200
[DCCP]: Do not process a packet twice when it's received in a state != DCCP_OPEN.
When packets are received, the connection is either in DCCP_OPEN [fast-path] or
it isn't. If it's not [e.g. DCCP_PARTOPEN] upper layers will perform sanity
checks and parse options. If it is in DCCP_OPEN, dccp_rcv_established() will do
it. It is important not to re-parse options in dccp_rcv_established() when it
is not called from the fast-path. Else, fore example, the ack vector will be
added twice and the CCID will see the packet twice.
The solution is to always enfore sanity checks from the upper layers. When
packets arrive in the fast-path, sanity checks will be performed before calling
dccp_rcv_established().
Note(acme): I rewrote the patch to achieve the same result but keeping
dccp_rcv_established with the previous semantics and having it split into
__dccp_rcv_established, that doesn't does do any sanity check, code in state
!= DCCP_OPEN use this lighter version as they already do the sanity checks.
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
------------------------------------------------------------------------------
input.c | 56 ++++++++++++++++++++++++++++++++++----------------------
1 file changed, 34 insertions(+), 22 deletions(-)
------------------------------------------------------------------------------
diff --git a/net/dccp/input.c b/net/dccp/input.c
index 55e921b..5e312b0 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -151,29 +151,12 @@ static int dccp_check_seqno(struct sock
return 0;
}
-int dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
- const struct dccp_hdr *dh, const unsigned len)
+static inline int __dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
+ const struct dccp_hdr *dh,
+ const unsigned len)
{
struct dccp_sock *dp = dccp_sk(sk);
- if (dccp_check_seqno(sk, skb))
- goto discard;
-
- if (dccp_parse_options(sk, skb))
- goto discard;
-
- if (DCCP_SKB_CB(skb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
- dccp_event_ack_recv(sk, skb);
-
- if (dp->dccps_options.dccpo_send_ack_vector &&
- dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,
- DCCP_SKB_CB(skb)->dccpd_seq,
- DCCP_ACKVEC_STATE_RECEIVED))
- goto discard;
-
- ccid_hc_rx_packet_recv(dp->dccps_hc_rx_ccid, sk, skb);
- ccid_hc_tx_packet_recv(dp->dccps_hc_tx_ccid, sk, skb);
-
switch (dccp_hdr(skb)->dccph_type) {
case DCCP_PKT_DATAACK:
case DCCP_PKT_DATA:
@@ -250,6 +233,35 @@ discard:
return 0;
}
+int dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
+ const struct dccp_hdr *dh, const unsigned len)
+{
+ struct dccp_sock *dp = dccp_sk(sk);
+
+ if (dccp_check_seqno(sk, skb))
+ goto discard;
+
+ if (dccp_parse_options(sk, skb))
+ goto discard;
+
+ if (DCCP_SKB_CB(skb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
+ dccp_event_ack_recv(sk, skb);
+
+ if (dp->dccps_options.dccpo_send_ack_vector &&
+ dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,
+ DCCP_SKB_CB(skb)->dccpd_seq,
+ DCCP_ACKVEC_STATE_RECEIVED))
+ goto discard;
+
+ ccid_hc_rx_packet_recv(dp->dccps_hc_rx_ccid, sk, skb);
+ ccid_hc_tx_packet_recv(dp->dccps_hc_tx_ccid, sk, skb);
+
+ return __dccp_rcv_established(sk, skb, dh, len);
+discard:
+ __kfree_skb(skb);
+ return 0;
+}
+
EXPORT_SYMBOL_GPL(dccp_rcv_established);
static int dccp_rcv_request_sent_state_process(struct sock *sk,
@@ -400,9 +412,9 @@ static int dccp_rcv_respond_partopen_sta
if (dh->dccph_type == DCCP_PKT_DATAACK ||
dh->dccph_type == DCCP_PKT_DATA) {
- dccp_rcv_established(sk, skb, dh, len);
+ __dccp_rcv_established(sk, skb, dh, len);
queued = 1; /* packet was queued
- (by dccp_rcv_established) */
+ (by __dccp_rcv_established) */
}
break;
}
^ permalink raw reply related
* Re: [PATCH] DCCP: Typo
From: David S. Miller @ 2005-12-22 3:02 UTC (permalink / raw)
To: dccp
In-Reply-To: <cbec11ac0512201507p168d332bl8e23a2ade30935d0@mail.gmail.com>
From: Ian McDonald <imcdnzl@gmail.com>
Date: Wed, 21 Dec 2005 12:07:30 +1300
> Please apply to net-2.6 for 2.6.15 tree.
>
> I hope to actually change this behaviour shortly but this will help
> anybody grepping code at present.
>
> Signed-off-by: Ian McDonald <imcdnzl@gmail.com>
Applied, thanks Ian.
^ 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