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] Grant Table Network Issues

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Grant Table Network Issues
From: David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>
Date: Sun, 14 Aug 2005 17:53:36 +0100
Delivery-date: Sun, 14 Aug 2005 16:51:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050814153953.GA5037@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20050813185945.GA23341@xxxxxxxxxx> <85c87b7ce2e667949306ca7da953d219@xxxxxxxxxxxx> <20050814153953.GA5037@xxxxxxxxxx>
Reply-to: david.nospam.hopwood@xxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
Michael Vrable wrote:
On Sun, Aug 14, 2005 at 09:29:02AM +0100, Keir Fraser wrote:
On 13 Aug 2005, at 19:59, Michael Vrable wrote:

The line causing trouble is "BUG_ON(in_irq())". [...]

The only code between irq_exit and kmap_skb_frag on the stack trace is unmodified Linux code. Assuming that is all correct (and presumably the same whether we enable grant tables or not) I might guess another interrupt arrives and the handler corrupts things?

I discovered the cause of this and other crashes yesterday: when grant
tables are enabled in the netback driver, net_tx_action() and
net_tx_action_dealloc() in netback.c each allocate large arrays from the
kernel's stack ("gnttab_map_grant_ref_t map_ops[MAX_PENDING_REQS]" and
"gnttab_unmap_grant_ref_t unmap_ops[MAX_PENDING_REQS]").  This results
in a stack overflow.

Is there no way to make a kernel stack overflow fail fast with an obvious
error, rather than causing other subtle failures?

David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>

Xen-devel mailing list