From: ira.weiny@intel.com
To: Rik van Riel <riel@surriel.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 0/3] Print CPU at segfault time
Date: Wed, 10 Aug 2022 19:49:00 -0700 [thread overview]
Message-ID: <20220811024903.178925-1-ira.weiny@intel.com> (raw)
From: Ira Weiny <ira.weiny@intel.com>
Changes from RFC:
Drop patch 1 as I misunderstood the code and it is not needed for this
use case
Combine patch 2 and 5 into a patch 3 which stores the CPU only for page
faults
Rik reported that the knowledge of which CPU's are seeing faults can help in
determining which CPUs are failing in a large data center.[1]
Storing the CPU at exception entry time allows this print to report the CPU
which actually took the exception. This still may not be the CPU which is
failing but it should be closer.
Dave and Boris recognized that the auxiliary pt_regs work I did for the PKS
series could help to store this value and avoid passing the CPU throughout the
fault handler call stack.
The patches I sent for RFC had a lot more overhead than is needed to report the
CPU in a page fault.[2] After the discussions the generic save/restore of the
auxiliary pt_regs is overkill for the current use case. Skip that overhead and
only store the CPU in the page fault path.
[1] https://lore.kernel.org/all/20220805101644.2e674553@imladris.surriel.com/
[2] https://lore.kernel.org/lkml/20220805173009.3128098-1-ira.weiny@intel.com/
Ira Weiny (2):
x86/entry: Add auxiliary pt_regs space
x86/mm: Store CPU info on exception entry
Rik van Riel (1):
x86,mm: print likely CPU at segfault time
arch/x86/Kconfig | 4 ++++
arch/x86/entry/calling.h | 19 +++++++++++++++++++
arch/x86/entry/entry_64.S | 22 ++++++++++++++++++++++
arch/x86/entry/entry_64_compat.S | 6 ++++++
arch/x86/include/asm/ptrace.h | 19 +++++++++++++++++++
arch/x86/kernel/asm-offsets_64.c | 15 +++++++++++++++
arch/x86/kernel/head_64.S | 6 ++++++
arch/x86/mm/fault.c | 18 ++++++++++++++++++
8 files changed, 109 insertions(+)
base-commit: d4252071b97d2027d246f6a82cbee4d52f618b47
--
2.35.3
next reply other threads:[~2022-08-11 2:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 2:49 ira.weiny [this message]
2022-08-11 2:49 ` [PATCH 1/3] x86,mm: print likely " ira.weiny
2022-08-11 2:49 ` [PATCH 2/3] x86/entry: Add auxiliary pt_regs space ira.weiny
2022-08-11 2:49 ` [PATCH 3/3] x86/mm: Store CPU info on exception entry ira.weiny
2022-09-02 3:15 ` [PATCH 0/3] Print CPU at segfault time Ira Weiny
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=20220811024903.178925-1-ira.weiny@intel.com \
--to=ira.weiny@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@surriel.com \
--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
all inboxes | Powered by JetHome®