20 Oct, 2013

1 commit

  • There are a mix of function prototypes with and without extern
    in the kernel sources. Standardize on not using extern for
    function prototypes.

    Function prototypes don't need to be written with extern.
    extern is assumed by the compiler. Its use is as unnecessary as
    using auto to declare automatic/local variables in a block.

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

16 Aug, 2012

1 commit

  • ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
    a NULL ccid pointer leading to a NULL pointer dereference. This could
    lead to a privilege escalation if the attacker is able to map page 0 and
    prepare it with a fake ccid_ops pointer.

    Signed-off-by: Mathias Krause
    Cc: Gerrit Renker
    Cc: stable@vger.kernel.org
    Signed-off-by: David S. Miller

    Mathias Krause
     

29 Oct, 2010

1 commit

  • This patch reorganises the return value convention of the CCID TX sending
    function, to permit more flexible schemes, as required by subsequent patches.

    Currently the convention is
    * values < 0 mean error,
    * a value == 0 means "send now", and
    * a value x > 0 means "send in x milliseconds".

    The patch provides symbolic constants and a function to interpret return values.

    In addition, it caps the maximum positive return value to 0xFFFF milliseconds,
    corresponding to 65.535 seconds. This is possible since in CCID-3/4 the
    maximum possible inter-packet gap is fixed at t_mbi = 64 sec.

    Signed-off-by: Gerrit Renker
    Signed-off-by: David S. Miller

    Gerrit Renker
     

12 Oct, 2010

1 commit

  • This removes the argument `more' from ccid_hc_tx_packet_sent, since it was
    nowhere used in the entire code.

    (Btw, this argument was not even used in the original KAME code where the
    function initially came from; compare the variable moreToSend in the
    freebsd61-dccp-kame-28.08.2006.patch kept by Emmanuel Lochin.)

    Signed-off-by: Gerrit Renker

    Gerrit Renker
     

21 Sep, 2010

1 commit

  • This
    1. adds packet type information to ccid_hc_{rx,tx}_parse_options(). This is
    necessary, since table 3 in RFC 4340, 5.8 leaves it to the CCIDs to state
    which options may (not) appear on what packet type.

    2. adds such a check for CCID-3's {Loss Event, Receive} Rate as specified in
    RFC 4340 8.3 ("Receive Rate options MUST NOT be sent on DCCP-Data packets")
    and 8.5 ("Loss Event Rate options MUST NOT be sent on DCCP-Data packets").

    3. removes an unused argument `idx' from ccid_hc_{rx,tx}_parse_options(). This
    is also no longer necessary, since the CCID-specific option-parsing routines
    are passed every single parameter of the type-length-value option encoding.

    Signed-off-by: Gerrit Renker

    Gerrit Renker
     

04 Feb, 2010

