netdev - Re: lots of cpu time spent in skb_copy_bits() in net-next with small mtu

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 17 Jun 2009 09:57:19 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	David Miller <davem@...emloft.net>
cc:	john.dykstra1@...il.com, ben.lahaise@...erion.com,
	Netdev <netdev@...r.kernel.org>
Subject: Re: lots of cpu time spent in skb_copy_bits() in net-next with small
 mtu

On Tue, 16 Jun 2009, David Miller wrote:

> From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
> Date: Wed, 17 Jun 2009 08:46:56 +0300 (EEST)
> 
> > While I took a very short view on it earlier I notice that handling of the 
> > case when head is at the last skb and tail is at the end of queue was 
> > changed (without mention in the commit message whether it was 
> > intentionally) in the Dave's change (we used to exit at skb == tail while 
> > we don't necessarily do that anymore but take the additional checks that 
> > are made inside the loop ub tcp_collapse()). It would be nice if Dave 
> > would split that kind of complex transformation into more easily 
> > verifiable changes, even if the intermediate form itself would not remain 
> > in the final form, as is it's rather hard to track it all :-).
> > 
> > I'm not sure if that change is significant though as one might view it as 
> > the opposite, ie., that the previous was unintented early exit since we 
> > wouldn't collapse bloated skb in the end but who knows... ...But I'm yet 
> > to really _understand_ everything that is going on there.
> 
> Sorry, will be more careful in the future. :-)

I re-looked into the problem I supposedly found earlier and it seems that
it turned out to be a false alarm... Huoh, how complex it is track that 
change :-).

> Can we atleast verify that applying the following revert patch makes
> the problem go away?  (it's a combination revert of commits
> 2df9001edc382c331f338f45d259feeaa740c418 and
> 915219441d566f1da0caa0e262be49b666159e17).

Yeah, that's a good start...

-- 
 i.

ps. I'll be out of reach of email access for a week.