[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Jan Beulich" <JBeulich@xxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Fri, 28 May 2010 17:22:55 +1000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 28 May 2010 00:25:34 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acr+NYmTrocjGgrlQ0SZ5H+6woRSIgAALWGQ
  • Thread-topic: [Xen-devel] PATCH for NULL pointer in netback_uevent

> >>> On 28.05.10 at 02:58, "James Harper"
> wrote:
> > The following is sufficient to get domain creation working on my
> > (see threads "null-pointer access in netback_uevent" and "oops
> > domain on 4.0.0  +"). I'm not sure if it's the
> > solution though - should we expect a call to netback_uevent before
> > vif is properly set up? All I'm doing is returning 0 (success?) if
> > 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="
> (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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.