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. 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.) Yes, it could be lockdep_assert_preemption_enabled(), but I'm not sure "ensures the cost of this assertion is only paid on debug kernels" is worth the cost of hiding this on production kernels. The consequences of using FPU/vector/SIMD registers when they can't be are very bad: some random task's registers get corrupted. - Eric
