On Wed, Jul 12, 2017 at 09:18:26PM +0200, Richard Weinberger wrote:
> Thomas,
>
> Am 12.07.2017 um 17:11 schrieb Thomas Meyer:
> > Am 10.07.2017 9:06 nachm. schrieb Richard Weinberger <ri...@no...>:
> >
> > Thomas,
> >
> > Am 10.07.2017 um 00:33 schrieb Thomas Meyer:
> > > Hard code max size. Taken from
> > > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/common/x86-xstate.h
> > >
> > > v3: use static fp_regs for get_skas_faultinfo
> > >
> > > Signed-off-by: Thomas Meyer <th...@m3...>
> > > ---
> > > arch/um/os-Linux/skas/process.c | 7 ++++---
> > > arch/x86/um/os-Linux/registers.c | 18 ++++++++++++------
> > > arch/x86/um/user-offsets.c | 2 +-
> > > 3 files changed, 17 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
> > > index 03b3c4cc7735..b5fdef795985 100644
> > > --- a/arch/um/os-Linux/skas/process.c
> > > +++ b/arch/um/os-Linux/skas/process.c
> > > @@ -88,12 +88,13 @@ void wait_stub_done(int pid)
> > >
> > > extern unsigned long current_stub_stack(void);
> > >
> > > +static unsigned long skas_faultinfo_fpregs[FP_SIZE];
> > > +
> >
> > Uhmm, are you sure that this does not race with other userspace() instances?
> >
> > Oh, is it really possible that a task gets schedule while we are in userspace signal handling from ptrace?
>
> I hoped that you'd double check. ;)
I just did write a little test program, which seems to survive this
patch. Please have a look at this test program. As far as I understand
the problem, the test program should cover above test case.
Feel free to have a look at it:
https://github.com/thomasmey/xmm-test/
> From my knowledge it is not possible, but this code was not written by me and UML internal
> semantics are more than tricky.
> Let's postpone this patch for -rc2 and check again.
>
> > Another question: when malloc a memory area in userspace: when does a userspace process end in userspace function!? Where would you free the malloced memory?
>
> It ends via handle_trap() when userspac does an exit syscall.
> I agree this is tricky to catch and needs more effort.
Ah, okay, that makes sense!
>
> Thanks,
> //richard
|
