WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PATCH for NULL pointer in netback_uevent

To: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] PATCH for NULL pointer in netback_uevent
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 28 May 2010 08:15:05 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 May 2010 00:17:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01996BE1@trantor>
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>
References: <AEC6C66638C05B468B556EA548C1A77D01996BE1@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 28.05.10 at 02:58, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:
> The following is sufficient to get domain creation working on my server
> (see threads "null-pointer access in netback_uevent" and "oops starting
> domain on 4.0.0  + 2.6.32.13-gf6fe658"). I'm not sure if it's the right
> solution though - should we expect a call to netback_uevent before the
> vif is properly set up? All I'm doing is returning 0 (success?) if the
> drvdata hasn't been set yet.

We've seen this just now too (with our non-pv-ops kernel). Since this
can be called due to sysfs reads (starting in 2.6.22), the function
must be prepared to be called at any time. I do think, however, that
it should provide as much data as possible in this state, i.e. not
plainly return zero in that case, but at least add the "script=" setting
(which is independent of "be" being NULL).

Even then we still depend on uevent not caching the output (but
rather re-issuing the read) once the backend for the new vif is fully
set up.

Jan


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

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