Until commit 6c85f52b10fd ("kvm/ppc: IRQ disabling cleanup"),
kvmppc_prepare_to_enter() was called with interrupts already disabled by
the caller, which was documented in the comment above the function.
Post-cleanup, the function is now called with interrupts enabled, and
disables interrupts itsel
On Tue, Aug 5, 2025 at 10:19 PM Andrey Ryabinin wrote:
>
>
>
> On 8/5/25 4:26 PM, Sabyrzhan Tasbolatov wrote:
> >
> > diff --git a/arch/um/Kconfig b/arch/um/Kconfig
> > index 9083bfdb773..8d14c8fc2cd 100644
> > --- a/arch/um/Kconfig
> > +++ b/arch/um/Kconfig
> > @@ -5,6 +5,7 @@ menu "UML-specific
On Tue, Aug 5, 2025 at 10:18 PM Andrey Ryabinin wrote:
>
>
>
> On 8/5/25 4:26 PM, Sabyrzhan Tasbolatov wrote:
> > LoongArch needs deferred KASAN initialization as it has a custom
> > kasan_arch_is_ready() implementation that tracks shadow memory
> > readiness via the kasan_early_stage flag.
> >
>
On 8/4/2025 5:17 PM, Breno Leitao wrote:
Similarly to pci_dev_aer_stats_incr(), pci_print_aer() may be called
when dev->aer_info is NULL. Add a NULL check before proceeding to avoid
calling aer_ratelimit() with a NULL aer_info pointer, returning 1, which
does not rate limit, given this is fata
On 8/5/2025 11:18 PM, Breno Leitao wrote:
On Tue, Aug 05, 2025 at 10:25:11PM +0800, Ethan Zhao wrote:
Seems you are using arm64 platform default config item
arch/arm64/configs/defconfig:CONFIG_ACPI_APEI_PCIEAER=y
So the issue wouldn't be triggered on X86_64 with default config.
Not really,
On Tue, Aug 05, 2025 at 03:28:54PM -0700, Eric Biggers wrote:
> Reimplement crypto/md5.c on top of the new MD5 library functions. Also
> add support for HMAC-MD5, again just wrapping the library functions.
>
> This closely mirrors crypto/sha1.c.
>
> Signed-off-by: Eric Biggers
> ---
> crypto/K
Reimplement crypto/md5.c on top of the new MD5 library functions. Also
add support for HMAC-MD5, again just wrapping the library functions.
This closely mirrors crypto/sha1.c.
Signed-off-by: Eric Biggers
---
crypto/Kconfig| 2 +-
crypto/md5.c | 359 ++
Add a KUnit test suite for the MD5 library functions, including the
corresponding HMAC support. The core test logic is in the
previously-added hash-test-template.h. This commit just adds the actual
KUnit suite, and it adds the generated test vectors to the tree so that
gen-hash-testvecs.py won't
Instead of exposing the sparc-optimized MD5 code via sparc-specific
crypto_shash algorithms, instead just implement the md5_blocks() library
function. This is much simpler, it makes the MD5 library functions be
sparc-optimized, and it fixes the longstanding issue where the
sparc-optimized MD5 code
Instead of exposing the powerpc-optimized MD5 code via powerpc-specific
crypto_shash algorithms, instead just implement the md5_blocks() library
function. This is much simpler, it makes the MD5 library functions be
powerpc-optimized, and it fixes the longstanding issue where the
powerpc-optimized
Instead of exposing the mips-optimized MD5 code via mips-specific
crypto_shash algorithms, instead just implement the md5_blocks() library
function. This is much simpler, it makes the MD5 library functions be
mips-optimized, and it fixes the longstanding issue where the
mips-optimized MD5 code was
Since octeon-crypto.c is the only remaining source file in
arch/mips/cavium-octeon/crypto/, move it into its parent directory
arch/mips/cavium-octeon/. Then remove the directory
arch/mips/cavium-octeon/crypto/, including its Makefile.
Signed-off-by: Eric Biggers
---
arch/mips/cavium-octeon/Make
Add library functions for MD5, including HMAC support. The MD5
implementation is derived from crypto/md5.c. This closely mirrors the
corresponding SHA-1 and SHA-2 changes.
Like SHA-1 and SHA-2, support for architecture-optimized MD5
implementations is included. I originally proposed dropping th
This series is targeting libcrypto-next and can also be retrieved from:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git md5-lib-v2
This series introduces a library API for MD5 and HMAC-MD5 and
reimplements the crypto_shash "md5" and "hmac(md5)" on top of it.
The
On Mon, Aug 04, 2025 at 04:17:04PM -0700, Mingming Cao wrote:
> POWER8 support a maximum of 16 subcrq indirect descriptor entries per
> H_SEND_SUB_CRQ_INDIRECT call, while POWER9 and newer hypervisors
> support up to 128 entries. Increasing the max number of indirect
> descriptor entries improves
On 8/5/25 4:26 PM, Sabyrzhan Tasbolatov wrote:
>
> diff --git a/arch/um/Kconfig b/arch/um/Kconfig
> index 9083bfdb773..8d14c8fc2cd 100644
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -5,6 +5,7 @@ menu "UML-specific options"
> config UML
> bool
> default y
> + select ARC
On 8/5/25 4:26 PM, Sabyrzhan Tasbolatov wrote:
> LoongArch needs deferred KASAN initialization as it has a custom
> kasan_arch_is_ready() implementation that tracks shadow memory
> readiness via the kasan_early_stage flag.
>
> Select ARCH_DEFER_KASAN to enable the unified static key mechanism
>
On Tue, Aug 05, 2025 at 04:17:49PM +0900, Simon Richter wrote:
> Hi,
>
> On 8/5/25 13:58, Eric Biggers wrote:
>
> > What does this have to do with this thread, which is about the PowerPC
> > optimized MD5 code?
>
> Hence the new subject. It is still related to removal of code, but asks
> about t
On Tue, Aug 05, 2025 at 08:27:14AM +0200, Christophe Leroy wrote:
> > What? That's crazy. Userspace MD5 code would be faster and more
> > reliable. No need to make syscalls, transfer data to and from the
> > kernel, have an external dependency, etc. Is this the coreutils md5sum?
> > We need to
Hi Sabyrzhan,
On 8/5/25 16:26, Sabyrzhan Tasbolatov wrote:
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since riscv doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal
On Tue, Aug 05, 2025 at 12:37:57PM +0300, Mike Rapoport wrote:
> On Mon, Aug 04, 2025 at 12:54:21PM +0200, Uladzislau Rezki wrote:
> > Hello, Lorenzo!
> >
> > > So sorry Ulad, I meant to get back to you on this sooner!
> > >
> > > On Tue, Jul 29, 2025 at 08:39:01PM +0200, Uladzislau Rezki wrote:
On Mon, Aug 04, 2025 at 04:37:56AM +0100, Matthew Wilcox wrote:
> On Sun, Aug 03, 2025 at 12:59:06PM -0300, Jason Gunthorpe wrote:
> > Matthew, do you think it makes sense to introduce types to make this
> > clearer? We have two kinds of values that a phys_addr_t can store -
> > something compatibl
On 05.08.2025 17:08, Christian Zigotzky wrote:
On 05.08.2025 15:12, Christian Zigotzky wrote:
Hi All,
Here is the alpha5 of kernel 6.17 for X1000 and e5500 machines
(X5000/20, X5000/40, Mirari, and QEMU VMs).
I created kernels with and without the drm-next-2025-07-30 updates
[1] because of
On Tue, Aug 05, 2025 at 10:25:11PM +0800, Ethan Zhao wrote:
>
> Seems you are using arm64 platform default config item
> arch/arm64/configs/defconfig:CONFIG_ACPI_APEI_PCIEAER=y
> So the issue wouldn't be triggered on X86_64 with default config.
Not really, I am running on x86 hosts. There are the
On 05.08.2025 15:12, Christian Zigotzky wrote:
Hi All,
Here is the alpha5 of kernel 6.17 for X1000 and e5500 machines (X5000/20,
X5000/40, Mirari, and QEMU VMs).
I created kernels with and without the drm-next-2025-07-30 updates [1] because
of the issue with the Radeon graphics framebuffer de
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since riscv doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
Closes: https://bugzilla.kernel.org/s
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since s390 doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
s390 sets up KASAN mappings in the dec
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since x86 doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op, and kasan_enabled() will return
IS_ENABLED(CONFIG_KASAN) for optimal compile-time behavior.
Closes: https://bugzilla.kernel.org/sho
UserMode Linux needs deferred KASAN initialization as it has a custom
kasan_arch_is_ready() implementation that tracks shadow memory readiness
via the kasan_um_is_ready flag.
As it's explained in commit 5b301409e8bc("UML: add support for KASAN
under x86_64"), if CONFIG_STATIC_LINK=y, then it works
LoongArch needs deferred KASAN initialization as it has a custom
kasan_arch_is_ready() implementation that tracks shadow memory
readiness via the kasan_early_stage flag.
Select ARCH_DEFER_KASAN to enable the unified static key mechanism
for runtime KASAN control. Call kasan_init_generic() which ha
Call kasan_init_generic() which handles Generic KASAN initialization.
Since arm64 doesn't select ARCH_DEFER_KASAN, this will be a no-op for
the runtime flag but will print the initialization banner.
For SW_TAGS and HW_TAGS modes, their respective init functions will
handle the flag enabling.
Clos
Call kasan_init_generic() which handles Generic KASAN initialization
and prints the banner. Since xtensa doesn't select ARCH_DEFER_KASAN,
kasan_enable() will be a no-op.
Note that arch/xtensa still uses "current" instead of "init_task" pointer
in `current->kasan_depth = 0;` to enable error message
Introduce CONFIG_ARCH_DEFER_KASAN to identify architectures that need
to defer KASAN initialization until shadow memory is properly set up,
and unify the static key infrastructure across all KASAN modes.
Some architectures (like PowerPC with radix MMU) need to set up their
shadow memory mappings b
PowerPC with radix MMU is the primary architecture that needs deferred
KASAN initialization, as it requires complex shadow memory setup before
KASAN can be safely enabled.
Select ARCH_DEFER_KASAN for PPC_RADIX_MMU to enable the static key
mechanism for runtime KASAN control. Other PowerPC configur
This patch series addresses the fragmentation in KASAN initialization
across architectures by introducing a unified approach that eliminates
duplicate static keys and arch-specific kasan_arch_is_ready()
implementations.
The core issue is that different architectures have inconsistent approaches
to
On 8/4/2025 5:17 PM, Breno Leitao wrote:
Similarly to pci_dev_aer_stats_incr(), pci_print_aer() may be called
when dev->aer_info is NULL. Add a NULL check before proceeding to avoid
calling aer_ratelimit() with a NULL aer_info pointer, returning 1, which
does not rate limit, given this is fata
Le 05/08/2025 à 00:59, Eric Biggers a écrit :
On Mon, Aug 04, 2025 at 09:02:27PM +0200, Christophe Leroy wrote:
Le 04/08/2025 à 20:09, Eric Biggers a écrit :
On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
Le 03/08/2025 à 22:44, Eric Biggers a écrit :
MD5 is insecure,
On Mon, Aug 04, 2025 at 10:41:05AM -0700, Dave Hansen wrote:
> On 8/4/25 10:12, Breno Leitao wrote:
> ...
> > +- These errros are divided by are, which includes CPU, Memory, PCI, CXL and
> > + others.
>
> There's a double typo in there I think:
>
> errros => errors
> and
> are,=>area
On 05/08/25 11:57 am, Saket Kumar Bhaskar wrote:
This patch series introduces support for the PROBE_MEM32,
bpf_addr_space_cast and PROBE_ATOMIC instructions in the powerpc BPF JIT,
facilitating the implementation of BPF arena and arena atomics.
The last patch in the series has fix for arena sp
On 05/08/25 1:04 pm, Christophe Leroy wrote:
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
bpf_jit_emit_probe_mem_store() is introduced to emit instructions for
storing memory values depending on the size (byte, halfword,
word, doubleword).
Build break with this patch
CC arc
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
LLVM generates bpf_addr_space_cast instruction while translating
pointers between native (zero) address space and
__attribute__((address_space(N))). The addr_space=0 is reserved as
bpf_arena address space.
rY = addr_space_cast(rX, 0, 1) is
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
Add support for [LDX | STX | ST], PROBE_MEM32, [B | H | W | DW]
instructions. They are similar to PROBE_MEM instructions with the
following differences:
- PROBE_MEM32 supports store.
- PROBE_MEM32 relies on the verifier to clear upper 32-bi
On Mon, Aug 04, 2025 at 12:54:21PM +0200, Uladzislau Rezki wrote:
> Hello, Lorenzo!
>
> > So sorry Ulad, I meant to get back to you on this sooner!
> >
> > On Tue, Jul 29, 2025 at 08:39:01PM +0200, Uladzislau Rezki wrote:
> > > On Tue, Jul 29, 2025 at 06:25:39AM +0100, Lorenzo Stoakes wrote:
> >
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
bpf_jit_emit_probe_mem_store() is introduced to emit instructions for
storing memory values depending on the size (byte, halfword,
word, doubleword).
Build break with this patch
CC arch/powerpc/net/bpf_jit_comp64.o
arch/powerpc/net
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
This patch series introduces support for the PROBE_MEM32,
bpf_addr_space_cast and PROBE_ATOMIC instructions in the powerpc BPF JIT,
facilitating the implementation of BPF arena and arena atomics.
This series seems to be limited to powerpc6
This patch series introduces support for the PROBE_MEM32,
bpf_addr_space_cast and PROBE_ATOMIC instructions in the powerpc BPF JIT,
facilitating the implementation of BPF arena and arena atomics.
The last patch in the series has fix for arena spinlock selftest
failure.
This series is rebased on t
Le 05/08/2025 à 01:09, Eric Biggers a écrit :
On Mon, Aug 04, 2025 at 10:59:01PM +, Eric Biggers wrote:
On Mon, Aug 04, 2025 at 09:02:27PM +0200, Christophe Leroy wrote:
Le 04/08/2025 à 20:09, Eric Biggers a écrit :
On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
On Mon, 4 Aug 2025 at 18:44, Kees Cook wrote:
> While tracking down a problem where constant expressions used by
> BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
> initializer was convincing the compiler that it couldn't track the state
> of the prior statically initiali
Hi,
On 8/5/25 13:58, Eric Biggers wrote:
What does this have to do with this thread, which is about the PowerPC
optimized MD5 code?
Hence the new subject. It is still related to removal of code, but asks
about the bigger picture.
The code removal changes you've been pushing lately absolute
49 matches
Mail list logo
