Date: Wed, 6 Apr 2011 22:31:22 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: kernel thread creation cleanup Message-ID: <20110406193122.GI78089@deviant.kiev.zoral.com.ua> In-Reply-To: <4D9C9F6D.4030503@freebsd.org> References: <4D9BBED1.3070402@freebsd.org> <20110406102143.GG78089@deviant.kiev.zoral.com.ua> <4D9C9F6D.4030503@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--BKnPblWxbRpCNYlk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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(). >=20 > 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. >=20 > One thing the current code does is puts a trap frame on hte stack,=20 > whether you will need it or not. > the result of that is that the trap frame is the next thing on the=20 > 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=20 > are creating a new kthread. > not that you SHOULD return of course... > anyhow it's a waste of 192 bytes of stack.. >=20 > For normal fork/thread_create I guess the frame tries to return to=20 > 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. >=20 > >>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. >=20 > 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=20 > way too.. > it even carries on with a 0 %rbp which is bogus. Yes, because it relies on unwind tables. --BKnPblWxbRpCNYlk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2cv4oACgkQC3+MBN1Mb4gXiwCgr4ypxH5s99z65Xmb4tevHhkB L7gAn1qH+BwkLKa5uaKm5NMwJROI9cdj =r+Hg -----END PGP SIGNATURE----- --BKnPblWxbRpCNYlk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110406193122.GI78089>