lkml.org 
[lkml]   [2013]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] net: sctp: bug fixing when sctp path recovers

On 11/13/2013 09:44 AM, Daniel Borkmann wrote:
> On 11/13/2013 03:54 AM, Chang wrote:
>> On 11/13/2013 03:37 AM, Vlad Yasevich wrote:
>>> On 11/12/2013 08:34 PM, Chang Xiangzhong wrote:
>>>> Look for the __two__ most recently used path/transport and set to
>>>> active_path
>>>> and retran_path respectively
>
> Please also for the log, elaborate a bit more, explaining what currently
> happens, and what the effects of this bug are, so that later when people
> are looking through the Git log they can easily get what problem you are
> trying to fix; and if possible, add:
>
> Fixes: <12 digits SHA1> ("<commit title>")
>
Yeah, sure, I'll elaborate that more specifically.
I assume the 12-digit SHA1 is the revision number. But may I ask where
and how shall I add the tag "Fixes" tag? The revision number is
generated after "git commit", how can I know that in advance?

Best Regards!

>>>> Signed-off-by: changxiangzhong@gmail.com
>>>> ---
>>>> net/sctp/associola.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
>>>> index ab67efc..070011a 100644
>>>> --- a/net/sctp/associola.c
>>>> +++ b/net/sctp/associola.c
>>>> @@ -913,11 +913,15 @@ void sctp_assoc_control_transport(struct
>>>> sctp_association *asoc,
>>>> if (!first || t->last_time_heard > first->last_time_heard) {
>>>> second = first;
>>>> first = t;
>>>> + continue;
>>>> }
>>>> if (!second || t->last_time_heard > second->last_time_heard)
>>>> second = t;
>>>
>>> You might as well remove this bit and then you don't need a continue.
>> I don't think we could remove this bit. My understanding of these
>> algorithms are to find the 1st recently used path and the 2nd,
>> assigning to active_path and retran_path respectively. If we remove
>> the looking-for-second block, how are we suppose to find the 2nd?
>> I think we can remove the continue and use else-if in the
>> 2nd-assignment-block.
>>>
>>>> }
>>>>
>>>> + if (!second)
>>>> + second = first;
>>>> +
>>>
>>> This needs to move down 1 more block. Set the second transport
>>> after we
>>> check to see if the primary is back up and we need to go back to
>>> using it.
>>>
>>> -vlad
>>>
>> I agree with this change
>>>> /* RFC 2960 6.4 Multi-Homed SCTP Endpoints
>>>> *
>>>> * By default, an endpoint should always transmit to the
>>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html



\
 
 \ /
  Last update: 2013-11-13 20:41    [W:0.062 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site