linux-stable.git/arch, branch linux-2.6.26.y

sparc64: Fix race in arch/sparc64/kernel/trampoline.S

2008-11-10T19:18:01+00:00

[ Upstream commit e0037df3852b4b60edbe01f70f4968e4a9fdb272 ]

Make arch/sparc64/kernel/trampoline.S in 2.6.27.1 lock prom_entry_lock
when calling the PROM.  This prevents a race condition that I observed
causing a hang on startup on a 12-CPU E4500.

I am not subscribed to this list, so please CC me on replies.

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

x86: avoid dereferencing beyond stack + THREAD_SIZE

2008-10-22T21:13:25+00:00

commit 60e6258cd43f9b06884f04f0f7cefb9c40f17a32 upstream

It's possible for get_wchan() to dereference past task->stack + THREAD_SIZE
while iterating through instruction pointers if fp equals the upper boundary,
causing a kernel panic.

Signed-off-by: David Rientjes 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86, early_ioremap: fix fencepost error

2008-10-22T21:13:13+00:00

commit c613ec1a7ff3714da11c7c48a13bab03beb5c376 upstream

The x86 implementation of early_ioremap has an off by one error. If we get
an object which ends on the first byte of a page we undermap by one page and
this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit
this alignment.

The size computation is currently

	last_addr = phys_addr + size - 1;
	npages = (PAGE_ALIGN(last_addr) - phys_addr)

(Consider a request for 1 byte at alignment 0...)

Closes #11693

Debugging work by Ian Campbell/Felix Geyer

Signed-off-by: Alan Cox 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: improve UP kernel when CPU-hotplug and SMP is enabled

2008-10-22T21:13:12+00:00

commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream

num_possible_cpus() can be > 1 when disabled CPUs have been accounted.

Disabled CPUs are not in the cpu_present_map, so we can use
num_present_cpus() as a safe indicator to switch to UP alternatives.

Reported-by: Chuck Ebbert 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.

2008-10-22T21:13:11+00:00

Not in upstream above 2.6.27 due to change in the way this code works
(has been fixed differently there.)

Someone from the community found out, that after repeatedly unloading
and loading a device driver that uses MSI IRQs, the system eventually
assigned the vector initially reserved for IRQ0 to the device driver.

The reason for this is, that although IRQ0 is tied to the
FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
corresponding bit in the used_vectors map is not set. So, if vectors are
released and assigned often enough, the vector will get assigned to
another interrupt. This happens more often with MSI interrupts as those
are exclusively using a vector.

Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.

Signed-off-by: Stefan Bader 
Acked-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

S390: CVE-2008-1514: prevent ptrace padding area read/write in 31-bit mode

2008-10-09T03:23:12+00:00

commit 3d6e48f43340343d97839eadb1ab7b6a3ea98797 upstream

When running a 31-bit ptrace, on either an s390 or s390x kernel,
reads and writes into a padding area in struct user_regs_struct32
will result in a kernel panic.

This is also known as CVE-2008-1514.

Test case available here:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/user-area-padding.c?cvsroot=systemtap

Steps to reproduce:
1) wget the above
2) gcc -o user-area-padding-31bit user-area-padding.c -Wall -ggdb2 -D_GNU_SOURCE -m31
3) ./user-area-padding-31bit


Test status
-----------
Without patch, both s390 and s390x kernels panic. With patch, the test case,
as well as the gdb testsuite, pass without incident, padding area reads
returning zero, writes ignored.

Nb: original version returned -EINVAL on write attempts, which broke the
gdb test and made the test case slightly unhappy, Jan Kratochvil suggested
the change to return 0 on write attempts.

Signed-off-by: Jarod Wilson 
Tested-by: Jan Kratochvil 
Signed-off-by: Martin Schwidefsky 
Cc: Moritz Muehlenhoff 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix missing devices due to PCI bridge test in of_create_pci_dev().

2008-10-09T03:23:10+00:00

[ Upstream commit 44b50e5a1af13c605d6c3b17a60e42eb0ee48d5f ]

Just like in the arch/sparc64/kernel/of_device.c code fix commit
071d7f4c3b411beae08d27656e958070c43b78b4 ("sparc64: Fix disappearing
PCI devices on e3500.") we have to check the OF device node name for
"pci" instead of relying upon the 'device_type' property being there
on all PCI bridges.

Tested by Meelis Roos, and confirmed to make the PCI QFE devices
reappear on the E3500 system.

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

sparc64: Fix disappearing PCI devices on e3500.

2008-10-09T03:23:10+00:00

[ Upstream commit 7ee766d8fba9dfd93bf3eca7a8d84a25404a68dc ]

Based upon a bug report by Meelis Roos.

The OF device layer builds properties by matching bus types and
applying 'range' properties as appropriate, up to the root.

The match for "PCI" busses is looking at the 'device_type' property,
and this does work %99 of the time.

But on an E3500 system with a PCI QFE card, the DEC 21153 bridge
sitting above the QFE network interface devices has a 'name' of "pci",
but it completely lacks a 'device_type' property.  So we don't match
it as a PCI bus, and subsequently we end up with no resource values at
all for the devices sitting under that DEC bridge.

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

sparc64: Fix OOPS in psycho_pcierr_intr_other().

2008-10-09T03:23:09+00:00

[ Upstream commit f948cc6ab9e61a8e88d70ee9aafc690e6d26f92c ]

We no longer put the top-level PCI controller device into the
PCI layer device list.  So pbm->pci_bus->self is always NULL.

Therefore, use direct PCI config space accesses to get at
the PCI controller's PCI_STATUS register.

Tested by Meelis Roos.

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

sparc64: Fix interrupt register calculations on Psycho and Sabre.

2008-10-09T03:23:09+00:00

[ Upstream commit ebfb2c63405f2410897674f14e41c031c9302909 ]

Use the IMAP offset calculation for OBIO devices as documented in the
programmer's manual.  Which is "0x10000 + ((ino & 0x1f) << 3)"

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