Date: Thu, 31 Mar 2011 14:18:31 -0400 From: John Baldwin <jhb@freebsd.org> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-current@freebsd.org, Svatopluk Kraus <onwahe@gmail.com> Subject: Re: schedcpu() in /sys/kern/sched_4bsd.c calls thread_lock() on thread with un-initialized td_lock Message-ID: <201103311418.31658.jhb@freebsd.org> In-Reply-To: <AANLkTikLexFE5ZZGkJ%2BUq1udkfs14jVFuvmak%2B-srfdv@mail.gmail.com> References: <AANLkTimEiOW%2BkSZD6n1MHiRou3UWibU6Oy3fr9RO4_O4@mail.gmail.com> <201103310958.51416.jhb@freebsd.org> <AANLkTikLexFE5ZZGkJ%2BUq1udkfs14jVFuvmak%2B-srfdv@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, March 31, 2011 12:34:31 pm Attilio Rao wrote:
> 2011/3/31 John Baldwin <jhb@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)
> > @@ -463,6 +463,10 @@ 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.
But the thread state isn't valid anyway. 4BSD shouldn't be touching the
thread since it is in an incomplete / undefined state.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103311418.31658.jhb>