Changes in debug_defconfig

3a47b1e3 - s390: Update defconfigs

Wed, 30 Apr 2025 14:41:01 +0000

s390: Update defconfigsJust the regular update of all defconfigs.Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/configs/debug_defconfig

d2b8111c - s390/configs: Enable options required for TC flow offload

Fri, 18 Apr 2025 15:20:15 +0000

s390/configs: Enable options required for TC flow offloadWhile testing Open vSwitch with Nvidia ConnectX-6 NIC, it was noticedthat it didn't offload TC flows into the NIC, and its log containedmany messages such as:"failed to offload flow: No such file or directory: "and, upon enabling more versose logging, additionally:"received NAK error=2 - TC classifier not found"The options enabled here are listed as requirements in Nvidia onlinedocumentation, among other options that were already enabled. Now alloptions listed by Nvidia are enabled..This option is also added because Fedora has it: CONFIG_NET_EMATCHSigned-off-by: Konstantin Shkolnyy Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/configs/debug_defconfig

0db8a9a9 - s390/configs: Enable VDPA on Nvidia ConnectX-6 network card

Fri, 18 Apr 2025 15:20:14 +0000

s390/configs: Enable VDPA on Nvidia ConnectX-6 network cardConnectX-6 is the first VDPA-capable NIC. For earlier NICs, Nvidiaimplements a VDPA emulation in s/w, which hasn't been validated on s390.Add options necessary for VDPA to work.These options are also added because Fedora has them: CONFIG_VDPA_SIM CONFIG_VDPA_SIM_NET CONFIG_VDPA_SIM_BLOCK CONFIG_VDPA_USER CONFIG_VP_VDPASigned-off-by: Konstantin Shkolnyy Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/configs/debug_defconfig

6df8bae8 - mm: zbud: remove zbud

Wed, 29 Jan 2025 18:06:32 +0000

mm: zbud: remove zbudThe zbud compressed pages allocator is rarely used, most users usezsmalloc. zbud consumes much more memory (only stores 1 or 2 compressedpages per physical page). The only advantage of zbud is a marginalperformance improvement that by no means justify the memory overhead.Historically, zsmalloc had significantly worse latency than zbud andz3fold but offered better memory savings. This is no longer the case asshown by a simple recent analysis [1]. In a kernel build test on tmpfs ina limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost ofusing ~32% more memory (1.5G vs 1.13G). The tradeoff does not make sensefor zbud in any practical scenario.The only alleged advantage of zbud is not having the dependency onCONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and zbudis only used by zswap.Remove zbud after z3fold's removal, leaving zsmalloc as the one and onlyzpool allocator. Leave the removal of the zpool API (and its associatedconfig options) to a followup cleanup after no more allocators show up.Deprecating zbud for a few cycles before removing it was initiallyproposed [2], like z3fold was marked as deprecated for 2 cycles [3]. However, Johannes rightfully pointed out that the 2 cycles is too shortfor most downstream consumers, and z3fold was deprecated first only as acourtesy anyway.[1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/[2]https://lore.kernel.org/lkml/Z5gdnSX5Lv-nfjQL@google.com/[3]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/Link: https://lkml.kernel.org/r/20250129180633.3501650-3-yosry.ahmed@linux.devSigned-off-by: Yosry Ahmed Reviewed-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Nhat Pham Cc: Alexander Gordeev Cc: Chengming Zhou Cc: Christian Borntraeger Cc: Dan Streetman Cc: Heiko Carstens Cc: Huacai Chen Cc: Miaohe Lin Cc: Seth Jennings Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vitaly Wool Cc: Vlastimil Babka Cc: WANG Xuerui Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/s390/configs/debug_defconfig

03544866 - s390/mm: Add configurable STRICT_MM_TYPECHECKS

Tue, 04 Mar 2025 08:14:33 +0000

