Date: Thu, 2 Oct 2014 10:55:37 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com>, Dimitry Andric <dim@FreeBSD.org>, Larry Baird <lab@gta.com> Subject: Re: Kernel/Compiler bug Message-ID: <20141002075537.GU26076@kib.kiev.ua> In-Reply-To: <542C8C75.30007@FreeBSD.org> References: <20141001031553.GA14360@gta.com> <CAFMmRNxAYcr8eEY0SJsX3zkRadjT29-mfsGcSTmG_Yx-Hidi6w@mail.gmail.com> <20141001134044.GA57022@gta.com> <FBB9E4C3-55B9-4917-9953-F8BC9AE43619@FreeBSD.org> <542C8C75.30007@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 01, 2014 at 06:21:25PM -0500, Bryan Drewery wrote: > On 10/1/2014 2:37 PM, Dimitry Andric wrote: > > On 01 Oct 2014, at 15:40, Larry Baird <lab@gta.com> wrote: > >> Ryan, > >> > >> On Wed, Oct 01, 2014 at 12:46:35AM -0400, Ryan Stone wrote: > >>> This may not be a compiler bug. A quick look at the esp values > >>> provided in that backtrace shows that at least 7KB has been used on > >>> the stack. The stack for kernel threads is only 8KB, and a stack > >>> overflow can cause a double fault like that. > >>> > >>> My suspicion would be that without optimizations on clang uses a lot > >>> more stack space and you push over the limit. There's a kernel build > >>> option for the stack size that you could change to confirm. I believe > >>> that it's called KSTACK_PAGES. Try increasing it to 4. > >> Good catch. Increasing KSTACK_PAGES does fix the issue. I wonder with > >> optimization, how close to stack overflow does the kernel get during boot? > > > > It obviously depends on which optimization flags you use, which drivers > > you include, and so on. There was a thread some time ago about somebody > > banging into the limit when mounting certain ZFS filesystems, here: > > > > https://lists.freebsd.org/pipermail/freebsd-current/2012-December/038208.html > > > > This is why Kostik added printing of the frame addresses to the panic > > backtrace output, so you can easily see if you hit the stack limit. > > > > That said, 8k is not much these days, especially not with fairly > > complicated code like ZFS, combined with high optimization, which can > > inline a lot of functions, causing even more stack usage. I would just > > bump KSTACK_PAGES. > > > > -Dimitry > > > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141002075537.GU26076>