On Monday 21 January 2013, Al Viro wrote:
> 1) alpha, mips
> .weak foo
> foo = sys_ni_syscall
> 2) itanic, ppc
> asmlinkage long x (void) __attribute__((weak,alias("sys_ni_syscall")))
> 3) very common - most of the architectures
> .weak foo
> .set foo sys_ni_syscall
>
On Tue, Jan 22, 2013 at 12:47:17PM +, James Hogan wrote:
> On 21/01/13 22:55, Al Viro wrote:
> > I've tried to sanitize cond_syscall/SYSCALL_ALIAS situation; the tree is in
> > git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-syscalls
> > NOTE: this is absolutely untested and
On Monday 21 January 2013, Al Viro wrote:
> Another question: what's the following comment from spu_callbacks.c about?
> * 4. They are optional and we can't rely on them being
> *linked into the kernel. Unfortunately, the cond_syscall
> *helper does not work here as it does not add the
On 21/01/13 22:55, Al Viro wrote:
> I've tried to sanitize cond_syscall/SYSCALL_ALIAS situation; the tree is in
> git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-syscalls
> NOTE: this is absolutely untested and might very well blow up
> on any number of architectures.
>
> Review
On 21/01/13 22:55, Al Viro wrote:
I've tried to sanitize cond_syscall/SYSCALL_ALIAS situation; the tree is in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-syscalls
NOTE: this is absolutely untested and might very well blow up
on any number of architectures.
Review and
On Monday 21 January 2013, Al Viro wrote:
Another question: what's the following comment from spu_callbacks.c about?
* 4. They are optional and we can't rely on them being
*linked into the kernel. Unfortunately, the cond_syscall
*helper does not work here as it does not add the
On Tue, Jan 22, 2013 at 12:47:17PM +, James Hogan wrote:
On 21/01/13 22:55, Al Viro wrote:
I've tried to sanitize cond_syscall/SYSCALL_ALIAS situation; the tree is in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal experimental-syscalls
NOTE: this is absolutely untested and might
On Monday 21 January 2013, Al Viro wrote:
1) alpha, mips
.weak foo
foo = sys_ni_syscall
2) itanic, ppc
asmlinkage long x (void) __attribute__((weak,alias(sys_ni_syscall)))
3) very common - most of the architectures
.weak foo
.set foo sys_ni_syscall
3a)
[linux-arch Cc'd]
On Mon, Jan 21, 2013 at 02:30:11AM +, Al Viro wrote:
> Neither do I, to be honest. It might be saving us a few cycles on
> some architectures, but I'd like to see examples of that. amd64
> doesn't seem to be one, at least...
*grumble*
OK, there is one problem -
Le 20/01/2013 04:12, Al Viro a écrit :
On Sat, Jan 19, 2013 at 06:38:08AM +, Al Viro wrote:
[ 64.313636] kbd[2563]: segfault at 9fe ip 09fe sp b758293c
error 4 in dash[8048000+18000]
After bisecting, the following commit seems responsible:
1d4b4b2994b5fc208963c0b795291f8c1f18becf
Le 20/01/2013 04:12, Al Viro a écrit :
On Sat, Jan 19, 2013 at 06:38:08AM +, Al Viro wrote:
[ 64.313636] kbd[2563]: segfault at 9fe ip 09fe sp b758293c
error 4 in dash[8048000+18000]
After bisecting, the following commit seems responsible:
1d4b4b2994b5fc208963c0b795291f8c1f18becf
[linux-arch Cc'd]
On Mon, Jan 21, 2013 at 02:30:11AM +, Al Viro wrote:
Neither do I, to be honest. It might be saving us a few cycles on
some architectures, but I'd like to see examples of that. amd64
doesn't seem to be one, at least...
*grumble*
OK, there is one problem -
On Sun, Jan 20, 2013 at 06:39:09PM -0800, Linus Torvalds wrote:
> And right now, that HAVE_SYSCALL_WRAPPERS does make it much harder to
> think about the header file changes.
Agreed.
> > FWIW, there's another bit of ugliness around that area - all these
> > #define __SC_BLAH3, etc., all of the
On Sun, Jan 20, 2013 at 6:30 PM, Al Viro wrote:
>
> Neither do I, to be honest. It might be saving us a few cycles on
> some architectures, but I'd like to see examples of that. amd64
> doesn't seem to be one, at least...
I think that the inlining of the body should make it basically be
pretty
On Sun, Jan 20, 2013 at 05:40:28PM -0800, Linus Torvalds wrote:
> On Sun, Jan 20, 2013 at 5:22 PM, Al Viro wrote:
> >
> > Anyway, that's a separate story - semctl(2) is going to be ugly, no matter
> > what we do, but the rest of those guys doesn't have to. How about the
> > following (completely
On Sun, Jan 20, 2013 at 5:22 PM, Al Viro wrote:
>
> Anyway, that's a separate story - semctl(2) is going to be ugly, no matter
> what we do, but the rest of those guys doesn't have to. How about the
> following (completely untested):
Hmm. Looks like the RightThing(tm) to me.
The thing that
On Sun, Jan 20, 2013 at 12:53:20PM -0800, Linus Torvalds wrote:
> On Sat, Jan 19, 2013 at 7:12 PM, Al Viro wrote:
> >
> > OK... I think I understand what's going on. We need asmlinkage_protect
> > in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
> > treat that as syscall
On Sun, Jan 20, 2013 at 12:53:20PM -0800, Linus Torvalds wrote:
> On Sat, Jan 19, 2013 at 7:12 PM, Al Viro wrote:
> >
> > OK... I think I understand what's going on. We need asmlinkage_protect
> > in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
> > treat that as syscall
On Sat, Jan 19, 2013 at 7:12 PM, Al Viro wrote:
>
> OK... I think I understand what's going on. We need asmlinkage_protect
> in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
> treat that as syscall wrappers - i.e. have SYSCALL_DEFINEx on i386 add
> a wrapper that would do
On Sat, Jan 19, 2013 at 7:12 PM, Al Viro v...@zeniv.linux.org.uk wrote:
OK... I think I understand what's going on. We need asmlinkage_protect
in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
treat that as syscall wrappers - i.e. have SYSCALL_DEFINEx on i386 add
a
On Sun, Jan 20, 2013 at 12:53:20PM -0800, Linus Torvalds wrote:
On Sat, Jan 19, 2013 at 7:12 PM, Al Viro v...@zeniv.linux.org.uk wrote:
OK... I think I understand what's going on. We need asmlinkage_protect
in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
treat
On Sun, Jan 20, 2013 at 12:53:20PM -0800, Linus Torvalds wrote:
On Sat, Jan 19, 2013 at 7:12 PM, Al Viro v...@zeniv.linux.org.uk wrote:
OK... I think I understand what's going on. We need asmlinkage_protect
in sys_clone() ;-/ For what it's worth, I really wonder if we ought to
treat
On Sun, Jan 20, 2013 at 5:22 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Anyway, that's a separate story - semctl(2) is going to be ugly, no matter
what we do, but the rest of those guys doesn't have to. How about the
following (completely untested):
Hmm. Looks like the RightThing(tm) to me.
On Sun, Jan 20, 2013 at 05:40:28PM -0800, Linus Torvalds wrote:
On Sun, Jan 20, 2013 at 5:22 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Anyway, that's a separate story - semctl(2) is going to be ugly, no matter
what we do, but the rest of those guys doesn't have to. How about the
On Sun, Jan 20, 2013 at 6:30 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Neither do I, to be honest. It might be saving us a few cycles on
some architectures, but I'd like to see examples of that. amd64
doesn't seem to be one, at least...
I think that the inlining of the body should make it
On Sun, Jan 20, 2013 at 06:39:09PM -0800, Linus Torvalds wrote:
And right now, that HAVE_SYSCALL_WRAPPERS does make it much harder to
think about the header file changes.
Agreed.
FWIW, there's another bit of ugliness around that area - all these
#define __SC_BLAH3, etc., all of the same
On Sat, Jan 19, 2013 at 06:38:08AM +, Al Viro wrote:
> > [ 64.313636] kbd[2563]: segfault at 9fe ip 09fe sp b758293c
> > error 4 in dash[8048000+18000]
> >
> > After bisecting, the following commit seems responsible:
> > 1d4b4b2994b5fc208963c0b795291f8c1f18becf (x86, um: switch to
On Sat, Jan 19, 2013 at 06:38:08AM +, Al Viro wrote:
[ 64.313636] kbd[2563]: segfault at 9fe ip 09fe sp b758293c
error 4 in dash[8048000+18000]
After bisecting, the following commit seems responsible:
1d4b4b2994b5fc208963c0b795291f8c1f18becf (x86, um: switch to generic
On Mon, Jan 14, 2013 at 10:42:10AM +0100, Nicolas Dichtel wrote:
> Hi,
>
> I'm running a virtual host (kvm/qemu x86 32 bits 16 CPUs, debian
> wheezy) over a x86 64bits target.
> The virtual host has problem during the boot with recent kernels
> (sometimes, daemons crash, but not always, and not
On Mon, Jan 14, 2013 at 10:42:10AM +0100, Nicolas Dichtel wrote:
Hi,
I'm running a virtual host (kvm/qemu x86 32 bits 16 CPUs, debian
wheezy) over a x86 64bits target.
The virtual host has problem during the boot with recent kernels
(sometimes, daemons crash, but not always, and not always
On Sat, Nov 10, 2012 at 07:33:39AM +, Al Viro wrote:
> I think I see what's going on there. It's PTREGSCALL blindly used for
> clone wrapper in ia32entry.S. FWIW, it's wrong for all of those
> suckers, anyway:
> * fork/clone/vfork need to save extra registers, but don't need
> to
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro wrote:
> Could you verify that this on top of for-next gets the things working again?
> It's a very lazy way to deal with that (we don't want to bother with
> restoring extras, at the very least), but the rest can go separately (and
> is shared with
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Could you verify that this on top of for-next gets the things working again?
It's a very lazy way to deal with that (we don't want to bother with
restoring extras, at the very least), but the rest can go separately (and
is
On Sat, Nov 10, 2012 at 07:33:39AM +, Al Viro wrote:
I think I see what's going on there. It's PTREGSCALL blindly used for
clone wrapper in ia32entry.S. FWIW, it's wrong for all of those
suckers, anyway:
* fork/clone/vfork need to save extra registers, but don't need
to restore
On Fri, Nov 09, 2012 at 09:47:54PM -0800, Michel Lespinasse wrote:
> On Fri, Nov 9, 2012 at 9:33 PM, Al Viro wrote:
> > On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
> >> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
> >> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro wrote:
> On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
>> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
>> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> >> Hi,
>> >>
>> >> I'm having an issue booting current
On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
> >> Hi,
> >>
> >> I'm having an issue booting current linux-next kernels on my test
> >> machines. Userspace
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
> On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> Hi,
>>
>> I'm having an issue booting current linux-next kernels on my test
>> machines. Userspace crashes when it's supposed to pivot to the rootfs.
>> With the loglevel=8
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
> Hi,
>
> I'm having an issue booting current linux-next kernels on my test
> machines. Userspace crashes when it's supposed to pivot to the rootfs.
> With the loglevel=8 kernel parameter, the last messages I see are:
>
>
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root filesystem in pivot_root init.
[6.252717] usb 2-1: link
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root filesystem in pivot_root init.
[6.252717] usb 2-1: link
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the
On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
Hi,
I'm having an issue booting current linux-next kernels on my test
machines.
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
Hi,
I'm
On Fri, Nov 09, 2012 at 09:47:54PM -0800, Michel Lespinasse wrote:
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov
46 matches
Mail list logo
