From patchwork Fri Feb 12 20:03:07 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 45209 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id A3E08B7C59 for ; Sat, 13 Feb 2010 07:02:55 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756421Ab0BLUCx (ORCPT ); Fri, 12 Feb 2010 15:02:53 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:60742 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752049Ab0BLUCx (ORCPT ); Fri, 12 Feb 2010 15:02:53 -0500 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 256CF24C106; Fri, 12 Feb 2010 12:03:08 -0800 (PST) Date: Fri, 12 Feb 2010 12:03:07 -0800 (PST) Message-Id: <20100212.120307.19150137.davem@davemloft.net> To: mroos@linux.ee Cc: sparclinux@vger.kernel.org Subject: Re: Spurious unaligned access messages during bootup From: David Miller In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org From: Meelis Roos Date: Thu, 21 Jan 2010 15:26:42 +0200 (EET) > Got these from current 2.6.33-rc4+git: > > [ 125.765427] Kernel unaligned access at TPC[43e3a4] __save_stack_trace+0x84/0x220 > [ 125.765627] Kernel unaligned access at TPC[43e3b8] __save_stack_trace+0x98/0x220 > [ 125.765802] Kernel unaligned access at TPC[43e3bc] __save_stack_trace+0x9c/0x220 > > This was during the bootup. Never seen these specific messages before > (last kernel was 2.6.32). The second bootup with current kernel did not > yield these messages either. Thanks for the report. I wonder if we're walking randomly past the top of the firmware's stack during these backtraces. In any event, I'll add the following sanity check to the tree, thanks for your report. sparc64: Tighten checks in kstack_valid(). The kernel stack pointer is invalid if it is not 16-byte aligned. Based upon a report by Meelis Roos Signed-off-by: David S. Miller --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/sparc/kernel/kstack.h b/arch/sparc/kernel/kstack.h index 4248d96..5247283 100644 --- a/arch/sparc/kernel/kstack.h +++ b/arch/sparc/kernel/kstack.h @@ -11,6 +11,10 @@ static inline bool kstack_valid(struct thread_info *tp, unsigned long sp) { unsigned long base = (unsigned long) tp; + /* Stack pointer must be 16-byte aligned. */ + if (sp & (16UL - 1)) + return false; + if (sp >= (base + sizeof(struct thread_info)) && sp <= (base + THREAD_SIZE - sizeof(struct sparc_stackf))) return true;