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

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> 
> >>> 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.

My assumption was that it happened because I upgraded udev which meant
turning off CONFIG_SYSFS_DEPRECATED_V2, and that one of those has
triggered the problem.

> 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).

Agreed. My patch got things up and running again for me, but I suspected
it wasn't really the correct approach.

> 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.
> 

I put debugging statements in and there were definitely multiple calls
to netback_uevent, if that counts for anything.

James


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