Change ia64 mca sysctls to use standard dynamic sysctls

John Baldwin jhb at freebsd.org
Tue Feb 3 11:44:16 PST 2009


On Tuesday 03 February 2009 2:09:35 pm Marcel Moolenaar wrote:
> 
> On Feb 3, 2009, at 8:07 AM, John Baldwin wrote:
> 
> > On Monday 02 February 2009 7:59:11 pm Marcel Moolenaar wrote:
> >>
> >> On Feb 2, 2009, at 10:44 AM, John Baldwin wrote:
> >>
> >>> While working on the locking for the sysctl tree, I ran into the
> >>> pseudo-dynamic machine check sysctls in ia64.  It is not really a
> >>> good idea
> >>> to call sysctl_register_oid() with a spin lock held and once I add
> >>> locking to
> >>> sysctl it becomes a bad LOR.  This changes the code to use the
> >>> public API for
> >>> adding dynamic sysctls outside of the spin lock.  Please test this
> >>> as it is a
> >>> prerequisite for finishing the locking of the sysctl tree.
> >>
> >> This won't be a solution, because eventually this code gets called
> >> for machine checks, which means that locks can be held (which is
> >> then the least of our worries :-)
> >>
> >> In any case: malloc(M_WAITOK) cannot be used. We should probably
> >> delay updating the sysctl tree and do it in a more controlled
> >> environment. If you can implement a simple linked list to store
> >> the saved state and remove the call to SYSCTL_ADD_OID, then I'll
> >> work on that part after you're done. Does that sound like a plan?
> >
> > Ok.  Checking for failures from M_NOWAIT is important, too. :)  Here's
> > an updated patch that uses the queue.  I haven't implemented the stuff
> > to schedule calls to the populate routine to drain the queue though.
> > Would you be able to do that?
> 
> Yes, I will. Getting everything right takes some careful
> testing and probably requires deliberate error injection.
> I can't ask that of you :-)

Heh, is it ok with you if I commit this patch for now (after cross-compiling 
it) so I can commit the sysctl locking?

-- 
John Baldwin


More information about the freebsd-ia64 mailing list