12 Dec, 2011

1 commit


23 Nov, 2011

1 commit


09 Nov, 2011

1 commit


12 Oct, 2010

1 commit

  • This fixes a problem and a potential loophole with regard to seqno/ackno
    validity: currently the initial adjustments to AWL/SWL are only performed
    once at the begin of the connection, during the handshake.

    Since the Sequence Window feature is always greater than Wmin=32 (7.5.2),
    it is however necessary to perform these adjustments at least for the first
    W/W' (variables as per 7.5.1) packets in the lifetime of a connection.

    This requirement is complicated by the fact that W/W' can change at any time
    during the lifetime of a connection.

    Therefore it is better to perform that safety check each time SWL/AWL are
    updated, as implemented by the patch.

    A second problem solved by this patch is that the remote/local Sequence Window
    feature values (which set the bounds for AWL/SWL/SWH) are undefined until the
    feature negotiation has completed.

    During the initial handshake we have more stringent sequence number protection;
    the changes added by this patch effect that {A,S}W{L,H} are within the correct
    bounds at the instant that feature negotiation completes (since the SeqWin
    feature activation handlers call dccp_update_gsr/gss()).

    Signed-off-by: Gerrit Renker

    Gerrit Renker
     

30 Mar, 2010

1 commit

  • …it 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>

    Tejun Heo
     

06 Mar, 2010

1 commit


03 Dec, 2009

1 commit

  • Add optional function parameters associated with sending SYNACK.
    These parameters are not needed after sending SYNACK, and are not
    used for retransmission. Avoids extending struct tcp_request_sock,
    and avoids allocating kernel memory.

    Also affects DCCP as it uses common struct request_sock_ops,
    but this parameter is currently reserved for future use.

    Signed-off-by: William.Allen.Simpson@gmail.com
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    William Allen Simpson
     

22 Jan, 2009

