Re: kernel thread creation cleanup

On Wed, Apr 06, 2011 at 10:14:21AM -0700, Julian Elischer wrote:
> On 4/6/11 3:21 AM, Kostik Belousov wrote:
> >On Tue, Apr 05, 2011 at 06:16:01PM -0700, Julian Elischer wrote:
> >>I was just looking in the thread creation code after most of a decade
> >>NOT looking at it..
> >>boy we really need to go through there with a broom.. the cobwebs are
> >>getting thick.
> >>Like we always call the code to put an upcall, even though we don't
> >>have upcalls any more,
> >cpu_set_upcall() probably could be renamed to cpu_init_thread(),
> >and cpu_set_upcall_kse() is better named cpu_init_thread_for_user().
> 
> yeah, we should have changed the names when they got the new jobs.
> (when KSE went away)
> >IMO, rename would only add a code churn.
> >>and we always create an trap frame on the stack even when we are
> >>making kernel threads
> >>that don't need it, actually, come to think of it DOES fork even need
> >>it? (need to go look)
> >Trap frame for the new thread that is going to usermode after fork is
> >definitely needed. Having fork trampoline executed for all threads is
> >good, because it provides a convenient single point which is passed by
> >all new threads.
> 
> One thing the  current code does is puts a trap frame on hte stack, 
> whether you will need it or not.
> the result of that is that the trap frame is the next thing on the 
> stack after fork_exit on the stack so that if you return
> from fork_exit you hit the frame (which is not set up to work) if you 
> are creating a new  kthread.
> not that you SHOULD return of course...
> anyhow it's a waste of 192 bytes of stack..
> 
> For normal fork/thread_create I guess the frame tries to return to 
> userland, and is needed.

The change would require a serious review. I am not quite sure that
assumption of existence of trap frame is not engraved in some piece of
MD code.

> 
> >>and we go through the fork trampoline even when we are doing kthread
> >>creation and could just as well go
> >>directly to the final function directly.  (All of the above on amd64)..
> >>May be slighly different on other hardware, though much of it is
> >>encoded in MI code so probably not.
> >>
> >>
> >>
> >>This came from looking to see if I could somehow munge the stack to
> >>convince kgdb to damn well stop at
> >>that point (still failed.  if anyone has ideas... :-)
> >Was it for amd64 ? I think the issue with kgdb is lack of the proper
> >dwarf annotations for trampoline.
> 
> It's possible some sort of anotation woudl stop the stack when
> it saw that return address, but one would think there was some other 
> way too..
> it even carries on with a 0 %rbp which is bogus.
Yes, because it relies on unwind tables.