BMC/Intel-BMC/linux.git/arch/ia64/kernel/fsys.S, branch dev

ia64: remove paravirt code

2015-06-10T21:26:32+00:00

All the ia64 pvops code is now dead code since both xen and kvm support have been ripped out [0] [1]. Just that no one had troubled to rip this stuff out. The only useful remaining pieces were the old pvops docs but that was recently also generalized and moved out from ia64 [2]. This has been run time tested on an ia64 Madison system. [0] 003f7de625890 "KVM: ia64: remove" since v3.19-rc1 [1] d52eefb47d4eb "ia64/xen: Remove Xen support for ia64" since v3.14-rc1 [2] "virtual: Documentation: simplify and generalize paravirt_ops.txt" Signed-off-by: Luis R. Rodriguez Signed-off-by: Tony Luck

Fix broken fsys_getppid()

2013-03-19T23:14:52+00:00

In particular fsys_getppid always returns the ppid in the initial pid namespace so it does not work for a process in a pid namespace. Fix from Eric Biederman just removes the fast system call path. While it is a little bit sad to see another one of these bite the dust ... I can't imagine that getppid() is really on any real applications critical path. Signed-off-by: Tony Luck

cputime: Generic on-demand virtual cputime accounting

2013-01-27T18:23:27+00:00

If we want to stop the tick further idle, we need to be able to account the cputime without using the tick. Virtual based cputime accounting solves that problem by hooking into kernel/user boundaries. However implementing CONFIG_VIRT_CPU_ACCOUNTING require low level hooks and involves more overhead. But we already have a generic context tracking subsystem that is required for RCU needs by archs which plan to shut down the tick outside idle. This patch implements a generic virtual based cputime accounting that relies on these generic kernel/user hooks. There are some upsides of doing this: - This requires no arch code to implement CONFIG_VIRT_CPU_ACCOUNTING if context tracking is already built (already necessary for RCU in full tickless mode). - We can rely on the generic context tracking subsystem to dynamically (de)activate the hooks, so that we can switch anytime between virtual and tick based accounting. This way we don't have the overhead of the virtual accounting when the tick is running periodically. And one downside: - There is probably more overhead than a native virtual based cputime accounting. But this relies on hooks that are already set anyway. Signed-off-by: Frederic Weisbecker Cc: Andrew Morton Cc: Ingo Molnar Cc: Li Zhong Cc: Namhyung Kim Cc: Paul E. McKenney Cc: Paul Gortmaker Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner

[IA64] Liberate the signal layer from IA64 assembler

2012-05-16T21:09:55+00:00

Currently IA64 has a assembler implementation of sigrtprocmask. Having a single architecture implement this in assembler language is a serious maintenance problem that inhibits further evolution of the signal subsystem. Everyone who wants to do deep changes to signals would need to learn that assembler language. Whatever performance improvements IA64 gets from this it cannot be worth the price in maintainability. We have some locking problems in signal that need to be fixed, but this roadblock needs to be removed first. So just disable the special assembler IA64 implementation and fall back to a normal syscall there. Acked-by: Matt Fleming Signed-off-by: Andi Kleen Signed-off-by: Tony Luck

[IA64] Fix fast syscall version of getcpu()

2012-05-16T20:58:29+00:00

GETCPU(2) says: int getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *tcache); ... When either cpu or node is NULL nothing is written to the respective pointer. But the fast system call path had no checks for NULL, and would thus return -EFAULT if either (or both) of these were NULL. Reported-by: Mike Frysinger Tested-by: Mike Frysinger Signed-off-by: Tony Luck

Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-03-29T21:16:48+00:00

Pull timer core updates from Thomas Gleixner. * 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ia64: vsyscall: Add missing paranthesis alarmtimer: Don't call rtc_timer_init() when CONFIG_RTC_CLASS=n x86: vdso: Put declaration before code x86-64: Inline vdso clock_gettime helpers x86-64: Simplify and optimize vdso clock_gettime monotonic variants kernel-time: fix s/then/than/ spelling errors time: remove no_sync_cmos_clock time: Avoid scary backtraces when warning of > 11% adj alarmtimer: Make sure we initialize the rtctimer ntp: Fix leap-second hrtimer livelock x86, tsc: Skip refined tsc calibration on systems with reliable TSC rtc: Provide flag for rtc devices that don't support UIE ia64: vsyscall: Use seqcount instead of seqlock x86: vdso: Use seqcount instead of seqlock x86: vdso: Remove bogus locking in update_vsyscall_tz() time: Remove bogus comments time: Fix change_clocksource locking time: x86: Fix race switching from vsyscall to non-vsyscall clock

Disintegrate asm/system.h for IA64

2012-03-28T17:30:02+00:00

Disintegrate asm/system.h for IA64. Signed-off-by: David Howells Acked-by: Tony Luck cc: linux-ia64@vger.kernel.org

ia64: vsyscall: Use seqcount instead of seqlock

2012-03-16T01:17:59+00:00

The update of the vdso data happens under xtime_lock, so adding a nested lock is pointless. Just use a seqcount to sync the readers. Signed-off-by: Thomas Gleixner Cc: Tony Luck Signed-off-by: John Stultz

[IA64] Optimize ticket spinlocks in fsys_rt_sigprocmask

2010-09-15T22:35:48+00:00

Tony's fix (f574c843191728d9407b766a027f779dcd27b272) has a small bug, it incorrectly uses "r3" as a scratch register in the first of the two unlock paths ... it is also inefficient. Optimize the fast path again. Signed-off-by: Petr Tesarik Signed-off-by: Tony Luck

[IA64] fix siglock

2010-09-09T22:16:56+00:00

When ia64 converted to using ticket locks, an inline implementation of trylock/unlock in fsys.S was missed. This was not noticed because in most circumstances it simply resulted in using the slow path because the siglock was apparently not available (under old spinlock rules). Problems occur when the ticket spinlock has value 0x0 (when first initialised, or when it wraps around). At this point the fsys.S code acquires the lock (changing the 0x0 to 0x1. If another process attempts to get the lock at this point, it will change the value from 0x1 to 0x2 (using new ticket lock rules). Then the fsys.S code will free the lock using old spinlock rules by writing 0x0 to it. From here a variety of bad things can happen. Signed-off-by: Tony Luck