From patchwork Tue Jan 20 06:52:28 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 19437 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.176.167]) by ozlabs.org (Postfix) with ESMTP id B0275DDF00 for ; Tue, 20 Jan 2009 17:52:28 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751657AbZATGw1 (ORCPT ); Tue, 20 Jan 2009 01:52:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752926AbZATGw1 (ORCPT ); Tue, 20 Jan 2009 01:52:27 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:47414 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751657AbZATGw0 (ORCPT ); Tue, 20 Jan 2009 01:52:26 -0500 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 7CDA0C8C23B; Mon, 19 Jan 2009 22:52:28 -0800 (PST) Date: Mon, 19 Jan 2009 22:52:28 -0800 (PST) Message-Id: <20090119.225228.194299431.davem@davemloft.net> To: dgilmore@redhat.com Cc: sparclinux@vger.kernel.org Subject: Re: opps building sparc64 packages From: David Miller In-Reply-To: <20090119.223517.190558209.davem@davemloft.net> References: <200901021435.23972.dgilmore@redhat.com> <20090119.223517.190558209.davem@davemloft.net> X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org From: David Miller Date: Mon, 19 Jan 2009 22:35:17 -0800 (PST) > The code in sun4v_data_access_exception() needs some logic to properly > handle the case of the kernel doing a userspace access. Currently it > does an OOPS unconditionally when triggered from kernel space, which > is wrong. > > I'll fix this up and post a patch. Dennis, here is a 2.6.27 based patch that should fix this bug. sparc64: Fix DAX handling via userspace access from kernel. If we do a userspace access from kernel mode, and get a data access exception, we need to check the exception table just like a normal fault does. The spitfire DAX handler was doing this, but such logic was missing from the sun4v DAX code. Reported-by: Dennis Gilmore 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/sparc64/kernel/traps.c b/arch/sparc64/kernel/traps.c index c824df1..eb19724 100644 --- a/arch/sparc64/kernel/traps.c +++ b/arch/sparc64/kernel/traps.c @@ -1,6 +1,6 @@ /* arch/sparc64/kernel/traps.c * - * Copyright (C) 1995,1997,2008 David S. Miller (davem@davemloft.net) + * Copyright (C) 1995,1997,2008,2009 David S. Miller (davem@davemloft.net) * Copyright (C) 1997,1999,2000 Jakub Jelinek (jakub@redhat.com) */ @@ -262,6 +262,21 @@ void sun4v_data_access_exception(struct pt_regs *regs, unsigned long addr, unsig return; if (regs->tstate & TSTATE_PRIV) { + /* Test if this comes from uaccess places. */ + const struct exception_table_entry *entry; + + entry = search_exception_tables(regs->tpc); + if (entry) { + /* Ouch, somebody is trying VM hole tricks on us... */ +#ifdef DEBUG_EXCEPTIONS + printk("Exception: PC<%016lx> faddr\n", regs->tpc); + printk("EX_TABLE: insn<%016lx> fixup<%016lx>\n", + regs->tpc, entry->fixup); +#endif + regs->tpc = entry->fixup; + regs->tnpc = regs->tpc + 4; + return; + } printk("sun4v_data_access_exception: ADDR[%016lx] " "CTX[%04x] TYPE[%04x], going.\n", addr, ctx, type);