Re: [git pull] signal.git

2013-02-24 Thread James Bottomley
On Sat, 2013-02-23 at 18:56 -0800, Linus Torvalds wrote: > Ok, in the meantime I had merged the parisc and powerpc trees, which > had their own fixes in this area: powerpc added the transactional > memory support for power8 (which impacted signal save/restore), and > parisc had some fixes to the ro

Re: [git pull] signal.git

2013-02-24 Thread Benjamin Herrenschmidt
On Sat, 2013-02-23 at 18:56 -0800, Linus Torvalds wrote: > On Wed, Feb 20, 2013 at 2:52 PM, Al Viro wrote: > > * a bunch of signal-related syscalls (both native and compat) unified. > > Ok, in the meantime I had merged the parisc and powerpc trees, which > had their own fixes in this area: powerp

Re: [git pull] signal.git

2013-02-23 Thread Al Viro
On Sat, Feb 23, 2013 at 06:56:02PM -0800, Linus Torvalds wrote: > On Wed, Feb 20, 2013 at 2:52 PM, Al Viro wrote: > > * a bunch of signal-related syscalls (both native and compat) unified. > > Ok, in the meantime I had merged the parisc and powerpc trees, which > had their own fixes in this area:

Re: [git pull] signal.git

2013-02-23 Thread Linus Torvalds
On Wed, Feb 20, 2013 at 2:52 PM, Al Viro wrote: > * a bunch of signal-related syscalls (both native and compat) unified. Ok, in the meantime I had merged the parisc and powerpc trees, which had their own fixes in this area: powerpc added the transactional memory support for power8 (which impacted

Re: [git pull] signal.git

2013-02-20 Thread Al Viro
On Wed, Feb 20, 2013 at 10:52:14PM +, Al Viro wrote: > That's the first pile; another one will come a bit later and will contain > SYSCALL_DEFINE-related patches. Please, pull from > git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus For the sake of completeness - one obvious

Re: CONFIG_GENERIC_SIGALTSTACK with asm-generic/syscalls.h (was Re: [git pull] signal.git pile 2)

2012-12-21 Thread Al Viro
On Fri, Dec 21, 2012 at 11:52:01AM +, James Hogan wrote: > Reviewed-by: James Hogan > > I also see this issue with metag when I try and select > CONFIG_GENERIC_SIGALTSTACK. Until asm-generic/syscalls.h goes away it > seems a shame to have to keep a misleading #define sys_sigaltstack > sys_si

Re: CONFIG_GENERIC_SIGALTSTACK with asm-generic/syscalls.h (was Re: [git pull] signal.git pile 2)

2012-12-21 Thread James Hogan
On 21/12/12 06:24, Vineet Gupta wrote: > On Friday 21 December 2012 05:51 AM, Al Viro wrote: >> sigaltstack infrastructure + conversion for x86, alpha and um, >> COMPAT_SYSCALL_DEFINE infrastructure. Note that there are several >> conflicts between "unify SS_ONSTACK/SS_DISABLE definitions" and >>

Re: CONFIG_GENERIC_SIGALTSTACK with asm-generic/syscalls.h (was Re: [git pull] signal.git pile 2)

2012-12-20 Thread Al Viro
On Fri, Dec 21, 2012 at 11:54:08AM +0530, Vineet Gupta wrote: > On Friday 21 December 2012 05:51 AM, Al Viro wrote: > > sigaltstack infrastructure + conversion for x86, alpha and um, > > COMPAT_SYSCALL_DEFINE infrastructure. Note that there are several > > conflicts between "unify SS_ONSTACK/SS_DI

CONFIG_GENERIC_SIGALTSTACK with asm-generic/syscalls.h (was Re: [git pull] signal.git pile 2)

2012-12-20 Thread Vineet Gupta
On Friday 21 December 2012 05:51 AM, Al Viro wrote: > sigaltstack infrastructure + conversion for x86, alpha and um, > COMPAT_SYSCALL_DEFINE infrastructure. Note that there are several > conflicts between "unify SS_ONSTACK/SS_DISABLE definitions" and > UAPI patches in mainline; resolution is trivi

Re: [git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)

2012-10-12 Thread Benjamin Herrenschmidt
On Fri, 2012-10-12 at 02:09 +0100, Al Viro wrote: > Anyway, if ppc folks can live with that stuff in its current form for now, > here's the second signal.git pull request. Stuff in there: kernel_thread/ > kernel_execve/sys_execve conversions for several more architectures plus > assorted signal fi

Re: [git pull] signal.git, pile 2 (was Re: [RFC][CFT][CFReview] execve and kernel_thread unification work)

2012-10-11 Thread Paul Mackerras
On Fri, Oct 12, 2012 at 02:09:58AM +0100, Al Viro wrote: > > How granular are you planning to make that? I mean, we are talking about > 3 objects here - init/main.o, kernel/kthread.o and kernel/kmod.o. Do they > get TOC separate from that of arch/powerpc/kernel/entry_64.o? Potentially, yes, it