re: config_mounroot - spinout while attaching nouveaufb0 on amd64 with LOCKDEBUG

[matthew green <mrg%eterna.com.au@localhost>]

Jarom?r Dole?ek writes:
> Le lun. 17 f=C3=A9vr. 2020 =C3=A0 17:55, matthew green <mrg%eterna.com.au@localhost> =
> a =C3=A9crit :
> >
> > FWIW, i've been running my radeon with a patch that exlicitly drops
> > kernel lock around the "real attach" function (the one that config
> > mountroot ends up calling.)
> >
> > we really need to MPSAFE-ify the autoconf subsystem.  right now, it
> > is expected that autoconf runs with kernel lock... i am not sure of
> > the path we should take for this -- but let's actually have a design
> > in place we are happy with, while my change below works, it's ugly
> > and wrong.
> 
> Would it make sense to simply require all callers of
> config_mountroot() to have MPSAFE config routines and call the
> callbacks for them without kernel lock?
> 
> There are just few of those, and they can simply be changed to do the
> KERNEL_LOCK()/UNLOCK themselves.

this is a tempting idea, but i'm loathe to have different parts
of autoconf run with different locking semantics.

eg, my hack has the possibility of attempting to update the
autoconf private data which is currently protected by the
kernel lock, and i suspect it's actually possible because
these routines attach sub-devices:

radeon0 at pci10 dev 0 function 0: ATI Technologies Mobility Radeon HD 4500 (rev. 0x00)
radeondrmkmsfb0 at radeon0
wsdisplay0 at radeondrmkmsfb0 kbdmux 1
wsmux1: connecting to wsdisplay0
wskbd0: connecting to wsdisplay0

right now with my change, all that runs with no protection.
it seems non-trivial to fix that all up for only
config_mountroot().

this is why i wrote "let's actually have a design"  :-)


.mrg.