netdev - Re: [PATCH 6/7] [TCP]: Fix lost_retrans loop vs fastpath problems

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: <20071011.173550.39320216.davem@davemloft.net>
Date:	Thu, 11 Oct 2007 17:35:50 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	netdev@...r.kernel.org, takano@...-inc.co.jp
Subject: Re: [PATCH 6/7] [TCP]: Fix lost_retrans loop vs fastpath problems

From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Thu, 11 Oct 2007 14:41:06 +0300

> Detection implemented with lost_retrans must work also when
> fastpath is taken, yet most of the queue is skipped including
> (very likely) those retransmitted skb's we're interested in.
> This problem appeared when the hints got added, which removed
> a need to always walk over the whole write queue head.
> Therefore decicion for the lost_retrans worker loop entry must
> be separated from the sacktag processing more than it was
> necessary before.
> 
> It turns out to be problematic to optimize the worker loop
> very heavily because ack_seqs of skb may have a number of
> discontinuity points. Maybe similar approach as currently is
> implemented could be attempted but that's becoming more and
> more complex because the trend is towards less skb walking
> in sacktag marker. Trying a simple work until all rexmitted
> skbs heve been processed approach.
> 
> Maybe after(highest_sack_end_seq, tp->high_seq) checking is not
> sufficiently accurate and causes entry too often in no-work-to-do
> cases. Since that's not known, I've separated solution to that
> from this patch.
> 
> Noticed because of report against a related problem from TAKANO
> Ryousei <takano@...-inc.co.jp>. He also provided a patch to
> that part of the problem. This patch includes solution to it
> (though this patch has to use somewhat different placement).
> TAKANO's description and patch is available here:
> 
>   http://marc.info/?l=linux-netdev&m=119149311913288&w=2
> 
> ...In short, TAKANO's problem is that end_seq the loop is using
> not necessarily the largest SACK block's end_seq because the
> current ACK may still have higher SACK blocks which are later
> by the loop.
> 
> Cc: TAKANO Ryousei <takano@...-inc.co.jp>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>

Applied.
-
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