2011/3/31 John Baldwin <jhb_at_freebsd.org>: > On Thursday, March 31, 2011 7:32:26 am Svatopluk Kraus wrote: >> Hi, >> >> I've got a page fault (because of NULL td_lock) in >> thread_lock_flags() called from schedcpu() in /sys/kern/sched_4bsd.c >> file. During process fork, new thread is linked to new process which >> is linked to allproc list and both allproc_lock and new process lock >> are unlocked before sched_fork() is called, where new thread td_lock >> is initialized. Only PRS_NEW process status is on sentry but not >> checked in schedcpu(). > > I think this should fix it: > > Index: sched_4bsd.c > =================================================================== > --- sched_4bsd.c (revision 220190) > +++ sched_4bsd.c (working copy) > _at__at_ -463,6 +463,10 _at__at_ schedcpu(void) > sx_slock(&allproc_lock); > FOREACH_PROC_IN_SYSTEM(p) { > PROC_LOCK(p); > + if (p->p_state == PRS_NEW) { > + PROC_UNLOCK(p); > + continue; > + } > FOREACH_THREAD_IN_PROC(p, td) { > awake = 0; > thread_lock(td); > I don't really think this fix is right because otherwise, when using sched_4bsd anytime we are going to scan the thread list within a proc we need to check for PRS_NEW. We likely need to change the init scheme for the td_lock by having a scheduler primitive setting it and doing that on thread_init() UMA constructor, or similar approach. Attilio -- Peace can only be achieved by understanding - A. EinsteinReceived on Thu Mar 31 2011 - 14:56:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:12 UTC