License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2005-08-10 03:14:34 +00:00
|
|
|
#ifndef _LINUX_DCCP_H
|
|
|
|
|
#define _LINUX_DCCP_H
|
|
|
|
|
|
2005-08-10 03:26:03 +00:00
|
|
|
|
|
|
|
|
#include <linux/in.h>
|
2011-06-06 10:43:46 +00:00
|
|
|
#include <linux/interrupt.h>
|
2007-08-20 00:18:33 +00:00
|
|
|
#include <linux/ktime.h>
|
2005-08-10 03:26:03 +00:00
|
|
|
#include <linux/list.h>
|
|
|
|
|
#include <linux/uio.h>
|
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
|
|
|
|
|
|
#include <net/inet_connection_sock.h>
|
2005-12-27 04:43:12 +00:00
|
|
|
#include <net/inet_sock.h>
|
2005-08-10 03:45:21 +00:00
|
|
|
#include <net/inet_timewait_sock.h>
|
2005-08-10 03:26:03 +00:00
|
|
|
#include <net/tcp_states.h>
|
2012-10-13 09:46:48 +00:00
|
|
|
#include <uapi/linux/dccp.h>
|
2005-08-10 03:26:03 +00:00
|
|
|
|
|
|
|
|
enum dccp_state {
|
2007-11-28 13:34:53 +00:00
|
|
|
DCCP_OPEN = TCP_ESTABLISHED,
|
|
|
|
|
DCCP_REQUESTING = TCP_SYN_SENT,
|
|
|
|
|
DCCP_LISTEN = TCP_LISTEN,
|
|
|
|
|
DCCP_RESPOND = TCP_SYN_RECV,
|
|
|
|
|
/*
|
|
|
|
|
* States involved in closing a DCCP connection:
|
|
|
|
|
* 1) ACTIVE_CLOSEREQ is entered by a server sending a CloseReq.
|
|
|
|
|
*
|
|
|
|
|
* 2) CLOSING can have three different meanings (RFC 4340, 8.3):
|
|
|
|
|
* a. Client has performed active-close, has sent a Close to the server
|
|
|
|
|
* from state OPEN or PARTOPEN, and is waiting for the final Reset
|
|
|
|
|
* (in this case, SOCK_DONE == 1).
|
|
|
|
|
* b. Client is asked to perform passive-close, by receiving a CloseReq
|
|
|
|
|
* in (PART)OPEN state. It sends a Close and waits for final Reset
|
|
|
|
|
* (in this case, SOCK_DONE == 0).
|
|
|
|
|
* c. Server performs an active-close as in (a), keeps TIMEWAIT state.
|
|
|
|
|
*
|
|
|
|
|
* 3) The following intermediate states are employed to give passively
|
|
|
|
|
* closing nodes a chance to process their unread data:
|
|
|
|
|
* - PASSIVE_CLOSE (from OPEN => CLOSED) and
|
|
|
|
|
* - PASSIVE_CLOSEREQ (from (PART)OPEN to CLOSING; case (b) above).
|
|
|
|
|
*/
|
|
|
|
|
DCCP_ACTIVE_CLOSEREQ = TCP_FIN_WAIT1,
|
|
|
|
|
DCCP_PASSIVE_CLOSE = TCP_CLOSE_WAIT, /* any node receiving a Close */
|
|
|
|
|
DCCP_CLOSING = TCP_CLOSING,
|
|
|
|
|
DCCP_TIME_WAIT = TCP_TIME_WAIT,
|
|
|
|
|
DCCP_CLOSED = TCP_CLOSE,
|
2015-03-22 17:22:24 +00:00
|
|
|
DCCP_NEW_SYN_RECV = TCP_NEW_SYN_RECV,
|
2007-11-28 13:34:53 +00:00
|
|
|
DCCP_PARTOPEN = TCP_MAX_STATES,
|
|
|
|
|
DCCP_PASSIVE_CLOSEREQ, /* clients receiving CloseReq */
|
2007-11-20 23:56:37 +00:00
|
|
|
DCCP_MAX_STATES
|
2005-08-10 03:26:03 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum {
|
2007-11-28 13:34:53 +00:00
|
|
|
DCCPF_OPEN = TCPF_ESTABLISHED,
|
|
|
|
|
DCCPF_REQUESTING = TCPF_SYN_SENT,
|
|
|
|
|
DCCPF_LISTEN = TCPF_LISTEN,
|
|
|
|
|
DCCPF_RESPOND = TCPF_SYN_RECV,
|
|
|
|
|
DCCPF_ACTIVE_CLOSEREQ = TCPF_FIN_WAIT1,
|
|
|
|
|
DCCPF_CLOSING = TCPF_CLOSING,
|
|
|
|
|
DCCPF_TIME_WAIT = TCPF_TIME_WAIT,
|
|
|
|
|
DCCPF_CLOSED = TCPF_CLOSE,
|
2015-03-22 17:22:24 +00:00
|
|
|
DCCPF_NEW_SYN_RECV = TCPF_NEW_SYN_RECV,
|
2007-11-28 13:34:53 +00:00
|
|
|
DCCPF_PARTOPEN = (1 << DCCP_PARTOPEN),
|
2005-08-10 03:26:03 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static inline struct dccp_hdr *dccp_hdr(const struct sk_buff *skb)
|
|
|
|
|
{
|
2007-04-26 01:04:18 +00:00
|
|
|
return (struct dccp_hdr *)skb_transport_header(skb);
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
2006-11-10 13:22:32 +00:00
|
|
|
static inline struct dccp_hdr *dccp_zeroed_hdr(struct sk_buff *skb, int headlen)
|
|
|
|
|
{
|
2007-03-13 16:06:52 +00:00
|
|
|
skb_push(skb, headlen);
|
|
|
|
|
skb_reset_transport_header(skb);
|
2007-04-26 01:04:18 +00:00
|
|
|
return memset(skb_transport_header(skb), 0, headlen);
|
2006-11-10 13:22:32 +00:00
|
|
|
}
|
|
|
|
|
|
2007-10-24 12:12:09 +00:00
|
|
|
static inline struct dccp_hdr_ext *dccp_hdrx(const struct dccp_hdr *dh)
|
2005-08-10 03:26:03 +00:00
|
|
|
{
|
2007-10-24 12:12:09 +00:00
|
|
|
return (struct dccp_hdr_ext *)((unsigned char *)dh + sizeof(*dh));
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
2005-08-10 03:26:55 +00:00
|
|
|
static inline unsigned int __dccp_basic_hdr_len(const struct dccp_hdr *dh)
|
|
|
|
|
{
|
|
|
|
|
return sizeof(*dh) + (dh->dccph_x ? sizeof(struct dccp_hdr_ext) : 0);
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-10 03:26:03 +00:00
|
|
|
static inline unsigned int dccp_basic_hdr_len(const struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
const struct dccp_hdr *dh = dccp_hdr(skb);
|
2005-08-10 03:26:55 +00:00
|
|
|
return __dccp_basic_hdr_len(dh);
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
2007-10-24 12:12:09 +00:00
|
|
|
static inline __u64 dccp_hdr_seq(const struct dccp_hdr *dh)
|
2005-08-10 03:26:03 +00:00
|
|
|
{
|
2006-03-21 03:23:32 +00:00
|
|
|
__u64 seq_nr = ntohs(dh->dccph_seq);
|
2005-08-10 03:26:03 +00:00
|
|
|
|
|
|
|
|
if (dh->dccph_x != 0)
|
2007-10-24 12:12:09 +00:00
|
|
|
seq_nr = (seq_nr << 32) + ntohl(dccp_hdrx(dh)->dccph_seq_low);
|
2006-03-21 03:23:32 +00:00
|
|
|
else
|
|
|
|
|
seq_nr += (u32)dh->dccph_seq2 << 16;
|
2005-08-10 03:26:03 +00:00
|
|
|
|
|
|
|
|
return seq_nr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct dccp_hdr_request *dccp_hdr_request(struct sk_buff *skb)
|
|
|
|
|
{
|
2007-04-26 01:04:18 +00:00
|
|
|
return (struct dccp_hdr_request *)(skb_transport_header(skb) +
|
|
|
|
|
dccp_basic_hdr_len(skb));
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct dccp_hdr_ack_bits *dccp_hdr_ack_bits(const struct sk_buff *skb)
|
|
|
|
|
{
|
2007-04-26 01:04:18 +00:00
|
|
|
return (struct dccp_hdr_ack_bits *)(skb_transport_header(skb) +
|
|
|
|
|
dccp_basic_hdr_len(skb));
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline u64 dccp_hdr_ack_seq(const struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
const struct dccp_hdr_ack_bits *dhack = dccp_hdr_ack_bits(skb);
|
2006-03-21 03:23:32 +00:00
|
|
|
return ((u64)ntohs(dhack->dccph_ack_nr_high) << 32) + ntohl(dhack->dccph_ack_nr_low);
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct dccp_hdr_response *dccp_hdr_response(struct sk_buff *skb)
|
|
|
|
|
{
|
2007-04-26 01:04:18 +00:00
|
|
|
return (struct dccp_hdr_response *)(skb_transport_header(skb) +
|
|
|
|
|
dccp_basic_hdr_len(skb));
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct dccp_hdr_reset *dccp_hdr_reset(struct sk_buff *skb)
|
|
|
|
|
{
|
2007-04-26 01:04:18 +00:00
|
|
|
return (struct dccp_hdr_reset *)(skb_transport_header(skb) +
|
|
|
|
|
dccp_basic_hdr_len(skb));
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
2005-08-10 03:26:55 +00:00
|
|
|
static inline unsigned int __dccp_hdr_len(const struct dccp_hdr *dh)
|
|
|
|
|
{
|
|
|
|
|
return __dccp_basic_hdr_len(dh) +
|
|
|
|
|
dccp_packet_hdr_len(dh->dccph_type);
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-10 03:26:03 +00:00
|
|
|
static inline unsigned int dccp_hdr_len(const struct sk_buff *skb)
|
|
|
|
|
{
|
2005-08-10 03:26:55 +00:00
|
|
|
return __dccp_hdr_len(dccp_hdr(skb));
|
2005-08-10 03:26:03 +00:00
|
|
|
}
|
|
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 14:37:19 +00:00
|
|
|
/**
|
|
|
|
|
* struct dccp_request_sock - represent DCCP-specific connection request
|
|
|
|
|
* @dreq_inet_rsk: structure inherited from
|
2012-02-27 01:22:02 +00:00
|
|
|
* @dreq_iss: initial sequence number, sent on the first Response (RFC 4340, 7.1)
|
|
|
|
|
* @dreq_gss: greatest sequence number sent (for retransmitted Responses)
|
|
|
|
|
* @dreq_isr: initial sequence number received in the first Request
|
|
|
|
|
* @dreq_gsr: greatest sequence number received (for retransmitted Request(s))
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 14:37:19 +00:00
|
|
|
* @dreq_service: service code present on the Request (there is just one)
|
2008-11-05 07:55:49 +00:00
|
|
|
* @dreq_featneg: feature negotiation options for this connection
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 14:37:19 +00:00
|
|
|
* The following two fields are analogous to the ones in dccp_sock:
|
|
|
|
|
* @dreq_timestamp_echo: last received timestamp to echo (13.1)
|
|
|
|
|
* @dreq_timestamp_echo: the time of receiving the last @dreq_timestamp_echo
|
|
|
|
|
*/
|
2005-08-10 03:14:34 +00:00
|
|
|
struct dccp_request_sock {
|
|
|
|
|
struct inet_request_sock dreq_inet_rsk;
|
|
|
|
|
__u64 dreq_iss;
|
2012-02-27 01:22:02 +00:00
|
|
|
__u64 dreq_gss;
|
2005-08-10 03:14:34 +00:00
|
|
|
__u64 dreq_isr;
|
2012-02-27 01:22:02 +00:00
|
|
|
__u64 dreq_gsr;
|
2006-03-21 03:23:32 +00:00
|
|
|
__be32 dreq_service;
|
2017-03-05 18:52:16 +00:00
|
|
|
spinlock_t dreq_lock;
|
2008-11-05 07:55:49 +00:00
|
|
|
struct list_head dreq_featneg;
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 14:37:19 +00:00
|
|
|
__u32 dreq_timestamp_echo;
|
|
|
|
|
__u32 dreq_timestamp_time;
|
2005-08-10 03:14:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static inline struct dccp_request_sock *dccp_rsk(const struct request_sock *req)
|
|
|
|
|
{
|
|
|
|
|
return (struct dccp_request_sock *)req;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-10 03:45:21 +00:00
|
|
|
extern struct inet_timewait_death_row dccp_death_row;
|
|
|
|
|
|
2007-12-13 14:29:24 +00:00
|
|
|
extern int dccp_parse_options(struct sock *sk, struct dccp_request_sock *dreq,
|
|
|
|
|
struct sk_buff *skb);
|
|
|
|
|
|
2005-08-10 03:14:34 +00:00
|
|
|
struct dccp_options_received {
|
2008-07-13 10:51:40 +00:00
|
|
|
u64 dccpor_ndp:48;
|
2005-08-10 03:14:34 +00:00
|
|
|
u32 dccpor_timestamp;
|
|
|
|
|
u32 dccpor_timestamp_echo;
|
|
|
|
|
u32 dccpor_elapsed_time;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ccid;
|
|
|
|
|
|
|
|
|
|
enum dccp_role {
|
|
|
|
|
DCCP_ROLE_UNDEFINED,
|
|
|
|
|
DCCP_ROLE_LISTEN,
|
|
|
|
|
DCCP_ROLE_CLIENT,
|
|
|
|
|
DCCP_ROLE_SERVER,
|
|
|
|
|
};
|
|
|
|
|
|
2005-09-16 23:58:40 +00:00
|
|
|
struct dccp_service_list {
|
|
|
|
|
__u32 dccpsl_nr;
|
2020-02-28 13:33:37 +00:00
|
|
|
__be32 dccpsl_list[];
|
2005-09-16 23:58:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DCCP_SERVICE_INVALID_VALUE htonl((__u32)-1)
|
2006-12-10 18:01:18 +00:00
|
|
|
#define DCCP_SERVICE_CODE_IS_ABSENT 0
|
2005-09-16 23:58:40 +00:00
|
|
|
|
2015-10-08 13:28:58 +00:00
|
|
|
static inline bool dccp_list_has_service(const struct dccp_service_list *sl,
|
2006-03-21 03:23:32 +00:00
|
|
|
const __be32 service)
|
2005-09-16 23:58:40 +00:00
|
|
|
{
|
|
|
|
|
if (likely(sl != NULL)) {
|
|
|
|
|
u32 i = sl->dccpsl_nr;
|
|
|
|
|
while (i--)
|
|
|
|
|
if (sl->dccpsl_list[i] == service)
|
2015-10-08 13:28:58 +00:00
|
|
|
return true;
|
2005-09-16 23:58:40 +00:00
|
|
|
}
|
2015-10-08 13:28:58 +00:00
|
|
|
return false;
|
2005-09-16 23:58:40 +00:00
|
|
|
}
|
|
|
|
|
|
2005-09-18 07:17:51 +00:00
|
|
|
struct dccp_ackvec;
|
|
|
|
|
|
2005-08-10 03:14:34 +00:00
|
|
|
/**
|
|
|
|
|
* struct dccp_sock - DCCP socket state
|
|
|
|
|
*
|
|
|
|
|
* @dccps_swl - sequence number window low
|
|
|
|
|
* @dccps_swh - sequence number window high
|
|
|
|
|
* @dccps_awl - acknowledgement number window low
|
|
|
|
|
* @dccps_awh - acknowledgement number window high
|
|
|
|
|
* @dccps_iss - initial sequence number sent
|
|
|
|
|
* @dccps_isr - initial sequence number received
|
|
|
|
|
* @dccps_osr - first OPEN sequence number received
|
|
|
|
|
* @dccps_gss - greatest sequence number sent
|
|
|
|
|
* @dccps_gsr - greatest valid sequence number received
|
|
|
|
|
* @dccps_gar - greatest valid ack number received on a non-Sync; initialized to %dccps_iss
|
2006-11-14 14:57:34 +00:00
|
|
|
* @dccps_service - first (passive sock) or unique (active sock) service code
|
|
|
|
|
* @dccps_service_list - second .. last service code on passive socket
|
2005-08-10 03:14:34 +00:00
|
|
|
* @dccps_timestamp_echo - latest timestamp received on a TIMESTAMP option
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 14:37:19 +00:00
|
|
|
* @dccps_timestamp_time - time of receiving latest @dccps_timestamp_echo
|
2007-04-20 20:57:21 +00:00
|
|
|
* @dccps_l_ack_ratio - feature-local Ack Ratio
|
|
|
|
|
* @dccps_r_ack_ratio - feature-remote Ack Ratio
|
2009-01-16 23:36:31 +00:00
|
|
|
* @dccps_l_seq_win - local Sequence Window (influences ack number validity)
|
|
|
|
|
* @dccps_r_seq_win - remote Sequence Window (influences seq number validity)
|
2006-11-10 19:43:06 +00:00
|
|
|
* @dccps_pcslen - sender partial checksum coverage (via sockopt)
|
|
|
|
|
* @dccps_pcrlen - receiver partial checksum coverage (via sockopt)
|
2008-12-08 09:18:37 +00:00
|
|
|
* @dccps_send_ndp_count - local Send NDP Count feature (7.7.2)
|
2005-08-10 03:14:34 +00:00
|
|
|
* @dccps_ndp_count - number of Non Data Packets since last data packet
|
2007-04-20 20:57:21 +00:00
|
|
|
* @dccps_mss_cache - current value of MSS (path MTU minus header sizes)
|
2007-09-26 14:31:49 +00:00
|
|
|
* @dccps_rate_last - timestamp for rate-limiting DCCP-Sync (RFC 4340, 7.5.4)
|
2008-11-05 07:55:49 +00:00
|
|
|
* @dccps_featneg - tracks feature-negotiation state (mostly during handshake)
|
2005-09-18 07:17:51 +00:00
|
|
|
* @dccps_hc_rx_ackvec - rx half connection ack vector
|
2007-04-20 20:57:21 +00:00
|
|
|
* @dccps_hc_rx_ccid - CCID used for the receiver (or receiving half-connection)
|
|
|
|
|
* @dccps_hc_tx_ccid - CCID used for the sender (or sending half-connection)
|
|
|
|
|
* @dccps_options_received - parsed set of retrieved options
|
2010-12-04 12:38:01 +00:00
|
|
|
* @dccps_qpolicy - TX dequeueing policy, one of %dccp_packet_dequeueing_policy
|
|
|
|
|
* @dccps_tx_qlen - maximum length of the TX queue
|
2007-04-20 20:57:21 +00:00
|
|
|
* @dccps_role - role of this sock, one of %dccp_role
|
|
|
|
|
* @dccps_hc_rx_insert_options - receiver wants to add options when acking
|
|
|
|
|
* @dccps_hc_tx_insert_options - sender wants to add options when sending
|
2007-12-13 14:25:01 +00:00
|
|
|
* @dccps_server_timewait - server holds timewait state on close (RFC 4340, 8.3)
|
2010-11-14 16:25:46 +00:00
|
|
|
* @dccps_sync_scheduled - flag which signals "send out-of-band message soon"
|
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-27 19:16:26 +00:00
|
|
|
* @dccps_xmitlet - tasklet scheduled by the TX CCID to dequeue data packets
|
|
|
|
|
* @dccps_xmit_timer - used by the TX CCID to delay sending (rate-based pacing)
|
2007-03-20 18:27:17 +00:00
|
|
|
* @dccps_syn_rtt - RTT sample from Request/Response exchange (in usecs)
|
2005-08-10 03:14:34 +00:00
|
|
|
*/
|
|
|
|
|
struct dccp_sock {
|
|
|
|
|
/* inet_connection_sock has to be the first member of dccp_sock */
|
|
|
|
|
struct inet_connection_sock dccps_inet_connection;
|
2007-03-20 18:27:17 +00:00
|
|
|
#define dccps_syn_rtt dccps_inet_connection.icsk_ack.lrcvtime
|
2005-08-10 03:14:34 +00:00
|
|
|
__u64 dccps_swl;
|
|
|
|
|
__u64 dccps_swh;
|
|
|
|
|
__u64 dccps_awl;
|
|
|
|
|
__u64 dccps_awh;
|
|
|
|
|
__u64 dccps_iss;
|
|
|
|
|
__u64 dccps_isr;
|
|
|
|
|
__u64 dccps_osr;
|
|
|
|
|
__u64 dccps_gss;
|
|
|
|
|
__u64 dccps_gsr;
|
|
|
|
|
__u64 dccps_gar;
|
2006-03-21 03:23:32 +00:00
|
|
|
__be32 dccps_service;
|
2008-02-03 12:07:48 +00:00
|
|
|
__u32 dccps_mss_cache;
|
2005-09-16 23:58:40 +00:00
|
|
|
struct dccp_service_list *dccps_service_list;
|
2005-08-10 03:14:34 +00:00
|
|
|
__u32 dccps_timestamp_echo;
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 14:37:19 +00:00
|
|
|
__u32 dccps_timestamp_time;
|
2006-03-21 01:41:47 +00:00
|
|
|
__u16 dccps_l_ack_ratio;
|
|
|
|
|
__u16 dccps_r_ack_ratio;
|
2009-01-16 23:36:31 +00:00
|
|
|
__u64 dccps_l_seq_win:48;
|
|
|
|
|
__u64 dccps_r_seq_win:48;
|
2008-11-17 06:53:48 +00:00
|
|
|
__u8 dccps_pcslen:4;
|
|
|
|
|
__u8 dccps_pcrlen:4;
|
2008-12-08 09:18:37 +00:00
|
|
|
__u8 dccps_send_ndp_count:1;
|
2008-07-13 10:51:40 +00:00
|
|
|
__u64 dccps_ndp_count:48;
|
2007-09-26 14:31:49 +00:00
|
|
|
unsigned long dccps_rate_last;
|
2008-11-05 07:55:49 +00:00
|
|
|
struct list_head dccps_featneg;
|
2005-09-18 07:17:51 +00:00
|
|
|
struct dccp_ackvec *dccps_hc_rx_ackvec;
|
2005-08-10 03:14:34 +00:00
|
|
|
struct ccid *dccps_hc_rx_ccid;
|
|
|
|
|
struct ccid *dccps_hc_tx_ccid;
|
|
|
|
|
struct dccp_options_received dccps_options_received;
|
2010-12-04 12:38:01 +00:00
|
|
|
__u8 dccps_qpolicy;
|
|
|
|
|
__u32 dccps_tx_qlen;
|
2005-08-10 03:14:34 +00:00
|
|
|
enum dccp_role dccps_role:2;
|
2005-09-09 05:30:07 +00:00
|
|
|
__u8 dccps_hc_rx_insert_options:1;
|
|
|
|
|
__u8 dccps_hc_tx_insert_options:1;
|
2007-12-13 14:25:01 +00:00
|
|
|
__u8 dccps_server_timewait:1;
|
2010-11-14 16:25:46 +00:00
|
|
|
__u8 dccps_sync_scheduled:1;
|
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-27 19:16:26 +00:00
|
|
|
struct tasklet_struct dccps_xmitlet;
|
2006-08-27 02:16:45 +00:00
|
|
|
struct timer_list dccps_xmit_timer;
|
2005-08-10 03:14:34 +00:00
|
|
|
};
|
2006-12-10 18:01:18 +00:00
|
|
|
|
2005-08-10 03:14:34 +00:00
|
|
|
static inline struct dccp_sock *dccp_sk(const struct sock *sk)
|
|
|
|
|
{
|
|
|
|
|
return (struct dccp_sock *)sk;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline const char *dccp_role(const struct sock *sk)
|
|
|
|
|
{
|
|
|
|
|
switch (dccp_sk(sk)->dccps_role) {
|
|
|
|
|
case DCCP_ROLE_UNDEFINED: return "undefined";
|
|
|
|
|
case DCCP_ROLE_LISTEN: return "listen";
|
|
|
|
|
case DCCP_ROLE_SERVER: return "server";
|
|
|
|
|
case DCCP_ROLE_CLIENT: return "client";
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-22 17:22:19 +00:00
|
|
|
extern void dccp_syn_ack_timeout(const struct request_sock *req);
|
2012-04-12 22:16:05 +00:00
|
|
|
|
2005-08-10 03:14:34 +00:00
|
|
|
#endif /* _LINUX_DCCP_H */
|