From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Thomas Gleixner <tglx@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: x86: missing FRED #PF event data?
Date: Tue, 11 Aug 2026 10:47:13 +0900 [thread overview]
Message-ID: <anp-paGLwEf-eEvD@google.com> (raw)
In-Reply-To: <29FD2DAB-C771-4E91-95C4-435B5DF90802@zytor.com>
On (26/08/10 08:40), H. Peter Anvin wrote:
> On August 10, 2026 1:58:18 AM PDT, Sergey Senozhatsky <senozhatsky@chromium.org> wrote:
> >On (26/08/10 16:38), Sergey Senozhatsky wrote:
> >> [..]
> >> > All the crashes are reported as NULL ptr derefs, however, I believe this
> >> > is not exactly the case. In all crashes CR2 is 0x1000 aligned (we always
> >> > crash accessing first byte of a page). It seems that csum_partial() calls
> >> > load_unaligned_zeropad() and we hit what load_unaligned_zeropad() comment
> >> > describes as very unlikely) case: "word being a page-crosser and the
> >> > next page not being mapped"). So instead of reading 4 remaining bytes
> >> > of the page and zeroes for trailing 4 bytes, we panic(). It appears that
> >> > FRED #PF is set to 0 while CR2 points to a correct page address. I added
> >> > a simple printk to exc_page_fault:
> >> >
> >> > address = cpu_feature_enabled(X86_FEATURE_FRED) ? fred_event_data(regs) : read_cr2();
> >> > /* Fall back to CR2 if FRED event data was empty */
> >> > if (unlikely(!address)) {
> >> > address = read_cr2();
> >> > pr_err(":: fixed up address to %lx [[fred: %lx cr2: %lx]]\n", address, fred_event_data(regs), read_cr2());
> >> > }
> >> >
> >> > and got the following while running my tests (and well, we don't crash
> >> > anymore):
> >> >
> >> > [ 254.040223] :: fixed up address to ffff9c4d64af4000 [[fred: 0 cr2: ffff9c4d64af4000]]
> >> > ...
> >> > [ 1821.904563] :: fixed up address to ffff9c4e9dd0a000 [[fred: 0 cr2: ffff9c4e9dd0a000]]
> >> >
> >> > Does any of this make sense to you?
> >>
> >> I think the explanation is some pKVM shenanigans. Sorry for the noise.
> >
> >No, I think we are back at square one. I thought that maybe pKVM
> >was disabling FRED and that was causing issues. But I actually see
> >that both cpu_feature_enabled(X86_FEATURE_FRED) and (cr4 & X86_CR4_FRED)
> >claim FRED is enabled, yet fred #PF data is 0 while CR2 holds the correct
> >address.
>
> What is pKVM? Paravirtualized KVM?
Protected KVM.
> In that case, it is most likely pKVM not filling in the relevant fields
> in the FRED stack frame, which would be a very serious bug.
>
> I cannot think of any other way that that could possibly happen otherwise;
> on bare metal those fields are set by hardware and Linux only consumes them.
I agree. I'll look at it from the pKVM side. I was not aware of pKVM
when I started this discussion, I found out about it later.
prev parent reply other threads:[~2026-08-11 1:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 6:49 x86: missing FRED #PF event data? Sergey Senozhatsky
2026-08-10 7:38 ` Sergey Senozhatsky
2026-08-10 8:58 ` Sergey Senozhatsky
2026-08-10 9:03 ` Peter Zijlstra
2026-08-10 9:09 ` Sergey Senozhatsky
2026-08-10 9:23 ` Peter Zijlstra
2026-08-10 13:51 ` Sean Christopherson
2026-08-10 14:47 ` Sergey Senozhatsky
2026-08-10 10:06 ` David Laight
2026-08-10 10:40 ` Sergey Senozhatsky
2026-08-10 15:40 ` H. Peter Anvin
2026-08-11 1:47 ` Sergey Senozhatsky [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=anp-paGLwEf-eEvD@google.com \
--to=senozhatsky@chromium.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@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