All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: ruixin.bao@ibm.com, jonathan.albrecht@linux.vnet.ibm.com,
	david@redhat.com, cohuck@redhat.com, qemu-devel@nongnu.org,
	qemu-s390x@nongnu.org
Subject: Re: [PATCH 0/5] linux-user/s390x: Fix psw.mask handling in signals
Date: Tue, 15 Jun 2021 10:51:28 +0100	[thread overview]
Message-ID: <87o8c7ihgf.fsf@linaro.org> (raw)
In-Reply-To: <87sg1jiiku.fsf@linaro.org> ("Alex Bennée"'s message of "Tue, 15 Jun 2021 10:27:13 +0100")

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


  reply	other threads:[~2021-06-15  9:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15  3:07 [PATCH 0/5] linux-user/s390x: Fix psw.mask handling in signals Richard Henderson
2021-06-15  3:07 ` [PATCH 1/5] target/s390x: Expose load_psw and get_psw_mask to cpu.h Richard Henderson
2021-06-15  7:47   ` David Hildenbrand
2021-06-15  8:57   ` Alex Bennée
2021-06-15  3:07 ` [PATCH 2/5] target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask Richard Henderson
2021-06-15  7:49   ` David Hildenbrand
2021-06-15  3:07 ` [PATCH 3/5] target/s390x: Improve s390_cpu_dump_state vs cc_op Richard Henderson
2021-06-15  7:51   ` David Hildenbrand
2021-06-15  3:07 ` [PATCH 4/5] target/s390x: Use s390_cpu_{set_psw, get_psw_mask} in gdbstub Richard Henderson
2021-06-15  7:52   ` David Hildenbrand
2021-06-15  3:07 ` [PATCH 5/5] linux-user/s390x: Save and restore psw.mask properly Richard Henderson
2021-06-15  7:59   ` David Hildenbrand
2021-06-15  9:02 ` [PATCH 0/5] linux-user/s390x: Fix psw.mask handling in signals Christian Borntraeger
2021-06-16 15:00   ` Cornelia Huck
2021-06-15  9:27 ` Alex Bennée
2021-06-15  9:51   ` Alex Bennée [this message]
2021-06-16 10:38   ` Cornelia Huck
2021-06-16 14:48     ` Richard Henderson
2021-06-16 14:59       ` Cornelia Huck
2021-06-15 18:03 ` jonathan.albrecht
2021-06-16 15:01   ` Cornelia Huck
2021-06-16 15:22     ` jonathan.albrecht
2021-06-17  8:33 ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8c7ihgf.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=jonathan.albrecht@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=ruixin.bao@ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.