* git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6:
parisc: export length of os_hpmc vector
parisc: fix kernel crash (protection id trap) when compiling ruby1.9
parisc: Use DEFINE_SPINLOCK
parisc: add uevent helper for parisc bus
parisc: fix ipv6 checksum
parisc: quiet palo not-found message from "which"
parisc: Replace NR_CPUS in parisc code
parisc: trivial fixes
parisc: fix braino in commit adding __space_to_prot
parisc: factor out sid to protid conversion
parisc: use leX_to_cpu in place of __fswabX
parisc: fix GFP_KERNEL use while atomic in unwinder
parisc: remove dead BIO_VMERGE_BOUNDARY and BIO_VMERGE_MAX_SIZE definitions
parisc: set_time() catch errors
parisc: use the new byteorder headers
parisc: drivers/parisc/: make code static
parisc: lib/: make code static
The atomic_t type cannot currently be used in some header files because it
would create an include loop with asm/atomic.h. Move the type definition
to linux/types.h to break the loop.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On Wed, Dec 17, 2008 at 11:46:05PM +0100, Helge Deller wrote:
>
Honestly, I can't decide whether to apply this. It really should never
happen in the kernel, since the kernel can guarantee it won't get the
access rights failure (highest privilege level, and can set %sr and
%protid to whatever it wants.)
It really genuinely is a bug that probably should panic the kernel. The
only precedent I can easily see is x86 fixing up a bad iret with a
general protection fault, which is more or less analogous to code 27
here.
On the other hand, taking the exception on a userspace access really
isn't all that critical, and there's fundamentally little reason for the
kernel not to SIGSEGV the process, and continue...
Argh.
(btw, I've instrumented my do_sys_poll with a pile of assertions that
%cr8 << 1 == %sr3 == current->mm.context... let's see if where we're
getting corrupted is deterministic, though, I would guess that it won't
be.)
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
ipv6 recently started exhibiting the same symptoms as ipv4 was, add
a memory clobber around inline checksum assembly that fribbles memory
to ensure gcc doesn't erroneously cache across it.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Create a new __space_to_prot inline to convert the space id (mmu context)
to a protection id. Sadly it doesn't look like the #ifdef can be eliminated
since relying on the compiler to not truncate a bit on
return (ctx >> SPACEID_SHIFT) << 1;
seems a little dodgy.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
On 32bit (and sometimes 64bit) and with big kernel modules like xfs or
ipv6 the relocation types R_PARISC_PCREL17F and R_PARISC_PCREL22F may
fail to reach their PLT stub if we only create one big stub array for
all sections at the beginning of the core or init section.
With this patch we now instead add individual PLT stub entries
directly in front of the code sections where the stubs are actually
called. This reduces the distance between the PCREL location and the
stub entry so that the relocations can be fulfilled.
While calculating the final layout of the kernel module in memory, the
kernel module loader calls arch_mod_section_prepend() to request the
to be reserved amount of memory in front of each individual section.
Tested with 32- and 64bit kernels.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is defined in linux/cpumask.h (included in this file already),
and this is now defined differently.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-parisc@vger.kernel.org
flush_tlb_mm's "optimized" uniprocessor case of allocating a new
context for userspace is exposing a race where we can suddely return
to a syscall with the protection id and space id out of sync, trapping
on the next userspace access.
Debugged-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6:
parisc: struct device - replace bus_id with dev_name(), dev_set_name()
parisc: fix kernel crash when unwinding a userspace process
parisc: __kernel_time_t is always long
All architectures now use the generic compat_sys_ptrace, as should every
new architecture that needs 32bit compat (if we'll ever get another).
Remove the now superflous __ARCH_WANT_COMPAT_SYS_PTRACE define, and also
kill a comment about __ARCH_SYS_PTRACE that was added after
__ARCH_SYS_PTRACE was already gone.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(I did not compile or test it, please let me know, or help fixing
it, if something is wrong with the conversion)
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Thanks,
Kay
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: linux-parisc@vger.kernel.org
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
__kernel_time_t is always long on PA-RISC, irrespective of CONFIG_64BIT,
hence move it out of the #ifdef CONFIG_64BIT / #else / #endif block.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Commit 2d3854a37e ("cpumask: introduce new
API, without changing anything") introduced a build breakage on parisc.
This trivial patch fixes it.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kyle Mc Martin <kyle@hera.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch does the compat_sys_ptrace conversion for parisc.
In addition it does convert the parisc ptrace code to use the
architecture-independent ptrace infrastructure instead of own coding.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
The unwinder was being initialized way too late to be any use
debugging early boot crashes. Instead of relying on module_init
initcalls to initialize it, let's do it explicitly as early as
we can.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
These functions are called only when bringing up the monarch cpu,
so it is safe to call them without taking the pdc spinlock. In the
future, this may become relevant for lockdep, since these functions were
taking spinlocks before start_kernel called the lockdep initializers.
Linus Torvalds