1 commit

  • This fixes a bug introduced in commit de4ef86cfce60d2250111f34f8a084e769f23b16
    ("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the
    vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since
    slab_name_fmt is now a 4-byte pointer and no longer a 32-character array.

    This lead to error messages such as
    FATAL: Error inserting dccp: No buffer space available

    >> kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci
    generated due to the truncation after the 3rd character.

    Fixed for the moment by introducing a symbolic constant. Tested to fix the bug.

    Signed-off-by: Gerrit Renker
    Acked-by: Neil Horman
    Signed-off-by: David S. Miller

    Gerrit Renker
     

19 Jan, 2010

1 commit

  • Hey all-
    I was tinkering with dccp recently and noticed that I BUG halted the
    kernel when I rmmod-ed the dccp module. The bug halt occured because the page
    that I passed to kfree failed the PageCompound and PageSlab test in the slub
    implementation of kfree. I tracked the problem down to the following set of
    events:

    1) dccp, unlike all other uses of kmem_cache_create, allocates a string
    dynamically when registering a slab cache. This allocated string is freed when
    the cache is destroyed.

    2) Normally, (1) is not an issue, but when Slub is in use, it is possible that
    caches are 'merged'. This process causes multiple caches of simmilar
    configuration to use the same cache data structure. When this happens, the new
    name of the cache is effectively dropped.

    3) (2) results in kmem_cache_name returning an ambigous value (i.e.
    ccid_kmem_cache_destroy, which uses this fuction to retrieve the name pointer
    for freeing), is no longer guaranteed that the string it assigned is what is
    returned.

    4) If such merge event occurs, ccid_kmem_cache_destroy frees the wrong pointer,
    which trips over the BUG in the slub implementation of kfree (since its likely
    not a slab allocation, but rather a pointer into the static string table
    section.

    So, what to do about this. At first blush this is pretty clearly a leak in the
    information that slub owns, and as such a slub bug. Unfortunately, theres no
    really good way to fix it, without exposing slub specific implementation details
    to the generic slab interface. Also, even if we could fix this in slub cleanly,
    I think the RCU free option would force us to do lots of string duplication, not
    only in slub, but in every slab allocator. As such, I'd like to propose this
    solution. Basically, I just move the storage for the kmem cache name to the
    ccid_operations structure. In so doing, we don't have to do the kstrdup or
    kfree when we allocate/free the various caches for dccp, and so we avoid the
    problem, by storing names with static memory, rather than heap, the way all
    other calls to kmem_cache_create do.

    I've tested this out myself here, and it solves the problem quite well.

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

    Neil Horman
     

05 Jan, 2009

2 commits

  • This patch cleans up after integrating the CCID modules and, in addition,

    * moves the if/else cases from ccid_delete() into ccid_hc_{tx,rx}_delete();
    * removes the 'gfp' argument to ccid_new() - since it is always gfp_any().

    Signed-off-by: Gerrit Renker
    Signed-off-by: David S. Miller

    Gerrit Renker
     
  • Based on Arnaldo's earlier patch, this patch integrates the standardised
    CCID congestion control plugins (CCID-2 and CCID-3) of DCCP with dccp.ko:

    * enables a faster connection path by eliminating the need to always go
    through the CCID registration lock;

    * updates the implementation to use only a single array whose size equals
    the number of configured CCIDs instead of the maximum (256);

    * since the CCIDs are now fixed array elements, synchronization is no
    longer needed, simplifying use and implementation.

    CCID-2 is suggested as minimum for a basic DCCP implementation (RFC 4340, 10);
    CCID-3 is a standards-track CCID supported by RFC 4342 and RFC 5348.

    Signed-off-by: Gerrit Renker
    Signed-off-by: David S. Miller

    Gerrit Renker
     

08 Dec, 2008

1 commit

  • 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
     

24 Nov, 2008

1 commit

  • This provides function to query the current TX/RX CCID dynamically,
    without reliance on the minisock value, using dynamic information
    available in the currently loaded CCID module.

    This query function is then used to
    (a) provide the getsockopt part for getting/setting CCIDs via sockopts;
    (b) replace the current test for "which CCID is in use" in probe.c.

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

    Gerrit Renker
     

12 Nov, 2008

1 commit

  • This provides a data structure to record which CCIDs are locally supported
    and three accessor functions:
    - a test function for internal use which is used to validate CCID requests
    made by the user;
    - a copy function so that the list can be used for feature-negotiation;
    - documented getsockopt() support so that the user can query capabilities.

    The data structure is a table which is filled in at compile-time with the
    list of available CCIDs (which in turn depends on the Kconfig choices).

    Using the copy function for cloning the list of supported CCIDs is useful for
    feature negotiation, since the negotiation is now with the full list of available
    CCIDs (e.g. {2, 3}) instead of the default value {2}. This means negotiation
    will not fail if the peer requests to use CCID3 instead of CCID2.

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

    Gerrit Renker
     

29 Jan, 2008

2 commits

  • This introduces a CCMPS field for setting a CCID-specific upper bound on the application payload
    size, as is defined in RFC 4340, section 14.

    Only the TX CCID is considered in setting this limit, since the RX CCID generates comparatively
    small (DCCP-Ack) feedback packets. The CCMPS field includes network and transport layer header
    lengths. The only current CCMPS customer is CCID4 (via RFC 4828).

    A wrapper is used to allow querying the CCMPS even at times where the CCID modules may not have
    been fully negotiated yet.

    In dccp_sync_mss() the variable `mss_now' has been renamed into `cur_mps', to reflect that we are
    dealing with an MPS, but not an MSS.
    Since the DCCP code closely follows the TCP code, the identifiers `dccp_sync_mss' and
    `dccps_mss_cache' have been kept, as they have direct TCP counterparts.

    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
     
  • This adds documentation for the ccid_operations structure.

    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
     

12 Dec, 2006

1 commit

  • The function ccid3_hc_tx_insert_options only does a redundant no-op,
    as the operation

    DCCP_SKB_CB(skb)->dccpd_ccval = hctx->ccid3hctx_last_win_count;

    is already performed _unconditionally_ in ccid3_hc_tx_send_packet.

    Since there is further no current need for this function, it is removed
    entirely. Since furthermore, there is actually no present need for the
    entire interface function ccid_hc_tx_insert_options, it was decided to
    remove it also, to clean up the interface.

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

    Gerrit Renker
     

08 Dec, 2006

1 commit

  • Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

03 Dec, 2006

1 commit

  • This patch implements a suggestion by Ian McDonald and

    1) Avoids tests against negative packet lengths by using unsigned int
    for packet payload lengths in the CCID send_packet()/packet_sent() routines

    2) As a consequence, it removes an now unnecessary test with regard to `len > 0'
    in ccid3_hc_tx_packet_sent: that condition is always true, since
    * negative packet lengths are avoided
    * ccid3_hc_tx_send_packet flags an error whenever the payload length is 0.
    As a consequence, ccid3_hc_tx_packet_sent is never called as all errors
    returned by ccid_hc_tx_send_packet are caught in dccp_write_xmit

    3) Removes the third argument of ccid_hc_tx_send_packet (the `len' parameter),
    since it is currently always set to skb->len. The code is updated with regard
    to this parameter change.

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

    Gerrit Renker
     

