| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] PATCH for NULL pointer in netback_uevent
>
> >>> 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
|
|
|
| |
|
Home