The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Thomas Gleixner <tglx@kernel.org>,
	 Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	 Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: x86: missing FRED #PF event data?
Date: Mon, 10 Aug 2026 16:38:34 +0900	[thread overview]
Message-ID: <anl_YEd9nlnsAc6p@google.com> (raw)
In-Reply-To: <anluk05_KYzy3Al6@google.com>

On (26/08/10 15:49), 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.

  reply	other threads:[~2026-08-10  7:38 UTC|newest]

Thread overview: 11+ 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 [this message]
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

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=anl_YEd9nlnsAc6p@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