Re: [PATCH 01/25] xor: assert that xor_blocks is not called from interrupt context
Heiko Carstens <[email protected]>
| Newsgroups | gmane.linux.ports.riscv,gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.ppc64.devel,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.linux.kernel.cryptoapi,gmane.comp.file-systems.btrfs,gmane.linux.kernel.cross-arch,gmane.linux.raid |
|---|---|
| Message-ID | <[email protected]> |
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: > > On Tue, Mar 03, 2026 at 05:00:50PM +0100, Christoph Hellwig wrote: > > > 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.