Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp85045rwb; Wed, 10 Aug 2022 19:59:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR5qV/KryHMSNpKCo0F9FPcFuQfklcy6vv36+kt35xXt9X/M03kVQiPJBnCYLikLDQzpQrJO X-Received: by 2002:a17:906:9b86:b0:72f:56db:ccf3 with SMTP id dd6-20020a1709069b8600b0072f56dbccf3mr22723748ejc.422.1660186776680; Wed, 10 Aug 2022 19:59:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660186776; cv=none; d=google.com; s=arc-20160816; b=Uxb8m4rzm8N/0BSGAZIyTi3BjZKUvTw3jinP2PbGHpMDXGhJORhlF5gYZVyGUhnLRL vTSVwzy21U32Br85zBFceitmoSHVaFy/TN7r1M0CHMQvZoklfazuj/CcXUzqRku5xAZq 8fiCL7zgULEJbtmZ2cu/jPEFj9B9B/DvqCJ3kuQghiEgeds+B2WpiJDILooVrjdPR6xd 5DmdU8gzBR3/FHyGh/GKMXodK5Devc4r7mDgtvF89ha3fjZZKSoA1HvA+Or8QcxUywGo BywrcdOEBd9eEshuoApRRbm0v/jRDCSui5K3JNedM8oMD/J9NkJD2lNgeKFzOuMnwrki AusQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=HCcUXdiERij09pgToBYG5VZjWdF/n5JCd5u3yYT29/0=; b=LpQt8FNJAItZTERr8jVHXtDL3Jw7e37YczH2izTRUxL3CNkUyB4QE4IO1qUHsVDfFS jjC8X2aQyBUJH4srFfDX5RsyOVmfdWAGe1Nopv2duRcARnieEM8nnWqtlGd63bZ/2nRS yM79X+cYIjeGHlQ6Hcg90N60TOYoEEmbL1vNlRNyXG/qpvRw2YTLn4+p0OBQrI7pCakd f2xE/42y3F/6hpsU4xGOORx2gYP/KE9EEVhHBpu7t9hm5vLvv6VqTIkKDMYlkal7PbCs bOYrRPPIfDQmw904xjnwWkZOHS6BkLrywLdnK6DE/zezN+fPlm4lWDZZm4VnmbBVr6yZ 6rfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hl6of4rA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j15-20020a05640211cf00b0043aa4fc7b9fsi15449406edw.17.2022.08.10.19.59.11; Wed, 10 Aug 2022 19:59:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hl6of4rA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233366AbiHKCtI (ORCPT + 99 others); Wed, 10 Aug 2022 22:49:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230006AbiHKCtH (ORCPT ); Wed, 10 Aug 2022 22:49:07 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FE4C88DE5 for ; Wed, 10 Aug 2022 19:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660186146; x=1691722146; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=8Mt8sFUCI2ItkayZuKBCPZE74Aj7OpvNmrzBBHWPO9E=; b=hl6of4rAO8yDNB+CkegIWRglDcS8FEZl4Orty5GjVdWN7QOXC9tMePcN ylUVJOPOxakmpikNz/Q1eSQah4Rg5FUndvJzw9IFIyO6jIBme0xVbSNUK zhF9PjNH7QSTDueWT4IU8WAkABwT441Kv5FW8xWlcV0OVW7rbbm4pnL+Y Ip+Weh2PLmFdeX9osxJ2UT0RODzwaF1JsBjdlAyrtpGV+WrX2OS3kAek7 s64KfIAgjSspSBgxJfapX2sKmMsAxWbhE7sfe2hZLVxHa8xLEA1o+b4j7 zL/ASSeikLCgt2AKQPv+Ylb9Gdo9Vmex5PsaaMW0uHqA45wq3icGjduB5 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10435"; a="271018788" X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="271018788" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 19:49:06 -0700 X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="933141852" Received: from zjoseph-mobl3.amr.corp.intel.com (HELO localhost) ([10.209.123.207]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 19:49:05 -0700 From: ira.weiny@intel.com To: Rik van Riel , Borislav Petkov , Dave Hansen Cc: Ira Weiny , 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 Message-Id: <20220811024903.178925-1-ira.weiny@intel.com> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ira Weiny 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