[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] linux-user: safe_syscall updates

From: Riku Voipio
Subject: Re: [Qemu-devel] [PATCH 0/6] linux-user: safe_syscall updates
Date: Tue, 21 Jun 2016 22:08:57 +0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Jun 13, 2016 at 11:09:17PM +0100, Peter Maydell wrote:
> On 13 June 2016 at 22:53, Peter Maydell <address@hidden> wrote:
> > On 13 June 2016 at 22:45, Richard Henderson <address@hidden> wrote:
> >> Richard Henderson (6):
> >>   linux-user: fix x86_64 safe_syscall
> >>   linux-user: Provide safe_syscall for i386
> >>   linux-user: Provide safe_syscall for arm
> >>   linux-user: Provide safe_syscall for aarch64
> >>   linux-user: Provide safe_syscall for s390x
> >>   linux-user: Provide safe_syscall for ppc64
> >
> > I just spent today writing these for i386, arm and aarch64,
> > so we've duplicated work here :-(

On the positive side, duplication makes it easier to give
a really throughout review :)

> Also, I have a patchset which moves from the generic/hostdep.h
> to having explicitly one hostdep.h per supported architecture.
> That needs to go in before these, otherwise these break
> compilation unless you do a 'make clean'.
> I'll send that out tomorrow, working version in
> https://git.linaro.org/people/peter.maydell/qemu-arm.git/shortlog/refs/heads/sigrace-fixes

I've merged all pending patches except the safe_syscall ones to:


Peter, Richard, do you have an agreement who's versions of
the safe_syscall patches should be included? 


> We also have a bug in the signal.c code which I noticed
> trying to test my i386 safe_syscall: we call sigfillset()
> on the uc_sigmask field of the ucontext_t* that the
> kernel passes us as argument 3 of the signal handler.
> This trashes a lot of stuff on the stack because the
> libc headers say "sigset_t is 128 bytes" and the kernel
> says "it's only 8 bytes", so the sigfillset() writes -1
> to a lot of the stack that it shouldn't. (I don't know
> why glibc exposes a struct that isn't actually what
> the kernel provides here, but it's a very long standing
> confusion :-( )
> thanks
> -- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]