1 commit

  • This adds full support for local/remote Sequence Window feature, from which the
    * sequence-number-validity (W) and
    * acknowledgment-number-validity (W') windows
    derive as specified in RFC 4340, 7.5.3.

    Specifically, the following is contained in this patch:
    * integrated new socket fields into dccp_sk;
    * updated the update_gsr/gss routines with regard to these fields;
    * updated handler code: the Sequence Window feature is located at the TX side,
    so the local feature is meant if the handler-rx flag is false;
    * the initialisation of `rcv_wnd' in reqsk is removed, since
    - rcv_wnd is not used by the code anywhere;
    - sequence number checks are not done in the LISTEN state (cf. 7.5.3);
    - dccp_check_req checks the Ack number validity more rigorously;
    * the `struct dccp_minisock' became empty and is now removed.

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     

08 Dec, 2008

4 commits

  • This removes the use of the sysctl and the minisock variable for the Send Ack
    Vector feature, as it now is handled fully dynamically via feature negotiation
    (i.e. when CCID-2 is enabled, Ack Vectors are automatically enabled as per
    RFC 4341, 4.).

    Using a sysctl in parallel to this implementation would open the door to
    crashes, since much of the code relies on tests of the boolean minisock /
    sysctl variable. Thus, this patch replaces all tests of type

    if (dccp_msk(sk)->dccpms_send_ack_vector)
    /* ... */
    with
    if (dp->dccps_hc_rx_ackvec != NULL)
    /* ... */

    The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
    negotiation concluded that Ack Vectors are to be used on the half-connection.
    Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
    so that the test is a valid one.

    The activation handler for Ack Vectors is called as soon as the feature
    negotiation has concluded at the
    * server when the Ack marking the transition RESPOND => OPEN arrives;
    * client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.

    Adding the sequence number of the Response packet to the Ack Vector has been
    removed, since
    (a) connection establishment implies that the Response has been received;
    (b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
    this entry will always be ignored;
    (c) it can not be used for anything useful - to detect loss for instance, only
    packets received after the loss can serve as pseudo-dupacks.

    There was a FIXME to change the error code when dccp_ackvec_add() fails.
    I removed this after finding out that:
    * the check whether ackno < ISN is already made earlier,
    * this Response is likely the 1st packet with an Ackno that the client gets,
    * so when dccp_ackvec_add() fails, the reason is likely not a packet error.

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     
  • Updating the NDP count feature is handled automatically now:
    * for CCID-2 it is disabled, since the code does not use NDP counts;
    * for CCID-3 it is enabled, as NDP counts are used to determine loss lengths.

    Allowing the user to change NDP values leads to unpredictable and failing
    behaviour, since it is then possible to disable NDP counts even when they
    are needed (e.g. in CCID-3).

    This means that only those user settings are sensible that agree with the
    values for Send NDP Count implied by the choice of CCID. But those settings
    are already activated by the feature negotiation (CCID dependency tracking),
    hence this form of support is redundant.

    At startup the initialisation of the NDP count feature uses the default
    value of 0, which is done implicitly by the zeroing-out of the socket when
    it is allocated. If the choice of CCID or feature negotiation enables NDP
    count, this will then be updated via the NDP activation handler.

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     
  • The TX/RX CCIDs of the minisock are now redundant: similar to the Ack Vector
    case, their value equals initially that of the sysctl, but at the end of
    feature negotiation may be something different.

    The old interface removed by this patch thus has been replaced by the newer
    interface to dynamically query the currently loaded CCIDs.

    Also removed are the constructors for the TX CCID and the RX CCID, since the
    switch "rx non-rx" is done by the handler in minisocks.c (and the handler
    is the only place in the code where CCIDs are loaded).

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     
  • This patch integrates the activation of features at the end of negotiation
    into the server-side code.

    Note regarding the removal of 'const':
    --------------------------------------
    The 'const' attribute has been removed from 'dreq' since dccp_activate_values()
    needs to operate on dreq's feature list. Part of the activation is to remove
    those options from the list that have already been confirmed, hence it is not
    purely read-only.

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     

17 Nov, 2008

1 commit

  • This patch deprecates the Ack Ratio sysctl, since
    * Ack Ratio is entirely ignored by CCID-3 and CCID-4,
    * Ack Ratio currently doesn't work in CCID-2 (i.e. is always set to 1);
    * even if it would work in CCID-2, there is no point for a user to change it:
    - Ack Ratio is constrained by cwnd (RFC 4341, 6.1.2),
    - if Ack Ratio > cwnd, the system resorts to spurious RTO timeouts
    (since waiting for Acks which will never arrive in this window),
    - cwnd is not a user-configurable value.

    The only reasonable place for Ack Ratio is to print it for debugging. It is
    planned to do this later on, as part of e.g. dccp_probe.

    With this patch Ack Ratio is now under full control of feature negotiation:
    * Ack Ratio is resolved as a dependency of the selected CCID;
    * if the chosen CCID supports it (i.e. CCID == CCID-2), Ack Ratio is set to
    the default of 2, following RFC 4340, 11.3 - "New connections start with Ack
    Ratio 2 for both endpoints";
    * what happens then is part of another patch set, since it concerns the
    dynamic update of Ack Ratio while the connection is in full flight.

    Thanks to Tomasz Grobelny for discussion leading up to this patch.

    Signed-off-by: Gerrit Renker
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Gerrit Renker
     

05 Nov, 2008

1 commit

  • This provides feature-negotiation initialisation for both DCCP sockets
    and DCCP request_sockets, to support feature negotiation during
    connection setup.

    It also resolves a FIXME regarding the congestion control
    initialisation.

    Thanks to Wei Yongjun for help with the IPv6 side of this patch.

    Signed-off-by: Gerrit Renker
    Acked-by: Ian McDonald
    Signed-off-by: David S. Miller

    Gerrit Renker
     

20 Oct, 2008

1 commit

  • Commit a3116ac5c216fc3c145906a46df9ce542ff7dcf2 from 1st October ("tcp: Port
    redirection support for TCP") broke DCCP skb lookup by changing inet_csk_clone,
    which is used by DCCP to generate the child socket after the handshake.

    This patch updates DCCP to use 'loc_port' instead of 'sport', which fixes the
    problem, and thus inheriting port redirection support via the new interface.

    Signed-off-by: Gerrit Renker
    Signed-off-by: KOVACS Krisztian
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Gerrit Renker
     

07 Aug, 2008

1 commit

  • If the following packet flow happen, kernel will panic.
    MathineA MathineB
    SYN
    ---------------------->
    SYN+ACK

    When a bad seq ACK is received, tcp_v4_md5_do_lookup(skb->sk, ip_hdr(skb)->daddr))
    is finally called by tcp_v4_reqsk_send_ack(), but the first parameter(skb->sk) is
    NULL at that moment, so kernel panic happens.
    This patch fixes this bug.

    OOPS output is as following:
    [ 302.812793] IP: [] tcp_v4_md5_do_lookup+0x12/0x42
    [ 302.817075] Oops: 0000 [#1] SMP
    [ 302.819815] Modules linked in: ipv6 loop dm_multipath rtc_cmos rtc_core rtc_lib pcspkr pcnet32 mii i2c_piix4 parport_pc i2c_core parport ac button ata_piix libata dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
    [ 302.849946]
    [ 302.851198] Pid: 0, comm: swapper Not tainted (2.6.27-rc1-guijf #5)
    [ 302.855184] EIP: 0060:[] EFLAGS: 00010296 CPU: 0
    [ 302.858296] EIP is at tcp_v4_md5_do_lookup+0x12/0x42
    [ 302.861027] EAX: 0000001e EBX: 00000000 ECX: 00000046 EDX: 00000046
    [ 302.864867] ESI: ceb69e00 EDI: 1467a8c0 EBP: cf75f180 ESP: c0792e54
    [ 302.868333] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
    [ 302.871287] Process swapper (pid: 0, ti=c0792000 task=c0712340 task.ti=c0746000)
    [ 302.875592] Stack: c06f413a 00000000 cf75f180 ceb69e00 00000000 c05d0d86 000016d0 ceac5400
    [ 302.883275] c05d28f8 000016d0 ceb69e00 ceb69e20 681bf6e3 00001000 00000000 0a67a8c0
    [ 302.890971] ceac5400 c04250a3 c06f413a c0792eb0 c0792edc cf59a620 cf59a620 cf59a634
    [ 302.900140] Call Trace:
    [ 302.902392] [] tcp_v4_reqsk_send_ack+0x17/0x35
    [ 302.907060] [] tcp_check_req+0x156/0x372
    [ 302.910082] [] printk+0x14/0x18
    [ 302.912868] [] tcp_v4_do_rcv+0x1d3/0x2bf
    [ 302.917423] [] tcp_v4_rcv+0x563/0x5b9
    [ 302.920453] [] ip_local_deliver_finish+0xe8/0x183
    [ 302.923865] [] ip_rcv_finish+0x286/0x2a3
    [ 302.928569] [] dev_alloc_skb+0x11/0x25
    [ 302.931563] [] netif_receive_skb+0x2d6/0x33a
    [ 302.934914] [] pcnet32_poll+0x333/0x680 [pcnet32]
    [ 302.938735] [] net_rx_action+0x5c/0xfe
    [ 302.941792] [] __do_softirq+0x5d/0xc1
    [ 302.944788] [] __do_softirq+0x0/0xc1
    [ 302.948999] [] do_softirq+0x55/0x88
    [ 302.951870] [] handle_fasteoi_irq+0x0/0xa4
    [ 302.954986] [] irq_exit+0x35/0x69
    [ 302.959081] [] do_IRQ+0x99/0xae
    [ 302.961896] [] common_interrupt+0x23/0x28
    [ 302.966279] [] default_idle+0x2a/0x3d
    [ 302.969212] [] cpu_idle+0xb2/0xd2
    [ 302.972169] =======================
    [ 302.974274] Code: fc ff 84 d2 0f 84 df fd ff ff e9 34 fe ff ff 83 c4 0c 5b 5e 5f 5d c3 90 90 57 89 d7 56 53 89 c3 50 68 3a 41 6f c0 e8 e9 55 e5 ff 93 9c 04 00 00 58 85 d2 59 74 1e 8b 72 10 31 db 31 c9 85 f6
    [ 303.011610] EIP: [] tcp_v4_md5_do_lookup+0x12/0x42 SS:ESP 0068:c0792e54
    [ 303.018360] Kernel panic - not syncing: Fatal exception in interrupt

    Signed-off-by: Gui Jianfeng
    Signed-off-by: David S. Miller

    Gui Jianfeng
     

11 Jun, 2008

1 commit


01 Mar, 2008

1 commit


29 Jan, 2008

2 commits

  • 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
    Acked-by: Ian McDonald
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Gerrit Renker
     
  • This adds option-parsing code to processing of Acks in the listening state
    on request_socks on the server, serving two purposes
    (i) resolves a FIXME (removed);
    (ii) paves the way for feature-negotiation during connection-setup.

    There is an intended subtlety here with regard to dccp_check_req:

    Parsing options happens only after testing whether the received packet is
    a retransmitted Request. Otherwise, if the Request contained (a possibly
    large number of) feature-negotiation options, recomputing state would have to
    happen each time a retransmitted Request arrives, which opens the door to an
    easy DoS attack. Since in a genuine retransmission the options should not be
    different from the original, reusing the already computed state seems better.

    The other point is - if there are timestamp options on the Request, they will
    not be answered; which means that in the presence of retransmission (likely
    due to loss and/or other problems), the use of Request/Response RTT sampling
    is suspended, so that startup problems here do not propagate.

    Signed-off-by: Gerrit Renker
    Signed-off-by: Ian McDonald
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Gerrit Renker
     

11 Oct, 2007

2 commits


26 Apr, 2007

1 commit


07 Mar, 2007

1 commit

  • This mirrors a recent change in tcp_open_req_child, whereby the icsk_rto of the
    newly created child socket was not set (but rather on the parent socket). Same
    fix for DCCP.

    Signed-off-by: Gerrit Renker
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Gerrit Renker
     

12 Dec, 2006

1 commit


05 Dec, 2006

1 commit


03 Dec, 2006

7 commits

  • This reaps the benefit of the earlier patch, which changed the type of
    CCID 3 states to use enums, in that many conditions are now simplified
    and the number of possible (unexpected) values is greatly reduced.

    In a few instances, this also allowed to simplify pre-conditions; where
    care has been taken to retain logical equivalence.

    [DCCP]: Introduce a consistent BUG/WARN message scheme

    This refines the existing set of DCCP messages so that
    * BUG(), BUG_ON(), WARN_ON() have meaningful DCCP-specific counterparts
    * DCCP_CRIT (for severe warnings) is not rate-limited
    * DCCP_WARN() is introduced as rate-limited wrapper

    Using these allows a faster and cleaner transition to their original
    counterparts once the code has matured into a full DCCP implementation.

    Signed-off-by: Gerrit Renker
    Signed-off-by: Arnaldo Carvalho de Melo

    Gerrit Renker
     
  • Based on implementation by Rick Payne.

    Signed-off-by: YOSHIFUJI Hideaki
    Signed-off-by: David S. Miller

    YOSHIFUJI Hideaki
     
  • In order to make their function clearer and obtain a consistent naming
    scheme to identify sysctls, all existing DCCP sysctls have been prefixed
    with `sysctl_dccp', following the same convention as used by TCP.

    Feature-specific sysctls retain the `feat' in the middle, although the
    `default' has been dropped, since it is obvious from use.

    Also removed a duplicate `dccp_feat_default_sequence_window' in ipv4.c.

    Signed-off-by: Gerrit Renker
    Signed-off-by: Arnaldo Carvalho de Melo

    Gerrit Renker
     
  • Problem:

    Gerrit Renker
     
  • Sorts out the comments for processing steps 2,3 in section 8.5 of RFC 4340.
    All comments have been updated against this document, and the reference to step
    2 has been made consistent throughout the files.

    Signed-off-by: Gerrit Renker
    Signed-off-by: Arnaldo Carvalho de Melo

    Gerrit Renker
     
  • This is a code simplification to remove reduplicated code
    by concentrating and abstracting shared code.

    Detailed Changes:

    Gerrit Renker
     
  • This patch removes two functions, the send_ack functions of request_sock,
    which are not called/used by the DCCP code. It is correct that these
    functions are not called, below is a justification why calling these
    functions (on a passive socket in the LISTEN/RESPOND state) would mean
    a DCCP protocol violation.

    A) Background: using request_sock in TCP:

    Gerrit Renker
     

22 Nov, 2006

1 commit


01 Jul, 2006

1 commit


21 Mar, 2006

4 commits

  • This will later be included in struct dccp_request_sock so that we can
    have per connection feature negotiation state while in the 3way
    handshake, when we clone the DCCP_ROLE_LISTEN socket (in
    dccp_create_openreq_child) we'll just copy this state from
    dreq_minisock to dccps_minisock.

    Also the feature negotiation and option parsing code will mostly touch
    dccps_minisock, which will simplify some stuff.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • 1. No need for ->ccid_init nor ->ccid_exit, this is what module_{init,exit}
    does and anynways neither ccid2 nor ccid3 were using it.

    2. Rename struct ccid to struct ccid_operations and introduce struct ccid
    with a pointer to ccid_operations and rigth after it the rx or tx
    private state.

    3. Remove the pointer to the state of the half connections from struct
    dccp_sock, now its derived thru ccid_priv() from the ccid pointer.

    Now we also can implement the setsockopt for changing the CCID easily as
    no ccid init routines can affect struct dccp_sock in any way that prevents
    other CCIDs from working if a CCID switch operation is asked by apps.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • 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
    18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response
    18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001:

    :-)

    Signed-off-by: Andrea Bittau
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Andrea Bittau
     
  • Simplifying the code a bit as we're always using DCCP_MAX_ACKVEC_LEN.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

04 Jan, 2006

1 commit