2005-08-10 07:14:34 +04:00
|
|
|
/*
|
|
|
|
* net/dccp/ccid.c
|
|
|
|
*
|
|
|
|
* An implementation of the DCCP protocol
|
|
|
|
* Arnaldo Carvalho de Melo <acme@conectiva.com.br>
|
|
|
|
*
|
|
|
|
* CCID infrastructure
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit 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>
2010-03-24 11:04:11 +03:00
|
|
|
#include <linux/slab.h>
|
|
|
|
|
2005-08-10 07:14:34 +04:00
|
|
|
#include "ccid.h"
|
2009-01-05 08:45:33 +03:00
|
|
|
#include "ccids/lib/tfrc.h"
|
2005-08-10 07:14:34 +04:00
|
|
|
|
2009-01-05 08:42:53 +03:00
|
|
|
static struct ccid_operations *ccids[] = {
|
|
|
|
&ccid2_ops,
|
|
|
|
#ifdef CONFIG_IP_DCCP_CCID3
|
|
|
|
&ccid3_ops,
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct ccid_operations *ccid_by_number(const u8 id)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(ccids); i++)
|
|
|
|
if (ccids[i]->ccid_id == id)
|
|
|
|
return ccids[i];
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* check that up to @array_len members in @ccid_array are supported */
|
|
|
|
bool ccid_support_check(u8 const *ccid_array, u8 array_len)
|
|
|
|
{
|
|
|
|
while (array_len > 0)
|
|
|
|
if (ccid_by_number(ccid_array[--array_len]) == NULL)
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ccid_get_builtin_ccids - Populate a list of built-in CCIDs
|
|
|
|
* @ccid_array: pointer to copy into
|
|
|
|
* @array_len: value to return length into
|
2012-07-10 14:55:09 +04:00
|
|
|
*
|
2009-01-05 08:42:53 +03:00
|
|
|
* This function allocates memory - caller must see that it is freed after use.
|
|
|
|
*/
|
|
|
|
int ccid_get_builtin_ccids(u8 **ccid_array, u8 *array_len)
|
|
|
|
{
|
|
|
|
*ccid_array = kmalloc(ARRAY_SIZE(ccids), gfp_any());
|
|
|
|
if (*ccid_array == NULL)
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
|
|
|
for (*array_len = 0; *array_len < ARRAY_SIZE(ccids); *array_len += 1)
|
|
|
|
(*ccid_array)[*array_len] = ccids[*array_len]->ccid_id;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ccid_getsockopt_builtin_ccids(struct sock *sk, int len,
|
|
|
|
char __user *optval, int __user *optlen)
|
|
|
|
{
|
|
|
|
u8 *ccid_array, array_len;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (ccid_get_builtin_ccids(&ccid_array, &array_len))
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
2010-02-07 23:20:28 +03:00
|
|
|
if (put_user(array_len, optlen))
|
|
|
|
err = -EFAULT;
|
|
|
|
else if (len > 0 && copy_to_user(optval, ccid_array,
|
|
|
|
len > array_len ? array_len : len))
|
2009-01-05 08:42:53 +03:00
|
|
|
err = -EFAULT;
|
|
|
|
|
|
|
|
kfree(ccid_array);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
dccp: fix dccp rmmod when kernel configured to use slub
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 <nhorman@tuxdriver.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-17 20:16:12 +03:00
|
|
|
static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char *slab_name_fmt, const char *fmt,...)
|
2005-08-10 07:14:34 +04:00
|
|
|
{
|
2006-12-07 07:33:20 +03:00
|
|
|
struct kmem_cache *slab;
|
2006-03-21 06:21:44 +03:00
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
2010-02-01 05:12:19 +03:00
|
|
|
vsnprintf(slab_name_fmt, CCID_SLAB_NAME_LENGTH, fmt, args);
|
2006-03-21 06:21:44 +03:00
|
|
|
va_end(args);
|
|
|
|
|
dccp: fix dccp rmmod when kernel configured to use slub
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 <nhorman@tuxdriver.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-17 20:16:12 +03:00
|
|
|
slab = kmem_cache_create(slab_name_fmt, sizeof(struct ccid) + obj_size, 0,
|
2007-07-20 05:11:58 +04:00
|
|
|
SLAB_HWCACHE_ALIGN, NULL);
|
2006-03-21 06:21:44 +03:00
|
|
|
return slab;
|
|
|
|
}
|
|
|
|
|
2006-12-07 07:33:20 +03:00
|
|
|
static void ccid_kmem_cache_destroy(struct kmem_cache *slab)
|
2006-03-21 06:21:44 +03:00
|
|
|
{
|
dccp: fix dccp rmmod when kernel configured to use slub
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 <nhorman@tuxdriver.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-17 20:16:12 +03:00
|
|
|
if (slab != NULL)
|
2006-03-21 06:21:44 +03:00
|
|
|
kmem_cache_destroy(slab);
|
|
|
|
}
|
|
|
|
|
2014-10-01 08:52:06 +04:00
|
|
|
static int __init ccid_activate(struct ccid_operations *ccid_ops)
|
2006-03-21 06:21:44 +03:00
|
|
|
{
|
|
|
|
int err = -ENOBUFS;
|
|
|
|
|
|
|
|
ccid_ops->ccid_hc_rx_slab =
|
|
|
|
ccid_kmem_cache_create(ccid_ops->ccid_hc_rx_obj_size,
|
dccp: fix dccp rmmod when kernel configured to use slub
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 <nhorman@tuxdriver.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-17 20:16:12 +03:00
|
|
|
ccid_ops->ccid_hc_rx_slab_name,
|
2007-12-14 04:33:25 +03:00
|
|
|
"ccid%u_hc_rx_sock",
|
|
|
|
ccid_ops->ccid_id);
|
2006-03-21 06:21:44 +03:00
|
|
|
if (ccid_ops->ccid_hc_rx_slab == NULL)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ccid_ops->ccid_hc_tx_slab =
|
|
|
|
ccid_kmem_cache_create(ccid_ops->ccid_hc_tx_obj_size,
|
dccp: fix dccp rmmod when kernel configured to use slub
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 <nhorman@tuxdriver.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-17 20:16:12 +03:00
|
|
|
ccid_ops->ccid_hc_tx_slab_name,
|
2007-12-14 04:33:25 +03:00
|
|
|
"ccid%u_hc_tx_sock",
|
|
|
|
ccid_ops->ccid_id);
|
2006-03-21 06:21:44 +03:00
|
|
|
if (ccid_ops->ccid_hc_tx_slab == NULL)
|
|
|
|
goto out_free_rx_slab;
|
2005-08-10 07:14:34 +04:00
|
|
|
|
2011-07-03 19:51:14 +04:00
|
|
|
pr_info("DCCP: Activated CCID %d (%s)\n",
|
2006-03-21 06:21:44 +03:00
|
|
|
ccid_ops->ccid_id, ccid_ops->ccid_name);
|
2009-01-05 08:42:53 +03:00
|
|
|
err = 0;
|
2006-03-21 06:21:44 +03:00
|
|
|
out:
|
2005-08-10 07:14:34 +04:00
|
|
|
return err;
|
2006-03-21 06:21:44 +03:00
|
|
|
out_free_rx_slab:
|
|
|
|
ccid_kmem_cache_destroy(ccid_ops->ccid_hc_rx_slab);
|
|
|
|
ccid_ops->ccid_hc_rx_slab = NULL;
|
|
|
|
goto out;
|
2005-08-10 07:14:34 +04:00
|
|
|
}
|
|
|
|
|
2009-01-05 08:42:53 +03:00
|
|
|
static void ccid_deactivate(struct ccid_operations *ccid_ops)
|
2005-08-10 07:14:34 +04:00
|
|
|
{
|
2006-03-21 06:21:44 +03:00
|
|
|
ccid_kmem_cache_destroy(ccid_ops->ccid_hc_tx_slab);
|
|
|
|
ccid_ops->ccid_hc_tx_slab = NULL;
|
|
|
|
ccid_kmem_cache_destroy(ccid_ops->ccid_hc_rx_slab);
|
|
|
|
ccid_ops->ccid_hc_rx_slab = NULL;
|
|
|
|
|
2011-07-03 19:51:14 +04:00
|
|
|
pr_info("DCCP: Deactivated CCID %d (%s)\n",
|
2006-03-21 06:21:44 +03:00
|
|
|
ccid_ops->ccid_id, ccid_ops->ccid_name);
|
2005-08-10 07:14:34 +04:00
|
|
|
}
|
|
|
|
|
2009-01-05 08:43:23 +03:00
|
|
|
struct ccid *ccid_new(const u8 id, struct sock *sk, bool rx)
|
2005-08-10 07:14:34 +04:00
|
|
|
{
|
2009-01-05 08:42:53 +03:00
|
|
|
struct ccid_operations *ccid_ops = ccid_by_number(id);
|
2006-03-21 06:21:44 +03:00
|
|
|
struct ccid *ccid = NULL;
|
2005-08-10 07:14:34 +04:00
|
|
|
|
2006-03-21 06:21:44 +03:00
|
|
|
if (ccid_ops == NULL)
|
2009-01-05 08:42:53 +03:00
|
|
|
goto out;
|
2005-08-10 07:14:34 +04:00
|
|
|
|
2006-03-21 06:21:44 +03:00
|
|
|
ccid = kmem_cache_alloc(rx ? ccid_ops->ccid_hc_rx_slab :
|
2009-01-05 08:43:23 +03:00
|
|
|
ccid_ops->ccid_hc_tx_slab, gfp_any());
|
2006-03-21 06:21:44 +03:00
|
|
|
if (ccid == NULL)
|
2009-01-05 08:42:53 +03:00
|
|
|
goto out;
|
2006-03-21 06:21:44 +03:00
|
|
|
ccid->ccid_ops = ccid_ops;
|
|
|
|
if (rx) {
|
|
|
|
memset(ccid + 1, 0, ccid_ops->ccid_hc_rx_obj_size);
|
|
|
|
if (ccid->ccid_ops->ccid_hc_rx_init != NULL &&
|
|
|
|
ccid->ccid_ops->ccid_hc_rx_init(ccid, sk) != 0)
|
|
|
|
goto out_free_ccid;
|
|
|
|
} else {
|
|
|
|
memset(ccid + 1, 0, ccid_ops->ccid_hc_tx_obj_size);
|
|
|
|
if (ccid->ccid_ops->ccid_hc_tx_init != NULL &&
|
|
|
|
ccid->ccid_ops->ccid_hc_tx_init(ccid, sk) != 0)
|
|
|
|
goto out_free_ccid;
|
|
|
|
}
|
2005-08-10 07:14:34 +04:00
|
|
|
out:
|
|
|
|
return ccid;
|
2006-03-21 06:21:44 +03:00
|
|
|
out_free_ccid:
|
|
|
|
kmem_cache_free(rx ? ccid_ops->ccid_hc_rx_slab :
|
|
|
|
ccid_ops->ccid_hc_tx_slab, ccid);
|
2005-08-10 07:14:34 +04:00
|
|
|
ccid = NULL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2006-03-21 06:21:44 +03:00
|
|
|
void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk)
|
|
|
|
{
|
2009-01-05 08:43:23 +03:00
|
|
|
if (ccid != NULL) {
|
|
|
|
if (ccid->ccid_ops->ccid_hc_rx_exit != NULL)
|
|
|
|
ccid->ccid_ops->ccid_hc_rx_exit(sk);
|
|
|
|
kmem_cache_free(ccid->ccid_ops->ccid_hc_rx_slab, ccid);
|
|
|
|
}
|
2006-03-21 06:21:44 +03:00
|
|
|
}
|
2005-08-10 07:14:34 +04:00
|
|
|
|
2006-03-21 06:21:44 +03:00
|
|
|
void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk)
|
|
|
|
{
|
2009-01-05 08:43:23 +03:00
|
|
|
if (ccid != NULL) {
|
|
|
|
if (ccid->ccid_ops->ccid_hc_tx_exit != NULL)
|
|
|
|
ccid->ccid_ops->ccid_hc_tx_exit(sk);
|
|
|
|
kmem_cache_free(ccid->ccid_ops->ccid_hc_tx_slab, ccid);
|
|
|
|
}
|
2005-08-10 07:14:34 +04:00
|
|
|
}
|
|
|
|
|
2009-01-05 08:42:53 +03:00
|
|
|
int __init ccid_initialize_builtins(void)
|
|
|
|
{
|
2009-01-05 08:45:33 +03:00
|
|
|
int i, err = tfrc_lib_init();
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
return err;
|
2009-01-05 08:42:53 +03:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(ccids); i++) {
|
|
|
|
err = ccid_activate(ccids[i]);
|
|
|
|
if (err)
|
|
|
|
goto unwind_registrations;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
unwind_registrations:
|
|
|
|
while(--i >= 0)
|
|
|
|
ccid_deactivate(ccids[i]);
|
2009-01-05 08:45:33 +03:00
|
|
|
tfrc_lib_exit();
|
2009-01-05 08:42:53 +03:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ccid_cleanup_builtins(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(ccids); i++)
|
|
|
|
ccid_deactivate(ccids[i]);
|
2009-01-05 08:45:33 +03:00
|
|
|
tfrc_lib_exit();
|
2009-01-05 08:42:53 +03:00
|
|
|
}
|