Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Aug 1997 09:49:12 -0600
From:      Steve Passe <smp@csn.net>
To:        Michael Smith <msmith@atrad.adelaide.edu.au>
Cc:        cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern init_main.c 
Message-ID:  <199708121549.JAA19349@Ilsa.StevesCafe.com>
In-Reply-To: Your message of "Tue, 12 Aug 1997 14:21:15 %2B0930." <199708120451.OAA05899@genesis.atrad.adelaide.edu.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
Mike,

> >   Log:
> >   Fixes kern/3835: SMP kernel crash on enable "dumps on wd0"
> >   
> >    - SMP: set value of curproc in main(), before the SYSINIT stuff 
> 
> If I read this correctly, this means that nothing hung off a SYSINIT()
> macro needs to worry about curproc being invalid, ie. one can
> explicitly expect curproc to be useful for subsystem locking etc. at a
> very early stage?

no, its a hack to prevent code in configure() from panic()ing when trying
to dereference (struct proc*)p->xxx thingies.  there is code that does this
early in the boot process that knows that curproc is incomplete and is careful
to not use the missing parts.  There is nothing SMP specific about this.  The
only reason its needed is that the UP kernel "sets" it at compile time via:

struct proc* curproc = &proc0;

However the SMP kernel keeps this in per-cpu private page data, and thus there
is no compile time init.  So I set it here to prevent the dereference
panics.  Any code that actually uses it this early better know what its doing.

--
Steve Passe	| powered by
smp@csn.net	|            Symmetric MultiProcessor FreeBSD





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708121549.JAA19349>