s390/mm: Add configurable STRICT_MM_TYPECHECKSAdd support for configurable STRICT_MM_TYPECHECKS. The s390 ABI definesthat return values with complex types like structures and unions arereturned in a return value buffer allocated by the caller. This is alsotrue for small structures and unions which would fit into a register. Onthe other hand when such types are passed as arguments to functions theyare passed in registers, if they are small enough.This leads to inefficient code when such a return value of a function callis then passed as argument to a subsequent function call.This is especially true for all mm types, like pte_t and others, which areonly for type checking reasons defined as a structure. This however can bebypassed with the STRICT_MM_TYPECHECKS feature, which is used by a fewother architectures, which seem to have the same problem.Add CONFIG_STRICT_MM_TYPECHECKS which can be used to change the type ofpte_t and other structures. If the config option is not enabled the typesare defined to unsigned long, allowing for better code generation, howeverthere is no type checking anymore. If it is enabled the types arestructures like before so that type checking is performed, but lessefficient code is generated.The option is always enabled in debug_defconfig, and for convenience anmmtypes.config topic target is added, which allows to easily enable it, incase memory management code is changed.CONFIG_STRICT_MM_TYPECHECKS and STRICT_MM_TYPECHECKS are kept separate,since STRICT_MM_TYPECHECKS is common across architectures and commoncode. Therefore use the same define also for s390 code.Add CONFIG_STRICT_MM_TYPECHECKS to make it build time configurable.Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/configs/debug_defconfig

aa09b322 - lib/crc: remove unnecessary prompt for CONFIG_CRC8

Tue, 04 Mar 2025 23:07:10 +0000

lib/crc: remove unnecessary prompt for CONFIG_CRC8All modules that need CONFIG_CRC8 already select it, so there is no needto bother users about the option.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250304230712.167600-4-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/s390/configs/debug_defconfig

f5a40fcf - lib/crc: remove unnecessary prompt for CONFIG_CRC7

Tue, 04 Mar 2025 23:07:09 +0000

lib/crc: remove unnecessary prompt for CONFIG_CRC7All modules that need CONFIG_CRC7 already select it, so there is no needto bother users about the option.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250304230712.167600-3-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/s390/configs/debug_defconfig

7f36255f - lib/crc: remove unnecessary prompt for CONFIG_CRC4

Tue, 04 Mar 2025 23:07:08 +0000

lib/crc: remove unnecessary prompt for CONFIG_CRC4All modules that need CONFIG_CRC4 already select it, so there is no needto bother users about the option.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250304230712.167600-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/s390/configs/debug_defconfig

fa151887 - s390: Sort mcount locations at build time

Thu, 13 Feb 2025 12:57:33 +0000

s390: Sort mcount locations at build timeFor s390 the mcount_loc section of the kernel image contains the addressesof the mcount locations. All addresses will be adjusted with the sameoffset by the decompressor before the kernel is started.Therefore select HAVE_BUILDTIME_MCOUNT_SORT so that the entries of thissection are sorted at build time. Given that the same offset is applied toall entries the section will be sorted in any case.Note that this was not possible before commit 778666df60f0 ("s390: compilerelocatable kernel without -fPIE"). Since this commit all R_390_64 absoluterelocations are handled in a special way: only the address of the to bechanged location is put into a special section. For all those locations thesame offset is applied as described above.Without that change it would have been necessary to also adjust the addendof all relocations which correspond to the mcount_loc section, when sortingthe mcount_loc section.Reported-by: Steven Rostedt Closes: https://lore.kernel.org/r/20250210142647.083ff456@gandalf.local.home/Signed-off-by: Heiko Carstens Acked-by: Vasily Gorbik Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/configs/debug_defconfig

ed83aff5 - s390: Update defconfigs

Wed, 12 Feb 2025 11:01:15 +0000

s390: Update defconfigsSigned-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/configs/debug_defconfig

8d1d1e8d - s390/configs: Remove CONFIG_LSM

Thu, 30 Jan 2025 13:56:07 +0000

s390/configs: Remove CONFIG_LSMs390 defconfig does not have BPF LSM, resulting in systemd[1]: bpf-restrict-fs: BPF LSM hook not enabled in the kernel, BPF LSM not supported.with the respective kernels. The other architectures do not explicitlyset it, and the default values have BPF in them, so just drop it.Reported-by: Marc Hartmayer Acked-by: Vasily Gorbik Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/configs/debug_defconfig

730f67d8 - crypto: keywrap - remove unused keywrap algorithm

Fri, 27 Dec 2024 22:08:02 +0000

