Xen devel - Aug 2008 - Possible overflow in netbk_get_requests()

Hi,

I''m wondering if the call to netbk_get_requests() in
net_tx_action() might cause an overflow in the case where
there are more fragments than available slots in tx_map_ops (aka mop).

-- 
Horms


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

netbk_count_frags() should check we have no more than MAX_SKB_FRAGS for this
packet, and the loop header in net_tx_action() checks we do no more than
MAX_PENDING_REQS fragments of work (this is subtle: NR_PENDING_REQS cannot
decrease while we execute the loop!).

It''s all a bit too subtle for its own good. ;-)

 -- Keir

On 4/8/08 03:48, "Simon Horman" <horms@verge.net.au> wrote:
> Hi,
> 
> I''m wondering if the call to netbk_get_requests() in
> net_tx_action() might cause an overflow in the case where
> there are more fragments than available slots in tx_map_ops (aka mop).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Thanks, I wasn''t keeping my eye on pending_prod.

On Mon, Aug 04, 2008 at 11:35:30AM +0100, Keir Fraser
wrote:
> netbk_count_frags() should check we have no more than MAX_SKB_FRAGS for
this
> packet, and the loop header in net_tx_action() checks we do no more than
> MAX_PENDING_REQS fragments of work (this is subtle: NR_PENDING_REQS cannot
> decrease while we execute the loop!).
> 
> It''s all a bit too subtle for its own good. ;-)
> 
>  -- Keir
> 
> On 4/8/08 03:48, "Simon Horman" <horms@verge.net.au> wrote:
> 
> > Hi,
> > 
> > I''m wondering if the call to netbk_get_requests() in
> > net_tx_action() might cause an overflow in the case where
> > there are more fragments than available slots in tx_map_ops (aka mop).
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel