16 Sep, 2015

1 commit

  • Remove unneeded NULL test.

    The semantic patch that makes this change is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @@
    expression x;
    @@

    -if (x != NULL)
    \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);

    @@
    expression x;
    @@

    -if (x != NULL) {
    \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
    x = NULL;
    -}
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: David S. Miller

    Julia Lawall
     

02 Oct, 2014

1 commit


11 Jul, 2012

1 commit


05 Jul, 2011

1 commit


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
     

13 Feb, 2010

1 commit

  • This fixes a problem in the DCCP getsockopt() API: currently there is no way
    for a user to a priori know the number of built-in CCIDs, other than trying
    DCCP_SOCKOPT_AVAILABLE_CCIDS in a loop, incrementing the option length until
    EINVAL is no longer returned.

    This patch truncates the array to the user-provided length. No copy is made
    when the length is
    Signed-off-by: David S. Miller

    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

3 commits

  • This patch integrates the TFRC library, which is a dependency of CCID-3 (and
    CCID-4), with the new use of CCIDs in the DCCP module.

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

    Gerrit Renker
     
  • 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
     

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
     

17 Oct, 2008

1 commit


29 Jan, 2008

1 commit

  • The patch makes the registration messages of CCID 2/3 a bit more
    informative: instead of repeating the CCID number as currently done,

    "CCID: Registered CCID 2 (ccid2)" or
    "CCID: Registered CCID 3 (ccid3)",

    the descriptive names of the CCID's (from RFCs) are now used:

    "CCID: Registered CCID 2 (TCP-like)" and
    "CCID: Registered CCID 3 (TCP-Friendly Rate Control)".

    To allow spaces in the name, the slab name string has been changed to
    refer to the numeric CCID identifier, using the same format as before.

    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
     

14 Aug, 2007

1 commit


20 Jul, 2007

1 commit

  • Slab destructors were no longer supported after Christoph's
    c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
    BUGs for both slab and slub, and slob never supported them
    either.

    This rips out support for the dtor pointer from kmem_cache_create()
    completely and fixes up every single callsite in the kernel (there were
    about 224, not including the slab allocator definitions themselves,
    or the documentation references).

    Signed-off-by: Paul Mundt

    Paul Mundt
     

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
     

21 Mar, 2006

2 commits

  • 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
     
  • Testing if the ccid being instantiated has these methods in
    ccid_init().

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

    Arnaldo Carvalho de Melo
     

30 Aug, 2005

1 commit

  • 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