This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Possible overflow in netbk_get_requests()

To: Simon Horman <horms@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Possible overflow in netbk_get_requests()
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 04 Aug 2008 11:35:30 +0100
Delivery-date: Mon, 04 Aug 2008 03:36:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080804024832.GA10400@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acj2HdDxD0OiGGIREd2MqAAX8io7RQ==
Thread-topic: [Xen-devel] Possible overflow in netbk_get_requests()
User-agent: Microsoft-Entourage/
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@xxxxxxxxxxxx> 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

<Prev in Thread] Current Thread [Next in Thread>