Date: Wed, 25 Mar 2009 11:04:31 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r189574 - head/sys/kern Message-ID: <20090325.110431.-165354456.imp@bsdimp.com> In-Reply-To: <200903251259.20921.jhb@freebsd.org> References: <200903091320.n29DKNT8027311@svn.freebsd.org> <200903251259.20921.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
In message: <200903251259.20921.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> writes:
: On Monday 09 March 2009 9:20:23 am Warner Losh wrote:
: > Author: imp
: > Date: Mon Mar 9 13:20:23 2009
: > New Revision: 189574
: > URL: http://svn.freebsd.org/changeset/base/189574
: >
: > Log:
: > Fix a long-standing bug in newbus. It was introduced when subclassing
: > was introduced. If you have a bus, say cardbus, that is derived from
: > a base-bus (say PCI), then ordinarily all PCI drivers would attach to
: > cardbus devices. However, there had been one exception: kldload
: > wouldn't work.
: >
: > The problem is in devclass_add_driver. In this routine, all we did
: > was call to the pci device's BUS_DRIVER_ADDED routine. However, since
: > cardbus bus instances had a different devclass, none of them were
: > called.
: >
: > Modified: head/sys/kern/subr_bus.c
: >
: ==============================================================================
: > --- head/sys/kern/subr_bus.c Mon Mar 9 13:12:48 2009 (r189573)
: > +++ head/sys/kern/subr_bus.c Mon Mar 9 13:20:23 2009 (r189574)
: > @@ -82,6 +82,8 @@ struct devclass {
: > char *name;
: > device_t *devices; /* array of devices indexed by unit */
: > int maxunit; /* size of devices array */
: > + int flags;
: > +#define DC_HAS_CHILDREN 1
: >
: > struct sysctl_ctx_list sysctl_ctx;
: > struct sysctl_oid *sysctl_tree;
: > @@ -813,6 +815,7 @@ devclass_find_internal(const char *class
: > if (parentname && dc && !dc->parent &&
: > strcmp(classname, parentname) != 0) {
: > dc->parent = devclass_find_internal(parentname, NULL, FALSE);
: > + dc->parent->flags |= DC_HAS_CHILDREN;
: > }
: >
: > return (dc);
:
: So this is the cause of the recent reports of panics on boot. The problem is
: that when drivers are registered during boot they are loaded in a "random"
: order (depends on the order the objects are linked actually). The point,
: though, is that a subclass might register first. In that case, trying to set
: dc->parent will fail because the parent driver isn't registered yet, so
: dc->parent will be NULL when it tries to set DC_HAS_CHILDREN. Just not
: setting the flag if dc->parent is NULL will fix the panics, but I think you
: can have baseclasses that won't have DC_HAS_CHILDREN set. Perhaps the second
: devclass there should always create a devclass (i.e. last param is true)?
: Otherwise dc->parent could be NULL when it shouldn't be, either. I think
: that is probably the best solution. I've tested this and it worked.
I think that's a good fix. And one that's needed if we want
subclassing to work in the face of these random orderings. Otherwise,
dc->parent wouldn't get set right anyway, and the function inheritance
wouldn't happen correctly since it is NULL.
Warner
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090325.110431.-165354456.imp>