BMC/Intel-BMC/linux.git/net/dccp/ccids/ccid3.c, branch dev

dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)

2012-08-16T04:36:31+00:00

The CCID3 code fails to initialize the trailing padding bytes of struct tfrc_tx_info added for alignment on 64 bit architectures. It that for potentially leaks four bytes kernel stack via the getsockopt() syscall. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Cc: Gerrit Renker Signed-off-by: David S. Miller

net: Fix (nearly-)kernel-doc comments for various functions

2012-07-11T06:13:45+00:00

Fix incorrect start markers, wrapped summary lines, missing section breaks, incorrect separators, and some name mismatches. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller

net: cleanup unsigned to unsigned int

2012-04-15T16:44:40+00:00

Use of "unsigned int" is preferred to bare "unsigned" in net tree. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

dccp ccid-3: replace incorrect BUG_ON

2012-03-03T16:02:36+00:00

This replaces an unjustified BUG_ON(), which could get triggered under normal conditions: X_calc can be 0 when p > 0. X would in this case be set to the minimum, s/t_mbi. Its replacement avoids t_ipi = 0 (unbounded sending rate). Thanks to Jordi, Victor and Xavier who reported this. Signed-off-by: Gerrit Renker Acked-by: Ian McDonald

module_param: make bool parameters really bool (net & drivers/net)

2011-12-20T03:27:29+00:00

module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. (Thanks to Joe Perches for suggesting coccinelle for 0/1 -> true/false). Cc: "David S. Miller" Cc: netdev@vger.kernel.org Signed-off-by: Rusty Russell Signed-off-by: David S. Miller

dccp: Return-value convention of hc_tx_send_packet()

2010-10-28T17:27:00+00:00

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

dccp: remove unused argument in CCID tx function

2010-10-12T04:57:41+00:00

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

dccp ccid-3: Remove redundant 'options_received' struct

2010-09-21T10:14:26+00:00

The `options_received' struct is redundant, since it re-duplicates the existing `p' and `x_recv' fields. This patch removes the sub-struct and migrates the format conversion operations to ccid3_hc_tx_parse_options(). Signed-off-by: Gerrit Renker

dccp tfrc/ccid-3: computing the loss rate from the Loss Event Rate

2010-09-21T10:14:26+00:00

This adds a function to take care of the following, separate cases occurring in the computation of the Loss Rate p: * 1/(2^32-1) is mapped into 0% as per RFC 4342, 8.5; * 1/0 is mapped into 100%, the maximum; * to avoid that p = 1/x is rounded down to 0 when x is very large, since this means accidentally re-entering slow-start indicated by p == 0, the minimum resolution value of p is now returned instead; * a bug in ccid3_hc_rx_getsockopt is fixed: 1/0 was mapped into ~0U. Signed-off-by: Gerrit Renker

dccp ccid-3: remove dead states

2010-09-21T10:14:26+00:00

This patch is thanks to an investigation by Leandro Sales de Melo and his colleagues. They worked out two state diagrams which highlight the fact that the xxx_TERM states in CCID-3/4 are in fact not necessary. And this can be confirmed by in turn looking at the code: the xxx_TERM states are only ever set in ccid3_hc_{rx,tx}_exit(): when CCID-3 sets the state to xxx_TERM, it is at a time where no more processing should be going on, hence it is not necessary to introduce a dedicated exit state - this is already implied by unloading the CCID. Signed-off-by: Gerrit Renker