When the kernel creates a signal frame on the user stack, it puts the
old stack pointer value at the beginning so that the signal frame is
linked into the chain of stack frames like any other frame.
Unfortunately, for 32-bit processes we are writing the old stack
pointer as a 64-bit value rather than a 32-bit value, and the process
sees that as a null pointer, since it only looks at the first 32 bits,
which are zero since ppc is bigendian and the stack pointer is below
4GB. This bug is in SLES9 and RHEL4 too, hence the ccs.
This patch fixes the bug by making the signal code write the old stack
pointer as a u32 instead of an unsigned long.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Patch from Lennert Buytenhek
The IXDP2800 is an evalution platform for the IXP2800 processor that
has two IXP2800s connected to the same PCI bus. This is problematic
as both CPUs will try to configure the PCI bus as they boot linux.
Contrary to on the other IXP2000 platforms, the boot loader on the
IXDP2800 doesn't configure the PCI bus properly, so we do want the
linux instance on one of the CPUs to do that.
Making one of the CPUs ignore the PCI bus (and thus act like a pure
PCI slave device) is not an option because there is a 82559 NIC on
the PCI bus for each of the CPUs.
The chosen solution is to have the master CPU configure the PCI bus
while the slave is kept in a quiescent state, and then to have the
slave CPU scan the PCI bus (without assigning resources) while the
master is kept in a quiescent state. After this ritual, the master
deletes the slave NIC from its PCI device list, the slave deletes
the master NIC from its device list, and (almost) all is well.
There's still one little problem: each of the CPUs has a 1G SDRAM
BAR, but the IXP2000 only has 512M of outbound PCI memory window.
We solve this by hand-assigning the master and slave SDRAM BARs to
a location outside each of the IXP's outbound PCI windows, and by
having the rest of the BARs autoconfigured in the outbound PCI
windows, in the range [e0000000..ffffffff], so that there is a 1:1
pci:phys mapping between them.
Even with this patch, a number of issues still remain -- just imagine
what happens if one of the CPUs is rebooted, by watchdog or by hand,
but the other one isn't. But those issues are not easily fixable
given the strange PCI layout of this board and the behavior of the
boot loader shipped with the platform.
Signed-off-by: Lennert Buytenhek
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from George G. Davis
This patch is required for kernel XIP support on ARMv6 machines. It ensures that the access permission bits for kernel XIP section descriptors are APX=1 and AP[1:0]=01, which is Kernel read-only/User no access permissions. Prior to this change, kernel XIP section descriptor access permissions were set to Kernel no access/User no access on ARMv6 machines and the kernel would therefore hang upon entry to userspace when set_fs(USER_DS) was executed.
Signed-off-by: Steve Longerbeam
Signed-off-by: George G. Davis
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
This patch entirely reworks the kernel assistance for NPTL on ARM.
In particular this provides an efficient way to retrieve the TLS
value and perform atomic operations without any instruction emulation
nor special system call. This even allows for pre ARMv6 binaries to
be forward compatible with SMP systems without any penalty.
The problematic and performance critical operations are performed
through segment of kernel provided user code reachable from user space
at a fixed address in kernel memory. Those fixed entry points are
within the vector page so we basically get it for free as no extra
memory page is required and nothing else may be mapped at that
location anyway.
This is different from (but doesn't preclude) a full blown VDSO
implementation, however a VDSO would prevent some assembly tricks with
constants that allows for efficient branching to those code segments.
And since those code segments only use a few cycles before returning to
user code, the overhead of a VDSO far call would add a significant
overhead to such minimalistic operations.
The ARM_NR_set_tls syscall also changed number. This is done for two
reasons:
1) this patch changes the way the TLS value was previously meant to be
retrieved, therefore we ensure whatever library using the old way
gets fixed (they only exist in private tree at the moment since the
NPTL work is still progressing).
2) the previous number was allocated in a range causing an undefined
instruction trap on kernels not supporting that syscall and it was
determined that allocating it in a range returning -ENOSYS would be
much nicer for libraries trying to determine if the feature is
present or not.
Signed-off-by: Nicolas Pitre
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from George G. Davis
As noted in http://www.arm.com/linux/patch-2.6.9-arm1.gz, the "Faulty SWP instruction on 1136 doesn't set bit 11 in DFSR." So the v6_early_abort handler does not report the correct rd/wr direction for the SWP instruction which may result in SEGVS or hangs. In order to work around this problem, this patch merely updates the fix contained in the ARM Ltd. patch to use the macroised abort handler fixups.
Signed-off-by: George G. Davis
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
Assigning the address zero to a PCI device BAR causes some part of the
PCI subsystem to believe that resource allocation for that BAR failed
due to resource conflicts, which will make attempts to enable the
device fail. Work around this by assigning I/O addresses starting
from 00010000.
While we're at it, make the PCI I/O resource end at 0001ffff, since we
only have 64k of outbound I/O window on the IXP2000, and we don't do
bank switching.
Signed-off-by: Lennert Buytenhek
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
On the IXDP2800, the bootloader does an awful job of configuring
the PCI bus, so we make linux reconfigure everything. Having a 1:1
pci:phys address mapping generally simplifies everything, so try to
allocate PCI addresses from the [e0000000..ffffffff] range, which is
the physical address range of the outbound PCI window on the IXP2000.
This does not affect any of the other IXP2000 platforms since they
all use their bootloader's PCI resource assignment.
Signed-off-by: Lennert Buytenhek
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
Export ixp2000_pci_config_addr, to be used by the IXDP2800 platform
setup code to coordinate booting the master and slave NPU.
Signed-off-by: Lennert Buytenhek
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This makes a trap on the 'iret' that returns us to user space
cause a nice clean SIGSEGV, instead of just a hard (and silent)
exit.
That way a debugger can actually try to see what happened, and
we also properly notify everybody who might be interested about
us being gone.
This loses the error code, but tells the debugger what happened
with ILL_BADSTK in the siginfo.
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype
Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Attached is a patch against David's audit.17 kernel that adds checks
for the TIF_SYSCALL_AUDIT thread flag to the ia64 system call and
signal handling code paths.The patch enables auditing of system
calls set up via fsys_bubble_down, as well as ensuring that
audit_syscall_exit() is called on return from sigreturn.
Neglecting to check for TIF_SYSCALL_AUDIT at these points results in
incorrect information in audit_context, causing frequent system panics
when system call auditing is enabled on an ia64 system.
Signed-off-by: Amy Griffis <amy.griffis@hp.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
We were calling ptrace_notify() after auditing the syscall and arguments,
but the debugger could have _changed_ them before the syscall was actually
invoked. Reorder the calls to fix that.
While we're touching ever call to audit_syscall_entry(), we also make it
take an extra argument: the architecture of the syscall which was made,
because some architectures allow more than one type of syscall.
Also add an explicit success/failure flag to audit_syscall_exit(), for
the benefit of architectures which return that in a condition register
rather than only returning a single register.
Change type of syscall return value to 'long' not 'int'.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The addition of the PT_NOTE didn't take in the x86_64 version of the i386
vDSO, because I forgot the linker script bit in that copy.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Yanmin Zhang pointed out a sequence problem when saving the psr. David
Mosberger provided this patch (which gave up a cycle).
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch switches the srlz.i in ia64_leave_kernel() to srlz.d. As
per architecture manual, the former is needed only to ensure that the
clearing of PSR.IC is seen by the VHPT for subsequent instruction
fetches. However, since the remainder of the code (up to and
including the RFI instruction) is mapped by a pinned TLB entry, there
is no chance of an iTLB miss and we don't care whether or not the VHPT
sees PSR.IC cleared. Since srlz.d is substantially cheaper than
srlz.i, this should shave off a few cycles off the interrupt path
(unverified though; I'm not setup to measure this at the moment).
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch changes comments & formatting only. There is no code
change.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Improvements come from eliminating srlz.i, not scheduling AR/CR-reads
too early (while there are others still pending), scheduling the
backing-store switch as well as possible, splitting the BBB bundle
into a MIB/MBB pair.
Why is it safe to eliminate the srlz.i? Observe
that we used to clear bits ~PSR_PRESERVED_BITS in PSR.L. Since
PSR_PRESERVED_BITS==PSR.{UP,MFL,MFH,PK,DT,PP,SP,RT,IC}, we
ended up clearing PSR.{BE,AC,I,DFL,DFH,DI,DB,SI,TB}. However,
PSR.BE : already is turned off in __kernel_syscall_via_epc()
PSR.AC : don't care (kernel normally turns PSR.AC on)
PSR.I : already turned off by the time fsys_bubble_down gets invoked
PSR.DFL: always 0 (kernel never turns it on)
PSR.DFH: don't care --- kernel never touches f32-f127 on its own
initiative
PSR.DI : always 0 (kernel never turns it on)
PSR.SI : always 0 (kernel never turns it on)
PSR.DB : don't care --- kernel never enables kernel-level breakpoints
PSR.TB : must be 0 already; if it wasn't zero on entry to
__kernel_syscall_via_epc, the branch to fsys_bubble_down
will trigger a taken branch; the taken-trap-handler then
converts the syscall into a break-based system-call.
In other words: all the bits we're clearying are either 0 already or
are don't cares! Thus, we don't have to write PSR.L at all and we
don't have to do a srlz.i either.
Good for another ~20 cycle improvement for EPC-based heavy-weight
syscalls.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Two other very minor changes: use "mov.i" instead of "mov" for reading
ar.pfs (for clarity; doesn't affect the code at all). Also, predicate
the load of r14 for consistency.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Avoid some stalls, which is good for about 2 cycles when invoking a
light-weight handler. When invoking a heavy-weight handler, this
helps by about 7 cycles, with most of the improvement coming from the
improved branch-prediction achieved by splitting the BBB bundle into
two MIB bundles.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch reorganizes break_fault() to optimistically assume that a
system-call is being performed from user-space (which is almost always
the case). If it turns out that (a) we're not being called due to a
system call or (b) we're being called from within the kernel, we fixup
the no-longer-valid assumptions in non_syscall() and .break_fixup(),
respectively.
With this approach, there are 3 major phases:
- Phase 1: Read various control & application registers, in
particular the current task pointer from AR.K6.
- Phase 2: Do all memory loads (load system-call entry,
load current_thread_info()->flags, prefetch
kernel register-backing store) and switch
to kernel register-stack.
- Phase 3: Call ia64_syscall_setup() and invoke
syscall-handler.
Good for 26-30 cycles of improvement on break-based syscall-path.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Reschedule code to read ar.bsp as early as possible. To enable this,
don't bother clearing some of the registers when we're returning to
kernel stacks. Also, instead of trying to support the pNonSys case
(which makes no sense), do a bugcheck instead (with break 0). Finally,
remove a clear of r14 which is a left-over from the previous patch.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Using stf8 seemed like a clever idea at the time, but stf8 forces
the cache-line to be invalidated in the L1D (if it happens to be
there already). This patch eliminates a guaranteed L1D cache-miss
and, by itself, is good for a 1-2 cycle improvement for heavy-weight
syscalls.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Why is this a good idea? Clearing b7 to 0 is guaranteed to do us no
good and writing it with __kernel_syscall_via_epc() yields a 6 cycle
improvement _if_ the application performs another EPC-based system-
call without overwriting b7, which is not all that uncommon. Well
worth the minimal cost of 1 bundle of code.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Decreases syscall overhead by approximately 6 cycles.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This by itself is good for a 1-2 cycle speed up. Effect is bigger
when combined with the later patches.
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
The ppc vDSO would not properly clear the return value for some calls,
which will be a problem when interfacing those calls with glibc. This
should be fixed before 2.6.12 is released (as it is the first kernel
with the ppc vDSO) so that we don't have to play with symbol versioning
and ugly workarounds.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
->pretcode in struct rt_sigframe is a userland pointer (and already
treated as such by code using that field).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
SVC_MODE reflects the MODE_SVC definition in asm/ptrace.h. Use
the asm/ptrace.h definition instead, and remove SVC_MODE.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Patch from Jeff Lackey
This patch updates arch/arm/mach-pxa/sleep.S to support
the PXA270 CPU. It works around Errata 39 & 50 from the
Intel(R) PXA27x Processor Family Specification Update.
Signed-off-by: Jeff Lackey
Signed-off-by: Russell King
[IA64] fix ia64 Kconfig to allow CONFIG_PM on sn2
This probably should have been fixed when I fixed up the generic build for
discontig+numa machines, but oh well.
CONFIG_PM is allowable for generic builds but not for sn2 builds, which
doesn't make much sense, and in fact breaks the build if recent ACPI bits are
added to the tree. It looks like the only arch that needs to prevent
CONFIG_PM stuff is the ski simulator (though those options could probably use
some cleanup as well), so remove the big conditional and replace it with a
simple test for IA64_HP_SIM instead.
Signed-off-by: Jesse Barnes <jbarnes@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
vector sharing patch had a typo ... mismatched spin_lock() with
a spin_unlock_irq(). Fix from Kenji Kaneshige.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Rohit and Suresh changed their mind about the order to print things
in /proc/cpuinfo, but didn't include the change in the version of
the patch they sent to me.
Signed-off-by: Tony Luck <tony.luck@intel.com>
