From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 19:31:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98537106566C; Wed, 6 Apr 2011 19:31:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 31D238FC14; Wed, 6 Apr 2011 19:31:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p36JVMZC087523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 22:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p36JVMGq089422; Wed, 6 Apr 2011 22:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p36JVMQd089421; Wed, 6 Apr 2011 22:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Apr 2011 22:31:22 +0300 From: Kostik Belousov To: Julian Elischer Message-ID: <20110406193122.GI78089@deviant.kiev.zoral.com.ua> References: <4D9BBED1.3070402@freebsd.org> <20110406102143.GG78089@deviant.kiev.zoral.com.ua> <4D9C9F6D.4030503@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BKnPblWxbRpCNYlk" Content-Disposition: inline In-Reply-To: <4D9C9F6D.4030503@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 19:31:26 -0000 --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--