21 Mar, 2006

2 commits

  • And not the silly LIMIT_NETDEBUG and silently return without inserting
    the option requested.

    Also drop some old debugging messages associated to option insertion.

    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
     

04 Jan, 2006

1 commit


11 Oct, 2005

1 commit


18 Sep, 2005

1 commit


30 Aug, 2005

5 commits

  • And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
    information that is specific to them.

    For now reusing struct tcp_info, later I'll try to figure out a better
    solution, for now its really nice to get this kind of info:

    [root@qemu ~]# ./ss -danemi
    State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
    LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
    mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
    ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
    mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377

    This, for instance, shows that we're not congestion controlling ACKs,
    as the above output is in the ttcp receiving host, and ttcp is a one
    way app, i.e. the received never calls sendmsg, so
    ccid_hc_tx_send_packet is never called, so the TX half connection
    stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
    stays with the value set in ccid3_hc_tx_init, 4us, as show above in
    milliseconds (0.004ms), upcoming patches will fix this.

    rcv_rtt seems sane tho, matching ping results :-)

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

    Arnaldo Carvalho de Melo
     
  • Just like kfree, etc it will just not call the CCID exit
    routines when the private data area is set to NULL.

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

    Arnaldo Carvalho de Melo
     
  • Andrew Morton should be happy now 8)

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

    Arnaldo Carvalho de Melo
     
  • This way it gets closer to the TCP flow, where congestion window
    checks are done, it seems we can map ccid_hc_tx_send_packet in
    dccp_write_xmit to tcp_snd_wnd_test in tcp_write_xmit, a CCID2
    decision should just fit in here as well...

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

    Arnaldo Carvalho de Melo
     
  • Development to this point was done on a subversion repository at:

    http://oops.ghostprotocols.net:81/cgi-bin/viewcvs.cgi/dccp-2.6/

    This repository will be kept at this site for the foreseable future,
    so that interested parties can see the history of this code,
    attributions, etc.

    If I ever decide to take this offline I'll provide the full history at
    some other suitable place.

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

    Arnaldo Carvalho de Melo