Searched hist:ff2266cd (Results 1 – 3 of 3) sorted by relevance
/openbmc/linux/net/sctp/ |
H A D | endpointola.c | ff2266cd Sun Apr 14 22:27:17 CDT 2013 Daniel Borkmann <dborkman@redhat.com> net: sctp: remove sctp_ep_common struct member 'malloced'
There is actually no need to keep this member in the structure, because after init it's always 1 anyway, thus always kfree called. This seems to be an ancient leftover from the very initial implementation from 2.5 times. Only in case the initialization of an association fails, we leave base.malloced as 0, but we nevertheless kfree it in the error path in sctp_association_new().
Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> ff2266cd Sun Apr 14 22:27:17 CDT 2013 Daniel Borkmann <dborkman@redhat.com> net: sctp: remove sctp_ep_common struct member 'malloced' There is actually no need to keep this member in the structure, because after init it's always 1 anyway, thus always kfree called. This seems to be an ancient leftover from the very initial implementation from 2.5 times. Only in case the initialization of an association fails, we leave base.malloced as 0, but we nevertheless kfree it in the error path in sctp_association_new(). Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
H A D | associola.c | ff2266cd Sun Apr 14 22:27:17 CDT 2013 Daniel Borkmann <dborkman@redhat.com> net: sctp: remove sctp_ep_common struct member 'malloced'
There is actually no need to keep this member in the structure, because after init it's always 1 anyway, thus always kfree called. This seems to be an ancient leftover from the very initial implementation from 2.5 times. Only in case the initialization of an association fails, we leave base.malloced as 0, but we nevertheless kfree it in the error path in sctp_association_new().
Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> ff2266cd Sun Apr 14 22:27:17 CDT 2013 Daniel Borkmann <dborkman@redhat.com> net: sctp: remove sctp_ep_common struct member 'malloced' There is actually no need to keep this member in the structure, because after init it's always 1 anyway, thus always kfree called. This seems to be an ancient leftover from the very initial implementation from 2.5 times. Only in case the initialization of an association fails, we leave base.malloced as 0, but we nevertheless kfree it in the error path in sctp_association_new(). Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
/openbmc/linux/include/net/sctp/ |
H A D | structs.h | ff2266cd Sun Apr 14 22:27:17 CDT 2013 Daniel Borkmann <dborkman@redhat.com> net: sctp: remove sctp_ep_common struct member 'malloced'
There is actually no need to keep this member in the structure, because after init it's always 1 anyway, thus always kfree called. This seems to be an ancient leftover from the very initial implementation from 2.5 times. Only in case the initialization of an association fails, we leave base.malloced as 0, but we nevertheless kfree it in the error path in sctp_association_new().
Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> ff2266cd Sun Apr 14 22:27:17 CDT 2013 Daniel Borkmann <dborkman@redhat.com> net: sctp: remove sctp_ep_common struct member 'malloced' There is actually no need to keep this member in the structure, because after init it's always 1 anyway, thus always kfree called. This seems to be an ancient leftover from the very initial implementation from 2.5 times. Only in case the initialization of an association fails, we leave base.malloced as 0, but we nevertheless kfree it in the error path in sctp_association_new(). Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|