2019-05-27 14:55:01 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-08-10 11:14:34 +08:00
|
|
|
/*
|
|
|
|
* net/dccp/output.c
|
2006-12-11 02:01:18 +08:00
|
|
|
*
|
2005-08-10 11:14:34 +08:00
|
|
|
* An implementation of the DCCP protocol
|
|
|
|
* Arnaldo Carvalho de Melo <acme@conectiva.com.br>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/dccp.h>
|
2005-10-30 08:20:59 +08:00
|
|
|
#include <linux/kernel.h>
|
2005-08-10 11:14:34 +08:00
|
|
|
#include <linux/skbuff.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2017-02-03 02:15:33 +08:00
|
|
|
#include <linux/sched/signal.h>
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2005-12-27 12:43:12 +08:00
|
|
|
#include <net/inet_sock.h>
|
2005-08-10 11:14:34 +08:00
|
|
|
#include <net/sock.h>
|
|
|
|
|
2005-09-18 15:17:51 +08:00
|
|
|
#include "ackvec.h"
|
2005-08-10 11:14:34 +08:00
|
|
|
#include "ccid.h"
|
|
|
|
#include "dccp.h"
|
|
|
|
|
|
|
|
static inline void dccp_event_ack_sent(struct sock *sk)
|
|
|
|
{
|
|
|
|
inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
|
|
|
|
}
|
|
|
|
|
2011-07-03 23:51:29 +08:00
|
|
|
/* enqueue @skb on sk_send_head for retransmission, return clone to send now */
|
|
|
|
static struct sk_buff *dccp_skb_entail(struct sock *sk, struct sk_buff *skb)
|
2005-10-30 08:20:59 +08:00
|
|
|
{
|
|
|
|
skb_set_owner_w(skb, sk);
|
|
|
|
WARN_ON(sk->sk_send_head);
|
|
|
|
sk->sk_send_head = skb;
|
2011-07-03 23:51:29 +08:00
|
|
|
return skb_clone(sk->sk_send_head, gfp_any());
|
2005-10-30 08:20:59 +08:00
|
|
|
}
|
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
/*
|
|
|
|
* All SKB's seen here are completely headerless. It is our
|
|
|
|
* job to build the DCCP header, and pass the packet down to
|
|
|
|
* IP so it can do the same plus pass the packet off to the
|
|
|
|
* device.
|
|
|
|
*/
|
2005-10-30 08:20:59 +08:00
|
|
|
static int dccp_transmit_skb(struct sock *sk, struct sk_buff *skb)
|
2005-08-10 11:14:34 +08:00
|
|
|
{
|
|
|
|
if (likely(skb != NULL)) {
|
2011-05-07 13:23:20 +08:00
|
|
|
struct inet_sock *inet = inet_sk(sk);
|
2005-12-14 15:16:16 +08:00
|
|
|
const struct inet_connection_sock *icsk = inet_csk(sk);
|
2005-08-10 11:14:34 +08:00
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
struct dccp_skb_cb *dcb = DCCP_SKB_CB(skb);
|
|
|
|
struct dccp_hdr *dh;
|
|
|
|
/* XXX For now we're using only 48 bits sequence numbers */
|
2006-03-21 14:31:09 +08:00
|
|
|
const u32 dccp_header_size = sizeof(*dh) +
|
2005-08-10 11:14:34 +08:00
|
|
|
sizeof(struct dccp_hdr_ext) +
|
2005-08-14 07:34:54 +08:00
|
|
|
dccp_packet_hdr_len(dcb->dccpd_type);
|
2005-08-10 11:14:34 +08:00
|
|
|
int err, set_ack = 1;
|
|
|
|
u64 ackno = dp->dccps_gsr;
|
dccp: Bug-Fix - AWL was never updated
The AWL lower Ack validity window advances in proportion to GSS, the greatest
sequence number sent. Updating AWL other than at connection setup (in the
DCCP-Request sent by dccp_v{4,6}_connect()) was missing in the DCCP code.
This bug lead to syslog messages such as
"kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...]
P.ackno exists or LAWL(82947089) <= P.ackno(82948208)
<= S.AWH(82948728), sending SYNC..."
The difference between AWL/AWH here is 1639 packets, while the expected value
(the Sequence Window) would have been 100 (the default). A closer look showed
that LAWL = AWL = 82947089 equalled the ISS on the Response.
The patch now updates AWL with each increase of GSS.
Further changes:
----------------
The patch also enforces more stringent checks on the ISS sequence number:
* AWL is initialised to ISS at connection setup and remains at this value;
* AWH is then always set to GSS (via dccp_update_gss());
* so on the first Request: AWL = AWH = ISS,
and on the n-th Request: AWL = ISS, AWH = ISS + n.
As a consequence, only Response packets that refer to Requests sent by this
host will pass, all others are discarded. This is the intention and in effect
implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-07-26 18:59:10 +08:00
|
|
|
/*
|
|
|
|
* Increment GSS here already in case the option code needs it.
|
|
|
|
* Update GSS for real only if option processing below succeeds.
|
|
|
|
*/
|
|
|
|
dcb->dccpd_seq = ADD48(dp->dccps_gss, 1);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
switch (dcb->dccpd_type) {
|
|
|
|
case DCCP_PKT_DATA:
|
|
|
|
set_ack = 0;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2005-10-30 08:20:59 +08:00
|
|
|
case DCCP_PKT_DATAACK:
|
2007-09-26 22:30:02 +08:00
|
|
|
case DCCP_PKT_RESET:
|
2005-08-10 11:14:34 +08:00
|
|
|
break;
|
2005-10-30 08:20:59 +08:00
|
|
|
|
[DCCP]: Initial feature negotiation implementation
Still needs more work, but boots and doesn't crashes, even
does some negotiation!
18:38:52.174934 127.0.0.1.43458 > 127.0.0.1.5001: request <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-21 09:43:56 +08:00
|
|
|
case DCCP_PKT_REQUEST:
|
|
|
|
set_ack = 0;
|
dccp: Bug-Fix - AWL was never updated
The AWL lower Ack validity window advances in proportion to GSS, the greatest
sequence number sent. Updating AWL other than at connection setup (in the
DCCP-Request sent by dccp_v{4,6}_connect()) was missing in the DCCP code.
This bug lead to syslog messages such as
"kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...]
P.ackno exists or LAWL(82947089) <= P.ackno(82948208)
<= S.AWH(82948728), sending SYNC..."
The difference between AWL/AWH here is 1639 packets, while the expected value
(the Sequence Window) would have been 100 (the default). A closer look showed
that LAWL = AWL = 82947089 equalled the ISS on the Response.
The patch now updates AWL with each increase of GSS.
Further changes:
----------------
The patch also enforces more stringent checks on the ISS sequence number:
* AWL is initialised to ISS at connection setup and remains at this value;
* AWH is then always set to GSS (via dccp_update_gss());
* so on the first Request: AWL = AWH = ISS,
and on the n-th Request: AWL = ISS, AWH = ISS + n.
As a consequence, only Response packets that refer to Requests sent by this
host will pass, all others are discarded. This is the intention and in effect
implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-07-26 18:59:10 +08:00
|
|
|
/* Use ISS on the first (non-retransmitted) Request. */
|
|
|
|
if (icsk->icsk_retransmits == 0)
|
|
|
|
dcb->dccpd_seq = dp->dccps_iss;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
[DCCP]: Initial feature negotiation implementation
Still needs more work, but boots and doesn't crashes, even
does some negotiation!
18:38:52.174934 127.0.0.1.43458 > 127.0.0.1.5001: request <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-21 09:43:56 +08:00
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
case DCCP_PKT_SYNC:
|
|
|
|
case DCCP_PKT_SYNCACK:
|
2007-09-26 13:42:27 +08:00
|
|
|
ackno = dcb->dccpd_ack_seq;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2005-10-30 08:20:59 +08:00
|
|
|
default:
|
|
|
|
/*
|
2007-09-26 22:30:02 +08:00
|
|
|
* Set owner/destructor: some skbs are allocated via
|
|
|
|
* alloc_skb (e.g. when retransmission may happen).
|
|
|
|
* Only Data, DataAck, and Reset packets should come
|
|
|
|
* through here with skb->sk set.
|
2005-10-30 08:20:59 +08:00
|
|
|
*/
|
|
|
|
WARN_ON(skb->sk);
|
|
|
|
skb_set_owner_w(skb, sk);
|
2005-08-10 11:14:34 +08:00
|
|
|
break;
|
|
|
|
}
|
2005-08-21 16:40:16 +08:00
|
|
|
|
2006-03-21 14:32:06 +08:00
|
|
|
if (dccp_insert_options(sk, skb)) {
|
|
|
|
kfree_skb(skb);
|
|
|
|
return -EPROTO;
|
|
|
|
}
|
2007-02-09 22:24:38 +08:00
|
|
|
|
2005-10-14 14:38:49 +08:00
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
/* Build DCCP header and checksum it. */
|
2006-11-10 21:22:32 +08:00
|
|
|
dh = dccp_zeroed_hdr(skb, dccp_header_size);
|
2005-08-10 11:14:34 +08:00
|
|
|
dh->dccph_type = dcb->dccpd_type;
|
2009-10-15 14:30:45 +08:00
|
|
|
dh->dccph_sport = inet->inet_sport;
|
|
|
|
dh->dccph_dport = inet->inet_dport;
|
2005-08-10 11:14:34 +08:00
|
|
|
dh->dccph_doff = (dccp_header_size + dcb->dccpd_opt_len) / 4;
|
|
|
|
dh->dccph_ccval = dcb->dccpd_ccval;
|
2006-11-11 03:43:06 +08:00
|
|
|
dh->dccph_cscov = dp->dccps_pcslen;
|
2005-08-10 11:14:34 +08:00
|
|
|
/* XXX For now we're using only 48 bits sequence numbers */
|
|
|
|
dh->dccph_x = 1;
|
|
|
|
|
dccp: Bug-Fix - AWL was never updated
The AWL lower Ack validity window advances in proportion to GSS, the greatest
sequence number sent. Updating AWL other than at connection setup (in the
DCCP-Request sent by dccp_v{4,6}_connect()) was missing in the DCCP code.
This bug lead to syslog messages such as
"kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...]
P.ackno exists or LAWL(82947089) <= P.ackno(82948208)
<= S.AWH(82948728), sending SYNC..."
The difference between AWL/AWH here is 1639 packets, while the expected value
(the Sequence Window) would have been 100 (the default). A closer look showed
that LAWL = AWL = 82947089 equalled the ISS on the Response.
The patch now updates AWL with each increase of GSS.
Further changes:
----------------
The patch also enforces more stringent checks on the ISS sequence number:
* AWL is initialised to ISS at connection setup and remains at this value;
* AWH is then always set to GSS (via dccp_update_gss());
* so on the first Request: AWL = AWH = ISS,
and on the n-th Request: AWL = ISS, AWH = ISS + n.
As a consequence, only Response packets that refer to Requests sent by this
host will pass, all others are discarded. This is the intention and in effect
implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-07-26 18:59:10 +08:00
|
|
|
dccp_update_gss(sk, dcb->dccpd_seq);
|
2005-08-10 11:14:34 +08:00
|
|
|
dccp_hdr_set_seq(dh, dp->dccps_gss);
|
|
|
|
if (set_ack)
|
|
|
|
dccp_hdr_set_ack(dccp_hdr_ack_bits(skb), ackno);
|
|
|
|
|
|
|
|
switch (dcb->dccpd_type) {
|
|
|
|
case DCCP_PKT_REQUEST:
|
2005-08-14 07:34:54 +08:00
|
|
|
dccp_hdr_request(skb)->dccph_req_service =
|
2005-09-17 07:58:40 +08:00
|
|
|
dp->dccps_service;
|
dccp: Bug-Fix - AWL was never updated
The AWL lower Ack validity window advances in proportion to GSS, the greatest
sequence number sent. Updating AWL other than at connection setup (in the
DCCP-Request sent by dccp_v{4,6}_connect()) was missing in the DCCP code.
This bug lead to syslog messages such as
"kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...]
P.ackno exists or LAWL(82947089) <= P.ackno(82948208)
<= S.AWH(82948728), sending SYNC..."
The difference between AWL/AWH here is 1639 packets, while the expected value
(the Sequence Window) would have been 100 (the default). A closer look showed
that LAWL = AWL = 82947089 equalled the ISS on the Response.
The patch now updates AWL with each increase of GSS.
Further changes:
----------------
The patch also enforces more stringent checks on the ISS sequence number:
* AWL is initialised to ISS at connection setup and remains at this value;
* AWH is then always set to GSS (via dccp_update_gss());
* so on the first Request: AWL = AWH = ISS,
and on the n-th Request: AWL = ISS, AWH = ISS + n.
As a consequence, only Response packets that refer to Requests sent by this
host will pass, all others are discarded. This is the intention and in effect
implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-07-26 18:59:10 +08:00
|
|
|
/*
|
|
|
|
* Limit Ack window to ISS <= P.ackno <= GSS, so that
|
|
|
|
* only Responses to Requests we sent are considered.
|
|
|
|
*/
|
|
|
|
dp->dccps_awl = dp->dccps_iss;
|
2005-08-10 11:14:34 +08:00
|
|
|
break;
|
|
|
|
case DCCP_PKT_RESET:
|
2005-08-14 07:34:54 +08:00
|
|
|
dccp_hdr_reset(skb)->dccph_reset_code =
|
|
|
|
dcb->dccpd_reset_code;
|
2005-08-10 11:14:34 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2010-04-11 10:15:55 +08:00
|
|
|
icsk->icsk_af_ops->send_check(sk, skb);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2005-08-24 12:50:06 +08:00
|
|
|
if (set_ack)
|
2005-08-10 11:14:34 +08:00
|
|
|
dccp_event_ack_sent(sk);
|
|
|
|
|
|
|
|
DCCP_INC_STATS(DCCP_MIB_OUTSEGS);
|
|
|
|
|
2014-04-16 00:58:34 +08:00
|
|
|
err = icsk->icsk_af_ops->queue_xmit(sk, skb, &inet->cork.fl);
|
2006-11-14 21:21:36 +08:00
|
|
|
return net_xmit_eval(err);
|
2005-08-10 11:14:34 +08:00
|
|
|
}
|
|
|
|
return -ENOBUFS;
|
|
|
|
}
|
|
|
|
|
2007-12-14 09:37:55 +08:00
|
|
|
/**
|
2011-03-31 09:57:33 +08:00
|
|
|
* dccp_determine_ccmps - Find out about CCID-specific packet-size limits
|
2020-10-28 09:14:12 +08:00
|
|
|
* @dp: socket to find packet size limits of
|
|
|
|
*
|
2007-12-14 09:37:55 +08:00
|
|
|
* We only consider the HC-sender CCID for setting the CCMPS (RFC 4340, 14.),
|
|
|
|
* since the RX CCID is restricted to feedback packets (Acks), which are small
|
|
|
|
* in comparison with the data traffic. A value of 0 means "no current CCMPS".
|
|
|
|
*/
|
|
|
|
static u32 dccp_determine_ccmps(const struct dccp_sock *dp)
|
|
|
|
{
|
|
|
|
const struct ccid *tx_ccid = dp->dccps_hc_tx_ccid;
|
|
|
|
|
|
|
|
if (tx_ccid == NULL || tx_ccid->ccid_ops == NULL)
|
|
|
|
return 0;
|
|
|
|
return tx_ccid->ccid_ops->ccid_ccmps;
|
|
|
|
}
|
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
unsigned int dccp_sync_mss(struct sock *sk, u32 pmtu)
|
|
|
|
{
|
2005-12-14 15:26:10 +08:00
|
|
|
struct inet_connection_sock *icsk = inet_csk(sk);
|
2005-08-10 11:14:34 +08:00
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
2007-12-14 09:37:55 +08:00
|
|
|
u32 ccmps = dccp_determine_ccmps(dp);
|
2009-02-28 06:38:28 +08:00
|
|
|
u32 cur_mps = ccmps ? min(pmtu, ccmps) : pmtu;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2007-12-14 09:37:55 +08:00
|
|
|
/* Account for header lengths and IPv4/v6 option overhead */
|
|
|
|
cur_mps -= (icsk->icsk_af_ops->net_header_len + icsk->icsk_ext_hdr_len +
|
|
|
|
sizeof(struct dccp_hdr) + sizeof(struct dccp_hdr_ext));
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
/*
|
2009-02-28 06:38:28 +08:00
|
|
|
* Leave enough headroom for common DCCP header options.
|
|
|
|
* This only considers options which may appear on DCCP-Data packets, as
|
|
|
|
* per table 3 in RFC 4340, 5.8. When running out of space for other
|
|
|
|
* options (eg. Ack Vector which can take up to 255 bytes), it is better
|
|
|
|
* to schedule a separate Ack. Thus we leave headroom for the following:
|
|
|
|
* - 1 byte for Slow Receiver (11.6)
|
|
|
|
* - 6 bytes for Timestamp (13.1)
|
|
|
|
* - 10 bytes for Timestamp Echo (13.3)
|
|
|
|
* - 8 bytes for NDP count (7.7, when activated)
|
|
|
|
* - 6 bytes for Data Checksum (9.3)
|
|
|
|
* - %DCCPAV_MIN_OPTLEN bytes for Ack Vector size (11.4, when enabled)
|
2005-08-10 11:14:34 +08:00
|
|
|
*/
|
2009-02-28 06:38:28 +08:00
|
|
|
cur_mps -= roundup(1 + 6 + 10 + dp->dccps_send_ndp_count * 8 + 6 +
|
|
|
|
(dp->dccps_hc_rx_ackvec ? DCCPAV_MIN_OPTLEN : 0), 4);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
/* And store cached results */
|
2005-12-14 15:26:10 +08:00
|
|
|
icsk->icsk_pmtu_cookie = pmtu;
|
2007-12-14 09:37:55 +08:00
|
|
|
dp->dccps_mss_cache = cur_mps;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2007-12-14 09:37:55 +08:00
|
|
|
return cur_mps;
|
2005-08-10 11:14:34 +08:00
|
|
|
}
|
|
|
|
|
2005-12-14 15:24:16 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dccp_sync_mss);
|
|
|
|
|
2005-08-29 13:15:54 +08:00
|
|
|
void dccp_write_space(struct sock *sk)
|
|
|
|
{
|
2010-04-29 19:01:49 +08:00
|
|
|
struct socket_wq *wq;
|
2005-08-29 13:15:54 +08:00
|
|
|
|
2010-04-29 19:01:49 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
wq = rcu_dereference(sk->sk_wq);
|
2015-11-26 13:55:39 +08:00
|
|
|
if (skwq_has_sleeper(wq))
|
2010-04-29 19:01:49 +08:00
|
|
|
wake_up_interruptible(&wq->wait);
|
2005-08-29 13:15:54 +08:00
|
|
|
/* Should agree with poll, otherwise some programs break */
|
|
|
|
if (sock_writeable(sk))
|
2007-11-26 20:10:50 +08:00
|
|
|
sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
|
2005-08-29 13:15:54 +08:00
|
|
|
|
2010-04-29 19:01:49 +08:00
|
|
|
rcu_read_unlock();
|
2005-08-29 13:15:54 +08:00
|
|
|
}
|
|
|
|
|
2005-08-27 14:06:35 +08:00
|
|
|
/**
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
* dccp_wait_for_ccid - Await CCID send permission
|
2007-10-05 05:38:49 +08:00
|
|
|
* @sk: socket to wait for
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
* @delay: timeout in jiffies
|
2012-07-10 18:55:09 +08:00
|
|
|
*
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
* This is used by CCIDs which need to delay the send time in process context.
|
2005-08-27 14:06:35 +08:00
|
|
|
*/
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
static int dccp_wait_for_ccid(struct sock *sk, unsigned long delay)
|
2005-08-27 14:06:35 +08:00
|
|
|
{
|
|
|
|
DEFINE_WAIT(wait);
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
long remaining;
|
2005-08-27 14:06:35 +08:00
|
|
|
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
|
|
|
|
sk->sk_write_pending++;
|
|
|
|
release_sock(sk);
|
2007-10-05 05:38:49 +08:00
|
|
|
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
remaining = schedule_timeout(delay);
|
2005-08-27 14:06:35 +08:00
|
|
|
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
lock_sock(sk);
|
|
|
|
sk->sk_write_pending--;
|
2010-04-20 21:03:51 +08:00
|
|
|
finish_wait(sk_sleep(sk), &wait);
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
|
|
|
|
if (signal_pending(current) || sk->sk_err)
|
|
|
|
return -1;
|
|
|
|
return remaining;
|
2005-08-27 14:06:35 +08:00
|
|
|
}
|
|
|
|
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
/**
|
|
|
|
* dccp_xmit_packet - Send data packet under control of CCID
|
2020-10-28 09:14:12 +08:00
|
|
|
* @sk: socket to send data packet on
|
|
|
|
*
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
* Transmits next-queued payload and informs CCID to account for the packet.
|
|
|
|
*/
|
|
|
|
static void dccp_xmit_packet(struct sock *sk)
|
|
|
|
{
|
|
|
|
int err, len;
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
2010-12-04 20:38:01 +08:00
|
|
|
struct sk_buff *skb = dccp_qpolicy_pop(sk);
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
|
|
|
|
if (unlikely(skb == NULL))
|
|
|
|
return;
|
|
|
|
len = skb->len;
|
|
|
|
|
|
|
|
if (sk->sk_state == DCCP_PARTOPEN) {
|
|
|
|
const u32 cur_mps = dp->dccps_mss_cache - DCCP_FEATNEG_OVERHEAD;
|
|
|
|
/*
|
|
|
|
* See 8.1.5 - Handshake Completion.
|
|
|
|
*
|
|
|
|
* For robustness we resend Confirm options until the client has
|
|
|
|
* entered OPEN. During the initial feature negotiation, the MPS
|
|
|
|
* is smaller than usual, reduced by the Change/Confirm options.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&dp->dccps_featneg) && len > cur_mps) {
|
|
|
|
DCCP_WARN("Payload too large (%d) for featneg.\n", len);
|
|
|
|
dccp_send_ack(sk);
|
|
|
|
dccp_feat_list_purge(&dp->dccps_featneg);
|
|
|
|
}
|
|
|
|
|
|
|
|
inet_csk_schedule_ack(sk);
|
|
|
|
inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
|
|
|
|
inet_csk(sk)->icsk_rto,
|
|
|
|
DCCP_RTO_MAX);
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATAACK;
|
|
|
|
} else if (dccp_ack_pending(sk)) {
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATAACK;
|
|
|
|
} else {
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATA;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = dccp_transmit_skb(sk, skb);
|
|
|
|
if (err)
|
|
|
|
dccp_pr_debug("transmit_skb() returned err=%d\n", err);
|
|
|
|
/*
|
|
|
|
* Register this one as sent even if an error occurred. To the remote
|
|
|
|
* end a local packet drop is indistinguishable from network loss, i.e.
|
|
|
|
* any local drop will eventually be reported via receiver feedback.
|
|
|
|
*/
|
|
|
|
ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, len);
|
2010-11-15 00:25:46 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the CCID needs to transfer additional header options out-of-band
|
|
|
|
* (e.g. Ack Vectors or feature-negotiation options), it activates this
|
|
|
|
* flag to schedule a Sync. The Sync will automatically incorporate all
|
|
|
|
* currently pending header options, thus clearing the backlog.
|
|
|
|
*/
|
|
|
|
if (dp->dccps_sync_scheduled)
|
|
|
|
dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
}
|
|
|
|
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
/**
|
|
|
|
* dccp_flush_write_queue - Drain queue at end of connection
|
2020-10-28 09:14:12 +08:00
|
|
|
* @sk: socket to be drained
|
|
|
|
* @time_budget: time allowed to drain the queue
|
|
|
|
*
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
* Since dccp_sendmsg queues packets without waiting for them to be sent, it may
|
|
|
|
* happen that the TX queue is not empty at the end of a connection. We give the
|
|
|
|
* HC-sender CCID a grace period of up to @time_budget jiffies. If this function
|
|
|
|
* returns with a non-empty write queue, it will be purged later.
|
|
|
|
*/
|
|
|
|
void dccp_flush_write_queue(struct sock *sk, long *time_budget)
|
|
|
|
{
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
struct sk_buff *skb;
|
|
|
|
long delay, rc;
|
|
|
|
|
|
|
|
while (*time_budget > 0 && (skb = skb_peek(&sk->sk_write_queue))) {
|
|
|
|
rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
|
|
|
|
|
|
|
|
switch (ccid_packet_dequeue_eval(rc)) {
|
|
|
|
case CCID_PACKET_WILL_DEQUEUE_LATER:
|
|
|
|
/*
|
|
|
|
* If the CCID determines when to send, the next sending
|
|
|
|
* time is unknown or the CCID may not even send again
|
|
|
|
* (e.g. remote host crashes or lost Ack packets).
|
|
|
|
*/
|
|
|
|
DCCP_WARN("CCID did not manage to send all packets\n");
|
|
|
|
return;
|
|
|
|
case CCID_PACKET_DELAY:
|
|
|
|
delay = msecs_to_jiffies(rc);
|
|
|
|
if (delay > *time_budget)
|
|
|
|
return;
|
|
|
|
rc = dccp_wait_for_ccid(sk, delay);
|
|
|
|
if (rc < 0)
|
|
|
|
return;
|
|
|
|
*time_budget -= (delay - rc);
|
|
|
|
/* check again if we can send now */
|
|
|
|
break;
|
|
|
|
case CCID_PACKET_SEND_AT_ONCE:
|
|
|
|
dccp_xmit_packet(sk);
|
|
|
|
break;
|
|
|
|
case CCID_PACKET_ERR:
|
|
|
|
skb_dequeue(&sk->sk_write_queue);
|
|
|
|
kfree_skb(skb);
|
|
|
|
dccp_pr_debug("packet discarded due to err=%ld\n", rc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void dccp_write_xmit(struct sock *sk)
|
2005-08-10 11:30:56 +08:00
|
|
|
{
|
2006-08-27 10:16:45 +08:00
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
2010-12-04 20:38:01 +08:00
|
|
|
while ((skb = dccp_qpolicy_top(sk))) {
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
int rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
|
2005-08-27 14:06:35 +08:00
|
|
|
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
switch (ccid_packet_dequeue_eval(rc)) {
|
|
|
|
case CCID_PACKET_WILL_DEQUEUE_LATER:
|
|
|
|
return;
|
|
|
|
case CCID_PACKET_DELAY:
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:27 +08:00
|
|
|
sk_reset_timer(sk, &dp->dccps_xmit_timer,
|
|
|
|
jiffies + msecs_to_jiffies(rc));
|
|
|
|
return;
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
case CCID_PACKET_SEND_AT_ONCE:
|
|
|
|
dccp_xmit_packet(sk);
|
|
|
|
break;
|
|
|
|
case CCID_PACKET_ERR:
|
2010-12-04 20:38:01 +08:00
|
|
|
dccp_qpolicy_drop(sk, skb);
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28 03:16:26 +08:00
|
|
|
dccp_pr_debug("packet discarded due to err=%d\n", rc);
|
2006-12-10 10:05:12 +08:00
|
|
|
}
|
2006-08-27 10:16:45 +08:00
|
|
|
}
|
2005-08-10 11:30:56 +08:00
|
|
|
}
|
|
|
|
|
2008-07-26 18:59:09 +08:00
|
|
|
/**
|
|
|
|
* dccp_retransmit_skb - Retransmit Request, Close, or CloseReq packets
|
2020-10-28 09:14:12 +08:00
|
|
|
* @sk: socket to perform retransmit on
|
|
|
|
*
|
2008-07-26 18:59:09 +08:00
|
|
|
* There are only four retransmittable packet types in DCCP:
|
|
|
|
* - Request in client-REQUEST state (sec. 8.1.1),
|
|
|
|
* - CloseReq in server-CLOSEREQ state (sec. 8.3),
|
|
|
|
* - Close in node-CLOSING state (sec. 8.3),
|
|
|
|
* - Acks in client-PARTOPEN state (sec. 8.1.5, handled by dccp_delack_timer()).
|
|
|
|
* This function expects sk->sk_send_head to contain the original skb.
|
|
|
|
*/
|
|
|
|
int dccp_retransmit_skb(struct sock *sk)
|
2005-08-10 11:14:34 +08:00
|
|
|
{
|
2008-07-26 18:59:09 +08:00
|
|
|
WARN_ON(sk->sk_send_head == NULL);
|
|
|
|
|
2005-12-14 15:16:16 +08:00
|
|
|
if (inet_csk(sk)->icsk_af_ops->rebuild_header(sk) != 0)
|
2005-08-10 11:14:34 +08:00
|
|
|
return -EHOSTUNREACH; /* Routing failure or similar. */
|
|
|
|
|
2008-07-26 18:59:09 +08:00
|
|
|
/* this count is used to distinguish original and retransmitted skb */
|
|
|
|
inet_csk(sk)->icsk_retransmits++;
|
|
|
|
|
|
|
|
return dccp_transmit_skb(sk, skb_clone(sk->sk_send_head, GFP_ATOMIC));
|
2005-08-10 11:14:34 +08:00
|
|
|
}
|
|
|
|
|
2015-09-25 22:39:22 +08:00
|
|
|
struct sk_buff *dccp_make_response(const struct sock *sk, struct dst_entry *dst,
|
2005-08-10 11:14:34 +08:00
|
|
|
struct request_sock *req)
|
|
|
|
{
|
|
|
|
struct dccp_hdr *dh;
|
2005-09-17 07:58:40 +08:00
|
|
|
struct dccp_request_sock *dreq;
|
2006-03-21 14:31:09 +08:00
|
|
|
const u32 dccp_header_size = sizeof(struct dccp_hdr) +
|
2005-08-10 11:14:34 +08:00
|
|
|
sizeof(struct dccp_hdr_ext) +
|
|
|
|
sizeof(struct dccp_hdr_response);
|
2015-09-25 22:39:22 +08:00
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
/* sk is marked const to clearly express we dont hold socket lock.
|
|
|
|
* sock_wmalloc() will atomically change sk->sk_wmem_alloc,
|
|
|
|
* it is safe to promote sk to non const.
|
|
|
|
*/
|
|
|
|
skb = sock_wmalloc((struct sock *)sk, MAX_DCCP_HEADER, 1,
|
|
|
|
GFP_ATOMIC);
|
|
|
|
if (!skb)
|
2005-08-10 11:14:34 +08:00
|
|
|
return NULL;
|
|
|
|
|
2015-09-25 22:39:22 +08:00
|
|
|
skb_reserve(skb, MAX_DCCP_HEADER);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2009-06-02 13:19:30 +08:00
|
|
|
skb_dst_set(skb, dst_clone(dst));
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2005-09-17 07:58:40 +08:00
|
|
|
dreq = dccp_rsk(req);
|
2012-02-27 09:22:02 +08:00
|
|
|
if (inet_rsk(req)->acked) /* increase GSS upon retransmission */
|
|
|
|
dccp_inc_seqno(&dreq->dreq_gss);
|
2005-08-10 11:14:34 +08:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_RESPONSE;
|
2012-02-27 09:22:02 +08:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_seq = dreq->dreq_gss;
|
2006-03-21 14:32:06 +08:00
|
|
|
|
2008-11-17 14:49:52 +08:00
|
|
|
/* Resolve feature dependencies resulting from choice of CCID */
|
|
|
|
if (dccp_feat_server_ccid_dependencies(dreq))
|
|
|
|
goto response_failed;
|
|
|
|
|
|
|
|
if (dccp_insert_options_rsk(dreq, skb))
|
|
|
|
goto response_failed;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2006-11-14 22:57:34 +08:00
|
|
|
/* Build and checksum header */
|
2006-11-10 21:22:32 +08:00
|
|
|
dh = dccp_zeroed_hdr(skb, dccp_header_size);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2013-10-10 15:04:37 +08:00
|
|
|
dh->dccph_sport = htons(inet_rsk(req)->ir_num);
|
2013-10-10 06:21:29 +08:00
|
|
|
dh->dccph_dport = inet_rsk(req)->ir_rmt_port;
|
2005-08-14 07:34:54 +08:00
|
|
|
dh->dccph_doff = (dccp_header_size +
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_opt_len) / 4;
|
2005-08-10 11:14:34 +08:00
|
|
|
dh->dccph_type = DCCP_PKT_RESPONSE;
|
|
|
|
dh->dccph_x = 1;
|
2012-02-27 09:22:02 +08:00
|
|
|
dccp_hdr_set_seq(dh, dreq->dreq_gss);
|
|
|
|
dccp_hdr_set_ack(dccp_hdr_ack_bits(skb), dreq->dreq_gsr);
|
2005-09-17 07:58:40 +08:00
|
|
|
dccp_hdr_response(skb)->dccph_resp_service = dreq->dreq_service;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2006-11-11 03:43:06 +08:00
|
|
|
dccp_csum_outgoing(skb);
|
|
|
|
|
2006-11-13 23:12:07 +08:00
|
|
|
/* We use `acked' to remember that a Response was already sent. */
|
|
|
|
inet_rsk(req)->acked = 1;
|
2005-08-10 11:14:34 +08:00
|
|
|
DCCP_INC_STATS(DCCP_MIB_OUTSEGS);
|
|
|
|
return skb;
|
2008-11-17 14:49:52 +08:00
|
|
|
response_failed:
|
|
|
|
kfree_skb(skb);
|
|
|
|
return NULL;
|
2005-08-10 11:14:34 +08:00
|
|
|
}
|
|
|
|
|
2005-12-14 15:24:16 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dccp_make_response);
|
|
|
|
|
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
It is useful to have this separate, since the following Reset codes will always
be generated from the control socket rather than via dccp_send_reset:
* Code 3, "No Connection", cf. 8.3.1;
* Code 4, "Packet Error" (identification for Data 1 added);
* Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
* Code 6, "Mandatory Error" (same as Option Error);
* Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
* Code 8, "Bad Service Code";
* Code 9, "Too Busy";
* Code 10, "Bad Init Cookie" (not used).
Code 0 is not recommended by the RFC, the following codes would be used in
dccp_send_reset() instead, since they all relate to an established DCCP connection:
* Code 1, "Closed";
* Code 2, "Aborted";
* Code 11, "Aggression Penalty" (12.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2007-09-27 01:35:19 +08:00
|
|
|
/* answer offending packet in @rcv_skb with Reset from control socket @ctl */
|
2008-04-04 05:20:52 +08:00
|
|
|
struct sk_buff *dccp_ctl_make_reset(struct sock *sk, struct sk_buff *rcv_skb)
|
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
It is useful to have this separate, since the following Reset codes will always
be generated from the control socket rather than via dccp_send_reset:
* Code 3, "No Connection", cf. 8.3.1;
* Code 4, "Packet Error" (identification for Data 1 added);
* Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
* Code 6, "Mandatory Error" (same as Option Error);
* Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
* Code 8, "Bad Service Code";
* Code 9, "Too Busy";
* Code 10, "Bad Init Cookie" (not used).
Code 0 is not recommended by the RFC, the following codes would be used in
dccp_send_reset() instead, since they all relate to an established DCCP connection:
* Code 1, "Closed";
* Code 2, "Aborted";
* Code 11, "Aggression Penalty" (12.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2007-09-27 01:35:19 +08:00
|
|
|
{
|
|
|
|
struct dccp_hdr *rxdh = dccp_hdr(rcv_skb), *dh;
|
|
|
|
struct dccp_skb_cb *dcb = DCCP_SKB_CB(rcv_skb);
|
|
|
|
const u32 dccp_hdr_reset_len = sizeof(struct dccp_hdr) +
|
|
|
|
sizeof(struct dccp_hdr_ext) +
|
|
|
|
sizeof(struct dccp_hdr_reset);
|
|
|
|
struct dccp_hdr_reset *dhr;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
2008-04-04 05:20:52 +08:00
|
|
|
skb = alloc_skb(sk->sk_prot->max_header, GFP_ATOMIC);
|
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
It is useful to have this separate, since the following Reset codes will always
be generated from the control socket rather than via dccp_send_reset:
* Code 3, "No Connection", cf. 8.3.1;
* Code 4, "Packet Error" (identification for Data 1 added);
* Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
* Code 6, "Mandatory Error" (same as Option Error);
* Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
* Code 8, "Bad Service Code";
* Code 9, "Too Busy";
* Code 10, "Bad Init Cookie" (not used).
Code 0 is not recommended by the RFC, the following codes would be used in
dccp_send_reset() instead, since they all relate to an established DCCP connection:
* Code 1, "Closed";
* Code 2, "Aborted";
* Code 11, "Aggression Penalty" (12.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2007-09-27 01:35:19 +08:00
|
|
|
if (skb == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2008-04-04 05:20:52 +08:00
|
|
|
skb_reserve(skb, sk->sk_prot->max_header);
|
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
It is useful to have this separate, since the following Reset codes will always
be generated from the control socket rather than via dccp_send_reset:
* Code 3, "No Connection", cf. 8.3.1;
* Code 4, "Packet Error" (identification for Data 1 added);
* Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
* Code 6, "Mandatory Error" (same as Option Error);
* Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
* Code 8, "Bad Service Code";
* Code 9, "Too Busy";
* Code 10, "Bad Init Cookie" (not used).
Code 0 is not recommended by the RFC, the following codes would be used in
dccp_send_reset() instead, since they all relate to an established DCCP connection:
* Code 1, "Closed";
* Code 2, "Aborted";
* Code 11, "Aggression Penalty" (12.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2007-09-27 01:35:19 +08:00
|
|
|
|
|
|
|
/* Swap the send and the receive. */
|
|
|
|
dh = dccp_zeroed_hdr(skb, dccp_hdr_reset_len);
|
|
|
|
dh->dccph_type = DCCP_PKT_RESET;
|
|
|
|
dh->dccph_sport = rxdh->dccph_dport;
|
|
|
|
dh->dccph_dport = rxdh->dccph_sport;
|
|
|
|
dh->dccph_doff = dccp_hdr_reset_len / 4;
|
|
|
|
dh->dccph_x = 1;
|
|
|
|
|
|
|
|
dhr = dccp_hdr_reset(skb);
|
|
|
|
dhr->dccph_reset_code = dcb->dccpd_reset_code;
|
|
|
|
|
|
|
|
switch (dcb->dccpd_reset_code) {
|
|
|
|
case DCCP_RESET_CODE_PACKET_ERROR:
|
|
|
|
dhr->dccph_reset_data[0] = rxdh->dccph_type;
|
|
|
|
break;
|
2020-08-24 06:36:59 +08:00
|
|
|
case DCCP_RESET_CODE_OPTION_ERROR:
|
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
It is useful to have this separate, since the following Reset codes will always
be generated from the control socket rather than via dccp_send_reset:
* Code 3, "No Connection", cf. 8.3.1;
* Code 4, "Packet Error" (identification for Data 1 added);
* Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
* Code 6, "Mandatory Error" (same as Option Error);
* Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
* Code 8, "Bad Service Code";
* Code 9, "Too Busy";
* Code 10, "Bad Init Cookie" (not used).
Code 0 is not recommended by the RFC, the following codes would be used in
dccp_send_reset() instead, since they all relate to an established DCCP connection:
* Code 1, "Closed";
* Code 2, "Aborted";
* Code 11, "Aggression Penalty" (12.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2007-09-27 01:35:19 +08:00
|
|
|
case DCCP_RESET_CODE_MANDATORY_ERROR:
|
|
|
|
memcpy(dhr->dccph_reset_data, dcb->dccpd_reset_data, 3);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* From RFC 4340, 8.3.1:
|
|
|
|
* If P.ackno exists, set R.seqno := P.ackno + 1.
|
|
|
|
* Else set R.seqno := 0.
|
|
|
|
*/
|
|
|
|
if (dcb->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
|
|
|
|
dccp_hdr_set_seq(dh, ADD48(dcb->dccpd_ack_seq, 1));
|
|
|
|
dccp_hdr_set_ack(dccp_hdr_ack_bits(skb), dcb->dccpd_seq);
|
|
|
|
|
|
|
|
dccp_csum_outgoing(skb);
|
|
|
|
return skb;
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(dccp_ctl_make_reset);
|
|
|
|
|
2007-09-26 22:30:02 +08:00
|
|
|
/* send Reset on established socket, to close or abort the connection */
|
2006-03-21 11:25:24 +08:00
|
|
|
int dccp_send_reset(struct sock *sk, enum dccp_reset_codes code)
|
|
|
|
{
|
2007-09-26 22:30:02 +08:00
|
|
|
struct sk_buff *skb;
|
2006-03-21 11:25:24 +08:00
|
|
|
/*
|
|
|
|
* FIXME: what if rebuild_header fails?
|
|
|
|
* Should we be doing a rebuild_header here?
|
|
|
|
*/
|
2007-11-28 16:35:08 +08:00
|
|
|
int err = inet_csk(sk)->icsk_af_ops->rebuild_header(sk);
|
2006-03-21 11:25:24 +08:00
|
|
|
|
2007-09-26 22:30:02 +08:00
|
|
|
if (err != 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
skb = sock_wmalloc(sk, sk->sk_prot->max_header, 1, GFP_ATOMIC);
|
|
|
|
if (skb == NULL)
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
|
|
|
/* Reserve space for headers and prepare control bits. */
|
|
|
|
skb_reserve(skb, sk->sk_prot->max_header);
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_RESET;
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_reset_code = code;
|
2006-03-21 11:25:24 +08:00
|
|
|
|
2007-09-26 22:30:02 +08:00
|
|
|
return dccp_transmit_skb(sk, skb);
|
2006-03-21 11:25:24 +08:00
|
|
|
}
|
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
/*
|
|
|
|
* Do all connect socket setups that can be done AF independent.
|
|
|
|
*/
|
2010-10-12 02:36:33 +08:00
|
|
|
int dccp_connect(struct sock *sk)
|
2005-08-10 11:14:34 +08:00
|
|
|
{
|
2010-10-12 02:36:33 +08:00
|
|
|
struct sk_buff *skb;
|
2005-12-14 15:24:16 +08:00
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
2005-08-10 11:14:34 +08:00
|
|
|
struct dst_entry *dst = __sk_dst_get(sk);
|
|
|
|
struct inet_connection_sock *icsk = inet_csk(sk);
|
|
|
|
|
|
|
|
sk->sk_err = 0;
|
|
|
|
sock_reset_flag(sk, SOCK_DONE);
|
2007-02-09 22:24:38 +08:00
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
dccp_sync_mss(sk, dst_mtu(dst));
|
|
|
|
|
dccp: Resolve dependencies of features on choice of CCID
This provides a missing link in the code chain, as several features implicitly
depend and/or rely on the choice of CCID. Most notably, this is the Send Ack Vector
feature, but also Ack Ratio and Send Loss Event Rate (also taken care of).
For Send Ack Vector, the situation is as follows:
* since CCID2 mandates the use of Ack Vectors, there is no point in allowing
endpoints which use CCID2 to disable Ack Vector features such a connection;
* a peer with a TX CCID of CCID2 will always expect Ack Vectors, and a peer
with a RX CCID of CCID2 must always send Ack Vectors (RFC 4341, sec. 4);
* for all other CCIDs, the use of (Send) Ack Vector is optional and thus
negotiable. However, this implies that the code negotiating the use of Ack
Vectors also supports it (i.e. is able to supply and to either parse or
ignore received Ack Vectors). Since this is not the case (CCID-3 has no Ack
Vector support), the use of Ack Vectors is here disabled, with a comment
in the source code.
An analogous consideration arises for the Send Loss Event Rate feature,
since the CCID-3 implementation does not support the loss interval options
of RFC 4342. To make such use explicit, corresponding feature-negotiation
options are inserted which signal the use of the loss event rate option,
as it is used by the CCID3 code.
Lastly, the values of the Ack Ratio feature are matched to the choice of CCID.
The patch implements this as a function which is called after the user has
made all other registrations for changing default values of features.
The table is variable-length, the reserved (and hence for feature-negotiation
invalid, confirmed by considering section 19.4 of RFC 4340) feature number `0'
is used to mark the end of the table.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-11-12 16:48:44 +08:00
|
|
|
/* do not connect if feature negotiation setup fails */
|
|
|
|
if (dccp_feat_finalise_settings(dccp_sk(sk)))
|
|
|
|
return -EPROTO;
|
|
|
|
|
2010-10-12 02:36:33 +08:00
|
|
|
/* Initialise GAR as per 8.5; AWL/AWH are set in dccp_transmit_skb() */
|
|
|
|
dp->dccps_gar = dp->dccps_iss;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2006-03-21 14:31:09 +08:00
|
|
|
skb = alloc_skb(sk->sk_prot->max_header, sk->sk_allocation);
|
2005-08-10 11:14:34 +08:00
|
|
|
if (unlikely(skb == NULL))
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
|
|
|
/* Reserve space for headers. */
|
2006-03-21 14:31:09 +08:00
|
|
|
skb_reserve(skb, sk->sk_prot->max_header);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_REQUEST;
|
|
|
|
|
2011-07-03 23:51:29 +08:00
|
|
|
dccp_transmit_skb(sk, dccp_skb_entail(sk, skb));
|
2005-08-10 11:14:34 +08:00
|
|
|
DCCP_INC_STATS(DCCP_MIB_ACTIVEOPENS);
|
|
|
|
|
|
|
|
/* Timer for repeating the REQUEST until an answer. */
|
2010-10-12 02:36:33 +08:00
|
|
|
icsk->icsk_retransmits = 0;
|
2005-08-10 11:30:56 +08:00
|
|
|
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
|
|
|
|
icsk->icsk_rto, DCCP_RTO_MAX);
|
2005-08-10 11:14:34 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-12-14 15:24:16 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dccp_connect);
|
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
void dccp_send_ack(struct sock *sk)
|
|
|
|
{
|
|
|
|
/* If we have been reset, we may not send again. */
|
|
|
|
if (sk->sk_state != DCCP_CLOSED) {
|
2006-03-21 14:31:09 +08:00
|
|
|
struct sk_buff *skb = alloc_skb(sk->sk_prot->max_header,
|
|
|
|
GFP_ATOMIC);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
if (skb == NULL) {
|
|
|
|
inet_csk_schedule_ack(sk);
|
|
|
|
inet_csk(sk)->icsk_ack.ato = TCP_ATO_MIN;
|
2005-08-14 07:34:54 +08:00
|
|
|
inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
|
|
|
|
TCP_DELACK_MAX,
|
|
|
|
DCCP_RTO_MAX);
|
2005-08-10 11:14:34 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reserve space for headers */
|
2006-03-21 14:31:09 +08:00
|
|
|
skb_reserve(skb, sk->sk_prot->max_header);
|
2005-08-10 11:14:34 +08:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_ACK;
|
|
|
|
dccp_transmit_skb(sk, skb);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(dccp_send_ack);
|
|
|
|
|
2008-06-11 18:19:09 +08:00
|
|
|
#if 0
|
2007-09-26 22:26:04 +08:00
|
|
|
/* FIXME: Is this still necessary (11.3) - currently nowhere used by DCCP. */
|
2005-08-10 11:14:34 +08:00
|
|
|
void dccp_send_delayed_ack(struct sock *sk)
|
|
|
|
{
|
|
|
|
struct inet_connection_sock *icsk = inet_csk(sk);
|
|
|
|
/*
|
|
|
|
* FIXME: tune this timer. elapsed time fixes the skew, so no problem
|
|
|
|
* with using 2s, and active senders also piggyback the ACK into a
|
|
|
|
* DATAACK packet, so this is really for quiescent senders.
|
|
|
|
*/
|
|
|
|
unsigned long timeout = jiffies + 2 * HZ;
|
|
|
|
|
|
|
|
/* Use new timeout only if there wasn't a older one earlier. */
|
|
|
|
if (icsk->icsk_ack.pending & ICSK_ACK_TIMER) {
|
|
|
|
/* If delack timer was blocked or is about to expire,
|
|
|
|
* send ACK now.
|
|
|
|
*
|
|
|
|
* FIXME: check the "about to expire" part
|
|
|
|
*/
|
|
|
|
if (icsk->icsk_ack.blocked) {
|
|
|
|
dccp_send_ack(sk);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!time_before(timeout, icsk->icsk_ack.timeout))
|
|
|
|
timeout = icsk->icsk_ack.timeout;
|
|
|
|
}
|
|
|
|
icsk->icsk_ack.pending |= ICSK_ACK_SCHED | ICSK_ACK_TIMER;
|
|
|
|
icsk->icsk_ack.timeout = timeout;
|
|
|
|
sk_reset_timer(sk, &icsk->icsk_delack_timer, timeout);
|
|
|
|
}
|
2008-06-11 18:19:09 +08:00
|
|
|
#endif
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2007-09-26 13:42:27 +08:00
|
|
|
void dccp_send_sync(struct sock *sk, const u64 ackno,
|
2005-08-17 14:10:59 +08:00
|
|
|
const enum dccp_pkt_type pkt_type)
|
2005-08-10 11:14:34 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We are not putting this on the write queue, so
|
|
|
|
* dccp_transmit_skb() will set the ownership to this
|
|
|
|
* sock.
|
|
|
|
*/
|
2006-03-21 14:31:09 +08:00
|
|
|
struct sk_buff *skb = alloc_skb(sk->sk_prot->max_header, GFP_ATOMIC);
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2007-09-26 13:42:27 +08:00
|
|
|
if (skb == NULL) {
|
2005-08-10 11:14:34 +08:00
|
|
|
/* FIXME: how to make sure the sync is sent? */
|
2007-09-26 13:42:27 +08:00
|
|
|
DCCP_CRIT("could not send %s", dccp_packet_name(pkt_type));
|
2005-08-10 11:14:34 +08:00
|
|
|
return;
|
2007-09-26 13:42:27 +08:00
|
|
|
}
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
/* Reserve space for headers and prepare control bits. */
|
2006-03-21 14:31:09 +08:00
|
|
|
skb_reserve(skb, sk->sk_prot->max_header);
|
2005-08-17 14:10:59 +08:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = pkt_type;
|
2007-09-26 13:42:27 +08:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_ack_seq = ackno;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2010-11-15 00:25:46 +08:00
|
|
|
/*
|
|
|
|
* Clear the flag in case the Sync was scheduled for out-of-band data,
|
|
|
|
* such as carrying a long Ack Vector.
|
|
|
|
*/
|
|
|
|
dccp_sk(sk)->dccps_sync_scheduled = 0;
|
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
dccp_transmit_skb(sk, skb);
|
|
|
|
}
|
|
|
|
|
2006-03-21 13:25:11 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dccp_send_sync);
|
|
|
|
|
2005-08-14 07:34:54 +08:00
|
|
|
/*
|
|
|
|
* Send a DCCP_PKT_CLOSE/CLOSEREQ. The caller locks the socket for us. This
|
|
|
|
* cannot be allowed to fail queueing a DCCP_PKT_CLOSE/CLOSEREQ frame under
|
|
|
|
* any circumstances.
|
2005-08-10 11:14:34 +08:00
|
|
|
*/
|
2005-08-24 12:50:06 +08:00
|
|
|
void dccp_send_close(struct sock *sk, const int active)
|
2005-08-10 11:14:34 +08:00
|
|
|
{
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
struct sk_buff *skb;
|
2005-10-21 15:20:43 +08:00
|
|
|
const gfp_t prio = active ? GFP_KERNEL : GFP_ATOMIC;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2005-08-24 12:50:06 +08:00
|
|
|
skb = alloc_skb(sk->sk_prot->max_header, prio);
|
|
|
|
if (skb == NULL)
|
|
|
|
return;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
/* Reserve space for headers and prepare control bits. */
|
|
|
|
skb_reserve(skb, sk->sk_prot->max_header);
|
2007-12-13 22:25:01 +08:00
|
|
|
if (dp->dccps_role == DCCP_ROLE_SERVER && !dp->dccps_server_timewait)
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_CLOSEREQ;
|
|
|
|
else
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_CLOSE;
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2005-08-24 12:50:06 +08:00
|
|
|
if (active) {
|
2011-07-03 23:51:29 +08:00
|
|
|
skb = dccp_skb_entail(sk, skb);
|
2007-12-13 22:02:43 +08:00
|
|
|
/*
|
|
|
|
* Retransmission timer for active-close: RFC 4340, 8.3 requires
|
|
|
|
* to retransmit the Close/CloseReq until the CLOSING/CLOSEREQ
|
|
|
|
* state can be left. The initial timeout is 2 RTTs.
|
|
|
|
* Since RTT measurement is done by the CCIDs, there is no easy
|
|
|
|
* way to get an RTT sample. The fallback RTT from RFC 4340, 3.4
|
|
|
|
* is too low (200ms); we use a high value to avoid unnecessary
|
|
|
|
* retransmissions when the link RTT is > 0.2 seconds.
|
|
|
|
* FIXME: Let main module sample RTTs and use that instead.
|
|
|
|
*/
|
|
|
|
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
|
|
|
|
DCCP_TIMEOUT_INIT, DCCP_RTO_MAX);
|
2011-07-03 23:51:29 +08:00
|
|
|
}
|
|
|
|
dccp_transmit_skb(sk, skb);
|
2005-08-10 11:14:34 +08:00
|
|
|
}
|