All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Brodsky <kevin.brodsky@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, Dave.Martin@arm.com,
	will@kernel.org
Subject: Re: [PATCH v2] arm64: signal: Ensure signal delivery failure is recoverable
Date: Fri, 13 Dec 2024 10:15:15 +0100	[thread overview]
Message-ID: <b2b0f73e-ba2b-4402-afa6-4960814ea1fd@arm.com> (raw)
In-Reply-To: <Z1siulo_PKdI3xC_@arm.com>

On 12/12/2024 18:51, Catalin Marinas wrote:
> On Thu, Dec 12, 2024 at 05:26:47PM +0000, Mark Brown wrote:
>> On Thu, Dec 12, 2024 at 05:10:14PM +0000, Catalin Marinas wrote:
>>> On Thu, Dec 12, 2024 at 04:47:46PM +0000, Mark Brown wrote:
>>>>> Fixes: eaf62ce1563b ("arm64/signal: Set up and restore the GCS context for signal handlers")
>>>> Presumably we also need a Fixes for whatever introduced the above copy.
>>> Hmm, it was like this from the beginning. If we are to do a cc stable to
>>> the oldest maintained LTS, I'd rather have a separate patch for
>>> copy_siginfo_to_user(), it doesn't make much sense to backport a GCS
>>> patch to early kernels.
>> Hrm, good point about it triggering backports.  I'm not sure it's worth
>> doing that TBH.
> I had the same thoughts. I think this was mostly triggered by the
> POR_EL0 changes when Will raised the point that the kernel might return
> with a more privileged value in this sysreg.

I don't think backporting would be worth it either, referencing the
original commit implementing signal support felt like overkill. The
copy_siginfo_to_user() issue is such a corner case that I doubt anyone
ever ran into it.

- Kevin


  reply	other threads:[~2024-12-13  9:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10 16:09 [PATCH v2] arm64: signal: Ensure signal delivery failure is recoverable Kevin Brodsky
2024-12-12 14:35 ` Dave Martin
2024-12-12 16:01   ` Kevin Brodsky
2024-12-12 16:47 ` Mark Brown
2024-12-12 17:10   ` Catalin Marinas
2024-12-12 17:26     ` Mark Brown
2024-12-12 17:51       ` Catalin Marinas
2024-12-13  9:15         ` Kevin Brodsky [this message]
2024-12-13 14:55 ` Catalin Marinas

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=b2b0f73e-ba2b-4402-afa6-4960814ea1fd@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 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.