[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: config_mounroot - spinout while attaching nouveaufb0 on amd64 with LOCKDEBUG
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
this is why i wrote "let's actually have a design" :-)
Main Index |
Thread Index |