From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 2 17:51:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0E872D4; Thu, 2 Oct 2014 17:51:58 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95E168CD; Thu, 2 Oct 2014 17:51:58 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s92HpuTd078739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2014 10:51:57 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s92HpuKv078738; Thu, 2 Oct 2014 10:51:56 -0700 (PDT) (envelope-from jmg) Date: Thu, 2 Oct 2014 10:51:56 -0700 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: Kernel/Compiler bug Message-ID: <20141002175156.GM43300@funkthat.com> Mail-Followup-To: Konstantin Belousov , Larry Baird , "freebsd-hackers@freebsd.org" , Ryan Stone , Dimitry Andric , Bryan Drewery References: <20141001031553.GA14360@gta.com> <20141001134044.GA57022@gta.com> <542C8C75.30007@FreeBSD.org> <20141002075537.GU26076@kib.kiev.ua> <20141002140232.GA52387@gta.com> <20141002143345.GY26076@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002143345.GY26076@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 02 Oct 2014 10:51:57 -0700 (PDT) Cc: Dimitry Andric , "freebsd-hackers@freebsd.org" , Ryan Stone , Larry Baird , Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:51:59 -0000 Konstantin Belousov wrote this message on Thu, Oct 02, 2014 at 17:33 +0300: > On Thu, Oct 02, 2014 at 10:02:32AM -0400, Larry Baird wrote: > > > > Is this something that can be bumped in the tree for GENERIC? > > > > > > The cost of the increased size for kernel stack is significant, even > > > on architectures with ample KVA. This must not be done just because > > > some non-default kernel settings cause stack overflow. If somebody > > > feels himself qualified enough to tune compiler options, it must > > > understand the consequences and do other required adjustments, > > > including kernel stack size tuning. > > > > > > FWIW, there was old reason why -O0 did not worked for the kernel. > > > The cpufunc.h inlines are not provided in non-inline version, and > > > at least gcc at -O0 level sometimes generated the call to nonexisting > > > function, leading to linking failure. It is curious that clang always > > > inlines at -O0, but it is possible, although unlikely, that kernel > > > source was changed to be immune. > > > > Overall I aggree with your comments. The fact is that I have been using > > -O0 and -O1 on custom kernels for years. It makes using kgdb much more > > effective. Both optimization levels work for a custom kernel I have for > > FreeBSD 10.0 but do not work for FreeBSD 10.1. I just tried turning off > > optimization for a FreeBSD 10.0 release GENERIC kernel. Same issue. My > > concern is that opimized kernels may be close to the edge as well. Since > > people have been runing 10.0 for a while without issue, maybe me concern > > is unfounded. Anybody have any thoughts on how to instrument a kernel > > build option to check for maximum used stack depth? It would be nice to > > prove that my concern is unfounded. > > The easiest thing to do is to record the stack depth for kernel mode > on entry into interrupt. Interrupt handlers are usually well written > and do not consume a lot of stack. > > Look at the intr_event_handle(), which is the entry point. The mode can > be deduced from trapframe passed. The kernel stack for the thread is > described by td->td_kstack (base, i.e. bottom) and td->td_kstack_pages > (size), so the top of the stack is at td_kstack + td_kstack_size [*]. > The current stack consumption could be taken from reading %rsp register, > or you may take the address of any local variable as well. > > * - there are pcb and usermode fpu save area at the top of the stack, and > actual kernel stack top is right below fpu save area. This should not > be important for your measurements, since you are looking at how close > the %rsp gets to the bottom. There once was a script that would print out stack usage for each function in the kernel... This could help identify functions that use too much stack... I poked around in tools, but couldn't find it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."