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 mi
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 n
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 a
[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 - SYSCALL_AL
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 (x86
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 s
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 sta
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 w
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 w
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 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 generi
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 al
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 restor
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 mainlin
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 Le
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 l
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 c
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 kernel
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
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 qh256-0001/
23 matches
Mail list logo
