Thread (71 messages) flat view 71 messages, 8 authors, 2026-03-10

Re: [PATCH 01/25] xor: assert that xor_blocks is not called from interrupt context

From: Heiko Carstens <hca@linux.ibm.com>
Date: 2026-03-04 15:10:01
Also in: linux-alpha, linux-arch, linux-btrfs, linux-crypto, linux-raid, linux-riscv, linux-s390, linux-um, lkml, loongarch, sparclinux

On Wed, Mar 04, 2026 at 04:01:46PM +0100, Heiko Carstens wrote:
On Tue, Mar 03, 2026 at 11:55:17AM -0800, Eric Biggers wrote:
quoted
On Tue, Mar 03, 2026 at 05:00:50PM +0100, Christoph Hellwig wrote:
quoted
On Fri, Feb 27, 2026 at 03:24:55PM +0100, Peter Zijlstra wrote:
Because of that CPU feature check, I don't think
"WARN_ON_ONCE(!may_use_simd())" would actually be correct here.

How about "WARN_ON_ONCE(!preemptible())"?  I think that covers the union
of the context restrictions correctly.  (Compared to in_task(), it
handles the cases where hardirqs or softirqs are disabled.)
I guess, this is not true, since there is at least one architecture which
allows to run simd code in interrupt context (but which missed to implement
may_use_simd()).
Oh, just to avoid confusion, which I may have caused: I made only
general comments about s390 simd usage. Our xor() implementation does
not make use of simd, since our normal xc instruction allows to xor up
to 256 bytes. A simd implementation wouldn't be faster.
Also here it would be possible to run it in any context.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help