dccp ccid-2: Separate option parsing from CCID processing

This patch replaces an almost identical replication of code: large parts
of dccp_parse_options() re-appeared as ccid2_ackvector() in ccid2.c.

Apart from the duplication, this caused two more problems:
 1. CCIDs should not need to be concerned with parsing header options;
 2. one can not assume that Ack Vectors appear as a contiguous area within an
    skb, it is legal to insert other options and/or padding in between. The
    current code would throw an error and stop reading in such a case.

The patch provides a new data structure and associated list housekeeping.

Only small changes were necessary to integrate with CCID-2: data structure
initialisation, adapt list traversal routine, and add call to the provided
cleanup routine.

The latter also lead to fixing the following BUG: CCID-2 so far ignored
Ack Vectors on all packets other than Ack/DataAck, which is incorrect,
since Ack Vectors can be present on any packet that has an Ack field.

Details:
--------
 * received Ack Vectors are parsed by dccp_parse_options() alone, which passes
   the result on to the CCID-specific routine ccid_hc_tx_parse_options();
 * CCIDs interested in using/decoding Ack Vector information will add code
   to fetch parsed Ack Vectors via this interface;
 * a data structure, `struct dccp_ackvec_parsed' is provided as interface;
 * this structure arranges Ack Vectors of the same skb into a FIFO order;
 * a doubly-linked list is used to keep the required FIFO code small.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>

1 files changed, 10 insertions, 7 deletions

diff --git a/net/dccp/options.c b/net/dccp/options.c
index 791e07853a79..e5a32979d7d7 100644
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -128,13 +128,6 @@ int dccp_parse_options(struct sock *sk, struct dccp_request_sock *dreq,
                         if (rc)
                                 goto out_featneg_failed;
                         break;
-                case DCCPO_ACK_VECTOR_0:
-                case DCCPO_ACK_VECTOR_1:
-                        if (dccp_packet_without_ack(skb))   /* RFC 4340, 11.4 */
-                                break;
-                        dccp_pr_debug("%s Ack Vector (len=%u)\n", dccp_role(sk),
-                                      len);
-                        break;
                 case DCCPO_TIMESTAMP:
                         if (len != 4)
                                 goto out_invalid_option;
@@ -224,6 +217,16 @@ int dccp_parse_options(struct sock *sk, struct dccp_request_sock *dreq,
                                                      pkt_type, opt, value, len))
                                 goto out_invalid_option;
                         break;
+                case DCCPO_ACK_VECTOR_0:
+                case DCCPO_ACK_VECTOR_1:
+                        if (dccp_packet_without_ack(skb))   /* RFC 4340, 11.4 */
+                                break;
+                        /*
+                         * Ack vectors are processed by the TX CCID if it is
+                         * interested. The RX CCID need not parse Ack Vectors,
+                         * since it is only interested in clearing old state.
+                         * Fall through.
+                         */
                 case DCCPO_MIN_TX_CCID_SPECIFIC ... DCCPO_MAX_TX_CCID_SPECIFIC:
                         if (ccid_hc_tx_parse_options(dp->dccps_hc_tx_ccid, sk,
                                                      pkt_type, opt, value, len))