target/s390x/cpu.h | 3 ++ target/s390x/internal.h | 5 -- linux-user/s390x/signal.c | 37 ++++++++++++-- target/s390x/cc_helper.c | 2 +- target/s390x/excp_helper.c | 28 +++++----- target/s390x/gdbstub.c | 15 +----- target/s390x/helper.c | 101 ++++++++++++++++++++----------------- target/s390x/sigp.c | 3 +- 8 files changed, 110 insertions(+), 84 deletions(-)
The PSW_MASK_CC component of psw.mask was not handled properly
in the creation or restoration of signal frames.
r~
Richard Henderson (5):
target/s390x: Expose load_psw and get_psw_mask to cpu.h
target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
target/s390x: Improve s390_cpu_dump_state vs cc_op
target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
linux-user/s390x: Save and restore psw.mask properly
target/s390x/cpu.h | 3 ++
target/s390x/internal.h | 5 --
linux-user/s390x/signal.c | 37 ++++++++++++--
target/s390x/cc_helper.c | 2 +-
target/s390x/excp_helper.c | 28 +++++-----
target/s390x/gdbstub.c | 15 +-----
target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
target/s390x/sigp.c | 3 +-
8 files changed, 110 insertions(+), 84 deletions(-)
--
2.25.1
On 15.06.21 05:07, Richard Henderson wrote:
> The PSW_MASK_CC component of psw.mask was not handled properly
> in the creation or restoration of signal frames.
>
Maybe add a Reported-by: jonathan.albrecht@linux.vnet.ibm.com
in the right patches?
> Richard Henderson (5):
> target/s390x: Expose load_psw and get_psw_mask to cpu.h
> target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
> target/s390x: Improve s390_cpu_dump_state vs cc_op
> target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
> linux-user/s390x: Save and restore psw.mask properly
>
> target/s390x/cpu.h | 3 ++
> target/s390x/internal.h | 5 --
> linux-user/s390x/signal.c | 37 ++++++++++++--
> target/s390x/cc_helper.c | 2 +-
> target/s390x/excp_helper.c | 28 +++++-----
> target/s390x/gdbstub.c | 15 +-----
> target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
> target/s390x/sigp.c | 3 +-
> 8 files changed, 110 insertions(+), 84 deletions(-)
>
On Tue, Jun 15 2021, Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 15.06.21 05:07, Richard Henderson wrote: >> The PSW_MASK_CC component of psw.mask was not handled properly >> in the creation or restoration of signal frames. >> > > > Maybe add a Reported-by: jonathan.albrecht@linux.vnet.ibm.com > in the right patches? Let me know to which ones, and I will add them.
On Mon, Jun 14 2021, Richard Henderson <richard.henderson@linaro.org> wrote:
> The PSW_MASK_CC component of psw.mask was not handled properly
> in the creation or restoration of signal frames.
>
>
> r~
>
>
> Richard Henderson (5):
> target/s390x: Expose load_psw and get_psw_mask to cpu.h
> target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
> target/s390x: Improve s390_cpu_dump_state vs cc_op
> target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
> linux-user/s390x: Save and restore psw.mask properly
>
> target/s390x/cpu.h | 3 ++
> target/s390x/internal.h | 5 --
> linux-user/s390x/signal.c | 37 ++++++++++++--
> target/s390x/cc_helper.c | 2 +-
> target/s390x/excp_helper.c | 28 +++++-----
> target/s390x/gdbstub.c | 15 +-----
> target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
> target/s390x/sigp.c | 3 +-
> 8 files changed, 110 insertions(+), 84 deletions(-)
Thanks, applied.
On 2021-06-14 11:07 pm, Richard Henderson wrote:
> The PSW_MASK_CC component of psw.mask was not handled properly
> in the creation or restoration of signal frames.
>
Thanks Richard! Peter and I tested this series against:
* https://bugs.launchpad.net/qemu/+bug/1886793
* https://bugs.launchpad.net/qemu/+bug/1893040
and they look fixed now.
Appreciate your time on this,
Jon
>
> r~
>
>
> Richard Henderson (5):
> target/s390x: Expose load_psw and get_psw_mask to cpu.h
> target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
> target/s390x: Improve s390_cpu_dump_state vs cc_op
> target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
> linux-user/s390x: Save and restore psw.mask properly
>
> target/s390x/cpu.h | 3 ++
> target/s390x/internal.h | 5 --
> linux-user/s390x/signal.c | 37 ++++++++++++--
> target/s390x/cc_helper.c | 2 +-
> target/s390x/excp_helper.c | 28 +++++-----
> target/s390x/gdbstub.c | 15 +-----
> target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
> target/s390x/sigp.c | 3 +-
> 8 files changed, 110 insertions(+), 84 deletions(-)
On Tue, Jun 15 2021, "jonathan.albrecht" <jonathan.albrecht@linux.vnet.ibm.com> wrote: > On 2021-06-14 11:07 pm, Richard Henderson wrote: >> The PSW_MASK_CC component of psw.mask was not handled properly >> in the creation or restoration of signal frames. >> > > Thanks Richard! Peter and I tested this series against: > * https://bugs.launchpad.net/qemu/+bug/1886793 > * https://bugs.launchpad.net/qemu/+bug/1893040 > and they look fixed now. May I add some Tested-by: tags for this? (I don't know who Peter is.)
On 2021-06-16 11:01 am, Cornelia Huck wrote: > On Tue, Jun 15 2021, "jonathan.albrecht" > <jonathan.albrecht@linux.vnet.ibm.com> wrote: > >> On 2021-06-14 11:07 pm, Richard Henderson wrote: >>> The PSW_MASK_CC component of psw.mask was not handled properly >>> in the creation or restoration of signal frames. >>> >> >> Thanks Richard! Peter and I tested this series against: >> * https://bugs.launchpad.net/qemu/+bug/1886793 >> * https://bugs.launchpad.net/qemu/+bug/1893040 >> and they look fixed now. > > May I add some Tested-by: tags for this? (I don't know who Peter is.) Yes, thanks. Peter is ruixin.bao@ibm.com
Richard Henderson <richard.henderson@linaro.org> writes:
> The PSW_MASK_CC component of psw.mask was not handled properly
> in the creation or restoration of signal frames.
Still seeing issues running on s390x machine:
05:00:29 [ajb@qemu01:~/l/q/b/debug] s390x/signal-fixes|… 38 + retry.py -n 100 -c -- ./qemu-s390x ./tests/tcg/s390x-linux-user/signals
...
...
Results summary:
0: 62 times (62.00%), avg time 2.253 (0.00 varience/0.00 deviation)
-11: 38 times (38.00%), avg time 0.251 (0.00 varience/0.00 deviation)
Ran command 100 times, 62 passes
I don't get much from the backtrace, maybe the atomic triggered the seg?
#0 0x0000000001016244 in vfprintf ()
[Current thread is 1 (Thread 0x4001001910 (LWP 27308))]
(gdb) bt
#0 0x0000000001016244 in vfprintf ()
#1 0x000000000101d484 in printf ()
#2 0x0000000001000b2e in background_thread_func (arg=0x10a3620) at /home/ajb/lsrc/qemu.git/tests/tcg/multiarch/signals.c:65
#3 0x0000000001003150 in start_thread (arg=0x4001001910) at pthread_create.c:463
#4 0x0000000001035b40 in thread_start ()
(gdb) frame 2
#2 0x0000000001000b2e in background_thread_func (arg=0x10a3620) at /home/ajb/lsrc/qemu.git/tests/tcg/multiarch/signals.c:65
65 printf("thread%d: started\n", job->number);
(gdb) info locals
job = 0x10a3620
(gdb) p job
$1 = (ThreadJob *) 0x10a3620
(gdb) p job->number
$2 = 0
(gdb) frame 0
#0 0x0000000001016244 in vfprintf ()
(gdb) x/5i $pc
=> 0x1016244 <vfprintf+1316>: asi 224(%r11),1
0x101624a <vfprintf+1322>: cgijne %r1,0,0x1017570 <vfprintf+6224>
0x1016250 <vfprintf+1328>: lg %r1,336(%r11)
0x1016256 <vfprintf+1334>: lghi %r3,37
0x101625a <vfprintf+1338>: aghik %r6,%r1,1
(gdb) p/x $r11
$3 = 0x4001000708
(gdb) p/x $r11 + 224
$4 = 0x40010007e8
(gdb) x/1g $4
0x40010007e8: 0x0000000000000000
(gdb)
However running on x86 backend everything seems to be fine.
Results summary:
0: 200 times (100.00%), avg time 2.255 (0.00 varience/0.00 deviation)
Ran command 200 times, 200 passes
>
>
> r~
>
>
> Richard Henderson (5):
> target/s390x: Expose load_psw and get_psw_mask to cpu.h
> target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
> target/s390x: Improve s390_cpu_dump_state vs cc_op
> target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
> linux-user/s390x: Save and restore psw.mask properly
>
> target/s390x/cpu.h | 3 ++
> target/s390x/internal.h | 5 --
> linux-user/s390x/signal.c | 37 ++++++++++++--
> target/s390x/cc_helper.c | 2 +-
> target/s390x/excp_helper.c | 28 +++++-----
> target/s390x/gdbstub.c | 15 +-----
> target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
> target/s390x/sigp.c | 3 +-
> 8 files changed, 110 insertions(+), 84 deletions(-)
--
Alex Bennée
Alex Bennée <alex.bennee@linaro.org> writes:
> Richard Henderson <richard.henderson@linaro.org> writes:
>
>> The PSW_MASK_CC component of psw.mask was not handled properly
>> in the creation or restoration of signal frames.
>
> Still seeing issues running on s390x machine:
>
> 05:00:29 [ajb@qemu01:~/l/q/b/debug] s390x/signal-fixes|… 38 + retry.py -n 100 -c -- ./qemu-s390x ./tests/tcg/s390x-linux-user/signals
> ...
> ...
> Results summary:
> 0: 62 times (62.00%), avg time 2.253 (0.00 varience/0.00 deviation)
> -11: 38 times (38.00%), avg time 0.251 (0.00 varience/0.00 deviation)
> Ran command 100 times, 62 passes
>
> I don't get much from the backtrace, maybe the atomic triggered the seg?
>
> #0 0x0000000001016244 in vfprintf ()
> [Current thread is 1 (Thread 0x4001001910 (LWP 27308))]
> (gdb) bt
> #0 0x0000000001016244 in vfprintf ()
> #1 0x000000000101d484 in printf ()
> #2 0x0000000001000b2e in background_thread_func (arg=0x10a3620) at /home/ajb/lsrc/qemu.git/tests/tcg/multiarch/signals.c:65
> #3 0x0000000001003150 in start_thread (arg=0x4001001910) at pthread_create.c:463
> #4 0x0000000001035b40 in thread_start ()
> (gdb) frame 2
> #2 0x0000000001000b2e in background_thread_func (arg=0x10a3620) at /home/ajb/lsrc/qemu.git/tests/tcg/multiarch/signals.c:65
> 65 printf("thread%d: started\n", job->number);
> (gdb) info locals
> job = 0x10a3620
> (gdb) p job
> $1 = (ThreadJob *) 0x10a3620
> (gdb) p job->number
> $2 = 0
> (gdb) frame 0
> #0 0x0000000001016244 in vfprintf ()
> (gdb) x/5i $pc
> => 0x1016244 <vfprintf+1316>: asi 224(%r11),1
> 0x101624a <vfprintf+1322>: cgijne %r1,0,0x1017570 <vfprintf+6224>
> 0x1016250 <vfprintf+1328>: lg %r1,336(%r11)
> 0x1016256 <vfprintf+1334>: lghi %r3,37
> 0x101625a <vfprintf+1338>: aghik %r6,%r1,1
> (gdb) p/x $r11
> $3 = 0x4001000708
> (gdb) p/x $r11 + 224
> $4 = 0x40010007e8
> (gdb) x/1g $4
> 0x40010007e8: 0x0000000000000000
> (gdb)
>
> However running on x86 backend everything seems to be fine.
>
> Results summary:
> 0: 200 times (100.00%), avg time 2.255 (0.00 varience/0.00 deviation)
> Ran command 200 times, 200 passes
It's hard to desegregate the SEGVs we get during normal runs but a pass
followed by a fail shows:
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
shutting down after: 2000 signals
qemu: SIGSEGV pc=0x3fff484bd1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4848f1a address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff47477f2 address=40007ff000 w=1 oldset=0x00000000
[Thread 0x3fffdff1780 (LWP 32928) exited]
[Inferior 1 (process 32928) exited normally]
(gdb) r
Starting program: /home/ajb/lsrc/qemu.git/builds/debug/qemu-s390x ./tests/tcg/s390x-linux-user/signals
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
[New Thread 0x3fffceff910 (LWP 32964)]
qemu: SIGSEGV pc=0x3fff4752f2a address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff471fa1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff475c49c address=40007ff000 w=1 oldset=0x00000000
[New Thread 0x3fffdff0910 (LWP 32965)]
qemu: SIGSEGV pc=0x3fff4703b18 address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fffd812efe address=4001000000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff471081e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4715ee6 address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff471a02a address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff472491e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4725d1e address=4001000000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4730536 address=4001000000 w=0 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473171e address=40007ff000 w=1 oldset=0x00000000
[Thread 0x3fffdff0910 (LWP 32965) exited]
[Thread 0x3fffceff910 (LWP 32964) exited]
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
So something is going astray to 4001000000 which otherwise doesn't.
>
>>
>>
>> r~
>>
>>
>> Richard Henderson (5):
>> target/s390x: Expose load_psw and get_psw_mask to cpu.h
>> target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
>> target/s390x: Improve s390_cpu_dump_state vs cc_op
>> target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
>> linux-user/s390x: Save and restore psw.mask properly
>>
>> target/s390x/cpu.h | 3 ++
>> target/s390x/internal.h | 5 --
>> linux-user/s390x/signal.c | 37 ++++++++++++--
>> target/s390x/cc_helper.c | 2 +-
>> target/s390x/excp_helper.c | 28 +++++-----
>> target/s390x/gdbstub.c | 15 +-----
>> target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
>> target/s390x/sigp.c | 3 +-
>> 8 files changed, 110 insertions(+), 84 deletions(-)
--
Alex Bennée
On Tue, Jun 15 2021, Alex Bennée <alex.bennee@linaro.org> wrote: > Richard Henderson <richard.henderson@linaro.org> writes: > >> The PSW_MASK_CC component of psw.mask was not handled properly >> in the creation or restoration of signal frames. > > Still seeing issues running on s390x machine: (...) > However running on x86 backend everything seems to be fine. (...) So, in summary, this improves things, although there are some remaining problems? Asking because I'm looking to queue this.
On 6/16/21 3:38 AM, Cornelia Huck wrote: > On Tue, Jun 15 2021, Alex Bennée <alex.bennee@linaro.org> wrote: > >> Richard Henderson <richard.henderson@linaro.org> writes: >> >>> The PSW_MASK_CC component of psw.mask was not handled properly >>> in the creation or restoration of signal frames. >> >> Still seeing issues running on s390x machine: > > (...) > >> However running on x86 backend everything seems to be fine. > > (...) > > So, in summary, this improves things, although there are some remaining > problems? > > Asking because I'm looking to queue this. Alex is seeing something that I believe is unrelated. And also, I have a patch set out for that as well. :-) r~
On Wed, Jun 16 2021, Richard Henderson <richard.henderson@linaro.org> wrote: > On 6/16/21 3:38 AM, Cornelia Huck wrote: >> On Tue, Jun 15 2021, Alex Bennée <alex.bennee@linaro.org> wrote: >> >>> Richard Henderson <richard.henderson@linaro.org> writes: >>> >>>> The PSW_MASK_CC component of psw.mask was not handled properly >>>> in the creation or restoration of signal frames. >>> >>> Still seeing issues running on s390x machine: >> >> (...) >> >>> However running on x86 backend everything seems to be fine. >> >> (...) >> >> So, in summary, this improves things, although there are some remaining >> problems? >> >> Asking because I'm looking to queue this. > > Alex is seeing something that I believe is unrelated. > And also, I have a patch set out for that as well. :-) Good to hear :)
© 2016 - 2024 Red Hat, Inc.