From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@intel.com>,
"Xin Li (Intel)" <xin@zytor.com>,
linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org,
peterz@infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/1] x86/fred/signal: Prevent single-step upon ERETU completion
Date: Fri, 23 May 2025 01:10:15 +0100 [thread overview]
Message-ID: <0a4db439-e402-4b6a-8aba-79a3c0398d9a@citrix.com> (raw)
In-Reply-To: <3D4D48D6-D6E7-4391-8DCF-6B9D307FE2E2@zytor.com>
On 22/05/2025 10:28 pm, H. Peter Anvin wrote:
> On May 22, 2025 10:53:16 AM PDT, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 22/05/2025 6:22 pm, Dave Hansen wrote:
>>> On 5/22/25 10:17, Xin Li (Intel) wrote:
>>>> Clear the software event flag in the augmented SS to prevent infinite
>>>> SIGTRAP handler loop if TF is used without an external debugger.
>>> Do you have a test case for this? It seems like the kind of thing we'd
>>> want in selftests/.
>> Hmm.
>>
>> This was a behaviour intentionally changed in FRED so traps wouldn't get
>> lost if an exception where to occur.
>>
>> What precise case is triggering this?
>>
>> ~Andrew
> SIGTRAP → sigreturn. Basically, we have to uplevel the suppression behavior to the kernel (where it belongs) instead of doing it at the ISA level.
So the problem is specifically that we're in a SYSCALL context (from
FRED's point of view), and we rewrite state in the FRED FRAME to be
another context which happened to have eflags.TF set.
And the combination of these two triggers a new singlestep to be pending
immediately.
I have to admit that I didn't like the implication from the SYSCALL bit,
and argued to have it handled differently, but alas. I think the real
bug here is trying to ERETU with a splice of two different contexts
worth of FRED state.
~Andrew
next prev parent reply other threads:[~2025-05-23 0:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-22 17:17 Xin Li (Intel)
2025-05-22 17:22 ` Dave Hansen
2025-05-22 17:26 ` Xin Li
2025-05-22 17:53 ` Andrew Cooper
2025-05-22 21:28 ` H. Peter Anvin
2025-05-23 0:10 ` Andrew Cooper [this message]
2025-05-23 3:48 ` H. Peter Anvin
2025-05-23 0:57 ` Xin Li
2025-05-23 7:42 ` H. Peter Anvin
2025-05-23 17:21 ` Xin Li
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=0a4db439-e402-4b6a-8aba-79a3c0398d9a@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xin@zytor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®