Re: schedcpu() in /sys/kern/sched_4bsd.c calls thread_lock() on thread with un-initialized td_lock

From: Attilio Rao <attilio_at_freebsd.org>
Date: Thu, 31 Mar 2011 12:34:31 -0400
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. Einstein
Received 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