Message ID | 20231121160740.1249350-1-leitao@debian.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp775029vqb; Tue, 21 Nov 2023 09:10:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IFVcC+s98BLreJo2wbTm+50SMOO8H75ZYo2Gph12JLrkxpfQP0oQTU3EX+euiTcsh3dSKyz X-Received: by 2002:a17:902:a5c5:b0:1cf:5760:43f9 with SMTP id t5-20020a170902a5c500b001cf576043f9mr7278834plq.64.1700586600824; Tue, 21 Nov 2023 09:10:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700586600; cv=none; d=google.com; s=arc-20160816; b=u/Agc0ygfhKqyC1MyBz2sOnQnSWrJsuNzAB7Z6gW6iupi5mJfBxav4u/Jm1iCggGyW PVtYoxSUYcwKjngUcBdFrmunEgy3EGxE2k5njmlHxtjP3zRlI2c43OwV8+pZkv7wGarU 7cG07U7zA8HnMynEUrPEfbTcWvevlgAFSP5Y7dZv9pHgSmmTg1XtQeVYuYWxbaIR9uVt NBXJgRmlz/6cDE4XVHsVYwwiHG8NdBvieBuJwt9vrecUbKS2iUuFna8Sa5m52quIKfd9 aZGObsCZemDmTruwn/hY/IuNXZ5cmPOM7tSSFpPEMwnCRyAo0kLG6KrigrKXy93hC1WR oF+w== 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; bh=ZDqY6LIVmpxgbya3l2Nab39btyfIaWzyAEzG5sT0dtA=; fh=Gas4LCE1B1UaWNP/xjrTqjIkkrJrhlLVx7tGCuedev8=; b=f/xbjZrf+3hm5jzFzXDdKPfpHwH+JIsvtALffzFd4wSzLFr+OWyO5nbam71Us7ZVnO tYoJalyp6hX2s3lh6jBjtLAZCWytg/Sbwe2bWk2gwXtJphUdWtlKVrMpbsmjeJnN4dm4 YywNJcSnDTrAtBmXjqYk66t5VDsMJritusJ460vI6Ui4trS86/1lZu+uWjLTkAiUJLPM dL+Bi1Zsk7Keylm01tsBdQykouqCCYkUJMx5E8ZwtkhmPElh8XLvhQ/OcS23LD8dTM6T HQLWgSY0iMe3WXlzz1QKS204mTLoNH0nkg90znYXj9gnpgNAPdPNnEoLBBhyb3dum+IE fn2g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id d7-20020a170903230700b001c5f80bf574si8891787plh.487.2023.11.21.09.10.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 09:10:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 2262480259B9; Tue, 21 Nov 2023 09:09:49 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230399AbjKURJu (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Tue, 21 Nov 2023 12:09:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230340AbjKURJt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Nov 2023 12:09:49 -0500 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC07210E; Tue, 21 Nov 2023 09:09:43 -0800 (PST) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-548ce39b101so3047612a12.2; Tue, 21 Nov 2023 09:09:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700586582; x=1701191382; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZDqY6LIVmpxgbya3l2Nab39btyfIaWzyAEzG5sT0dtA=; b=IbCn2yFewox/9WR3VkSjZNXYZr87pBIZIUg2QjaRRPvuhqHzDzLuhvZRX6PHX/6D0a sDuGPRdeTuwxxeD0qCgQG1iW4NOTfILOmCVlNCfm53i9byGeNPG52ZX2Vka5JyKKiY2e kxOGfGHR0B1WsdXnR6WsCb5ADP9ub7BsNjViU5iEaQD8s3vOVV3to33mGvgokADh3m1O EWFTfFYlQnkorbw7U4wcdsbFa1A9OGTsXJNptbIXrqLb++6XfbL/3JbKqq0Af1wofTR+ SPvl08OlXnTJQNIaJRVQoHduTCRo9DgK8Y0L+T69B/XbFjJiptF20GBhYuPmWzQWIDnn s/fQ== X-Gm-Message-State: AOJu0YxBmJ13O5ea68EeVdFYub5uMNA5YYg/SFmhWSYP2TjQB4+f/F65 grxwhlV+KrUvhOjVs91lX2E= X-Received: by 2002:a17:906:10b:b0:9c7:59d1:b2ce with SMTP id 11-20020a170906010b00b009c759d1b2cemr8410617eje.5.1700586581954; Tue, 21 Nov 2023 09:09:41 -0800 (PST) Received: from localhost (fwdproxy-cln-027.fbsv.net. [2a03:2880:31ff:1b::face:b00c]) by smtp.gmail.com with ESMTPSA id h4-20020a170906590400b00997d7aa59fasm5560744ejq.14.2023.11.21.09.09.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 09:09:41 -0800 (PST) From: Breno Leitao <leitao@debian.org> To: jpoimboe@kernel.org, mingo@redhat.com, tglx@linutronix.de, bp@alien8.de Cc: x86@kernel.org, leit@meta.com, linux-kernel@vger.kernel.org, pawan.kumar.gupta@linux.intel.com, bpf@vger.kernel.org (open list:BPF [MISC]:Keyword:(?:\b|_)bpf(?:\b|_)) Subject: [PATCH v6 00/13] x86/bugs: Add a separate config for each mitigation Date: Tue, 21 Nov 2023 08:07:27 -0800 Message-Id: <20231121160740.1249350-1-leitao@debian.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 21 Nov 2023 09:09:49 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783194295319472856 X-GMAIL-MSGID: 1783194295319472856 |
Series |
x86/bugs: Add a separate config for each mitigation
|
|
Message
Breno Leitao
Nov. 21, 2023, 4:07 p.m. UTC
Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, where some mitigations have entries in Kconfig, and they could be modified, while others mitigations do not have Kconfig entries, and could not be controlled at build time. The fact of having a fine grained control can help in a few ways: 1) Users can choose and pick only mitigations that are important for their workloads. 2) Users and developers can choose to disable mitigations that mangle the assembly code generation, making it hard to read. 3) Separate configs for just source code readability, so that we see *which* butt-ugly piece of crap code is for what reason. Important to say, if a mitigation is disabled at compilation time, it could be enabled at runtime using kernel command line arguments. Discussion about this approach: https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/ and https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ In order to get the missing mitigations, some clean up was done. 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig entries. 2) Adding the missing mitigations, so, the mitigations have entries in the Kconfig that could be easily configure by the user. With this patchset applied, all configs have an individual entry under CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION. Changelog --------- V1: * Creates a way to mitigate all (or none) hardware bugs V2: * Create KCONFIGs entries only some hardware bugs (MDS, TAA, MMIO) V3: * Expand the mitigations KCONFIGs to all hardware bugs that are Linux mitigates. V4: * Patch rebase. * Better documentation about the reasons of this decision. V5: * Create a "MITIGATION" Kconfig namespace for the entries mitigating hardware bugs. * Add GDS to the set of mitigations that are being covered. * Reduce the ifdefs in the code by leveraging conditionals with omitted operands. V6: * Reference documentation RST files from Kconfig entries * Fix some grammar mistakes and Kconfig dependencies * Now spectre v2 user depends on CONFIG_MITIGATION_SPECTRE_V2. See patch "spectre_v2_user default mode depends on Kconfig" Breno Leitao (13): x86/bugs: Rename GDS_FORCE_MITIGATION to MITIGATION_GDS_FORCE x86/bugs: Rename CPU_IBPB_ENTRY to MITIGATION_IBPB_ENTRY x86/bugs: Rename CALL_DEPTH_TRACKING to MITIGATION_CALL_DEPTH_TRACKING x86/bugs: Rename PAGE_TABLE_ISOLATION to MITIGATION_PAGE_TABLE_ISOLATION x86/bugs: Rename RETPOLINE to MITIGATION_RETPOLINE x86/bugs: Rename SLS to CONFIG_MITIGATION_SLS x86/bugs: Rename CPU_UNRET_ENTRY to MITIGATION_UNRET_ENTRY x86/bugs: Rename CPU_IBRS_ENTRY to MITIGATION_IBRS_ENTRY x86/bugs: Rename CPU_SRSO to MITIGATION_SRSO x86/bugs: Rename RETHUNK to MITIGATION_RETHUNK x86/bugs: Create a way to disable GDS mitigation x86/bugs: spectre_v2_user default mode depends on Kconfig x86/bugs: Add a separate config for missing mitigation Documentation/admin-guide/hw-vuln/spectre.rst | 8 +- .../admin-guide/kernel-parameters.txt | 4 +- Documentation/arch/x86/pti.rst | 6 +- arch/x86/Kconfig | 151 +++++++++++++++--- arch/x86/Makefile | 8 +- arch/x86/boot/compressed/ident_map_64.c | 4 +- arch/x86/configs/i386_defconfig | 2 +- arch/x86/entry/calling.h | 8 +- arch/x86/entry/entry_64.S | 2 +- arch/x86/entry/vdso/Makefile | 4 +- arch/x86/include/asm/current.h | 2 +- arch/x86/include/asm/disabled-features.h | 10 +- arch/x86/include/asm/linkage.h | 16 +- arch/x86/include/asm/nospec-branch.h | 30 ++-- arch/x86/include/asm/pgalloc.h | 2 +- arch/x86/include/asm/pgtable-3level.h | 2 +- arch/x86/include/asm/pgtable.h | 18 +-- arch/x86/include/asm/pgtable_64.h | 3 +- arch/x86/include/asm/processor-flags.h | 2 +- arch/x86/include/asm/pti.h | 2 +- arch/x86/include/asm/static_call.h | 2 +- arch/x86/kernel/alternative.c | 14 +- arch/x86/kernel/asm-offsets.c | 2 +- arch/x86/kernel/cpu/amd.c | 2 +- arch/x86/kernel/cpu/bugs.c | 98 +++++++----- arch/x86/kernel/dumpstack.c | 2 +- arch/x86/kernel/ftrace.c | 3 +- arch/x86/kernel/head_32.S | 4 +- arch/x86/kernel/head_64.S | 2 +- arch/x86/kernel/kprobes/opt.c | 2 +- arch/x86/kernel/ldt.c | 8 +- arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 10 +- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/mmu_internal.h | 2 +- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/vmenter.S | 4 +- arch/x86/kvm/vmx/vmx.c | 2 +- arch/x86/lib/Makefile | 2 +- arch/x86/lib/retpoline.S | 26 +-- arch/x86/mm/Makefile | 2 +- arch/x86/mm/debug_pagetables.c | 4 +- arch/x86/mm/dump_pagetables.c | 4 +- arch/x86/mm/pgtable.c | 4 +- arch/x86/mm/tlb.c | 10 +- arch/x86/net/bpf_jit_comp.c | 4 +- arch/x86/net/bpf_jit_comp32.c | 2 +- arch/x86/purgatory/Makefile | 2 +- include/linux/compiler-gcc.h | 2 +- include/linux/indirect_call_wrapper.h | 2 +- include/linux/module.h | 2 +- include/linux/objtool.h | 2 +- include/linux/pti.h | 2 +- include/net/netfilter/nf_tables_core.h | 2 +- include/net/tc_wrapper.h | 2 +- kernel/trace/ring_buffer.c | 2 +- net/netfilter/Makefile | 2 +- net/netfilter/nf_tables_core.c | 6 +- net/netfilter/nft_ct.c | 4 +- net/netfilter/nft_lookup.c | 2 +- net/sched/sch_api.c | 2 +- scripts/Makefile.lib | 8 +- scripts/Makefile.vmlinux_o | 2 +- scripts/generate_rust_target.rs | 2 +- scripts/mod/modpost.c | 2 +- .../arch/x86/include/asm/disabled-features.h | 10 +- 66 files changed, 344 insertions(+), 219 deletions(-)
Comments
On Tue, Nov 21, 2023 at 08:07:27AM -0800, Breno Leitao wrote: > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > where some mitigations have entries in Kconfig, and they could be > modified, while others mitigations do not have Kconfig entries, and > could not be controlled at build time. All looks good to me, thanks! Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
* Breno Leitao <leitao@debian.org> wrote: > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > where some mitigations have entries in Kconfig, and they could be > modified, while others mitigations do not have Kconfig entries, and > could not be controlled at build time. > > The fact of having a fine grained control can help in a few ways: > > 1) Users can choose and pick only mitigations that are important for > their workloads. > > 2) Users and developers can choose to disable mitigations that mangle > the assembly code generation, making it hard to read. > > 3) Separate configs for just source code readability, > so that we see *which* butt-ugly piece of crap code is for what > reason. > > Important to say, if a mitigation is disabled at compilation time, it > could be enabled at runtime using kernel command line arguments. > > Discussion about this approach: > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/ > and > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ > > In order to get the missing mitigations, some clean up was done. > > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig > entries. > > 2) Adding the missing mitigations, so, the mitigations have entries in the > Kconfig that could be easily configure by the user. > > With this patchset applied, all configs have an individual entry under > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION. Yeah, so: - I took this older series and updated it to current upstream, and made sure all renames were fully done: there were two new Kconfig option uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) - I also widened the renames to comments and messages, which were not always covered. - Then I took this cover letter and combined it with a more high level description of the reasoning behind this series I wrote up, and added it to patch #1. (see it below.) - Then I removed the changelog repetition from the other patches and just referred them back to patch #1. - Then I stuck the resulting updated series into tip:x86/bugs, without the last 3 patches that modify behavior. - You might notice the somewhat weird extra whitespaces in the titles - I've done that so that it all looks tidy in the shortlog: Breno Leitao (10): x86/bugs: Rename CONFIG_GDS_FORCE_MITIGATION => CONFIG_MITIGATION_GDS_FORCE x86/bugs: Rename CONFIG_CPU_IBPB_ENTRY => CONFIG_MITIGATION_IBPB_ENTRY x86/bugs: Rename CONFIG_CALL_DEPTH_TRACKING => CONFIG_MITIGATION_CALL_DEPTH_TRACKING x86/bugs: Rename CONFIG_PAGE_TABLE_ISOLATION => CONFIG_MITIGATION_PAGE_TABLE_ISOLATION x86/bugs: Rename CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINE x86/bugs: Rename CONFIG_SLS => CONFIG_MITIGATION_SLS x86/bugs: Rename CONFIG_CPU_UNRET_ENTRY => CONFIG_MITIGATION_UNRET_ENTRY x86/bugs: Rename CONFIG_CPU_IBRS_ENTRY => CONFIG_MITIGATION_IBRS_ENTRY x86/bugs: Rename CONFIG_CPU_SRSO => CONFIG_MITIGATION_SRSO x86/bugs: Rename CONFIG_RETHUNK => CONFIG_MITIGATION_RETHUNK I think the resulting tree is all mostly good, but still I'd like to see just the 10 pure low-risk renames done in this first step, to not carry too much of this around unnecessarily - maybe even send it Linuswards in this cycle if it's problem-free - without any real regression risk to upstream. Thanks, Ingo =============================> commit be83e809ca67bca98fde97ad6b9344237963220b Author: Breno Leitao <leitao@debian.org> Date: Tue Nov 21 08:07:28 2023 -0800 x86/bugs: Rename CONFIG_GDS_FORCE_MITIGATION => CONFIG_MITIGATION_GDS_FORCE So the CPU mitigations Kconfig entries - there's 10 meanwhile - are named in a historically idiosyncratic and hence rather inconsistent fashion and have become hard to relate with each other over the years: https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ When they were introduced we never expected that we'd eventually have about a dozen of them, and that more organization would be useful, especially for Linux distributions that want to enable them in an informed fashion, and want to make sure all mitigations are configured as expected. For example, the current CONFIG_SPECULATION_MITIGATIONS namespace is only halfway populated, where some mitigations have entries in Kconfig, and they could be modified, while others mitigations do not have Kconfig entries, and can not be controlled at build time. Fine-grained control over these Kconfig entries can help in a number of ways: 1) Users can choose and pick only mitigations that are important for their workloads. 2) Users and developers can choose to disable mitigations that mangle the assembly code generation, making it hard to read. 3) Separate Kconfigs for just source code readability, so that we see *which* butt-ugly piece of crap code is for what reason... In most cases, if a mitigation is disabled at compilation time, it can still be enabled at runtime using kernel command line arguments. This is the first patch of an initial series that renames various mitigation related Kconfig options, unifying them under a single CONFIG_MITIGATION_* namespace: CONFIG_GDS_FORCE_MITIGATION => CONFIG_MITIGATION_GDS_FORCE CONFIG_CPU_IBPB_ENTRY => CONFIG_MITIGATION_IBPB_ENTRY CONFIG_CALL_DEPTH_TRACKING => CONFIG_MITIGATION_CALL_DEPTH_TRACKING CONFIG_PAGE_TABLE_ISOLATION => CONFIG_MITIGATION_PAGE_TABLE_ISOLATION CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINE CONFIG_SLS => CONFIG_MITIGATION_SLS CONFIG_CPU_UNRET_ENTRY => CONFIG_MITIGATION_UNRET_ENTRY CONFIG_CPU_IBRS_ENTRY => CONFIG_MITIGATION_IBRS_ENTRY CONFIG_CPU_SRSO => CONFIG_MITIGATION_SRSO CONFIG_RETHUNK => CONFIG_MITIGATION_RETHUNK Implement step 1/10 of the namespace unification of CPU mitigations related Kconfig options and rename CONFIG_GDS_FORCE_MITIGATION to CONFIG_MITIGATION_GDS_FORCE. [ mingo: Rewrote changelog for clarity. ] Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20231121160740.1249350-2-leitao@debian.org
On Wed, Jan 10, 2024 at 10:56:46AM +0100, Ingo Molnar wrote: > > * Breno Leitao <leitao@debian.org> wrote: > > > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > > where some mitigations have entries in Kconfig, and they could be > > modified, while others mitigations do not have Kconfig entries, and > > could not be controlled at build time. > > > > The fact of having a fine grained control can help in a few ways: > > > > 1) Users can choose and pick only mitigations that are important for > > their workloads. > > > > 2) Users and developers can choose to disable mitigations that mangle > > the assembly code generation, making it hard to read. > > > > 3) Separate configs for just source code readability, > > so that we see *which* butt-ugly piece of crap code is for what > > reason. > > > > Important to say, if a mitigation is disabled at compilation time, it > > could be enabled at runtime using kernel command line arguments. > > > > Discussion about this approach: > > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/ > > and > > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ > > > > In order to get the missing mitigations, some clean up was done. > > > > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig > > entries. > > > > 2) Adding the missing mitigations, so, the mitigations have entries in the > > Kconfig that could be easily configure by the user. > > > > With this patchset applied, all configs have an individual entry under > > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION. > > Yeah, so: > > - I took this older series and updated it to current upstream, and made > sure all renames were fully done: there were two new Kconfig option > uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) > > - I also widened the renames to comments and messages, which were not > always covered. > > - Then I took this cover letter and combined it with a more high level > description of the reasoning behind this series I wrote up, and added it > to patch #1. (see it below.) > > - Then I removed the changelog repetition from the other patches and just > referred them back to patch #1. > > - Then I stuck the resulting updated series into tip:x86/bugs, without the > last 3 patches that modify behavior. Thanks for your work. I am currently reviwing the tip branch and the merge seems go so far. Regarding the last 3 patches, what are the next steps? Thank you! Breno
* Breno Leitao <leitao@debian.org> wrote: > > Yeah, so: > > > > - I took this older series and updated it to current upstream, and made > > sure all renames were fully done: there were two new Kconfig option > > uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) > > > > - I also widened the renames to comments and messages, which were not > > always covered. > > > > - Then I took this cover letter and combined it with a more high level > > description of the reasoning behind this series I wrote up, and added it > > to patch #1. (see it below.) > > > > - Then I removed the changelog repetition from the other patches and just > > referred them back to patch #1. > > > > - Then I stuck the resulting updated series into tip:x86/bugs, without the > > last 3 patches that modify behavior. > > Thanks for your work. I am currently reviwing the tip branch and the > merge seems go so far. > > Regarding the last 3 patches, what are the next steps? Please resubmit them in a few days (with Josh's Acked-by added and any fixes/enhancements done along the way), on top of tip:x86/bugs. Thanks, Ingo