From owner-freebsd-arch@FreeBSD.ORG Mon Nov 12 18:28:20 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 589E416A420; Mon, 12 Nov 2007 18:28:20 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 364B313C4BC; Mon, 12 Nov 2007 18:28:20 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp008-s [10.150.69.71]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id lACIQXYw015325; Mon, 12 Nov 2007 10:26:33 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp008/MantshX 4.0) with ESMTP id lACIQVp1026867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2007 10:26:31 -0800 (PST) Message-Id: <2FA48BC6-BCF3-4C16-B914-30A13C15B8AA@mac.com> From: Marcel Moolenaar To: Julian Elischer In-Reply-To: <4737D7E3.3090500@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Mon, 12 Nov 2007 10:26:28 -0800 References: <1191187393.00807485.1191175801@10.7.7.3> <1191189248.00807488.1191177603@10.7.7.3> <4736D8AF.7010209@FreeBSD.org> <20071111163815.GJ37471@deviant.kiev.zoral.com.ua> <47373C5E.2080800@elischer.org> <0414590D-0C2A-4EBD-9617-7AC193ABD1E8@mac.com> <4737696A.7050605@FreeBSD.org> <06618562-A789-4B5E-94BF-0ED8AB51A1FF@mac.com> <4737D7E3.3090500@elischer.org> X-Mailer: Apple Mail (2.912) Cc: Kostik Belousov , Alexander Motin , freebsd-arch@FreeBSD.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2007 18:28:20 -0000 On Nov 11, 2007, at 8:34 PM, Julian Elischer wrote: > Marcel Moolenaar wrote: >> It's the register stack that grows faster in general and >> yes, they grow towards each other so they can eventually >> run into each other. > > so one could write something that detects tha tyou are getting close, > but it would have to be machine dependent.. Yes. A good place would be cpu_switch in this case, because the processor flushes the dirty stacked registers onto the register stack only when it "feels" like it or when instructed to do so. In practice this means that while the stacks may have run into each other based on the pointers, the memory corruption (sec) often happens in cpu_switch where we force the processor to flush the dirty stacked registers. In other words: a thread is expected in the common case to encounter the corruption until the next switch-in, but could in case of excessive use of either or both stacks encounter it on function boundaries (function calls and/or returns). As a side-note: The implementation of kernel stack guard pages is just as meaningless for ia64. As a first improvement, you want guard pages both at the top and at the bottom and not just at the bottom. Secondly, you want to be able to protect each stack running into each other. However, putting a guard page somewhere in the middle may not be the right thing, because different threads may require different ratios... -- Marcel Moolenaar xcllnt@mac.com