crypto: keywrap - remove unused keywrap algorithmThe keywrap (kw) algorithm has no in-tree user. It has never had anin-tree user, and the patch that added it provided no justification forits inclusion. Even use of it via AF_ALG is impossible, as it uses aweird calling convention where part of the ciphertext is returned viathe IV buffer, which is not returned to userspace in AF_ALG.It's also unclear whether any new code in the kernel that does keywrapping would actually use this algorithm. It is controversial in thecryptographic community due to having no clearly stated security goal,no security proof, poor performance, and only a 64-bit auth tag. Laterwork (https://eprint.iacr.org/2006/221) suggested that the goal isdeterministic authenticated encryption. But there are now more modernalgorithms for this, and this is not the same as key wrapping, for whicha regular AEAD such as AES-GCM usually can be (and is) used instead.Therefore, remove this unused code.There were several special cases for this algorithm in the self-tests,due to its weird calling convention. Remove those too.Cc: Stephan Mueller Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Geert Uytterhoeven # m68kSigned-off-by: Herbert Xu List of files: /linux-6.15/arch/s390/configs/debug_defconfig

2890601f - crypto: vmac - remove unused VMAC algorithm

Thu, 26 Dec 2024 19:43:08 +0000

crypto: vmac - remove unused VMAC algorithmRemove the vmac64 template, as it has no known users. It also continuesto have longstanding bugs such as alignment violations (seehttps://lore.kernel.org/r/20241226134847.6690-1-evepolonium@gmail.com/).This code was added in 2009 by commit f1939f7c5645 ("crypto: vmac - Newhash algorithm for intel_txt support"). Based on the mention ofintel_txt support in the commit title, it seems it was added as aprerequisite for the contemporaneous patch"intel_txt: add s3 userspace memory integrity verification"(https://lore.kernel.org/r/4ABF2B50.6070106@intel.com/). In the designproposed by that patch, when an Intel Trusted Execution Technology (TXT)enabled system resumed from suspend, the "tboot" trusted executablelaunched the Linux kernel without verifying userspace memory, and thenthe Linux kernel used VMAC to verify userspace memory.However, that patch was never merged, as reviewers had objected to thedesign. It was later reworked into commit 4bd96a7a8185 ("x86, tboot:Add support for S3 memory integrity protection") which made tboot verifythe memory instead. Thus the VMAC support in Linux was never used.No in-tree user has appeared since then, other than potentially theusual components that allow specifying arbitrary hash algorithms byname, namely AF_ALG and dm-integrity. However there are no indicationsthat VMAC is being used with these components. Debian Code Search andweb searches for "vmac64" (the actual algorithm name) do not return anyresults other than the kernel itself, suggesting that it does not appearin any other code or documentation. Explicitly grepping the source codeof the usual suspects (libell, iwd, cryptsetup) finds no matches either.Before 2018, the vmac code was also completely broken due to using ahardcoded nonce and the wrong endianness for the MAC. It was then fixedby commit ed331adab35b ("crypto: vmac - add nonced version with bigendian digest") and commit 0917b873127c ("crypto: vmac - remove insecureversion with hardcoded nonce"). These were intentionally breakingchanges that changed all the computed MAC values as well as thealgorithm name ("vmac" to "vmac64"). No complaints were ever receivedabout these breaking changes, strongly suggesting the absence of users.The reason I had put some effort into fixing this code in 2018 isbecause it was used by an out-of-tree driver. But if it is still neededin that particular out-of-tree driver, the code can be carried in thatdriver instead. There is no need to carry it upstream.Cc: Atharva Tiwari Cc: Shane Wang Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Geert Uytterhoeven # m68kSigned-off-by: Herbert Xu List of files: /linux-6.15/arch/s390/configs/debug_defconfig

87fe0a13 - lib/crc32test: delete obsolete crc32test.c

Mon, 02 Dec 2024 01:20:54 +0000

lib/crc32test: delete obsolete crc32test.cDelete crc32test.c, since it has been superseded by crc_kunit.c.Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Acked-by: Geert Uytterhoeven # m68kCc: Vinicius Peixoto Link: https://lore.kernel.org/r/20241202012056.209768-11-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/s390/configs/debug_defconfig

00807191 - s390/crc32: expose CRC32 functions through lib

Mon, 02 Dec 2024 01:08:34 +0000

s390/crc32: expose CRC32 functions through libMove the s390 CRC32 assembly code into the lib directory and wire it upto the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Note: to see the diff from arch/s390/crypto/crc32-vx.c toarch/s390/lib/crc32-glue.c, view this commit with 'git show -M10'.Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20241202010844.144356-10-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/s390/configs/debug_defconfig

5e91e2f0 - s390/configs: Enable CONFIG_VIRTIO_MEM

Mon, 04 Nov 2024 10:00:01 +0000

s390/configs: Enable CONFIG_VIRTIO_MEMSigned-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/configs/debug_defconfig

73dfc79c - s390/pkey: Add new pkey handler module pkey-uv

Fri, 25 Oct 2024 10:34:32 +0000

s390/pkey: Add new pkey handler module pkey-uvThis new pkey handler module supports the conversion ofUltravisor retrievable secrets to protected keys.The new module pkey-uv.ko is able to retrieve and verifyprotected keys backed up by the Ultravisor layer which isonly available within protected execution environment.The module is only automatically loaded if there is theUV CPU feature flagged as available. Additionally on moduleinit there is a check for protected execution environmentand for UV supporting retrievable secrets. Also if the kernelis not running as a protected execution guest, the moduleunloads itself with errno ENODEV.The pkey UV module currently supports these Ultravisorsecrets and is able to retrieve a protected key for theseUV secret types: - UV_SECRET_AES_128 - UV_SECRET_AES_192 - UV_SECRET_AES_256 - UV_SECRET_AES_XTS_128 - UV_SECRET_AES_XTS_256 - UV_SECRET_HMAC_SHA_256 - UV_SECRET_HMAC_SHA_512 - UV_SECRET_ECDSA_P256 - UV_SECRET_ECDSA_P384 - UV_SECRET_ECDSA_P521 - UV_SECRET_ECDSA_ED25519 - UV_SECRET_ECDSA_ED448Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/configs/debug_defconfig

b4fa00fd - s390: Update defconfigs

Mon, 14 Oct 2024 10:07:26 +0000

s390: Update defconfigsSigned-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/configs/debug_defconfig

f9b56b2c - s390: Enable KVM_S390_UCONTROL config in debug_defconfig

Wed, 07 Aug 2024 15:45:12 +0000

s390: Enable KVM_S390_UCONTROL config in debug_defconfigTo simplify testing enable UCONTROL KVM by default in debug kernels.Signed-off-by: Christoph Schlameuss Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20240807154512.316936-11-schlameuss@linux.ibm.comSigned-off-by: Janosch Frank Message-ID: <20240807154512.316936-11-schlameuss@linux.ibm.com> List of files: /linux-6.15/arch/s390/configs/debug_defconfig

8fcc231c - s390/pkey: Introduce pkey base with handler registry and handler modules

Thu, 22 Aug 2024 09:32:19 +0000

s390/pkey: Introduce pkey base with handler registry and handler modulesIntroduce pkey base kernel code with a simple pkey handler registry.Regroup the pkey code into these kernel modules:- pkey is the pkey api supporting the ioctls, sysfs and in-kernel api. Also the pkey base code which offers the handler registry and handler wrapping invocation functions is integrated there. This module is automatically loaded in via CPU feature if the MSA feature is available.- pkey-cca is the CCA related handler code kernel module a offering CCA specific implementation for pkey. This module is loaded in via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.- pkey-ep11 is the EP11 related handler code kernel module offering an EP11 specific implementation for pkey. This module is loaded in via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.- pkey-pckmo is the PCKMO related handler code kernel module. This module is loaded in via CPU feature if the MSA feature is available, but on init a check for availability of the pckmo instruction is performed.The handler modules register via a pkey_handler struct at the pkeybase code and the pkey customer (that is currently the pkey api codefetches a handler via pkey handler registry functions and calls theunified handler functions via the pkey base handler functions.As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules getindependent from each other and it becomes possible to write newhandlers which offer another kind of implementation without implicitdependencies to other handler implementations and/or kernel devicedrivers.For each of these 4 kernel modules there is an individual Kconfigentry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEYCCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler andCONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handlermodules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt apiof the zcrypt device driver.Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/configs/debug_defconfig