lib/crc: remove CONFIG_LIBCRC32C

Now that LIBCRC32C does nothing besides select CRC32, make every option
that selects LIBCRC32C instead select CRC32 directly. Then remove
LIBCRC32C.

Reviewed-by: C

lib/crc: remove CONFIG_LIBCRC32C

Now that LIBCRC32C does nothing besides select CRC32, make every option
that selects LIBCRC32C instead select CRC32 directly. Then remove
LIBCRC32C.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: document all the CRC library kconfig options

Previous commits removed all the original CRC kconfig help text, since
it was oriented towards people configuring the kernel, and the options
ar

lib/crc: document all the CRC library kconfig options

Previous commits removed all the original CRC kconfig help text, since
it was oriented towards people configuring the kernel, and the options
are no longer user-selectable. However, it's still useful for there to
be help text for kernel developers. Add this.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC_ITU_T

All modules that need CONFIG_CRC_ITU_T already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwi

lib/crc: remove unnecessary prompt for CONFIG_CRC_ITU_T

All modules that need CONFIG_CRC_ITU_T already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC_T10DIF

All modules that need CONFIG_CRC_T10DIF already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hell

lib/crc: remove unnecessary prompt for CONFIG_CRC_T10DIF

All modules that need CONFIG_CRC_T10DIF already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC16

All modules that need CONFIG_CRC16 already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwig <hch@l

lib/crc: remove unnecessary prompt for CONFIG_CRC16

All modules that need CONFIG_CRC16 already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC_CCITT

All modules that need CONFIG_CRC_CCITT already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwi

lib/crc: remove unnecessary prompt for CONFIG_CRC_CCITT

All modules that need CONFIG_CRC_CCITT already select it, so there is no
need to bother users about the option.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC32 and drop 'default y'

All modules that need CONFIG_CRC32 already select it, so there is no
need to bother users about the option, nor to default it

lib/crc: remove unnecessary prompt for CONFIG_CRC32 and drop 'default y'

All modules that need CONFIG_CRC32 already select it, so there is no
need to bother users about the option, nor to default it to y.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC64

All modules that need CONFIG_CRC64 already select it, so there is no
need to bother users about the option.

Acked-by: Ard Biesheuvel <ardb@kernel

lib/crc: remove unnecessary prompt for CONFIG_CRC64

All modules that need CONFIG_CRC64 already select it, so there is no
need to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_LIBCRC32C

All modules that need CONFIG_LIBCRC32C already select it, so there is no
need to bother users about the option.

Acked-by: Ard Biesheuvel <ard

lib/crc: remove unnecessary prompt for CONFIG_LIBCRC32C

All modules that need CONFIG_LIBCRC32C already select it, so there is no
need to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC8

All modules that need CONFIG_CRC8 already select it, so there is no need
to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]

lib/crc: remove unnecessary prompt for CONFIG_CRC8

All modules that need CONFIG_CRC8 already select it, so there is no need
to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC7

All modules that need CONFIG_CRC7 already select it, so there is no need
to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]

lib/crc: remove unnecessary prompt for CONFIG_CRC7

All modules that need CONFIG_CRC7 already select it, so there is no need
to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: remove unnecessary prompt for CONFIG_CRC4

All modules that need CONFIG_CRC4 already select it, so there is no need
to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]

lib/crc: remove unnecessary prompt for CONFIG_CRC4

All modules that need CONFIG_CRC4 already select it, so there is no need
to bother users about the option.

Acked-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc64: add support for arch-optimized implementations

Add support for architecture-optimized implementations of the CRC64
library functions, following the approach taken for the CRC32 and
CRC-T1

lib/crc64: add support for arch-optimized implementations

Add support for architecture-optimized implementations of the CRC64
library functions, following the approach taken for the CRC32 and
CRC-T10DIF library functions.

