From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 715453A6B92 for ; Mon, 10 Aug 2026 08:58:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786352306; cv=none; b=Ks8f5fme5n9WckO5tSP10/dbzOux/1G5Zi1g6gNAALJZDxJHk0oGi5+k1486Q/bjS6XAC0to6UmXkj4TlwUlXly72TlfqBYNbxnDGo/Jm1PlFMyhDpWaXxJzJujyOUPeCGVlE71tJ6e+93FlGCsdJcr+1h069hsiNt7ucp/W/v0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786352306; c=relaxed/simple; bh=UAZCLfMwJJOzp8vPxiFmlX/Rbb20/Yx4CFnaw9PnT8k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XfR9iq5t8X12O0ul0/SdyVkbw4k5JdYGWaCw256Gpq4O4gh4nvKybnigZVPlV1ZK6/Bdtr6Wf337S04DYpRqMyqQzcYlm+SXpjrMcawk1EL2xacgAH/dOhibn3SRLaZwUqXsyq1ykw42drfwWbT28p/UAbX11YygxfNHbkiG0eg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=hwMU2RTd; arc=none smtp.client-ip=209.85.216.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="hwMU2RTd" Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-38dfe910e9dso1586563a91.3 for ; Mon, 10 Aug 2026 01:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1786352304; x=1786957104; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=8c/RO4etkmd+WChslVj6l+cqxwGGdKn7M1FY9PPf0Dk=; b=hwMU2RTd62RMRCUnlMEPGKwPvXFKLCq4gZl77RmZsYTh3HZaUazMqUUJw71Xm6gU5k oryb2XgfL8jt4x+YZUv+m8G9H+EbVUws3/nFzQsgPEHYuKXi3AhvuRNzFQbhsBwjv4vc 853qHyD6oaKZ8g4AEG9ttozD1Odzr5tx9LSCM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786352304; x=1786957104; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8c/RO4etkmd+WChslVj6l+cqxwGGdKn7M1FY9PPf0Dk=; b=Jt6CF/BwdYUvWCJ9CdBHr4fI8xwkcT81yGdc/PInsYK/0xRBeDBZfG6+RnFyNgCtfA rCWcwEf6q1ib63bhtTkwGviZEWFzozRdWEehVv8Eszu+lsey0TOytZWQ17g4zbLOqByw q4g8nXjAVFne8DWfipM6EFae0nxUIs/COLIFFzb8869Z3T/Zx4kKodi0cU7g4DOG4c96 foHQfdAVC4ZX/UFlVt0AYa3IVnSjw1jsoGDF18DRVgHHTwph21lxD//w22abeMz+NiFy XQ28jomz9jgx3Fu6+sjhrfU28RjXC1uvNWTsRpYo3gJ1Z3WxAFsRSmf4L0nEgqd1xxHH /wWg== X-Forwarded-Encrypted: i=1; AHgh+RqFcxrxStWWRowcv153ja6EPXyMdeNfXLJ0r+i/uuDxnMswT4lYRjkYjEUqyO8qDMgepiTxmqeB+vCYtG4=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+m55GLPC1vp1+L6vFLS+/YubY8bdKUzSa9FIbhd68V/3tpaEb 6tplgdULeu3sZFM8zFke5Ww13o+bSR/MXvLOaMTxekL4O++WmwTJrzG3HVqcSCb+YQ== X-Gm-Gg: AR+sD124gwYD5ZwwgAODRwpyT6WbkMrCR2gKgckvM834m617cjoLVnWV6KbgUrdtFRu DEqcq1r4QeNhp++2y05ZAsSwO0Da30tebkmEjPaSt8Rhu/Rm+Smtuti4f6VhDkxgS+wr20Vi+wj o17hGQSiM5rOisqTB2hA+2IQa4AeXuKp4+50UbmU5jE5DkIQ8aZN/zEqSi6l6gmQLM5VVKx4ZCt COJ5P5rv7alCkRIJxK1/0JznGnDG6OcoJ7q68cUtM1zlfaNaTaKOsYDIaUIJJogieD0G+ofaMSa PEBWgkza/029ql/rnmg2wwONmy5FJriVwzYCHF6hyyQDWnCkmoiZt4BXheo14YY6NsB19OYcWHw 8Wzj0kqZCEVyGd8+PqCZEuj6EyJAg4GMlrxcHjKceQf+ywvss+i5T8r01puTRgVcDurd6Wcapl9 UR2GcAuebLTj1sJO3nFZHvSsB+1XawF/04QjIUZ9LIiCWl7YujmWjb8U0kdxdeLEj7pIR+iYb3k 4yZqBMdjrJ88QQ4fZ4d7wlQ+6ltohggxTbQ3I4= X-Received: by 2002:a17:90b:4f91:b0:37c:6910:5758 with SMTP id 98e67ed59e1d1-3903c542f55mr34762293a91.1.1786352302794; Mon, 10 Aug 2026 01:58:22 -0700 (PDT) Received: from google.com ([2a00:79e0:2031:6:ddfb:e755:8f7f:81af]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3925fc6dab4sm11889346a91.3.2026.08.10.01.58.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 01:58:22 -0700 (PDT) Date: Mon, 10 Aug 2026 17:58:18 +0900 From: Sergey Senozhatsky To: Thomas Gleixner , Peter Zijlstra , "H. Peter Anvin" Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: x86: missing FRED #PF event data? Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.