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

Heiko Carstens
2026-03-04T15:03:04Z

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:
> > > > unsigned long *p1, *p2, *p3, *p4;
> > > >
> > > > + WARN_ON_ONCE(in_interrupt());
> > >
> > > Your changelog makes it sound like you want:
> > >
> > > WARN_ON_ONCE(!in_task());
> > >
> > > But perhaps something like so:
> > >
> > > lockdep_assert_preempt_enabled();
> > >
> > > Would do? That ensures we are in preemptible context, which is much the
> > > same. That also ensures the cost of this assertion is only paid on debug
> > > kernels.
> >
> > No idea honestly. The kernel FPU/vector helpers generally don't work
> > from irq context, and I want to assert that. Happy to do whatever
> > version works best for that.
>
> may_use_simd() is the "generic" way to check "can the FPU/vector/SIMD
> registers be used". However, what it does varies by architecture, and
> it's kind of a questionable abstraction in the first place. It's used
> mostly by architecture-specific code.
>
> If you union together the context restrictions from all the
> architectures, I think you get: "For may_use_simd() to be guaranteed not
> to return false due to the context, the caller needs to be running in
> task context without hardirqs or softirqs disabled."
>
> However, some architectures also incorporate a CPU feature check in
> may_use_simd() as well, which makes it return false if some
> CPU-dependent SIMD feature is not supported.

Oh, interesting. I wasn't aware of may_use_simd(), and of course this is
missing on s390, and hence we fallback to the generic !in_interrupt()
variant.

In fact the s390 simd implementation allows for usage in any context, also
interrupt context. So the s390 implementation of may_use_simd() would
always return true, _except_ for the feature check you mention.

Let me try to change that and see if anything explodes.

> 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()).