From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934593AbdBVVPf (ORCPT ); Wed, 22 Feb 2017 16:15:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44098 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933512AbdBVVPY (ORCPT ); Wed, 22 Feb 2017 16:15:24 -0500 Date: Wed, 22 Feb 2017 15:15:21 -0600 From: Josh Poimboeuf To: "H. Peter Anvin" Cc: Pavel Machek , kernel list , mingo@kernel.org, luto@kernel.org, bp@alien8.de, brgerst@gmail.com, dvlasenk@redhat.com, torvalds@linux-foundation.org, peterz@infradead.org, tglx@linutronix.de Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null) Message-ID: <20170222211521.bmhh74huuyfvr6dz@treble> References: <20170221221418.GA6918@amd> <20170221231216.y56gb62vkn5ewgea@treble> <20170222164515.zfnwysnuvce2ixdw@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 22 Feb 2017 21:15:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 22, 2017 at 12:51:11PM -0800, H. Peter Anvin wrote: > On 02/22/17 08:45, Josh Poimboeuf wrote: > >> > >> FWIW, it would be really darned nice to not have all those zeroes in a > >> 32-bit stack frame dump. > > > > Yeah, I'll fix that. > > > >> Is not a zero stack frame pointer value an end of stack token? > > > > There's no end of stack "token" per se, though any frame pointer value > > outside the bounds of the stack will terminate the stack trace (and that > > still happened here). > > > > Well, my understanding is that at least gdb and perhaps other unwinders > consider a zero stack frame pointer to be an indicator that the stack > has reached its end. That's why I'm wondering if this is possible in > this case or if it is unlikely because of the value. I'm not sure I follow your question. The frame pointer was zero, and that did cause the unwinder to stop the stack trace. The warning was because it ended in an unexpected place. > > The warning is because the stack trace didn't make it all the way to the > > "end" location of the stack (right before the syscall pt_regs location). > > The warning is part of the effort to ensure reliable stacks. > > It would be useful to get an understanding why... Agreed... -- Josh