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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 16 Sep 2008 18:25:34 +0300
From:	Eli Cohen <>
To:	Ben Hutchings <>
Subject: Re: LRO num of frags limit

On Tue, Sep 16, 2008 at 11:40:17AM +0100, Ben Hutchings wrote:
> On Tue, 2008-09-16 at 10:36 +0300, Eli Cohen wrote:
> > Hi,
> > 
> > looking at the LRO code, at __lro_proc_segment(), it seems that the
> > network driver can configure lro_mgr->max_aggr to any value it wants
> > while the number of fragments aggregated must not exceed MAX_SKB_FRAGS
> Correct.
> > (since we only use a single SKB to aggregate fragments, allocated by
> > lro_gen_skb()). Moreover, even if the driver does limit
> > lro_mgr->max_aggr to MAX_SKB_FRAGS, it might still cause overflow
> > since subsequent aggregations are done at lro_add_frags() which is
> > called before checking whether we overflow.
> So you must set max_aggr to
> MAX_SKB_FRAGS - max number of frags added at once + 1.
> > If the above observation is correct, I can send a patch.
> I would be interested to see that, anyway.
By the way, we need to introduce two kinds of "max_aggr" fields to
struct net_lro_mgr. The reason is that when LRO is used in the mode in
which SKBs are linked, the above limitation does not exist. One will
be used for drivers which use lro_receive_skb() (which does not have a
limit) and one for drivers which use lro_receive_frags(). This will
require changing all the drivers that use LRO.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists