netdev - Re: [PATCH] sctp: Do not account for sizeof(struct sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EF0CD69.9000602@hp.com>
Date:	Tue, 20 Dec 2011 13:01:13 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Wei Yongjun <weiyj.lk@...il.com>, linux-sctp@...r.kernel.org,
	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] sctp: Do not account for sizeof(struct sk_buff) in estimated
 rwnd



On 12/20/2011 04:39 AM, Thomas Graf wrote:
> On Tue, Dec 20, 2011 at 01:00:48PM +0800, Wei Yongjun wrote:
>> I saw you discussed this with Vlad in old mail:
>>      http://www.spinics.net/lists/linux-sctp/msg01365.html
>>
>> You said you will update patch to include a per packet overhead,
>> but it does not include in this patch, what's wrong with in?
>
> It's not possible because upon retransmission of a chunk we need
> to readd the overhead to the rwnd. There is no longer a reference
> to a packet so we can't know how much to add. This explanation is
> also in the original mail thread.
>


Right.  The original patches were done to work around the problem of
leftover rwnd when socket buffer is exhausted and they didn't really
address the problem sufficiently.  It was still possible to reach that
condition.  Some subsequent patches added support to address this issue
a different way.  As a result, I think this revert is just fine.

Acked-by: Vlad Yasevich <vladislav.yasevich@...com>

-vlad
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html