Use SHA-1 library instead of crypto_shash
> drm/bridge: it6505: Use SHA-1 library instead of crypto_shash
> nfc: s3fwrn5: Use SHA-1 library instead of crypto_shash
> ppp: mppe: Use SHA-1 library instead of crypto_shash
> KEYS: trusted_tpm1: Use SHA-1 library instead of crypto_shash
> ipv6: Switch to higher-level SHA-1 functions
> lib/crypto: sha1: Remove low-level functions from API
>
...
> 92 files changed, 1472 insertions(+), 2474 deletions(-)
Again, the diffstat speaks for itself.
For the series,
Reviewed-by: Ard Biesheuvel
drivers
> lib/crypto: sha256: Remove sha256_is_arch_optimized()
> lib/crypto: sha256: Consolidate into single module
> lib/crypto: sha256: Sync sha256_update() with sha512_update()
> lib/crypto: sha256: Document the SHA-224 and SHA-256 API
>
Acked-by: Ard Biesheuvel
> arch/mip
rpc: move arch/powerpc/lib/crypto/ into lib/crypto/
> lib/crypto: riscv: move arch/riscv/lib/crypto/ into lib/crypto/
> lib/crypto: s390: move arch/s390/lib/crypto/ into lib/crypto/
> lib/crypto: sparc: move arch/sparc/lib/crypto/ into lib/crypto/
> lib/crypto: x86: move arch/x86/lib/crypto/ into lib/crypto/
> MAINTAINERS: drop arch/*/lib/crypto/ pattern
>
For the series,
Acked-by: Ard Biesheuvel
sha256-armv4.pl (100%)
> rename arch/arm/{crypto/sha2-ce-core.S => lib/crypto/sha256-ce.S} (91%)
> create mode 100644 arch/arm/lib/crypto/sha256.c
>
Reviewed-by: Ard Biesheuvel
4/crypto/sha256-glue.c | 19 ++-
> 1 file changed, 2 insertions(+), 17 deletions(-)
>
Reviewed-by: Ard Biesheuvel
11 files changed, 98 insertions(+), 355 deletions(-)
> delete mode 100644 arch/arm64/crypto/sha2-ce-glue.c
> delete mode 100644 arch/arm64/crypto/sha256-glue.c
> rename arch/arm64/{crypto/sha512-armv8.pl => lib/crypto/sha2-armv8.pl} (100%)
> rename arch/arm64/{crypto/sha2-ce-core.S => lib/crypto/sha256-ce.S} (80%)
> create mode 100644 arch/arm64/lib/crypto/sha256.c
>
Reviewed-by: Ard Biesheuvel
glue" from filenames
> arm64/crc: drop "glue" from filenames
> powerpc/crc: drop "glue" from filenames
> powerpc/crc: rename crc32-vpmsum_core.S to crc-vpmsum-template.S
> s390/crc: drop "glue" from filenames
> sparc/crc: drop "glue"
CRYPTO dependency of library functions
> crypto: lib/chacha - remove INTERNAL symbol and selection of CRYPTO
> crypto: lib/poly1305 - remove INTERNAL symbol and selection of CRYPTO
>
This seems like a good idea.
Acked-by: Ard Biesheuvel
+-
> arch/x86/lib/crc-t10dif-glue.c | 2 +-
> arch/x86/lib/crc32-glue.c| 4 ++--
> arch/x86/lib/crc64-glue.c | 2 +-
> 12 files changed, 16 insertions(+), 16 deletions(-)
>
Acked-by: Ard Biesheuvel
> diff --git a/arch/arm/lib/crc-t10dif-glue.c b/arch/arm
On Sun, 23 Mar 2025 at 18:12, Eric Biggers wrote:
>
> On Sun, Mar 23, 2025 at 04:35:29PM +0100, Ard Biesheuvel wrote:
> > On Sat, 22 Mar 2025 at 15:33, Guenter Roeck wrote:
> > >
> > > Hi,
> > >
> > > On Sun, Dec 01, 2024 at 05:20:52PM -0800
implemented by a CRC variant.
> > - Optional benchmark of each CRC function with various data lengths.
> >
> > This is intended as a replacement for crc32test and crc16_kunit, as well
> > as a new test for CRC variants which didn't previously have a test.
> >
>
On Tue, 11 Mar 2025 at 06:56, Mike Rapoport wrote:
>
> On Fri, Mar 07, 2025 at 04:28:15PM +0100, Heiko Carstens wrote:
> > On Thu, Mar 06, 2025 at 08:51:17PM +0200, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)"
> > >
> > > Allocating the zero pages from memblock is simpler because
On Wed, 22 Jan 2025 at 13:25, Joel Granados wrote:
>
> On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> >
> > Hi Joel,
> >
> > > Add the const qualifier to all the ctl_tables in the tree except for
> > > watchdo
for CRC library functions
> lib/crc32test: delete obsolete crc32test.c
> powerpc/crc: delete obsolete crc-vpmsum_test.c
> MAINTAINERS: add entry for CRC library
>
Nice work. The shash API glue was particularly nasty, so good riddance.
For the series,
Reviewed-by: Ard Biesheuvel
Happy to take a R: or M: as well, if you need the help.
hack of parsing
> the driver name. This change still makes sense either way though.)
>
> Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
> ---
> crypto/crc32_generic.c | 8 ++--
> crypto/crc32c_generic.c | 8 ++--
> 2 files changed, 12 insertions(+), 4
to determine whether the crc32[c]-$arch shash
> algorithms should be registered in the crypto API. btrfs could also
> start using these flags instead of the hack that it currently uses where
> it parses the crypto_shash_driver_name.
>
> Signed-off-by: Eric Biggers
Reviewed-by: A
On Sat, 2 Nov 2024 at 17:36, Eric Biggers wrote:
>
> On Sat, Nov 02, 2024 at 07:08:43PM +0800, Herbert Xu wrote:
> > On Sat, Nov 02, 2024 at 12:05:01PM +0100, Ard Biesheuvel wrote:
> > >
> > > The only issue resulting from *not* taking this patch is that btrfs
&
On Sat, 2 Nov 2024 at 11:46, Ard Biesheuvel wrote:
>
> On Sat, 2 Nov 2024 at 11:20, Herbert Xu wrote:
> >
> > On Sat, Nov 02, 2024 at 10:58:53AM +0100, Ard Biesheuvel wrote:
> > >
> > > At least btrfs supports a variety of checksums/hashes (crc32c,
On Sat, 2 Nov 2024 at 11:20, Herbert Xu wrote:
>
> On Sat, Nov 02, 2024 at 10:58:53AM +0100, Ard Biesheuvel wrote:
> >
> > At least btrfs supports a variety of checksums/hashes (crc32c, xxhash,
> > sha) via the shash API.
>
> OK, given that btrfs is still doing
On Sat, 2 Nov 2024 at 10:45, Herbert Xu wrote:
>
> Eric Biggers wrote:
> >
> > While testing this patchset I notice that none of the crypto API drivers for
> > crc32 or crc32c even need to be loaded on my system anymore, as everything
> > on my
> > system that uses those algorithms (such as ext4
On Sat, 26 Oct 2024 at 06:10, Eric Biggers wrote:
>
> On Fri, Oct 25, 2024 at 10:02:39PM +, Eric Biggers wrote:
> > On Fri, Oct 25, 2024 at 10:47:15PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote:
> > >
r, and it improves
> performance due to eliminating the crypto API overhead.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
> ---
> drivers/target/iscsi/Kconfig | 2 +-
> drivers/target/iscsi/iscsi_target.c | 153 +++---
> dr
On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Make the CRC32 library export some flags that indicate which CRC32
> functions are actually executing optimized code at runtime. Set these
> correctly from the architectures that implement the CRC32 functions.
>
> This
On Fri, 25 Oct 2024 at 23:32, Eric Biggers wrote:
>
> On Fri, Oct 25, 2024 at 10:32:14PM +0200, Ard Biesheuvel wrote:
> > On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > > Make the CRC32 lib
On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Instead of registering the crc32-$arch and crc32c-$arch algorithms if
> the arch-specific code was built, only register them when that code was
> built *and* is not falling back to the base implementation at runtime.
>
>
()
> x86/crc32: update prototype for crc32_pclmul_le_16()
> x86/crc32: expose CRC32 functions through lib
> lib/crc32: make crc32c() go directly to lib
> ext4: switch to using the crc32c library
> jbd2: switch to using the crc32c library
> f2fs: switch to using the crc32 library
>
...
> 89 files changed, 1002 insertions(+), 2455 deletions(-)
Very nice cleanup!
For the series:
Reviewed-by: Ard Biesheuvel
Hi Mike,
On Mon, 9 Sept 2024 at 08:51, Mike Rapoport wrote:
>
> From: "Mike Rapoport (Microsoft)"
>
> Using large pages to map text areas reduces iTLB pressure and improves
> performance.
>
> Extend execmem_alloc() with an ability to use huge pages with ROX
> permissions as a cache for smaller a
memcpy() and memset(), so that
explicit trivial calls will no longer be elided and replaced with
plain loads and stores (as it can no longer guarantee the equivalence)
> (This isn't a new problem, originally it showed up as "GCC replaces
> (part of) my memcpy() implementation by a (
(cc Arnd)
On Thu, 11 Apr 2024 at 03:11, Samuel Holland wrote:
>
> Hi Thiago,
>
> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> > Samuel Holland writes:
> >> On 2024-04-10 5:21 PM, Thiago Jung Bauermann wrote:
> >>>
> >>> Unfortunately this patch causes build failures on arm with allyesco
s Wunner (2):
> sysfs: Add sysfs_bin_attr_simple_read() helper
> treewide: Use sysfs_bin_attr_simple_read() helper
>
Acked-by: Ard Biesheuvel
> arch/powerpc/platforms/powernv/opal.c | 10 +---
> drivers/acpi/bgrt.c|
On Tue, 13 Feb 2024 at 15:05, David Hildenbrand wrote:
>
> On 13.02.24 15:02, Ryan Roberts wrote:
> > On 13/02/2024 13:45, David Hildenbrand wrote:
> >> On 13.02.24 14:33, Ard Biesheuvel wrote:
> >>> On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
> &g
ng … -> init_pte:
> >>>> * __ptep_get()
> >>>> * __set_pte()
> >>>> * efi_memattr_apply_permissions -> efi_set_mapping_permissions … ->
> >>>> set_permissions
> >>>> * __ptep_get()
> >>&
On Fri, 10 Nov 2023 at 02:39, Daniel Walker wrote:
>
> This adds code to handle the generic command line changes.
> The efi code appears that it doesn't benefit as much from this design
> as it could.
>
> For example, if you had a prepend command line with "nokaslr" then
> you might be helpful to
Hello Giovanni,
On Thu, 3 Aug 2023 at 11:51, Giovanni Cabiddu
wrote:
>
> Hi Ard,
>
> On Tue, Jul 18, 2023 at 01:58:27PM +0100, Ard Biesheuvel wrote:
> > This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5.
> >
> > "zlib-deflate" was introduc
On Fri, 28 Jul 2023 at 11:59, Herbert Xu wrote:
>
> On Fri, Jul 28, 2023 at 11:57:42AM +0200, Ard Biesheuvel wrote:
> >
> > So will IPcomp be able to simply assign those pages to the SKB afterwards?
>
> Yes that is the idea. The network stack is very much in love wi
On Fri, 28 Jul 2023 at 11:56, Herbert Xu wrote:
>
> On Tue, Jul 18, 2023 at 02:58:26PM +0200, Ard Biesheuvel wrote:
> >
> > Patch #2 removes the support for on-the-fly allocation of destination
> > buffers and scatterlists from the Intel QAT driver. This is neve
On Fri, 21 Jul 2023 at 13:12, Simon Horman wrote:
>
> On Tue, Jul 18, 2023 at 02:58:46PM +0200, Ard Biesheuvel wrote:
>
> ...
>
> > -static int deflate_comp_init(struct deflate_ctx *ctx)
> > +static int deflate_process(struct acomp_req *req, str
On Wed, 19 Jul 2023 at 16:23, Zhihao Cheng wrote:
>
> 在 2023/7/19 16:33, Ard Biesheuvel 写道:
> > On Wed, 19 Jul 2023 at 00:38, Eric Biggers wrote:
> >>
> >> On Tue, Jul 18, 2023 at 02:58:31PM +0200, Ard Biesheuvel wrote:
> >>> Currently, the ubifs
o to configurations that have at least one of the
> users enabled.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Ard Biesheuvel
> ---
> arch/arm/kernel/setup.c | 4
> arch/arm64/kernel/efi.c | 4
> arc
On Wed, 19 Jul 2023 at 00:38, Eric Biggers wrote:
>
> On Tue, Jul 18, 2023 at 02:58:31PM +0200, Ard Biesheuvel wrote:
> > Currently, the ubifs code allocates a worst case buffer size to
> > recompress a data node, but does not pass the size of that buffer to the
> > comp
On Wed, 19 Jul 2023 at 00:54, Eric Biggers wrote:
>
> On Tue, Jul 18, 2023 at 03:32:39PM -0700, Eric Biggers wrote:
> > On Tue, Jul 18, 2023 at 02:58:27PM +0200, Ard Biesheuvel wrote:
> > > This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5.
> > >
> &g
ct it even if we decide to convert it to take advantage of
the ability to pass discontiguous scatterlists.
Signed-off-by: Ard Biesheuvel
---
crypto/scompress.c | 159 ++--
include/crypto/internal/scompress.h | 2 -
2 files changed, 76 insertions(+), 85 deletion
contiguous manner.
This is intended for use by the IPcomp code, which currently needs to
'linearize' SKBs in order for the compression to be able to consume the
input in a single chunk.
Signed-off-by: Ard Biesheuvel
---
crypto/deflate.c | 315 +++-
incl
27;comp' API as well.
Signed-off-by: Ard Biesheuvel
---
Documentation/crypto/architecture.rst | 2 -
crypto/Makefile | 2 +-
crypto/api.c | 4 -
crypto/compress.c | 32 -
crypto/crypto_user_base.c
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/crypto_null.c | 31
crypto/testmgr.c | 3 --
2 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/crypto/crypto_null.
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/cavium/zip/zip_crypto.c | 40
drivers/crypto/cavium/zip/zip_crypto.h | 10
drivers/crypto/cavium/zip/zip_mai
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/zstd.c | 56 +---
1 file changed, 1 insertion(+), 55 deletions(-)
diff --git a/crypto/zstd.c b/crypto/zstd.c
index 154a969c83a82277..c6e6f1
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/lzo.c | 60 +---
1 file changed, 1 insertion(+), 59 deletions(-)
diff --git a/crypto/lzo.c b/crypto/lzo.c
index ebda132dd22bf543..52558f9d41f3d
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/lzo-rle.c | 60 +---
1 file changed, 1 insertion(+), 59 deletions(-)
diff --git a/crypto/lzo-rle.c b/crypto/lzo-rle.c
index 0631d9
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/lz4hc.c | 63 +---
1 file changed, 1 insertion(+), 62 deletions(-)
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index d7cc94aa2fcf42fa..5d6b13
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/lz4.c | 61 +---
1 file changed, 1 insertion(+), 60 deletions(-)
diff --git a/crypto/lz4.c b/crypto/lz4.c
index 0606f8862e7872ad..c46b6cbd91ce1
No users of the obsolete 'comp' crypto compression API remain, so let's
drop the software deflate version of it.
Signed-off-by: Ard Biesheuvel
---
crypto/deflate.c | 58 +---
1 file changed, 1 insertion(+), 57 deletions(-)
diff --git a/crypto/deflate.c b/crypto/
The 'comp' API is obsolete and will be removed, so remove this comp
implementation.
Signed-off-by: Ard Biesheuvel
---
crypto/842.c | 63 +---
1 file changed, 1 insertion(+), 62 deletions(-)
diff --git a/crypto/842.c b/crypto/842.c
index e59e54d769609ba6..5001d88cf727f
rapped and
exposed as acomp implementation via the crypto subsystem's
acomp-to-scomp adaptation layer.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/nx/nx-842.c| 34
drivers/crypto/nx/nx-842.h| 14
drivers/crypto/nx/nx-common
page. This
makes the conversion quite straight-forward, and easy to back by either
a software or a hardware implementation.
Signed-off-by: Ard Biesheuvel
---
drivers/block/zram/zcomp.c| 67 +++-
drivers/block/zram/zcomp.h| 7 +-
drivers/block/zram/zram_drv.c | 12 +---
ard.
Only synchronous acomp implementations are considered at the moment, and
whether or not a future conversion to permit asynchronous ones too will
be worth the effort remains to be seen.
Signed-off-by: Ard Biesheuvel
---
fs/ubifs/compress.c | 61 ++--
fs/ubifs/file.
The recompression scratch buffer is only used when the data node is
compressed, and there is no need to allocate it otherwise. So move the
allocation into the branch of the if() that actually makes use of it.
Signed-off-by: Ard Biesheuvel
---
fs/ubifs/journal.c | 16
1 file
tiply out_len by WORST_COMPR_FACTOR after allocating the
buffer. Doing so is guaranteed not to overflow, given that the preceding
kmalloc_array() call would have failed otherwise.
Signed-off-by: Ard Biesheuvel
---
fs/ubifs/journal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ubifs/jour
y requires in- and output buffers to
be non-overlapping, scratch buffers will always be needed, and so
whether this conversion is worth while is TBD.
Signed-off-by: Ard Biesheuvel
---
include/crypto/acompress.h | 5 +
include/net/ipcomp.h | 4 +-
net/xfrm/xfrm_algo.c | 7 +-
output size is essentially unbounded, and so
the caller already needs to provide the size for this feature to work
reliably.
Signed-off-by: Ard Biesheuvel
---
crypto/acompress.c | 6
crypto/scompress.c | 14 +-
crypto/testmgr.c | 29
no current users, so let's remove it while we still
can.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/intel/qat/qat_common/qat_bl.c| 159
drivers/crypto/intel/qat/qat_common/qat_bl.h| 6 -
drivers/crypto/intel/qat/qat_common/qat_comp_algs.c
hat we will ever grow the need to support zlib-deflate.
Signed-off-by: Ard Biesheuvel
---
crypto/deflate.c | 61 +---
crypto/testmgr.c | 8 +--
crypto/testmgr.h | 75
3 files changed, 18 insertions(+), 126 deletions(-)
diff --git a/crypto/deflate.c
c: linux-...@lists.infradead.org
Cc: net...@vger.kernel.org
Ard Biesheuvel (21):
crypto: scomp - Revert "add support for deflate rfc1950 (zlib)"
crypto: qat - Drop support for allocating destination buffers
crypto: acompress - Drop destination scatterlist allocation feature
net: ipcomp: Mig
s part of this series.
>
> Cc: Neil Armstrong
> Cc: Daniel Golle
> Cc: Linus Walleij
> Cc: linux-ox...@groups.io
> Signed-off-by: Arnd Bergmann
Acked-by: Ard Biesheuvel
On Mon, 16 Jan 2023 at 10:33, John Paul Adrian Glaubitz
wrote:
>
> Hi Ard!
>
> On 1/14/23 00:25, Ard Biesheuvel wrote:
> > Thanks for reporting back. I (mis)read the debian ports page [3],
> > which mentions Debian 7 as the highest Debian version that supports
> &g
On Fri, 13 Jan 2023 at 22:06, John Paul Adrian Glaubitz
wrote:
>
> Hello Ard!
>
> > Can I take that as an ack on [0]? The EFI subsystem has evolved
> > substantially over the years, and there is really no way to do any
> > IA64 testing beyond build testing, so from that perspective, dropping
> > i
On Fri, 13 Jan 2023 at 01:31, Luck, Tony wrote:
>
> > Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> > in pure maintenance mode from a kernel perspective (if even that).
>
> There's not much "simultaneous" in the SMT on ia64. One thread in a
> spin loop will hog the core u
On Thu, 15 Sept 2022 at 10:47, Peter Zijlstra wrote:
>
> On Thu, Sep 15, 2022 at 10:56:58AM +0800, Chen Zhongjin wrote:
>
> > We have found some anonymous information on x86 in .rodata.
>
> Well yes, but that's still a bunch of heuristics on our side.
>
> > I'm not sure if those are *all* of Josh
On Sun, 11 Sept 2022 at 16:26, Peter Zijlstra wrote:
>
> On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> > Alternatives
> >
> >
> > Another idea which has been floated in the past is for objtool to read
> > DWARF (or .eh_frame) to help it figure out the control flow.
Hello Christophe,
On Fri, 8 Jul 2022 at 19:32, Christophe Leroy
wrote:
>
> This series applies on top of the series v3 "objtool: Enable and
> implement --mcount option on powerpc" [1] rebased on powerpc-next branch
>
> A few modifications are done to core parts to enable powerpc
> implementation:
@kernel.org>, Masahiro Yamada , Jarkko Sakkinen
, Sami Tolvanen , "Naveen N. Rao"
, Marco Elver , Kees Cook
, Steven Rostedt , Nathan
Chancellor , "Russell King \(Oracle\)"
, Mark Brown , Borislav Petkov
, Alexander Egorenkov , Thomas
Bogendoerfer , Parisc List
, Nathaniel McCallum ,
Dmitr
Deacon , Masahiro Yamada , Sami Tolvanen
, "Naveen N. Rao" , Marco
Elver , Kees Cook , Steven Rostedt
, Nathan Chancellor , "Russell King
\(Oracle\)" , Mark Brown ,
Borislav Petkov , Alexander Egorenkov ,
Thomas Bogendoerfer , linux-par...@vger.kernel.org,
Nathaniel McCallum , Dmitry Torokho
On Tue, 15 Feb 2022 at 10:13, Arnd Bergmann wrote:
>
> On Tue, Feb 15, 2022 at 9:17 AM Ard Biesheuvel wrote:
> > On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> >
> > With set_fs() out of the picture, wouldn'
On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> arm64 has an inline asm implementation of access_ok() that is derived from
> the 32-bit arm version and optimized for the case that both the limit and
> the size are variable. With set_fs() gone, the limit is always co
On Wed, 2 Feb 2022 at 08:10, Matthew Garrett wrote:
>
> On Wed, Feb 02, 2022 at 08:05:23AM +0100, Greg KH wrote:
>
> > I see different platform patches trying to stick these blobs in
> > different locations and ways to access (securityfs, sysfs, char device
> > node), which seems crazy to me. Why
On Thu, 27 Jan 2022 at 15:55, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 02:59:31PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 14:24, Mark Rutland wrote:
> > >
> > > On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote:
> > >
On Thu, 27 Jan 2022 at 14:24, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 13:59, Mark Rutland wrote:
> > >
> > > On Thu, Jan 27, 2022 at 01:22:17PM +0100, Ard Biesheuvel wrote:
> > &g
On Thu, 27 Jan 2022 at 13:59, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 01:22:17PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 13:20, Mark Rutland wrote:
> > > On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote:
> > >
> > > &
On Thu, 27 Jan 2022 at 13:20, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 12:47, Mark Rutland wrote:
> > >
> > > [adding LKML so this is easier for others to find]
> > >
> > &g
On Thu, 27 Jan 2022 at 12:47, Mark Rutland wrote:
>
> [adding LKML so this is easier for others to find]
>
> If anyone wants to follow the thread from the start, it's at:
>
>
> https://lore.kernel.org/linuxppc-dev/944d10da-8200-4ba9-8d0a-3bed9aa99...@linux.ibm.com/
>
> Ard, I was under the impr
Hi Arnd,
(replying to an old thread as this came up in the discussion regarding
misaligned loads and stored in siphash() when compiled for ARM
[f7e5b9bfa6c8820407b64eabc1f29c9a87e8993d])
On Fri, 14 May 2021 at 12:02, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> The get_unaligned()/put_unali
On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
>
> The CPU field will be moved back into thread_info even when
> THREAD_INFO_IN_TASK is enabled, so add it back to s390's definition of
> struct thread_info.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/s390/
On Tue, 28 Sept 2021 at 02:16, Michael Ellerman wrote:
>
> Michael Ellerman writes:
> > Ard Biesheuvel writes:
> >> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
> >>>
> >>> The CPU field will be moved back into thread_info even when
> &g
On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
>
> The CPU field will be moved back into thread_info even when
> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
> of struct thread_info.
>
> Signed-off-by: Ard Biesheuvel
Michael,
Do you have a
On Wed, 22 Sept 2021 at 12:43, Emmanuel Gil Peyrot
wrote:
>
> On Wed, Sep 22, 2021 at 12:10:41PM +0200, Ard Biesheuvel wrote:
> > On Tue, 21 Sept 2021 at 23:49, Emmanuel Gil Peyrot
> > wrote:
> > >
> > > This engine implements AES in CBC mode, using 128-bi
On Tue, 21 Sept 2021 at 23:49, Emmanuel Gil Peyrot
wrote:
>
> This engine implements AES in CBC mode, using 128-bit keys only. It is
> present on both the Wii and the Wii U, and is apparently identical in
> both consoles.
>
> The hardware is capable of firing an interrupt when the operation is
>
On Tue, 14 Sept 2021 at 15:55, Mark Rutland wrote:
>
> On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> > Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> > task_struct") mentions that, along with moving thread_info into
> > t
On Thu, 16 Sept 2021 at 16:41, Catalin Marinas wrote:
>
> On Tue, Sep 14, 2021 at 02:10:29PM +0200, Ard Biesheuvel wrote:
> > The CPU field will be moved back into thread_info even when
> > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
On Tue, 14 Sept 2021 at 17:59, Linus Torvalds
wrote:
>
> On Tue, Sep 14, 2021 at 8:53 AM Ard Biesheuvel wrote:
> >
> > task_cpu() takes a 'const struct task_struct *', whereas
> > task_thread_info() takes a 'struct task_struct *'.
>
> Oh,
On Tue, 14 Sept 2021 at 17:49, Linus Torvalds
wrote:
>
> On Tue, Sep 14, 2021 at 5:11 AM Ard Biesheuvel wrote:
> >
> > static inline unsigned int task_cpu(const struct task_struct *p)
> > {
> > #ifdef CONFIG_THREAD_INFO_IN_TASK
> > - return R
On Tue, 14 Sept 2021 at 17:41, Linus Torvalds
wrote:
>
> On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel wrote:
> >
> > The CPU field will be moved back into thread_info even when
> > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
> >
Now that the core code switched back to using thread_info::cpu to keep
a task's CPU number, we no longer need to keep it in sync explicitly. So
just drop the code that does this.
Signed-off-by: Ard Biesheuvel
---
This patch applies onto [0], which we hope to get merged for v5.16
[0]
Now that the core code switched back to using thread_info::cpu to keep
a task's CPU number, we no longer need to keep it in sync explicitly. So
just drop the code that does this.
Signed-off-by: Ard Biesheuvel
---
arch/riscv/kernel/asm-offsets.c | 1 -
arch/riscv/kernel/entry.S
Instead of relying on awful hacks to obtain the offset of the cpu field
in struct task_struct, move it back into struct thread_info, which does
not create the same level of circular dependency hell when trying to
include the header file that defines it.
Signed-off-by: Ard Biesheuvel
---
arch
Given that thread_info and task_struct are the same data structure
anyway when THREAD_INFO_IN_TASK=y, let's move it back so that having
access to the type definition of struct thread_info is sufficient to
reference the CPU number of the current task.
Signed-off-by: Ard Biesheuvel
---
arch/ar
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
of struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/powerpc/include/asm/thread_info.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/po
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to s390's definition of
struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/s390/include/asm/thread_info.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/includ
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to x86's definition of
struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/thread_info.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/includ
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/asm-offsets.c | 1 +
2 files chang
n
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Ard Biesheuvel (8):
arm64: add CPU field to struct thread_info
x86: add CPU field to struct thread_info
s390: add CPU field to struct thread_info
po
1 - 100 of 306 matches
Mail list logo