Also take the opportunity to tweak the function prototypes:
- Use 'const void *' for the lib entry points (since this is easier for
users) but 'const u8 *' for the underlying arch and generic functions
(since this is easier for the implementations of these functions).
- Don't bother with __pure. It's an unusual optimization that doesn't
help properly written code. It's a weird quirk we can do without.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Keith Busch <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc64-rocksoft: stop wrapping the crypto API

Following what was done for the CRC32 and CRC-T10DIF library functions,
get rid of the pointless use of the crypto API and make
crc64_rocksoft_update

lib/crc64-rocksoft: stop wrapping the crypto API

Following what was done for the CRC32 and CRC-T10DIF library functions,
get rid of the pointless use of the crypto API and make
crc64_rocksoft_update() call into the library directly. This is faster
and simpler.

Remove crc64_rocksoft() (the version of the function that did not take a
'crc' argument) since it is unused.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: "Martin K. Petersen" <[email protected]>
Acked-by: Keith Busch <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc32: remove other generic implementations

Now that we've standardized on the byte-by-byte implementation of CRC32
as the only generic implementation (see previous commit for the
rationale), re

lib/crc32: remove other generic implementations

Now that we've standardized on the byte-by-byte implementation of CRC32
as the only generic implementation (see previous commit for the
rationale), remove the code for the other implementations.

Tested with crc_kunit.

Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc: simplify the kconfig options for CRC implementations

Make the following simplifications to the kconfig options for choosing
CRC implementations for CRC32 and CRC_T10DIF:

1. Make the option

lib/crc: simplify the kconfig options for CRC implementations

Make the following simplifications to the kconfig options for choosing
CRC implementations for CRC32 and CRC_T10DIF:

1. Make the option to disable the arch-optimized code be visible only
when CONFIG_EXPERT=y.
2. Make a single option control the inclusion of the arch-optimized code
for all enabled CRC variants.
3. Make CRC32_SARWATE (a.k.a. slice-by-1 or byte-by-byte) be the only
generic CRC32 implementation.

The result is there is now just one option, CRC_OPTIMIZATIONS, which is
default y and can be disabled only when CONFIG_EXPERT=y.

Rationale:

1. Enabling the arch-optimized code is nearly always the right choice.
However, people trying to build the tiniest kernel possible would
find some use in disabling it. Anything we add to CRC32 is de facto
unconditional, given that CRC32 gets selected by something in nearly
all kernels. And unfortunately enabling the arch CRC code does not
eliminate the need to build the generic CRC code into the kernel too,
due to CPU feature dependencies. The size of the arch CRC code will
also increase slightly over time as more CRC variants get added and
more implementations targeting different instruction set extensions
get added. Thus, it seems worthwhile to still provide an option to
disable it, but it should be considered an expert-level tweak.

2. Considering the use case described in (1), there doesn't seem to be
sufficient value in making the arch-optimized CRC code be
independently configurable for different CRC variants. Note also
that multiple variants were already grouped together, e.g.
CONFIG_CRC32 actually enables three different variants of CRC32.

3. The bit-by-bit implementation is uselessly slow, whereas slice-by-n
for n=4 and n=8 use tables that are inconveniently large: 4096 bytes
and 8192 bytes respectively, compared to 1024 bytes for n=1. Higher
n gives higher instruction-level parallelism, so higher n easily wins
on traditional microbenchmarks on most CPUs. However, the larger
tables, which are accessed randomly, can be harmful in real-world
situations where the dcache may be cold or useful data may need be
evicted from the dcache. Meanwhile, today most architectures have
much faster CRC32 implementations using dedicated CRC32 instructions
or carryless multiplication instructions anyway, which make the
generic code obsolete in most cases especially on long messages.

Another reason for going with n=1 is that this is already what is
used by all the other CRC variants in the kernel. CRC32 was unique
in having support for larger tables. But as per the above this can
be considered an outdated optimization.

The standardization on slice-by-1 a.k.a. CRC32_SARWATE makes much of
the code in lib/crc32.c unused. A later patch will clean that up.

Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc32test: delete obsolete crc32test.c

