qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Christophe Lyon <christophe.lyon@st.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Christophe Lyon <christophe.lyon@linaro.org>,
	Riku Voipio <riku.voipio@iki.fi>,
	Laurent Vivier <laurent@vivier.eu>
Subject: Re: [Qemu-devel] [ARM/FDPIC v2 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
Date: Mon, 23 Apr 2018 16:31:11 +0100	[thread overview]
Message-ID: <CAFEAcA8L7n4vrdfe2GL9ASpFLiPdsDs+KfgbAYpacNMQuFHp7w@mail.gmail.com> (raw)
In-Reply-To: <e749ca16-26bc-b900-d6b3-a06007e6d572@st.com>

On 23 April 2018 at 15:22, Christophe Lyon <christophe.lyon@st.com> wrote:
> On 23/04/2018 15:05, Peter Maydell wrote:
>>
>> On 23 April 2018 at 08:51, Christophe Lyon <christophe.lyon@st.com> wrote:
>>> @@ -2149,7 +2164,21 @@ setup_return(CPUARMState *env, struct
>>> target_sigaction *ka,
>>>   {
>>>       abi_ulong handler = ka->_sa_handler;
>>>       abi_ulong retcode;
>>> -    int thumb = handler & 1;
>>> +    abi_ulong funcdesc_ptr = 0;
>>> +
>>> +    int thumb;
>>> +    int is_fdpic = ((TaskState *)thread_cpu->opaque)->is_fdpic;
>>> +
>>> +    if (is_fdpic) {
>>> +        /* In FDPIC mode, ka->_sa_handler points to a function
>>> +         * descriptor (FD). The first word contains the address of the
>>> +         * handler. The second word contains the value of the PIC
>>> +         * register (r9).  */
>>> +        funcdesc_ptr = ka->_sa_handler;
>>
>>
>> You already have ka->_sa_handler in the 'handler' local, so you
>> can just use that.
>>
> OK, I thought it was clearer to use a different name.

The other way to structure that would be to put
    handler = ka->_sa_handler;

in an else clause of this if ().

>>> +        get_user_ual(handler, funcdesc_ptr);
>>
>>
>> You need to check whether get_user_ual() returned non-zero
>> (indicating that the descriptor isn't readable) and handle that.
>>
> Ha... I feared that :)
> I noticed that quite a lot of get_user_XXX() calls do not
> check the returned value, and since this patch changes
> void setup_return(), I'm not sure what to do in case of
> read error? Call abort() or is there a global flag
> for this purpose, that I should set and which would
> be checked by the caller?

You need to:
 * make setup_return() return an error indication
   (other code in this file seems to follow the kernel's
   example and have this be a return value that's true on
   an error and false otherwise)
 * have the callers check the error indication, and
   if there was an error do:
     - unlock the user struct
     - call force_sigsegv()

All the callers already have code for doing force_sigsegv,
though they don't yet have a codepath that handles doing
the unlock first. You should be able to just put in
the call to unlock_user_struct(frame, ...) at the existing 'sigsegv:'
labels, because that is guaranteed to be safe on a NULL
host pointer, which is what you'll get in the other
code paths that go to that label. Then you can have
the error check be
    if (setup_return(...)) {
        goto sigsegv;
    }

thanks
-- PMM

      reply	other threads:[~2018-04-23 15:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-23  7:51 [Qemu-devel] [ARM/FDPIC v2 0/4] FDPIC ABI for ARM Christophe Lyon
2018-04-23  7:51 ` [Qemu-devel] [ARM/FDPIC v2 1/4] Remove CONFIG_USE_FDPIC Christophe Lyon
2018-04-23 12:23   ` Peter Maydell
2018-04-23  7:51 ` [Qemu-devel] [ARM/FDPIC v2 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries Christophe Lyon
2018-04-23 12:17   ` Peter Maydell
2018-04-23 12:53     ` Christophe Lyon
2018-04-23 13:26       ` Peter Maydell
2018-04-23  7:51 ` [Qemu-devel] [ARM/FDPIC v2 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM Christophe Lyon
2018-04-23 12:49   ` Peter Maydell
2018-04-23 14:13     ` Christophe Lyon
2018-04-23 15:13       ` Peter Maydell
2018-04-23  7:51 ` [Qemu-devel] [ARM/FDPIC v2 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets Christophe Lyon
2018-04-23 13:05   ` Peter Maydell
2018-04-23 14:22     ` Christophe Lyon
2018-04-23 15:31       ` Peter Maydell [this message]

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=CAFEAcA8L7n4vrdfe2GL9ASpFLiPdsDs+KfgbAYpacNMQuFHp7w@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=christophe.lyon@linaro.org \
    --cc=christophe.lyon@st.com \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).