linux-toradex.git/arch/sparc64, branch v2.6.27.25

sparc64: Reschedule KGDB capture to a software interrupt.

2009-06-12T03:01:15+00:00

[ Upstream commit 42cc77c861e8e850e86252bb5b1e12e006261973 ]

Otherwise it might interrupt switch_to() midstream and use
half-cooked register window state.

Reported-by: Chris Torek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix lost interrupts on sun4u.

2009-06-12T03:01:14+00:00

[ Upstream commit d0cac39e4ec8097e4c7099d291b1fdcc0fe56b58 ]

Based upon a report by Meelis Roos.

Sparc64 SBUS and PCI controllers use a combination of IMAP and ICLR
registers to manage device interrupts.

The IMAP register contains the "valid" enable bit as well as CPU
targetting information.  Whereas the ICLR register is written with
zero at the end of handling an interrupt to reset the state machine
for that interrupt to IDLE so it can be sent again.

For PCI slot and SBUS slot devices we can have multiple interrupts
sharing the same IMAP register.  There are individual ICLR registers
but only one IMAP register for managing those.

We represent each shared case with individual virtual IRQs so the
generic IRQ layer thinks there is only one user of the IRQ instance.

In such shared IMAP cases this is wrong, so if there are multiple
active users then a free_irq() call will prematurely turn off the
interrupt by clearing the Valid bit in the IMAP register even though
there are other active users.

Fix this by simply doing nothing in sun4u_disable_irq() and checking
IRQF_DISABLED during IRQ dispatch.

This situation doesn't exist in the hypervisor sun4v cases, so I left
those alone.

Tested-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix crash with /proc/iomem

2009-06-12T03:01:14+00:00

[ Upstream commit 192d7a4667c6d11d1a174ec4cad9a3c5d5f9043c ]

When you compile kernel on Sparc64 with heap memory checking and type
"cat /proc/iomem", you get a crash, because pointers in struct
resource are uninitialized.

Most code fills struct resource with zeros, so I assume that it is
responsibility of the caller of request_resource to initialized it,
not the responsibility of request_resource functuion.

After 2.6.29 is out, there could be a check for uninitialized fields
added to request_resource to avoid crashes like this.

Signed-off-by: Mikulas Patocka 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix MM refcount check in smp_flush_tlb_pending().

2009-06-12T03:01:11+00:00

[ Upstream commit f9384d41c02408dd404aa64d66d0ef38adcf6479 ]

As explained by Benjamin Herrenschmidt:

> CPU 0 is running the context, task->mm == task->active_mm == your
> context. The CPU is in userspace happily churning things.
>
> CPU 1 used to run it, not anymore, it's now running fancyfsd which
> is a kernel thread, but current->active_mm still points to that
> same context.
>
> Because there's only one "real" user, mm_users is 1 (but mm_count is
> elevated, it's just that the presence on CPU 1 as active_mm has no
> effect on mm_count().
>
> At this point, fancyfsd decides to invalidate a mapping currently mapped
> by that context, for example because a networked file has changed
> remotely or something like that, using unmap_mapping_ranges().
>
> So CPU 1 goes into the zapping code, which eventually ends up calling
> flush_tlb_pending(). Your test will succeed, as current->active_mm is
> indeed the target mm for the flush, and mm_users is indeed 1. So you
> will -not- send an IPI to the other CPU, and CPU 0 will continue happily
> accessing the pages that should have been unmapped.

To fix this problem, check ->mm instead of ->active_mm, and this
means:

> So if you test current->mm, you effectively account for mm_users == 1,
> so the only way the mm can be active on another processor is as a lazy
> mm for a kernel thread. So your test should work properly as long
> as you don't have a HW that will do speculative TLB reloads into the
> TLB on that other CPU (and even if you do, you flush-on-switch-in should
> get rid of any crap here).

And therefore we should be OK.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Fix bus type probing for ESP and LE devices.

2009-06-12T03:01:11+00:00

If there is a dummy "espdma" or "ledma" parent device above ESP scsi
or LE ethernet device nodes, we have to match the bus as SBUS.

Otherwise the address and size cell counts are wrong and we don't
calculate the final physical device resource values correctly at all.

Commit 5280267c1dddb8d413595b87dc406624bb497946 ("sparc: Fix handling
of LANCE and ESP parent nodes in of_device.c") was meant to fix this
problem, but that only influences the inner loop of
build_device_resources().  We need this logic to also kick in at the
beginning of build_device_resources() as well, when we make the first
attempt to determine the device's immediate parent bus type for 'reg'
property element extraction.

Based almost entirely upon a patch by Friedrich Oslage.

Tested-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix smp_callin() locking.

2009-06-12T03:01:10+00:00

[ Upstream commit 8e255baa449df3049a8827a7f1f4f12b6921d0d1 ]

Interrupts must be disabled when taking the IPI lock.

Caught by lockdep.

Reported-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix DAX handling via userspace access from kernel.

2009-03-17T00:52:42+00:00

[ Upstream commit fcd26f7ae2ea5889134e8b3d60a42ce8b993c95f ]

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 
Signed-off-by: Greg Kroah-Hartman

sparc64: Annotate sparc64 specific syscalls with SYSCALL_DEFINEx()

2009-02-17T17:46:26+00:00

[ Upstream commit e42650196df34789c825fa83f8bb37a5d5e52c14 ]

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Enable syscall wrappers for 64-bit (CVE-2009-0029)