Pull OpenRISC update from Jonas Bonn:
"Trivial cleanups for OpenRISC."
* tag 'for-3.8' of git://openrisc.net/~jonas/linux:
openrisc: use kbuild.h instead of defining macros in asm-offset.c
openrisc: Use Kbuild infrastructure for kvm_para.h
This is modelled on commits such as the one below:
Commit fc1c3a003e ("sh: use kbuild.h
instead of defining macros in asm-offsets.c") introduced in v2.6.26.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Jonas Bonn <jonas@southpole.se>
schedule_tail() requires that the 'prev' task be passed as an argument
to it. This arg is set in _switch, just before 'returning' to one of
the ret_* functions where schedule_tail is invoked.
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Pull OpenRISC updates from Jonas Bonn:
"Fixups for some corner cases, build issues, and some obvious bugs in
IRQ handling. No major changes."
* tag 'for-3.7' of git://openrisc.net/jonas/linux:
openrisc: mask interrupts in irq_mask_ack function
openrisc: fix typos in comments and warnings
openrisc: PIC should act on domain-local irqs
openrisc: Make cpu_relax() invoke barrier()
audit: define AUDIT_ARCH_OPENRISC
openrisc: delay: fix handling of counter overflow
openrisc: delay: fix loops calculation for __const_udelay
getname() is intended to copy pathname strings from userspace into a
kernel buffer. The result is just a string in kernel space. It would
however be quite helpful to be able to attach some ancillary info to
the string.
For instance, we could attach some audit-related info to reduce the
amount of audit-related processing needed. When auditing is enabled,
we could also call getname() on the string more than once and not
need to recopy it from userspace.
This patchset converts the getname()/putname() interfaces to return
a struct instead of a string. For now, the struct just tracks the
string in kernel space and the original userland pointer for it.
Later, we'll add other information to the struct as it becomes
convenient.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Now that IRQ domains are in use, we should be acting on domain-local
IRQ numbers (hwirq) instead of 'global' ones.
Signed-off-by: Jonas Bonn <jonas@southpole.se>
When using audit on OpenRISC, an audit arch is needed. This defines
it and fixes a compile-time bug uncovered in linux-next, likely from a
cut/paste from an arch with 64/32-bit modes that defined arch_arch():
arch/openrisc/kernel/ptrace.c:190:2: error: implicit declaration of function 'audit_arch'
This replaces it with the newly defined AUDIT_ARCH_OPENRISC, since it
is only 32-bit, and currently only operates in big-endian mode.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Does block_sigmask() + tracehook_signal_handler(); called when
sigframe has been successfully built. All architectures converted
to it; block_sigmask() itself is gone now (merged into this one).
I'm still not too happy with the signature, but that's a separate
story (IMO we need a structure that would contain signal number +
siginfo + k_sigaction, so that get_signal_to_deliver() would fill one,
signal_delivered(), handle_signal() and probably setup...frame() -
take one).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Only 3 out of 63 do not. Renamed the current variant to __set_current_blocked(),
added set_current_blocked() that will exclude unblockable signals, switched
open-coded instances to it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
replace boilerplate "should we use ->saved_sigmask or ->blocked?"
with calls of obvious inlined helper...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
first fruits of ..._restore_sigmask() helpers: now we can take
boilerplate "signal didn't have a handler, clear RESTORE_SIGMASK
and restore the blocked mask from ->saved_mask" into a common
helper. Open-coded instances switched...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Pull smp hotplug cleanups from Thomas Gleixner:
"This series is merily a cleanup of code copied around in arch/* and
not changing any of the real cpu hotplug horrors yet. I wish I'd had
something more substantial for 3.5, but I underestimated the lurking
horror..."
Fix up trivial conflicts in arch/{arm,sparc,x86}/Kconfig and
arch/sparc/include/asm/thread_info_32.h
* 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (79 commits)
um: Remove leftover declaration of alloc_task_struct_node()
task_allocator: Use config switches instead of magic defines
sparc: Use common threadinfo allocator
score: Use common threadinfo allocator
sh-use-common-threadinfo-allocator
mn10300: Use common threadinfo allocator
powerpc: Use common threadinfo allocator
mips: Use common threadinfo allocator
hexagon: Use common threadinfo allocator
m32r: Use common threadinfo allocator
frv: Use common threadinfo allocator
cris: Use common threadinfo allocator
x86: Use common threadinfo allocator
c6x: Use common threadinfo allocator
fork: Provide kmemcache based thread_info allocator
tile: Use common threadinfo allocator
fork: Provide weak arch_release_[task_struct|thread_info] functions
fork: Move thread info gfp flags to header
fork: Remove the weak insanity
sh: Remove cpu_idle_wait()
...
The function sys_or1k_atomic was using call-saved registers without
restoring their value before returning. This is a faux pas: either
we need to restore their values or use scratch regs; the latter is
less code so that's the route this patch takes.
Thanks to David Hennerström for doing most of the heavy-lifting in
tracking this one down.
Reported-by: Davd Hennerström <david.hennerstrom@aacmicrotec.com>
Signed-off-by: Jonas Bonn <jonas@southpole.se>