Mostly about syscall wrappers this time; there will be another pile with
patches in the same general area from various people, but I'd rather push
those after both that and vfs.git pile are in. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlog:
Al Vir
Fixes for several regressions introduced in the last signal.git pile,
along with fixing bugs in truncate and ftruncate compat (on just about
anything biarch at least one of those two had been done wrong).
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortl
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
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
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:
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
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
* a bunch of signal-related syscalls (both native and compat) unified.
* a bunch of compat syscalls switched to COMPAT_SYSCALL_DEFINE (fixing several
potential problems with missing argument validation, while we are at it)
* a lot of now-pointless wrappers killed
* a couple of architectures (cris a
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
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
>>
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
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
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 trivial - just remove definitions
of SS_ONSTACK and SS_DISABLED f
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
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
On Fri, Oct 12, 2012 at 11:16:33AM +1100, Paul Mackerras wrote:
> On Thu, Oct 11, 2012 at 01:53:06PM +0100, Al Viro wrote:
>
> > Umm... Maybe, but let's do that as subsequent cleanup. Again,
> > we almost certainly don't need to mess with TOC at all - the callbacks
> > are in the main kernel
16 matches
Mail list logo