Delete crc32test.c, since it has been superseded by crc_kunit.c.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <martin.pet

lib/crc32test: delete obsolete crc32test.c

Delete crc32test.c, since it has been superseded by crc_kunit.c.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]> # m68k
Cc: Vinicius Peixoto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc-t10dif: add support for arch overrides

Following what was done for CRC32, add support for architecture-specific
override of the CRC-T10DIF library. This will allow the CRC-T10DIF
library fu

lib/crc-t10dif: add support for arch overrides

Following what was done for CRC32, add support for architecture-specific
override of the CRC-T10DIF library. This will allow the CRC-T10DIF
library functions to access architecture-optimized code directly.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc-t10dif: stop wrapping the crypto API

In preparation for making the CRC-T10DIF library directly optimized for
each architecture, like what has been done for CRC32, get rid of the
weird layeri

lib/crc-t10dif: stop wrapping the crypto API

In preparation for making the CRC-T10DIF library directly optimized for
each architecture, like what has been done for CRC32, get rid of the
weird layering where crc_t10dif_update() calls into the crypto API.
Instead, move crc_t10dif_generic() into the crc-t10dif library module,
and make crc_t10dif_update() just call crc_t10dif_generic().
Acceleration will be reintroduced via crc_t10dif_arch() in the following
patches.

Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc32: make crc32c() go directly to lib

Now that the lower level __crc32c_le() library function is optimized for
each architecture, make crc32c() just call that instead of taking an
inefficient

lib/crc32: make crc32c() go directly to lib

Now that the lower level __crc32c_le() library function is optimized for
each architecture, make crc32c() just call that instead of taking an
inefficient and error-prone detour through the shash API.

Note: a future cleanup should make crc32c_le() be the actual library
function instead of __crc32c_le(). That will require updating callers
of __crc32c_le() to use crc32c_le() instead, and updating callers of
crc32c_le() that expect a 'const void *' arg to expect 'const u8 *'
instead. Similarly, a future cleanup should remove LIBCRC32C by making
everyone who is selecting it just select CRC32 directly instead.

Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/crc32: improve support for arch-specific overrides

Currently the CRC32 library functions are defined as weak symbols, and
the arm64 and riscv architectures override them.

This method of arch-sp

lib/crc32: improve support for arch-specific overrides

Currently the CRC32 library functions are defined as weak symbols, and
the arm64 and riscv architectures override them.

This method of arch-specific overrides has the limitation that it only
works when both the base and arch code is built-in. Also, it makes the
arch-specific code be silently not used if it is accidentally built with
lib-y instead of obj-y; unfortunately the RISC-V code does this.

This commit reorganizes the code to have explicit *_arch() functions
that are called when they are enabled, similar to how some of the crypto
library code works (e.g. chacha_crypt() calls chacha_crypt_arch()).

Make the existing kconfig choice for the CRC32 implementation also
control whether the arch-optimized implementation (if one is available)
is enabled or not. Make it enabled by default if CRC32 is also enabled.

The result is that arch-optimized CRC32 library functions will be
included automatically when appropriate, but it is now possible to
disable them. They can also now be built as a loadable module if the
CRC32 library functions happen to be used only by loadable modules, in
which case the arch and base CRC32 modules will be automatically loaded
via direct symbol dependency when appropriate.

Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Eric Biggers <[email protected]>

show more ...

lib/min_heap: introduce non-inline versions of min heap API functions

Patch series "Enhance min heap API with non-inline functions and
optimizations", v2.

Add non-inline versions of the min heap AP

lib/min_heap: introduce non-inline versions of min heap API functions

Patch series "Enhance min heap API with non-inline functions and
optimizations", v2.

