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