From: Kevin Brodsky <kevin.brodsky@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org,
catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH] arm64: signal: Ensure signal delivery failure is recoverable
Date: Tue, 3 Dec 2024 16:06:24 +0100 [thread overview]
Message-ID: <a9aa36eb-d5c2-4d1c-bf5d-e63e4cb55404@arm.com> (raw)
In-Reply-To: <Z07x69L6Mssncg/7@e133380.arm.com>
On 03/12/2024 12:56, Dave Martin wrote:
> On Tue, Dec 03, 2024 at 10:03:22AM +0000, Kevin Brodsky wrote:
>> [...]
>> @@ -1462,10 +1462,33 @@ static int setup_return(struct pt_regs *regs, struct ksignal *ksig,
>> struct rt_sigframe_user_layout *user, int usig)
>> {
>> __sigrestore_t sigtramp;
>> + int err;
>> +
>> + if (ksig->ka.sa.sa_flags & SA_RESTORER)
>> + sigtramp = ksig->ka.sa.sa_restorer;
>> + else
>> + sigtramp = VDSO_SYMBOL(current->mm->context.vdso, sigtramp);
>> +
>> + err = gcs_signal_entry(sigtramp, ksig);
>> + if (err)
>> + return err;
>> +
>> + /*
>> + * We must not fail from this point onwards. We are going to update
>> + * registers, including SP, in order to invoke the signal handler. If
>> + * we failed and attempted to deliver a nested SIGSEGV to a handler
>> + * after that point, the subsequent sigreturn would end up restoring
>> + * the (partial) state for the original signal handler.
>> + */
> The same is true at the call site of this function; could problems
> creep back in there?
That's a fair point, I could add a short comment after the call to
setup_return() to clarify this.
>>
>> regs->regs[0] = usig;
>> + if (ksig->ka.sa.sa_flags & SA_SIGINFO) {
>> + regs->regs[1] = (unsigned long)&user->sigframe->info;
>> + regs->regs[2] = (unsigned long)&user->sigframe->uc;
> Nit: This looks like it should work, but it's not really anything to do
> with setting up how the handler returns (we're in setup_return() here).
setup_return() is a bit of a misnomer, unless you interpret "return" as
"return to userspace". Aside from setting LR, setup_return() isn't about
how the handler returns but simply how it is invoked. For instance the
line just above sets X0 to the signal number, the first argument of the
handler. Setting X1/X2 here seems pretty natural (they're also arguments
for the handler).
- Kevin
next prev parent reply other threads:[~2024-12-03 15:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 10:03 [PATCH] arm64: signal: Ensure signal delivery failure is recoverable Kevin Brodsky
2024-12-03 11:56 ` Dave Martin
2024-12-03 15:06 ` Kevin Brodsky [this message]
2024-12-03 15:37 ` Dave Martin
2024-12-03 16:48 ` Kevin Brodsky
2024-12-04 11:20 ` Dave Martin
2024-12-04 12:07 ` Kevin Brodsky
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=a9aa36eb-d5c2-4d1c-bf5d-e63e4cb55404@arm.com \
--to=kevin.brodsky@arm.com \
--cc=Dave.Martin@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.org \
/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).