Hello,
On Sat, 20 Apr 2013, Dan Carpenter wrote:
> The sctp_events[] come from sch->type in set_sctp_state(). They are
> between 0-255 so that means we need 256 elements in the array.
>
> I believe that because of how the code is aligned there is normally a
> hole after sctp_events[] so this patch doesn't actually change anything.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> ---
> This is static checker stuff. I'm not very familiar with this code.
>
> diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> index 6e14a7b..8646488 100644
> --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> @@ -208,7 +208,7 @@ enum ipvs_sctp_event_t {
> IP_VS_SCTP_EVE_LAST
> };
>
> -static enum ipvs_sctp_event_t sctp_events[255] = {
> +static enum ipvs_sctp_event_t sctp_events[256] = {
> IP_VS_SCTP_EVE_DATA_CLI,
> IP_VS_SCTP_EVE_INIT_CLI,
> IP_VS_SCTP_EVE_INIT_ACK_CLI,
There are more confusing (still, non-fatal)
problems in this IPVS-SCTP support, eg.
if (direction == IP_VS_DIR_OUTPUT)
- event++;
+ event *= 2;
I guess we are running with wrong timeouts.
Also, I'm not sure we support properly the
one-way states as done for TCP (IP_VS_DIR_INPUT_ONLY).
May be this code deserves more serious review, for example,
net/netfilter/nf_conntrack_proto_sctp.c looks as good
source for comparison.
Anyways, this change looks correct to me,
Acked-by: Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
