Commits on Source (62)
-
Petr Oros authored
JIRA: https://issues.redhat.com/browse/RHEL-77838 Upstream commit(s): commit a1afb959add1fad43cb337448c244ed70bac3109 Author: Jiri Pirko <jiri@nvidia.com> Date: Wed Oct 30 09:11:56 2024 +0100 dpll: add clock quality level attribute and op In order to allow driver expose quality level of the clock it is running, introduce a new netlink attr with enum to carry it to the userspace. Also, introduce an op the dpll netlink code calls into the driver to obtain the value. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20241030081157.966604-2-jiri@resnulli.us Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Petr Oros <poros@redhat.com>
-
CKI Backport Bot authored
JIRA: https://issues.redhat.com/browse/RHEL-81489 CVE: CVE-2024-58005 commit a3a860bc0fd6c07332e4911cf9a238d20de90173 Author: Jarkko Sakkinen <jarkko@kernel.org> Date: Fri Dec 27 17:39:09 2024 +0200 tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). Suggested-by:
Ard Biesheuvel <ardb@kernel.org> Cc: stable@vger.kernel.org # v2.6.16+ Fixes: 55a82ab3 ("[PATCH] tpm: add bios measurement log") Reported-by:
Andy Liang <andy.liang@hpe.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495 Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Stefan Berger <stefanb@linux.ibm.com> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
Andy Liang <andy.liang@hpe.com> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit ea35e0d5df6c92fa2e124bb1b91d09b2240715ba Author: Stefan Berger <stefanb@linux.ibm.com> Date: Tue Jun 29 17:34:20 2021 -0400 certs: Trigger creation of RSA module signing key if it's not an RSA key Address a kbuild issue where a developer created an ECDSA key for signing kernel modules and then builds an older version of the kernel, when bi- secting the kernel for example, that does not support ECDSA keys. If openssl is installed, trigger the creation of an RSA module signing key if it is not an RSA key. Fixes: cfc411e7 ("Move certificate handling to its own directory") Cc: David Howells <dhowells@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Stefan Berger <stefanb@linux.ibm.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Tested-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit a4aed36ed5924a05ecfadc470584188bfba2b928 Author: Stefan Berger <stefanb@linux.ibm.com> Date: Tue Jun 29 17:34:21 2021 -0400 certs: Add support for using elliptic curve keys for signing modules Add support for using elliptic curve keys for signing modules. It uses a NIST P384 (secp384r1) key if the user chooses an elliptic curve key and will have ECDSA support built into the kernel. Note: A developer choosing an ECDSA key for signing modules should still delete the signing key (rm certs/signing_key.*) when building an older version of a kernel that only supports RSA keys. Unless kbuild automati- cally detects and generates a new kernel module key, ECDSA-signed kernel modules will fail signature verification. Cc: David Howells <dhowells@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Stefan Berger <stefanb@linux.ibm.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Tested-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Fedora Kernel Team authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 Upstream Status: RHEL only Hi, As part of the ongoing rebase effort, the following configuration options need to be reviewed. As a reminder, the ARK configuration flow involves moving unreviewed configuration options from the pending directory to the ark directory. In the diff below, options are removed from the pending directory and added to the ark hierarchy. The final options that need to be ACKed are the files that are being added to the ark hierarchy. If the value for a file that is added should be changed, please reply with a better option. Symbol: MODULE_SIG_KEY_TYPE_ECDSA [=n] Type : bool Defined at certs/Kconfig:31 Prompt: ECDSA Depends on: <choice> && (MODULE_SIG [=y] || IMA_APPRAISE_MODSIG [=y] && MODULES [=y]) Location: -> Cryptographic API (CRYPTO [=y]) -> Certificates for signature checking -> Type of module signing key to be generated (<choice> [=y]) Selects: CRYPTO_ECDSA [=m] --- Symbol: MODULE_SIG_KEY_TYPE_RSA [=y] Type : bool Defined at certs/Kconfig:25 Prompt: RSA Depends on: <choice> && (MODULE_SIG [=y] || IMA_APPRAISE_MODSIG [=y] && MODULES [=y]) Location: -> Cryptographic API (CRYPTO [=y]) -> Certificates for signature checking -> Type of module signing key to be generated (<choice> [=y]) --- Signed-off-by:
Fedora Kernel Team <kernel-team@fedoraproject.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 0f5d4a0b995faa6537c4de79973817a4f8da206a Author: Arnd Bergmann <arnd@arndb.de> Date: Thu Dec 15 18:02:52 2022 +0100 crypto: certs: fix FIPS selftest dependency The selftest code is built into the x509_key_parser module, and depends on the pkcs7_message_parser module, which in turn has a dependency on the key parser, creating a dependency loop and a resulting link failure when the pkcs7 code is a loadable module: ld: crypto/asymmetric_keys/selftest.o: in function `fips_signature_selftest': crypto/asymmetric_keys/selftest.c:205: undefined reference to `pkcs7_parse_message' ld: crypto/asymmetric_keys/selftest.c:209: undefined reference to `pkcs7_supply_detached_data' ld: crypto/asymmetric_keys/selftest.c:211: undefined reference to `pkcs7_verify' ld: crypto/asymmetric_keys/selftest.c:215: undefined reference to `pkcs7_validate_trust' ld: crypto/asymmetric_keys/selftest.c:219: undefined reference to `pkcs7_free_message' Avoid this by only allowing the selftest to be enabled when either both parts are loadable modules, or both are built-in. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 0a596b0682a7ce37e26c36629816f105c6459d06 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Sat Aug 26 16:36:41 2023 +0800 KEYS: Include linux/errno.h in linux/verification.h Add inclusion of linux/errno.h as otherwise the reference to EINVAL may be invalid. Fixes: f3cf4134c5c6 ("bpf: Add bpf_lookup_*_key() and bpf_key_put() kfuncs") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202308261414.HKw1Mrip-lkp@intel.com/ Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 04a93202ed7c3b451bf22d3ff4bcd379df27f299 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Mon Oct 16 13:21:44 2023 +0800 certs: Break circular dependency when selftest is modular The modular build fails because the self-test code depends on pkcs7 which in turn depends on x509 which contains the self-test. Split the self-test out into its own module to break the cycle. Fixes: 3cde3174eb91 ("certs: Add FIPS selftests") Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 8cd9f234f7066a783bb8beab8f25f9e31d878e17 Author: Joachim Vandersmissen <git@jvdsn.com> Date: Sun May 12 23:55:06 2024 -0500 certs: Move RSA self-test data to separate file In preparation of adding new ECDSA self-tests, the existing data for the RSA self-tests is moved to a separate file. This file is only compiled if the new CONFIG_FIPS_SIGNATURE_SELFTEST_RSA configuration option is set, which ensures that the required dependencies (RSA, SHA-256) are present. Otherwise, the kernel would panic when trying to execute the self-test. The introduction of this new option, rather than adding the dependencies to the existing CONFIG_FIPS_SIGNATURE_SELFTEST option, allows for additional self-tests to be added for different algorithms. The kernel can then be configured to only execute the self-tests for those algorithms that are included. Signed-off-by:
Joachim Vandersmissen <git@jvdsn.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Herbert Xu authored
JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 747ae81883d21595b162cc40523a982024700fed Author: Joachim Vandersmissen <git@jvdsn.com> Date: Sun May 12 23:55:07 2024 -0500 certs: Add ECDSA signature verification self-test Commit c27b2d2012e1 ("crypto: testmgr - allow ecdsa-nist-p256 and -p384 in FIPS mode") enabled support for ECDSA in crypto/testmgr.c. The PKCS#7 signature verification API builds upon the KCAPI primitives to perform its high-level operations. Therefore, this change in testmgr.c also allows ECDSA to be used by the PKCS#7 signature verification API (in FIPS mode). However, from a FIPS perspective, the PKCS#7 signature verification API is a distinct "service" from the KCAPI primitives. This is because the PKCS#7 API performs a "full" signature verification, which consists of both hashing the data to be verified, and the public key operation. On the other hand, the KCAPI primitive does not perform this hashing step - it accepts pre-hashed data from the caller and only performs the public key operation. For this reason, the ECDSA self-tests in crypto/testmgr.c are not sufficient to cover ECDSA signature verification offered by the PKCS#7 API. This is reflected by the self-test already present in this file for RSA PKCS#1 v1.5 signature verification. The solution is simply to add a second self-test here for ECDSA. P-256 with SHA-256 hashing was chosen as those parameters should remain FIPS-approved for the foreseeable future, while keeping the performance impact to a minimum. The ECDSA certificate and PKCS#7 signed data was generated using OpenSSL. The input data is identical to the input data for the existing RSA self-test. Signed-off-by:
Joachim Vandersmissen <git@jvdsn.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com>
-
Davide Caratti authored
JIRA: https://issues.redhat.com/browse/RHEL-82474 Upstream Status: kernel-ark commit dc40dd2b84fb This reverts commit bddbb6d2. commit dc40dd2b84fb6706b35c19b9a8cc4d796e093b0f Author: Davide Caratti <dcaratti@redhat.com> Date: Thu Feb 27 16:02:49 2025 +0100 Revert "redhat/configs: automotive: disable CONFIG_AIO" JIRA: https://issues.redhat.com/browse/VROOM-27201 re-enable CONFIG_AIO, as it's in-scope for file-system. This reverts commit a8e67f6b1ae9c31be7229f953fe11f570154e023. Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
Davide Caratti <dcaratti@redhat.com>
-
Mamatha Inamdar authored
JIRA: https://issues.redhat.com/browse/RHEL-80602 commit 2ffb26afa64261139e608bf087a0c1fe24d76d4d Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Date: Tue Jan 21 18:46:20 2025 +0530 arch/powerpc/perf: Check the instruction type before creating sample with perf_mem_data_src perf mem report aborts as below sometimes (during some corner case) in powerpc: # ./perf mem report 1>out *** stack smashing detected ***: terminated Aborted (core dumped) The backtrace is as below: __pthread_kill_implementation () raise () abort () __libc_message __fortify_fail __stack_chk_fail hist_entry.lvl_snprintf __sort__hpp_entry __hist_entry__snprintf hists.fprintf cmd_report cmd_mem Snippet of code which triggers the issue from tools/perf/util/sort.c static int hist_entry__lvl_snprintf(struct hist_entry *he, char *bf, size_t size, unsigned int width) { char out[64]; perf_mem__lvl_scnprintf(out, sizeof(out), he->mem_info); return repsep_snprintf(bf, size, "%-*s", width, out); } The value of "out" is filled from perf_mem_data_src value. Debugging this further showed that for some corner cases, the value of "data_src" was pointing to wrong value. This resulted in bigger size of string and causing stack check fail. The perf mem data source values are captured in the sample via isa207_get_mem_data_src function. The initial check is to fetch the type of sampled instruction. If the type of instruction is not valid (not a load/store instruction), the function returns. Since 'commit e16fd7f2cb1a ("perf: Use sample_flags for data_src")', data_src field is not initialized by the perf_sample_data_init() function. If the PMU driver doesn't set the data_src value to zero if type is not valid, this will result in uninitailised value for data_src. The uninitailised value of data_src resulted in stack check fail followed by abort for "perf mem report". When requesting for data source information in the sample, the instruction type is expected to be load or store instruction. In ISA v3.0, due to hardware limitation, there are corner cases where the instruction type other than load or store is observed. In ISA v3.0 and before values "0" and "7" are considered reserved. In ISA v3.1, value "7" has been used to indicate "larx/stcx". Drop the sample if instruction type has reserved values for this field with a ISA version check. Initialize data_src to zero in isa207_get_mem_data_src if the instruction type is not load/store. Reported-by:
Disha Goel <disgoel@linux.vnet.ibm.com> Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Signed-off-by:
Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250121131621.39054-1-atrajeev@linux.vnet.ibm.com Signed-off-by:
Mamatha Inamdar <minamdar@redhat.com>
-
Mamatha Inamdar authored
JIRA: https://issues.redhat.com/browse/RHEL-80602 commit f848e7ee1588d66539da7315d9a99bfaeda3b970 Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Date: Tue Jan 21 18:46:21 2025 +0530 arch/powerpc/perf: Update get_mem_data_src function to use saved values of sier and mmcra regs During performance monitor interrupt handling, the regs are setup using perf_read_regs function. Here some of the pt_regs fields is overloaded. Samples Instruction Event Register (SIER) is loaded into pt_regs, overloading regs->dar. And regs->dsisr to store MMCRA (Monitor Mode Control Register A) so that we only need to read these once on each interrupt. Update the isa207_get_mem_data_src function to use regs->dar instead of reading from SPRN_SIER again. Also use regs->dsisr to read the mmcra value Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Signed-off-by:
Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250121131621.39054-2-atrajeev@linux.vnet.ibm.com Signed-off-by:
Mamatha Inamdar <minamdar@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 Conflicts: Limited to remaining drivers/thermal/intel files commit bd745d1c41e7fa56242889eb5dc6df2d7dd5df32 Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Feb 13 22:06:13 2024 +0100 x86/cpu/topology: Rename topology_max_die_per_package() The plural of die is dies. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Michael Kelley <mhklinux@outlook.com> Tested-by:
Sohil Mehta <sohil.mehta@intel.com> Link: https://lore.kernel.org/r/20240213210253.065874205@linutronix.de Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 Upstream Status: RHEL-only In order to allow a smooth transition, topology_max_die_per_package() was provided even as part of RHEL commit b2d6cca8. As the function is no longer utilized it should be removed. Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 68de0ae4d6b5ea675b835e4a6b00f52a26cd7f0c Author: Zhang Rui <rui.zhang@intel.com> Date: Thu May 30 23:17:04 2024 +0800 thermal: intel: intel_pch: Improve cooling log The intel_pch_thermal cooling mechanism currently only provides one of the following final conclusions: 1. intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [48C] 2. intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [49C] after 30700 ms delay 3. intel_pch_thermal 0000:00:12.0: CPU-PCH is hot [60C] after 60000 ms delay. S0ix might fail 4. intel_pch_thermal 0000:00:12.0: Wakeup event detected, abort cooling This does not provide sufficient context about what is happening, especially for case 4. Add one line log to indicate when PCH overheats and the cooling delay has started. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 0f46ecc4242a49eb4630d0ac32afbb235f1239fa Author: Tony Luck <tony.luck@intel.com> Date: Tue May 28 11:47:17 2024 -0700 thermal: intel: intel_tcc_cooling: Switch to new Intel CPU model defines New CPU #defines encode vendor and family as well as model. Signed-off-by:
Tony Luck <tony.luck@intel.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 Conflicts: limited to drivers/thermal/intel commit cb787f4ac0c2e439ea8d7e6387b925f74576bdf8 Author: Al Viro <viro@zeniv.linux.org.uk> Date: Fri Sep 27 02:56:11 2024 +0100 [tree-wide] finally take no_llseek out no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\<no_llseek\>/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit bfc6819e4bf56a55df6178f93241b5845ad672eb Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Sep 30 16:18:00 2024 +0800 thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support CPU0/package0 is always online and the MMIO RAPL driver runs on single package systems only, so there is no need to handle CPU hotplug in it. Always register a RAPL package device for package 0 and remove the unnecessary CPU hotplug support. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Reviewed-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-6-rui.zhang@intel.com [ rjw: Subject edits ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 3fb0eea8a1c4be5884e0731ea76cbd3ce126e1f3 Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Sep 30 16:18:01 2024 +0800 thermal: intel: int340x: processor: Add MMIO RAPL PL4 support Similar to the MSR RAPL interface, MMIO RAPL supports PL4 too, so add MMIO RAPL PL4d support to the processor_thermal driver. As a result, the powercap sysfs for MMIO RAPL will show a new "peak power" constraint. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Reviewed-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-7-rui.zhang@intel.com [ rjw: Subject and changelog edits ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 110213b8f0e7021819d4db273facb27701bc3381 Author: Tony Luck <tony.luck@intel.com> Date: Thu Oct 31 11:57:33 2024 -0700 x86/cpu: Fix FAM5_QUARK_X1000 to use X86_MATCH_VFM() This family 5 CPU escaped notice when cleaning up all the family 6 CPUs. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/all/20241031185733.17327-1-tony.luck%40intel.com Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 7082503622986537f57bdb5ef23e69e70cfad881 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Thu Nov 14 12:02:13 2024 -0800 thermal: int3400: Fix reading of current_uuid for active policy When the current_uuid attribute is set to the active policy UUID, reading back the same attribute is returning "INVALID" instead of the active policy UUID on some platforms before Ice Lake. In platforms before Ice Lake, firmware provides a list of supported thermal policies. In this case, user space can select any of the supported thermal policies via a write to attribute "current_uuid". In commit c7ff29763989 ("thermal: int340x: Update OS policy capability handshake")', the OS policy handshake was updated to support Ice Lake and later platforms and it treated priv->current_uuid_index=0 as invalid. However, priv->current_uuid_index=0 is for the active policy, only priv->current_uuid_index=-1 is invalid. Fix this issue by updating the priv->current_uuid_index check. Fixes: c7ff29763989 ("thermal: int340x: Update OS policy capability handshake") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 5.18+ <stable@vger.kernel.org> # 5.18+ Link: https://patch.msgid.link/20241114200213.422303-1-srinivas.pandruvada@linux.intel.com [ rjw: Subject and changelog edits ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 13f3cbfbb8c9f3825a1e4e4371fe040fb35e41d5 Author: Thomas Weißschuh <linux@weissschuh.net> Date: Thu Nov 21 17:29:32 2024 +0100 thermal: int3400: Remove unneeded data_vault attribute_group The group only contains a single entry and the conditionals around its lifecycle make clear that this won't change. Remove the unnecessary group. This saves some memory and it's easier to read. The removal of a non-const bin_attribute[] instance is also a preparation for the constification of struct bin_attributes. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20241121-sysfs-const-bin_attr-int340x_thermal-v1-1-2436facf9dae@weissschuh.net Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 3cc83aeea0cd061e424f634da62dfcabe7fdd5c5 Author: Zhang Rui <rui.zhang@intel.com> Date: Tue Dec 3 15:58:01 2024 +0800 thermal: intel: int340x: processor: Enable MMIO RAPL for Panther Lake Enable MMIO RAPL support for PantherLake platform. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Link: https://patch.msgid.link/20241203075802.584741-3-rui.zhang@intel.com [ rjw: Subject edit ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 3fd3697ebfb49ee218416340b084208377ea081d Author: Zhang Rui <rui.zhang@intel.com> Date: Tue Dec 3 15:58:02 2024 +0800 ACPI: DPTF: Support Panther Lake Add Panther Lake ACPI IDs for DPTF. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Link: https://patch.msgid.link/20241203075802.584741-4-rui.zhang@intel.com [ rjw: Changelog edit ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 4596cbea0ed2ef4f563a92775c9f612700ece145 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Mon Dec 16 11:08:21 2024 -0800 thermal: intel: Remove explicit user_space governor selection Currently some user space programs like Linux thermald needs to register to get notifications from both thermal user space governor and also Thermal netlink. This is required as some messages like HFI (Hardware Feedback Notifications) requires Thermal netlink. This results in additional processing in kernel and user space to process both notifications. The cost of using user space governor using kobject_uevent is much higher as this is also used by other user space daemons like udev daemon. Do not select user_space thermal governor by default. If it is present user space programs can always use this governor by writing to "policy" attribute. Instead from the kernel select THERMAL_NETLINK. Trip temperature violation can be received by user space programs via thermal netlink events: THERMAL_GENL_EVENT_TZ_TRIP_UP THERMAL_GENL_EVENT_TZ_TRIP_DOWN Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20241216190821.1137162-1-srinivas.pandruvada@linux.intel.com Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit e50eeababa946d92f1669fd4d66a5f652b143b05 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Mon Dec 16 13:18:09 2024 -0800 thermal: intel: int340x: Panther Lake DLVR support Panther Lake follows same register set as Lunar Lake for DLVR. Enable feature flag to support DLVR. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/thermal : intel: int340x: Panther Lake DLVR support Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit b59bd75a4b0983d6bcd10987b32ea9b9042db88c Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Mon Dec 16 13:18:10 2024 -0800 thermal: intel: int340x: Panther Lake power floor and workload hint support Panther Lake follows same register set as Lunar Lake. Enable feature flags to support workload hints and power floor status. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20241216211810.1207028-2-srinivas.pandruvada@linux.intel.com Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 207a792d01603faae08d9bd82846bd99c42c30cc Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Wed Dec 18 13:44:44 2024 -0800 thermal: intel: Fix compile issue when CONFIG_NET is not defined If CONFIG_NET is not defined then THERMAL_NETLINK can't be selected. Hence add dependency on CONFIG_NET. Othewise it will generate compile errors while compiling thermal_netlink.c. Fixes: 4596cbea0ed2 ("thermal: intel: Remove explicit user_space governor selection") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20241218214444.1904650-1-srinivas.pandruvada@linux.intel.com [ rjw: Merge the "depends on" lines ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 69f3aa6ad92447d6e9f50c5b5aea85b56e80b198 Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Date: Thu Oct 10 20:06:17 2024 +0200 thermal: of: Simplify thermal_of_should_bind with scoped for each OF child Use scoped for_each_child_of_node_scoped() when iterating over device nodes to make code a bit simpler. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20241010-b4-cleanup-h-of-node-put-thermal-v4-1-bfbe29ad81f4@linaro.org Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
David Arcari <darcari@redhat.com>
-
David Arcari authored
JIRA: https://issues.redhat.com/browse/RHEL-79821 commit 423de5b5bc5b267586b449abd1c4fde562aa0cf9 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Feb 21 17:57:11 2025 +0100 thermal/of: Fix cdev lookup in thermal_of_should_bind() Since thermal_of_should_bind() terminates the loop after processing the first child found in cooling-maps, it will never match more than one cdev to a given trip point which is incorrect, as there may be cooling-maps associating one trip point with multiple cooling devices. Address this by letting the loop continue until either all children have been processed or a matching one has been found. To avoid adding conditionals or goto statements, put the loop in question into a separate function and make that function return right away after finding a matching cooling-maps entry. Fixes: 94c6110b0b13 ("thermal/of: Use the .should_bind() thermal zone callback") Link: https://lore.kernel.org/linux-pm/20250219-fix-thermal-of-v1-1-de36e7a590c4@chromium.org/ Reported-by:
Yu-Che Cheng <giver@chromium.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Yu-Che Cheng <giver@chromium.org> Tested-by:
Yu-Che Cheng <giver@chromium.org> Reviewed-by:
Lukasz Luba <lukasz.luba@arm.com> Tested-by:
Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/2788228.mvXUDI8C0e@rjwysocki.net Signed-off-by:
David Arcari <darcari@redhat.com>
-
Guillaume Nault authored
JIRA: https://issues.redhat.com/browse/RHEL-81542 Upstream Status: linux.git CVE: CVE-2025-21791 commit 6d0ce46a93135d96b7fa075a94a88fe0da8e8773 Author: Eric Dumazet <edumazet@google.com> Date: Fri Feb 7 13:58:38 2025 +0000 vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF. Fixes: a8e3e1a9 ("net: l3mdev: Add hook to output path") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250207135841.1948589-7-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Guillaume Nault <gnault@redhat.com>
-
Radu Rendec authored
JIRA: https://issues.redhat.com/browse/RHEL-83275 Upstream-status: RHEL-only The vxcan module is a software-only CAN bus driver that implements CAN bus interface pairs. It is similar to veth but for CAN bus. The main application is to test the various CAN bus protocol layers without requiring real CAN bus hardware. Signed-off-by:
Radu Rendec <rrendec@redhat.com>
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-83858 commit fc99045effa81fdf509c2a97cbb7e6e8f2fd4443 Author: Paulo Alcantara <pc@manguebit.com> Date: Wed Mar 12 10:51:31 2025 -0300 smb: client: fix regression with guest option When mounting a CIFS share with 'guest' mount option, mount.cifs(8) will set empty password= and password2= options. Currently we only handle empty strings from user= and password= options, so the mount will fail with cifs: Bad value for 'password2' Fix this by handling empty string from password2= option as well. Link: https://bbs.archlinux.org/viewtopic.php?id=303927 Reported-by:
Adam Williamson <awilliam@redhat.com> Closes: https://lore.kernel.org/r/83c00b5fea81c07f6897a5dd3ef50fd3b290f56c.camel@redhat.com Fixes: 35f834265e0d ("smb3: fix broken reconnect when password changing on the server by allowing password rotation") Cc: stable@vger.kernel.org Signed-off-by:
Paulo Alcantara (Red Hat) <pc@manguebit.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
Paulo Alcantara <paalcant@redhat.com>
-
Rafael Aquini authored
JIRA: https://issues.redhat.com/browse/RHEL-74363 This patch is a backport of the following upstream commit: commit 67a2f86846f244d81601cf2e1552c4656b8556d6 Author: Rafael Aquini <raquini@redhat.com> Date: Tue Feb 18 14:22:51 2025 -0500 selftests/mm: run_vmtests.sh: fix half_ufd_size_MB calculation We noticed that uffd-stress test was always failing to run when invoked for the hugetlb profiles on x86_64 systems with a processor count of 64 or bigger: ... # ------------------------------------ # running ./uffd-stress hugetlb 128 32 # ------------------------------------ # ERROR: invalid MiB (errno=9, @uffd-stress.c:459) ... # [FAIL] not ok 3 uffd-stress hugetlb 128 32 # exit=1 ... The problem boils down to how run_vmtests.sh (mis)calculates the size of the region it feeds to uffd-stress. The latter expects to see an amount of MiB while the former is just giving out the number of free hugepages halved down. This measurement discrepancy ends up violating uffd-stress' assertion on number of hugetlb pages allocated per CPU, causing it to bail out with the error above. This commit fixes that issue by adjusting run_vmtests.sh's half_ufd_size_MB calculation so it properly renders the region size in MiB, as expected, while maintaining all of its original constraints in place. Link: https://lkml.kernel.org/r/20250218192251.53243-1-aquini@redhat.com Fixes: 2e47a445d7b3 ("selftests/mm: run_vmtests.sh: fix hugetlb mem size calculation") Signed-off-by:
Rafael Aquini <raquini@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Rafael Aquini <raquini@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: fad610b987132868e3410c530871086552ce6155 commit fad610b987132868e3410c530871086552ce6155 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:47 2024 +0300 Documentation PCI: Reformat RMW ops documentation Extract the list of RMW protected PCIe Capability registers into a bullet list to make them easier to pick up on a glance. An upcoming change is going to add one more register among them so it will be much cleaner to have them as bullets. Link: https://lore.kernel.org/r/20241018144755.7875-2-ilpo.jarvinen@linux.intel.com Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lukas Wunner <lukas@wunner.de> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 04af8a399fa40310f831b4f1dc9f757085f41983 commit 04af8a399fa40310f831b4f1dc9f757085f41983 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:48 2024 +0300 PCI: Protect Link Control 2 Register with RMW locking The PCIe Bandwidth Controller performs RMW accesses the Link Control 2 Register which can occur concurrently to other sources of Link Control 2 Register writes. Therefore, add Link Control 2 Register among the PCI Express Capability Registers that need RMW locking. Link: https://lore.kernel.org/r/20241018144755.7875-3-ilpo.jarvinen@linux.intel.com Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lukas Wunner <lukas@wunner.de> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: d2bd39c0456b75be9dfc7d774b8d021355c26ae3 commit d2bd39c0456b75be9dfc7d774b8d021355c26ae3 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:49 2024 +0300 PCI: Store all PCIe Supported Link Speeds The PCIe bandwidth controller added by a subsequent commit will require selecting PCIe Link Speeds that are lower than the Maximum Link Speed. The struct pci_bus only stores max_bus_speed. Even if PCIe r6.1 sec 8.2.1 currently disallows gaps in supported Link Speeds, the Implementation Note in PCIe r6.1 sec 7.5.3.18, recommends determining supported Link Speeds using the Supported Link Speeds Vector in the Link Capabilities 2 Register (when available) to "avoid software being confused if a future specification defines Links that do not require support for all slower speeds." Reuse code in pcie_get_speed_cap() to add pcie_get_supported_speeds() to query the Supported Link Speeds Vector of a PCIe device. The value is taken directly from the Supported Link Speeds Vector or synthesized from the Max Link Speed in the Link Capabilities Register when the Link Capabilities 2 Register is not available. The Supported Link Speeds Vector in the Link Capabilities Register 2 corresponds to the bus below on Root Ports and Downstream Ports, whereas it corresponds to the bus above on Upstream Ports and Endpoints (PCIe r6.1 sec 7.5.3.18): Supported Link Speeds Vector - This field indicates the supported Link speed(s) of the associated Port. Add supported_speeds into the struct pci_dev that caches the Supported Link Speeds Vector. supported_speeds contains a set of Link Speeds only in the case where PCIe Link Speed can be determined. Root Complex Integrated Endpoints do not have a well-defined Link Speed because they do not implement either of the Link Capabilities Registers, which is allowed by PCIe r6.1 sec 7.5.3 (the same limitation applies to determining cur_bus_speed and max_bus_speed that are PCI_SPEED_UNKNOWN in such case). This is of no concern from PCIe bandwidth controller point of view because such devices are not attached into a PCIe Root Port that could be controlled. The supported_speeds field keeps the extra reserved zero at the least significant bit to match the Link Capabilities 2 Register layout. An attempt was made to store supported_speeds field into the struct pci_bus as an intersection of both ends of the Link, however, the subordinate struct pci_bus is not available early enough. The Target Speed quirk (in pcie_failed_link_retrain()) can run either during initial scan or later, requiring it to use the API provided by the PCIe bandwidth controller to set the Target Link Speed in order to co-exist with the bandwidth controller. When the Target Speed quirk is calling the bandwidth controller during initial scan, the struct pci_bus is not yet initialized. As such, storing supported_speeds into the struct pci_bus is not viable. Suggested-by:
Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20241018144755.7875-4-ilpo.jarvinen@linux.intel.com Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: move pcie_get_supported_speeds() decl to drivers/pci/pci.h] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: e93d9fcfd7dc643eb5fce43053774d27bea2b263 commit e93d9fcfd7dc643eb5fce43053774d27bea2b263 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:50 2024 +0300 PCI: Refactor pcie_update_link_speed() pcie_update_link_speed() is passed the Link Status register but not all callers have that value at hand nor need the value. Refactor pcie_update_link_speed() to include reading the Link Status register and create __pcie_update_link_speed() which can be used by the hotplug code that has the register value at hand beforehand (and needs the value for other purposes). Link: https://lore.kernel.org/r/20241018144755.7875-5-ilpo.jarvinen@linux.intel.com Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 3491f509666865412ad344cd4dde9f3c5a52326e commit 3491f509666865412ad344cd4dde9f3c5a52326e Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:51 2024 +0300 PCI: Abstract LBMS seen check into pcie_lbms_seen() The Target Speed quirk in pcie_failed_link_retrain() uses the presence of LBMS bit as one of the triggering conditions, effectively monopolizing the use of that bit. An upcoming change will introduce a PCIe bandwidth controller which sets up an interrupt to track LBMS. As LBMS will be cleared by the interrupt handler, the Target Speed quirk will no longer be able to observe LBMS directly. As a preparatory step for the change, extract the LBMS seen check from pcie_failed_link_retrain() into a new function pcie_lmbs_seen(). Link: https://lore.kernel.org/r/20241018144755.7875-6-ilpo.jarvinen@linux.intel.com Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 665745f274870c921020f610e2c99a3b1613519b commit 665745f274870c921020f610e2c99a3b1613519b Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:52 2024 +0300 PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller This mostly reverts the commit b4c7d207 ("PCI/LINK: Remove bandwidth notification"). An upcoming commit extends this driver building PCIe bandwidth controller on top of it. PCIe bandwidth notifications were first added in the commit e8303bb7 ("PCI/LINK: Report degraded links via link bandwidth notification") but later had to be removed. The significant changes compared with the old bandwidth notification driver include: 1) Don't print the notifications into kernel log, just keep the Link Speed cached in struct pci_bus updated. While somewhat unfortunate, the log spam was the source of complaints that eventually lead to the removal of the bandwidth notifications driver (see the links below for further information). 2) Besides the Link Bandwidth Management Interrupt, also enable Link Autonomous Bandwidth Interrupt to cover the other source of bandwidth changes. 3) Handle Link Speed updates robustly. Refresh the cached Link Speed when enabling Bandwidth Notification Interrupts, and solve the race between Link Speed read and LBMS/LABS update in pcie_bwnotif_irq_thread(). 4) Use concurrency safe LNKCTL RMW operations. 5) The driver is now called PCIe bwctrl (bandwidth controller) instead of just bandwidth notifications because of increased scope and functionality within the driver. 6) Coexist with the Target Link Speed quirk in pcie_failed_link_retrain(). Provide LBMS counting API for it. 7) Tweaks to variable/functions names for consistency and length reasons. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. [bhelgaas: This is based on previous work by Alexandru Gagniuc <mr.nuke.me@gmail.com>; see e8303bb7 ("PCI/LINK: Report degraded links via link bandwidth notification")] Link: https://lore.kernel.org/r/20241018144755.7875-7-ilpo.jarvinen@linux.intel.com Link: https://lore.kernel.org/all/20190429185611.121751-1-helgaas@kernel.org/ Link: https://lore.kernel.org/linux-pci/20190501142942.26972-1-keith.busch@intel.com/ Link: https://lore.kernel.org/linux-pci/20200115221008.GA191037@google.com/ Suggested-by: Lukas Wunner <lukas@wunner.de> # Building bwctrl on top of bwnotif Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash fix to drop IRQF_ONESHOT and convert to hardirq handler: https://lore.kernel.org/r/20241115165717.15233-1-ilpo.jarvinen@linux.intel.com ] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Tested-by:
Stefan Wahren <wahrenst@gmx.net> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 commit de9a6c8d5dbfedb5eb3722c822da0490f6a59a45 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Oct 18 17:47:53 2024 +0300 PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed Currently, PCIe Link Speeds are adjusted by custom code rather than in a common function provided in PCI core. The PCIe bandwidth controller (bwctrl) introduces an in-kernel API, pcie_set_target_speed(), to set PCIe Link Speed. Convert Target Speed quirk to use the new API. The Target Speed quirk runs very early when bwctrl is not yet probed for a Port and can also run later when bwctrl is already setup for the Port, which requires the per port mutex (set_speed_mutex) to be only taken if the bwctrl setup is already complete. The new API is also intended to be used in an upcoming commit that adds a thermal cooling device to throttle PCIe bandwidth when thermal thresholds are reached. The PCIe bandwidth control procedure is as follows. The highest speed supported by the Port and the PCIe device which is not higher than the requested speed is selected and written into the Target Link Speed in the Link Control 2 Register. Then bandwidth controller retrains the PCIe Link. Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to keep track PCIe Link Speed changes. While Bandwidth Notifications should also be generated when bandwidth controller alters the PCIe Link Speed, a few platforms do not deliver LMBS interrupt after Link Training as expected. Thus, after changing the Link Speed, bandwidth controller makes additional read for the Link Status Register to ensure cur_bus_speed is consistent with the new PCIe Link Speed. Link: https://lore.kernel.org/r/20241018144755.7875-8-ilpo.jarvinen@linux.intel.com Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash devm_mutex_init() error checking from https://lore.kernel.org/r/20241030163139.2111689-1-andriy.shevchenko@linux.intel.com , drop export of pcie_set_target_speed()] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: ba58eee1c57b2ad45c36f782861c18faef170a55 commit ba58eee1c57b2ad45c36f782861c18faef170a55 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Mon Nov 11 14:21:33 2024 -0600 PCI: Drop duplicate pcie_get_speed_cap(), pcie_get_width_cap() declarations 6cf57be0 ("PCI: Add pcie_get_speed_cap() to find max supported link speed") and c70b65fb ("PCI: Add pcie_get_width_cap() to find max supported link width") added declarations to drivers/pci/pci.h. 576c7218 ("PCI: Export pcie_get_speed_cap and pcie_get_width_cap") subsequently added duplicates to include/linux/pci.h. Remove the originals from drivers/pci/pci.h. Both interfaces are used by amdgpu, so they must be in include/linux/pci.h. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Krzysztof Wilczyński <kw@linux.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 3202ca221578850f34e0fea39dc6cfa745ed7aac commit 3202ca221578850f34e0fea39dc6cfa745ed7aac Author: Lukas Wunner <lukas@wunner.de> Date: Tue Dec 17 10:51:01 2024 +0100 PCI: Honor Max Link Speed when determining supported speeds The Supported Link Speeds Vector in the Link Capabilities 2 Register indicates the *supported* link speeds. The Max Link Speed field in the Link Capabilities Register indicates the *maximum* of those speeds. pcie_get_supported_speeds() neglects to honor the Max Link Speed field and will thus incorrectly deem higher speeds as supported. Fix it. One user-visible issue addressed here is an incorrect value in the sysfs attribute "max_link_speed". But the main motivation is a boot hang reported by Niklas: Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers supports 2.5-8 GT/s speeds, but indicate 2.5 GT/s as maximum. Ilpo recalls seeing this on more devices. It can be explained by the controller's Downstream Ports supporting 8 GT/s if an Endpoint is attached, but limiting to 2.5 GT/s if the port interfaces to a PCIe Adapter, in accordance with USB4 v2 sec 11.2.1: "This section defines the functionality of an Internal PCIe Port that interfaces to a PCIe Adapter. [...] The Logical sub-block shall update the PCIe configuration registers with the following characteristics: [...] Max Link Speed field in the Link Capabilities Register set to 0001b (data rate of 2.5 GT/s only). Note: These settings do not represent actual throughput. Throughput is implementation specific and based on the USB4 Fabric performance." The present commit is not sufficient on its own to fix Niklas' boot hang, but it is a prerequisite: A subsequent commit will fix the boot hang by enabling bandwidth control only if more than one speed is supported. The GENMASK() macro used herein specifies 0 as lowest bit, even though the Supported Link Speeds Vector ends at bit 1. This is done on purpose to avoid a GENMASK(0, 1) macro if Max Link Speed is zero. That macro would be invalid as the lowest bit is greater than the highest bit. Ilpo has witnessed a zero Max Link Speed on Root Complex Integrated Endpoints in particular, so it does occur in practice. (The Link Capabilities Register is optional on RCiEPs per PCIe r6.2 sec 7.5.3.) Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds") Closes: https://lore.kernel.org/r/70829798889c6d779ca0f6cd3260a765780d1369.camel@kernel.org Link: https://lore.kernel.org/r/fe03941e3e1cc42fb9bf4395e302bff53ee2198b.1734428762.git.lukas@wunner.de Reported-by:
Niklas Schnelle <niks@kernel.org> Tested-by:
Niklas Schnelle <niks@kernel.org> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 774c71c52aa487001c7da9f93b10cedc9985c371 commit 774c71c52aa487001c7da9f93b10cedc9985c371 Author: Lukas Wunner <lukas@wunner.de> Date: Tue Dec 17 10:51:02 2024 +0100 PCI/bwctrl: Enable only if more than one speed is supported If a PCIe port only supports a single speed, enabling bandwidth control is pointless: There's no need to monitor autonomous speed changes, nor can the speed be changed. Not enabling it saves a small amount of memory and compute resources, but also fixes a boot hang reported by Niklas: It occurs when enabling bandwidth control on Downstream Ports of Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers. The ports only support 2.5 GT/s in accordance with USB4 v2 sec 11.2.1, so the present commit works around the issue. PCIe r6.2 sec 8.2.1 prescribes that: "A device must support 2.5 GT/s and is not permitted to skip support for any data rates between 2.5 GT/s and the highest supported rate." Consequently, bandwidth control is currently only disabled if a port doesn't support higher speeds than 2.5 GT/s. However the Implementation Note in PCIe r6.2 sec 7.5.3.18 cautions: "It is strongly encouraged that software primarily utilize the Supported Link Speeds Vector instead of the Max Link Speed field, so that software can determine the exact set of supported speeds on current and future hardware. This can avoid software being confused if a future specification defines Links that do not require support for all slower speeds." In other words, future revisions of the PCIe Base Spec may allow gaps in the Supported Link Speeds Vector. To be future-proof, don't just check whether speeds above 2.5 GT/s are supported, but rather check whether *more than one* speed is supported. Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Closes: https://lore.kernel.org/r/db8e457fcd155436449b035e8791a8241b0df400.camel@kernel.org Link: https://lore.kernel.org/r/3564908a9c99fc0d2a292473af7a94ebfc8f5820.1734428762.git.lukas@wunner.de Reported-by:
Niklas Schnelle <niks@kernel.org> Tested-by:
Niklas Schnelle <niks@kernel.org> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by:
Jonathan Cameron <Jonthan.Cameron@huawei.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Myron Stowe authored
JIRA: https://issues.redhat.com/browse/RHEL-81906 Upstream Status: 15b8968dcb90f194d44501468b230e6e0d816d4a Conflict(s): Patching file drivers/pci/pcie/bwctrl.c; Hunk #2 FAILED at 334. This is due to RHEL not having incorporated the "PCIe cooling" driver (see upstream commit d278b098282d "thermal: Add PCIe cooling driver"). commit 15b8968dcb90f194d44501468b230e6e0d816d4a Author: Lukas Wunner <lukas@wunner.de> Date: Mon Jan 6 12:26:35 2025 +0100 PCI/bwctrl: Fix NULL pointer deref on unbind and bind The interrupt handler for bandwidth notifications, pcie_bwnotif_irq(), dereferences a "data" pointer. On unbind, that pointer is set to NULL by pcie_bwnotif_remove(). However the interrupt handler may still be invoked afterwards and will dereference that NULL pointer. That's because the interrupt is requested using a devm_*() helper and the driver core releases devm_*() resources *after* calling ->remove(). pcie_bwnotif_remove() does clear the Link Bandwidth Management Interrupt Enable and Link Autonomous Bandwidth Interrupt Enable bits in the Link Control Register, but that won't prevent execution of pcie_bwnotif_irq(): The interrupt for bandwidth notifications may be shared with AER, DPC, PME, and hotplug. So pcie_bwnotif_irq() may be executed as long as the interrupt is requested. There's a similar race on bind: pcie_bwnotif_probe() requests the interrupt when the "data" pointer still points to NULL. A NULL pointer deref may thus likewise occur if AER, DPC, PME or hotplug raise an interrupt in-between the bandwidth controller's call to devm_request_irq() and assignment of the "data" pointer. Drop the devm_*() usage and reorder requesting of the interrupt to fix the issue. While at it, drop a stray but harmless no_free_ptr() invocation when assigning the "data" pointer in pcie_bwnotif_probe(). Ilpo points out that the locking on unbind and bind needs to be symmetric, so move the call to pcie_bwnotif_disable() inside the critical section protected by pcie_bwctrl_setspeed_rwsem and pcie_bwctrl_lbms_rwsem. Evert reports a hang on shutdown of an ASUS ROG Strix SCAR 17 G733PYV. The issue is no longer reproducible with the present commit. Evert found that attaching a USB-C monitor prevented the hang. The machine contains an ASMedia USB 3.2 controller below a hotplug-capable Root Port. So one possible explanation is that the controller gets hot-removed on shutdown unless something is connected. And the ensuing hotplug interrupt occurs exactly when the bandwidth controller is unregistering. The precise cause could not be determined because the screen had already turned black when the hang occurred. Link: https://lore.kernel.org/r/ae2b02c9cfbefff475b6e132b0aa962aaccbd7b2.1736162539.git.lukas@wunner.de Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Reported-by:
Evert Vorster <evorster@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219629 Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Tested-by:
Evert Vorster <evorster@gmail.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Myron Stowe <mstowe@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6593 JIRA: https://issues.redhat.com/browse/RHEL-83858 Signed-off-by:
Paulo Alcantara <paalcant@redhat.com> Approved-by:
Jay Shin <jaeshin@redhat.com> Approved-by:
Benjamin Coddington <bcodding@redhat.com> Approved-by:
Scott Mayhew <smayhew@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6566 JIRA: https://issues.redhat.com/browse/RHEL-81542 Upstream Status: linux.git CVE: CVE-2025-21791 Signed-off-by:
Guillaume Nault <gnault@redhat.com> Approved-by:
Antoine Tenart <atenart@redhat.com> Approved-by:
Florian Westphal <fwestpha@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6599 JIRA: https://issues.redhat.com/browse/RHEL-74363 This patch is a backport of the following upstream commit: commit 67a2f86846f244d81601cf2e1552c4656b8556d6 Author: Rafael Aquini <raquini@redhat.com> Date: Tue Feb 18 14:22:51 2025 -0500 selftests/mm: run_vmtests.sh: fix half_ufd_size_MB calculation We noticed that uffd-stress test was always failing to run when invoked for the hugetlb profiles on x86_64 systems with a processor count of 64 or bigger: ... ... not ok 3 uffd-stress hugetlb 128 32 # exit=1 ... The problem boils down to how run_vmtests.sh (mis)calculates the size of the region it feeds to uffd-stress. The latter expects to see an amount of MiB while the former is just giving out the number of free hugepages halved down. This measurement discrepancy ends up violating uffd-stress' assertion on number of hugetlb pages allocated per CPU, causing it to bail out with the error above. This commit fixes that issue by adjusting run_vmtests.sh's half_ufd_size_MB calculation so it properly renders the region size in MiB, as expected, while maintaining all of its original constraints in place. Link: https://lkml.kernel.org/r/20250218192251.53243-1-aquini@redhat.com Fixes: 2e47a445d7b3 ("selftests/mm: run_vmtests.sh: fix hugetlb mem size calculation") Signed-off-by:
Rafael Aquini <raquini@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Rafael Aquini <raquini@redhat.com> Approved-by:
Nico Pache <npache@redhat.com> Approved-by:
Herton R. Krzesinski <herton@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6475 JIRA: https://issues.redhat.com/browse/RHEL-81489 CVE: CVE-2024-58005 ``` commit a3a860bc0fd6c07332e4911cf9a238d20de90173 Author: Jarkko Sakkinen <jarkko@kernel.org> Date: Fri Dec 27 17:39:09 2024 +0200 tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). Suggested-by:
Ard Biesheuvel <ardb@kernel.org> Cc: stable@vger.kernel.org # v2.6.16+ Fixes: 55a82ab3 ("[PATCH] tpm: add bios measurement log") Reported-by:
Andy Liang <andy.liang@hpe.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495 Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Stefan Berger <stefanb@linux.ibm.com> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
Andy Liang <andy.liang@hpe.com> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>```> Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com> --- <small>Created 2025-02-27 22:45 UTC by backporter - [KWF FAQ](https://red.ht/kernel_workflow_doc) - [Slack #team-kernel-workflow](https://redhat-internal.slack.com/archives/C04LRUPMJQ5) - [Source](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/webhook/utils/backporter.py) - [Documentation](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/docs/README.backporter.md) - [Report an issue](https://gitlab.com/cki-project/kernel-workflow/-/issues/new?issue%5Btitle%5D=backporter%20webhook%20issue)</small > Approved-by:
Štěpán Horáček <shoracek@redhat.com> Approved-by:
Jerry Snitselaar <jsnitsel@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6413 JIRA: https://issues.redhat.com/browse/RHEL-77838 Patches: `a1afb959add1f ("dpll: add clock quality level attribute and op") ` Signed-off-by:
Petr Oros <poros@redhat.com> Approved-by:
Ivan Vecera <ivecera@redhat.com> Approved-by:
Michal Schmidt <mschmidt@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6514 JIRA: https://issues.redhat.com/browse/RHEL-81929 commit 747ae81883d21595b162cc40523a982024700fed Author: Joachim Vandersmissen <git@jvdsn.com> Date: Sun May 12 23:55:07 2024 -0500 certs: Add ECDSA signature verification self-test Commit c27b2d2012e1 ("crypto: testmgr - allow ecdsa-nist-p256 and -p384 in FIPS mode") enabled support for ECDSA in crypto/testmgr.c. The PKCS#7 signature verification API builds upon the KCAPI primitives to perform its high-level operations. Therefore, this change in testmgr.c also allows ECDSA to be used by the PKCS#7 signature verification API (in FIPS mode). However, from a FIPS perspective, the PKCS#7 signature verification API is a distinct "service" from the KCAPI primitives. This is because the PKCS#7 API performs a "full" signature verification, which consists of both hashing the data to be verified, and the public key operation. On the other hand, the KCAPI primitive does not perform this hashing step - it accepts pre-hashed data from the caller and only performs the public key operation. For this reason, the ECDSA self-tests in crypto/testmgr.c are not sufficient to cover ECDSA signature verification offered by the PKCS#7 API. This is reflected by the self-test already present in this file for RSA PKCS#1 v1.5 signature verification. The solution is simply to add a second self-test here for ECDSA. P-256 with SHA-256 hashing was chosen as those parameters should remain FIPS-approved for the foreseeable future, while keeping the performance impact to a minimum. The ECDSA certificate and PKCS#7 signed data was generated using OpenSSL. The input data is identical to the input data for the existing RSA self-test. Signed-off-by:
Joachim Vandersmissen <git@jvdsn.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Herbert Xu <herbert.xu@redhat.com> Approved-by:
Vladis Dronov <vdronov@redhat.com> Approved-by:
Coiby Xu <coxu@redhat.com> Approved-by:
Clemens Lang <cllang@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6547 Description: Updates for powerpc perf mem data JIRA: https://issues.redhat.com/browse/RHEL-80602 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66923908 Tested: Verified Brew build test kernel RPMs Signed-off-by:
Mamatha Inamdar <minamdar@redhat.com> Approved-by:
Steve Best <sbest@redhat.com> Approved-by:
Tony Camuso <tcamuso@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6390 JIRA: https://issues.redhat.com/browse/RHEL-79821 The following upstream commits were not applied due to scope: 66bc1a173328 treewide: Use sysfs_bin_attr_simple_read() helper 4a62d588a84e thermal: core: Eliminate writable trip points masks dd64594ca2c5 thermal: Switch back to struct platform_driver::remove() cdd30ebb1b9f module: Convert symbol namespace to string literal Upstream commit 423de5b5bc5b is included in this patchset as it provides a fix for upstream 94c6110b0b13 which was included in a recent update to drivers/thermal Signed-off-by:
David Arcari <darcari@redhat.com> Approved-by:
Steve Best <sbest@redhat.com> Approved-by:
Tony Camuso <tcamuso@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6615 ``` JIRA: https://issues.redhat.com/browse/RHEL-81906 This series includes a set of key fixes related to PCIe's bandwidth link training from upstream v6.13 by taking in content from upstream merge request d957ff7acaf2 "Merge branch 'pci/bwctrl'". Signed-off-by:
Myron Stowe <mstowe@redhat.com> ``` Approved-by:
John W. Linville <linville@redhat.com> Approved-by:
Desnes Nunes <desnesn@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Approved-by:
Tony Camuso <tcamuso@redhat.com> Merged-by:
Augusto Caringi <acaringi@redhat.com>
-
Augusto Caringi authored
Signed-off-by:
Augusto Caringi <acaringi@redhat.com>
-
Dorinda Bassey authored
JIRA: https://issues.redhat.com/browse/RHEL-75561 Disable The IPsec Protocols and XFRM (IPSec) Networking Security Hooks and it's related dependencies. CONFIG_XFRM_* has a dependency on CONFIG_INET_*, CONFIG_IPV6 and CONFIG_NET_KEY. Hence, the following: CONFIG_INET_AH CONFIG_INET_ESP CONFIG_INET_IPCOMP CONFIG_NET_IPVTI CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_INET6_IPCOMP CONFIG_IPV6_VTI CONFIG_IPV6_MIP6 needs to be disabled in automotive. Upstream status: kernel-ark.git commit 75bff0bf3e67 commit 75bff0bf3e675bafb4e5039092ba3188788f9e10 Author: Dorinda Bassey <dbassey@redhat.com> Date: Tue Jan 21 18:43:28 2025 +0100 redhat/configs: automotive: Disable IPsec Protocols and XFRM Upstream Status: RHEL only Disable The IPsec Protocols and XFRM (IPSec) Networking Security Hooks and it's related dependencies. CONFIG_XFRM_* has a dependency on CONFIG_INET_* and CONFIG_IPV6. Hence, the following: CONFIG_INET_AH CONFIG_INET_ESP CONFIG_INET_IPCOMP CONFIG_NET_IPVTI CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_INET6_IPCOMP CONFIG_IPV6_VTI CONFIG_IPV6_MIP6 needs to be disabled in automotive. This is needed to satisfy a requirement of FuSa efforts for RHIVOS. Link: https://issues.redhat.com/browse/RHEL-75561 Signed-off-by:
Dorinda Bassey <dbassey@redhat.com> Signed-off-by:
Dorinda Bassey <dbassey@redhat.com>
-
Scott Weaver authored
kernel-5.14.0-575.el9 Signed-off-by:
Scott Weaver <scweaver@redhat.com>
-
Scott Weaver authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6568 JIRA: https://issues.redhat.com/browse/RHEL-83275 Upstream-status: RHEL-only The vxcan module is a software-only CAN bus driver that implements CAN bus interface pairs. It is similar to veth but for CAN bus. The main application is to test the various CAN bus protocol layers without requiring real CAN bus hardware. Signed-off-by:
Radu Rendec <rrendec@redhat.com> Approved-by:
Jared Kangas <jkangas@redhat.com> Approved-by:
Eric Chanudet <echanude@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Scott Weaver <scweaver@redhat.com>
-
Scott Weaver authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6533 re-enable CONFIG_AIO in rhel9 automotive JIRA: https://issues.redhat.com/browse/RHEL-82474 Resolves: RHEL-82474 Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Approved-by:
Brian Masney <bmasney@redhat.com> Approved-by:
Eric Chanudet <echanude@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Scott Weaver <scweaver@redhat.com>
-
Scott Weaver authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/6238 # Merge Request Required Information ## Summary of Changes Disable The IPsec Protocols and XFRM (IPSec) Networking Security Hooks and it's related dependencies. CONFIG_XFRM\_\* has a dependency on CONFIG_INET\_\* and CONFIG_IPV6. Hence, the following: CONFIG_INET_AH CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_INET6_IPCOMP CONFIG_INET6_XFRM_TUNNEL CONFIG_NET_KEY needs to be disabled in automotive. This is needed to satisfy a requirement of FuSa efforts for RHIVOS. ## Approved Development Ticket(s) JIRA: https://issues.redhat.com/browse/RHEL-75561 Upstream-status: RHEL-only: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3617 Signed-off-by:
Dorinda Bassey <dbassey@redhat.com> <details><summary>Click for formatting instructions</summary> Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/ ) for how to file this ticket and have it approved. List tickets each on their own line of this description using the format "Resolves: RHEL-1234", "Related: RHEL-2345" or "Reverts: RHEL-3456", as appropriate. </details> Approved-by:
Jiri Benc <jbenc@redhat.com> Approved-by:
Brian Masney <bmasney@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
Scott Weaver <scweaver@redhat.com>
-
Scott Weaver authored
Signed-off-by:
Scott Weaver <scweaver@redhat.com>
Showing
- Documentation/PCI/pciebus-howto.rst 9 additions, 5 deletionsDocumentation/PCI/pciebus-howto.rst
- Documentation/netlink/specs/dpll.yaml 41 additions, 0 deletionsDocumentation/netlink/specs/dpll.yaml
- MAINTAINERS 6 additions, 0 deletionsMAINTAINERS
- Makefile.rhelver 2 additions, 2 deletionsMakefile.rhelver
- arch/powerpc/perf/core-book3s.c 20 additions, 0 deletionsarch/powerpc/perf/core-book3s.c
- arch/powerpc/perf/isa207-common.c 15 additions, 3 deletionsarch/powerpc/perf/isa207-common.c
- arch/x86/include/asm/intel-family.h 0 additions, 1 deletionarch/x86/include/asm/intel-family.h
- arch/x86/include/asm/topology.h 0 additions, 5 deletionsarch/x86/include/asm/topology.h
- arch/x86/platform/efi/quirks.c 1 addition, 2 deletionsarch/x86/platform/efi/quirks.c
- arch/x86/platform/intel-quark/imr.c 1 addition, 1 deletionarch/x86/platform/intel-quark/imr.c
- arch/x86/platform/intel-quark/imr_selftest.c 1 addition, 1 deletionarch/x86/platform/intel-quark/imr_selftest.c
- certs/Kconfig 26 additions, 0 deletionscerts/Kconfig
- certs/Makefile 21 additions, 0 deletionscerts/Makefile
- crypto/asymmetric_keys/Kconfig 17 additions, 2 deletionscrypto/asymmetric_keys/Kconfig
- crypto/asymmetric_keys/Makefile 4 additions, 1 deletioncrypto/asymmetric_keys/Makefile
- crypto/asymmetric_keys/pkcs7_parser.c 8 additions, 0 deletionscrypto/asymmetric_keys/pkcs7_parser.c
- crypto/asymmetric_keys/pkcs7_verify.c 1 addition, 0 deletionscrypto/asymmetric_keys/pkcs7_verify.c
- crypto/asymmetric_keys/selftest.c 38 additions, 190 deletionscrypto/asymmetric_keys/selftest.c
- crypto/asymmetric_keys/selftest.h 22 additions, 0 deletionscrypto/asymmetric_keys/selftest.h
- crypto/asymmetric_keys/selftest_ecdsa.c 88 additions, 0 deletionscrypto/asymmetric_keys/selftest_ecdsa.c
crypto/asymmetric_keys/selftest.h
0 → 100644
crypto/asymmetric_keys/selftest_ecdsa.c
0 → 100644