Add non-inline versions of the min heap API functions in lib/min_heap.c
and updates all users outside of kernel/events/core.c to use these
non-inline versions. To mitigate the performance impact of indirect
function calls caused by the non-inline versions of the swap and compare
functions, a builtin swap has been introduced that swaps elements based on
their size. Additionally, it micro-optimizes the efficiency of the min
heap by pre-scaling the counter, following the same approach as in
lib/sort.c. Documentation for the min heap API has also been added to the
core-api section.


This patch (of 10):

All current min heap API functions are marked with '__always_inline'.
However, as the number of users increases, inlining these functions
everywhere leads to a increase in kernel size.

In performance-critical paths, such as when perf events are enabled and
min heap functions are called on every context switch, it is important to
retain the inline versions for optimal performance. To balance this, the
original inline functions are kept, and additional non-inline versions of
the functions have been added in lib/min_heap.c.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lore.kernel.org/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Suggested-by: Andrew Morton <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Ching-Chun (Jim) Huang <[email protected]>
Cc: Coly Li <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Kuan-Wei Chiu <[email protected]>
Cc: "Liang, Kan" <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Matthew Sakai <[email protected]>
Cc: Matthew Wilcox (Oracle) <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

lib/Makefile: make union-find compilation conditional on CONFIG_CPUSETS

Currently, cpuset is the only user of the union-find implementation.
Compiling union-find in all configurations unnecessarily

lib/Makefile: make union-find compilation conditional on CONFIG_CPUSETS

Currently, cpuset is the only user of the union-find implementation.
Compiling union-find in all configurations unnecessarily increases the
code size when building the kernel without cgroup support. Modify the
build system to compile union-find only when CONFIG_CPUSETS is enabled.

Link: https://lore.kernel.org/lkml/[email protected]/
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Suggested-by: Waiman Long <[email protected]>
Acked-by: Waiman Long <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Cc: Ching-Chun (Jim) Huang <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Michal Koutný <[email protected]>
Cc: Xavier <[email protected]>
Cc: Zefan Li <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

lib: packing: add KUnit tests adapted from selftests

Add 24 simple KUnit tests for the lib/packing.c pack() and unpack() APIs.

The first 16 tests exercise all combinations of quirks with a simple m

lib: packing: add KUnit tests adapted from selftests

Add 24 simple KUnit tests for the lib/packing.c pack() and unpack() APIs.

The first 16 tests exercise all combinations of quirks with a simple magic
number value on a 16-byte buffer. The remaining 8 tests cover
non-multiple-of-4 buffer sizes.

These tests were originally written by Vladimir as simple selftest
functions. I adapted them to KUnit, refactoring them into a table driven
approach. This will aid in adding additional tests in the future.

Co-developed-by: Vladimir Oltean <[email protected]>
Signed-off-by: Vladimir Oltean <[email protected]>
Signed-off-by: Jacob Keller <[email protected]>
Reviewed-by: Przemek Kitszel <[email protected]>
Reviewed-by: Vladimir Oltean <[email protected]>
Tested-by: Vladimir Oltean <[email protected]>
Link: https://patch.msgid.link/20241002-packing-kunit-tests-and-split-pack-unpack-v2-6-8373e551eae3@intel.com
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

dim: make DIMLIB dependent on NET

DIMLIB's capabilities are supplied by the dim, net_dim, and
rdma_dim objects, and dim's interfaces solely act as a base for
net_dim and rdma_dim and are not explici

dim: make DIMLIB dependent on NET

DIMLIB's capabilities are supplied by the dim, net_dim, and
rdma_dim objects, and dim's interfaces solely act as a base for
net_dim and rdma_dim and are not explicitly used anywhere else.
rdma_dim is utilized by the infiniband driver, while net_dim
is for network devices, excluding the soc/fsl driver.

In this patch, net_dim relies on some NET's interfaces, thus
DIMLIB needs to explicitly depend on the NET Kconfig.

The soc/fsl driver uses the functions provided by net_dim, so
it also needs to depend on NET.

Signed-off-by: Heng Qi <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...