* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
@ 2009-01-20 6:35 ` David Miller
2009-01-20 6:52 ` David Miller
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-01-20 6:35 UTC (permalink / raw)
To: sparclinux
From: Dennis Gilmore <dgilmore@redhat.com>
Date: Fri, 2 Jan 2009 14:35:19 -0600
> trying to build openbabel sparc64
> https://sparc.koji.fedoraproject.org/koji/taskinfo?taskID\x112540 I got an
> opps
>
> sun4v_data_access_exception: ADDR[ffffb83000000008] CTX[16ba] TYPE[0009], going.
...
> lt-atom(22311): Dax [#1]
> TSTATE: 0000009911001600 TPC: 00000000004821d8 TNPC: 00000000004821dc Y:
> 00000000 Not tainted
> TPC: <exit_robust_list+0x78/0x10c>
...
> Ive seen something similar building OOo also
> 22311 ? D 0:00 /builddir/build/BUILD/openbabel-2.2.0b3-20080215-
> r2249/test/.libs/lt-atom
>
> the process that should be running ends up in a D state so it is sleeping and
> unkillable. the processes hang around until a reboot. any ideas where I
> should start looking? this happens on a T1000 and T2000 i've not yet tried on
> non-niagara hardware.
Thanks for this report. I think I know why this happens.
exit_robust_list() just walks the userland linked list of
robust FUTEX objects to release. Since it's userland,
anything can be there, so this can generate all kinds of
exceptions depending upon the address used. Such exceptions
should just silently be handled and cause an abort of the
FUTEX list traversal.
The address in question is in register %g2 as the faulting
instruction is:
ldxa [ %g2 ] %asi, %g3
And register %g2 holds 0xfff8b83000000008 which is inside of
the address space hole on Niagara. Any acccess there is
illegal and will generate a data access exception as we see
here.
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.
Thanks again.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
2009-01-20 6:35 ` David Miller
@ 2009-01-20 6:52 ` David Miller
2009-01-23 17:31 ` Dennis Gilmore
2009-01-24 3:50 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-01-20 6:52 UTC (permalink / raw)
To: sparclinux
From: David Miller <davem@davemloft.net>
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 <dgilmore@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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<UNKNOWN>\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);
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
2009-01-20 6:35 ` David Miller
2009-01-20 6:52 ` David Miller
@ 2009-01-23 17:31 ` Dennis Gilmore
2009-01-24 3:50 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: Dennis Gilmore @ 2009-01-23 17:31 UTC (permalink / raw)
To: sparclinux
[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]
On Tuesday 20 January 2009 12:52:28 am David Miller wrote:
> From: David Miller <davem@davemloft.net>
> 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.
Dave,
The patch does fix the issue.
Dennis
> 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 <dgilmore@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> 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<UNKNOWN>\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);
> --
> 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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
` (2 preceding siblings ...)
2009-01-23 17:31 ` Dennis Gilmore
@ 2009-01-24 3:50 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-01-24 3:50 UTC (permalink / raw)
To: sparclinux
From: Dennis Gilmore <dennis@ausil.us>
Date: Fri, 23 Jan 2009 11:31:48 -0600
> On Tuesday 20 January 2009 12:52:28 am David Miller wrote:
> > From: David Miller <davem@davemloft.net>
> > 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.
> Dave,
>
> The patch does fix the issue.
Thanks a lot for testing.
^ permalink raw reply [flat|nested] 5+ messages in thread