(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
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| 9 +--
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
get()
> >>>> * __set_pte()
> >>>> * efi_memattr_apply_permissions -> efi_set_mapping_permissions … ->
> >>>> set_permissions
> >>>> * __ptep_get()
> >>>> * __set_pte()
> >>>
> >&
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 ubi
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
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 deletions(-)
diff
in a 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 +++-
include/crypto
.
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 | 16 ---
crypto
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.c b/crypto
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_main.c | 50
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..c6e6f135c5812c9c
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..52558f9d41f3dcea 100644
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 0631d975bfac1129
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..5d6b13319f5e7683
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..c46b6cbd91ce10c0 100644
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/deflate.c
index
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..5001d88cf727f74e 100644
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-powernv.c | 30
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 +---
3 files changed, 57
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.c | 46
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
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/journal.c
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 +-
net/xfrm
the 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 | 86
at 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 b/cr
...@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: Migrate to acomp API from deprecated comp A
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
> >
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
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
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
>
@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 ,
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
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't
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
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.
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]
> > >
> >
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
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
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/inclu
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 any ob
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
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, annoying, but
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
> > stru
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]
https
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 | 5
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
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/arm64/kernel
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/powerpc
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/include/asm
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/include/asm
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 changed, 2
ux-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
powerpc: add
On Tue, 31 Aug 2021 at 10:53, Peter Zijlstra wrote:
>
> On Tue, Aug 31, 2021 at 08:05:21AM +, Christophe Leroy wrote:
>
> > +#define ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) \
> > + asm(".pushsection .text, \"ax\" \n" \
> > + ".align
https://lore.kernel.org/r/8b972f1c03fb6bd59953035f0a3e4d26659de4f8.1620795204.git.christophe.le...@csgroup.eu/
>
> Cc: Ard Biesheuvel
> Cc: Michael Ellerman
> Cc: Thomas Gleixner
> Cc: Benjamin Herrenschmidt
> Cc: Christophe Leroy
> Cc: Paul Mackerras
> Cc: Jonathan M
(+ Arvind)
On Tue, 30 Mar 2021 at 19:57, 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
On Tue, 9 Mar 2021 at 01:03, Daniel Walker wrote:
>
> This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
> option.
>
> Cc: xe-linux-exter...@cisco.com
> Signed-off-by: Ruslan Ruslichenko
> Signed-off-by: Ruslan Bilovol
> Signed-off-by: Daniel Walker
> ---
> arch/x86/Kconfig
On Thu, 21 Jan 2021 at 10:54, Christophe Leroy
wrote:
>
>
>
> Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
> > On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
> > wrote:
> >>
> >>
> >>
> >> Le 20/01/2021 à 23:23, Ard Biesheuvel a
On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
wrote:
>
>
>
> Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
> > On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
> > wrote:
> >>
> >> Talitos Security Engine AESU considers any input
> >> data siz
On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
wrote:
>
> Talitos Security Engine AESU considers any input
> data size that is not a multiple of 16 bytes to be an error.
> This is not a problem in general, except for Counter mode
> that is a stream cipher and can have an input of any size.
>
>
On Wed, 28 Oct 2020 at 09:04, Ard Biesheuvel wrote:
>
> Commit 7053f80d9696 ("powerpc/64: Prevent stack protection in early boot")
> introduced a couple of uses of __attribute__((optimize)) with function
> scope, to disable the stack protector in some early boot c
Cc: Thomas Gleixner
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Peter Zijlstra (Intel)
Cc: Geert Uytterhoeven
Cc: Kees Cook
Fixes: 7053f80d9696 ("powerpc/64: Prevent stack protection in early boot")
Signed-off-by: Ard Biesheuvel
---
Related discussion here:
https://lore.kernel.org/lkml/
n Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> >>>> wrote:
> >>>>>
> >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> >>>&
On 9/16/20 3:32 AM, Ran Wang wrote:
Hi Ard,
On Tuesday, September 15, 2020 7:10 PM, Ard Biesheuvel wrote:
Subject: Re: [PATCH v1] soc: fsl: rcpm: Add ACPI support
On 9/15/20 1:06 PM, kuldip dwivedi wrote:
Add ACPI support in fsl RCPM driver. This is required to support ACPI
S3 state. S3
On 9/15/20 1:06 PM, kuldip dwivedi wrote:
Add ACPI support in fsl RCPM driver. This is required
to support ACPI S3 state. S3 is the ACPI sleep state
that is known as "sleep" or "suspend to RAM".
It essentially turns off most power of the system but
keeps memory powered.
Signed-off-by: tanveer
On Thu, 23 Jul 2020 at 04:52, Jarkko Sakkinen
wrote:
>
> On Thu, Jul 16, 2020 at 06:49:09PM +0200, Christophe Leroy wrote:
> > Jarkko Sakkinen a écrit :
> >
> > > Rename module_alloc() to text_alloc() and module_memfree() to
> > > text_memfree(), and move them to kernel/text.c, which is
On Tue, 14 Jul 2020 at 16:33, Mark Rutland wrote:
>
> On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > > So perhaps the answer is to have text_alloc() not with a 'where'
> > > argu
On Tue, 14 Jul 2020 at 14:31, Peter Zijlstra wrote:
>
> On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote:
>
> > As Ard says, module_alloc() _is_ special, in the sense that the virtual
> > memory it allocates wants to be close to the kernel text, whereas the
> > concept of allocating
On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen
wrote:
>
> On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> > This patch suggests that there are other reasons why conflating
> > allocation of module space and allocating text pages for other uses
> > is a
On Tue, 14 Jul 2020 at 05:04, Steven Rostedt wrote:
>
> On Mon, 13 Jul 2020 22:49:48 +0300
> Ard Biesheuvel wrote:
>
> > On arm64, we no longer use module_alloc for bpf or kprobes, to avoid
> > wasting va space on code that does not need to be loaded close to the
> &
On Mon, 13 Jul 2020 at 21:21, Jarkko Sakkinen
wrote:
>
> Rename module_alloc() to text_alloc() and module_memfree() to
> text_memfree(), and move them to kernel/text.c, which is unconditionally
> compiled to the kernel proper. This allows kprobes, ftrace and bpf to
> allocate space for executable
1 - remove unused temporary workspace
> crypto: powerpc/sha1 - prefix the "sha1_" functions
> crypto: s390/sha1 - prefix the "sha1_" functions
> crypto: lib/sha1 - rename "sha" to "sha1"
> crypto: lib/sha1 - remove unnecessary includ
defines a new IMA Kconfig IMA_SECURE_AND_OR_TRUSTED_BOOT option, allowing
> the different architectures to select it.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Nayna Jain
> Cc: Ard Biesheuvel
> Cc: Philipp Rudo
> Cc: Michael Ellerman
Acked-by: Ard Biesheuvel
for the
file needs to be updated. To avoid this "noise", this patch
> > defines a new IMA Kconfig IMA_SECURE_AND_OR_TRUSTED_BOOT option, allowing
> > the different architectures to select it.
> >
> > Suggested-by: Linus Torvalds
> > Signed-off-by: Nayna Jain
> >
e RNG for arch_get_random_seed_*
not arch_get_random_*")
Signed-off-by: Ard Biesheuvel
---
arch/powerpc/include/asm/archrandom.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch/powerpc/include/asm/archrandom.h
index 9c63b596e6ce..a09595f00
k
> s390x: Mark archrandom.h functions __must_check
>
Modulo the nit in reply to 1/6:
Reviewed-by: Ard Biesheuvel
> arch/powerpc/include/asm/archrandom.h | 24 +---
> arch/s390/include/asm/archrandom.h| 8
> arch/x86/include/asm/archrandom.h
On Mon, 28 Oct 2019 at 22:06, Richard Henderson
wrote:
>
> We cannot use the pointer output without validating the
> success of the random read.
>
> Signed-off-by: Richard Henderson
> ---
> Cc: Kees Cook
> Cc: "H. Peter Anvin"
> Cc: linux-a...@vger.kernel.org
> ---
> include/linux/random.h |
ll ppc_aes_setkey(), rather than
> creating a separate expand_key() function. This keeps the code
> shorter.
>
> Eric Biggers (3):
> crypto: powerpc - don't unnecessarily use atomic scatterwalk
> crypto: powerpc - don't set ivsize for AES-ECB
> crypto: powerp
On Mon, 14 Oct 2019 at 19:38, Eric Biggers wrote:
>
> On Mon, Oct 14, 2019 at 10:45:22AM +0200, Ard Biesheuvel wrote:
> > Hi Eric,
> >
> > On Sat, 12 Oct 2019 at 04:32, Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > &g
moved.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
> ---
> drivers/crypto/nx/nx-aes-ctr.c | 84 +++---
> drivers/crypto/nx/nx.c | 25 +++---
> drivers/crypto/nx/nx.h | 4 +-
> 3 files changed, 46 insertions(+), 67 d
moved.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
> ---
> drivers/crypto/nx/nx-aes-cbc.c | 78 ++
> drivers/crypto/nx/nx.c | 11 ++---
> drivers/crypto/nx/nx.h | 4 +-
> 3 files changed, 41 insertions(+), 52 del
1 - 100 of 278 matches
Mail list logo
