From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D78863890E9; Tue, 3 Mar 2026 19:56:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772567776; cv=none; b=UZf84atDxYdzOlZ62ATudKTjWCJLwCGWnz46FpQwU0DV01ji9DLG7HzuSOf145kxA3aqtgpEVpE+MRcLEh3ZTtdmfKGQRQrMP4/G0mcbOUmxsvybm13gCRShPrZ0jAy+D6QL0J9iMJt/d34RX8tO7WrJedTIVRXUNy9Rvbi2hfA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772567776; c=relaxed/simple; bh=9sr6A1ZQ/OAOM0MyaKuNScWB7UA08hne7lVI9ssYSPg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oYoTYjaKU31rDK5RzhF2BbBUGjdBu104ZgDQWBpvi8jBNu2GchXWxU+YCU5vZbWNT8U4yymINOqPxIW6Q8MDM0GrGES+RGEhZ5WqhGnnQqQ9vD39/r5oDJbwHt3xKjnvWIhl7T/UxEwERsyF15UBwl+WplbBdYITXA5fV6wdMxE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mHMra/+s; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mHMra/+s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1644C116C6; Tue, 3 Mar 2026 19:56:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772567774; bh=9sr6A1ZQ/OAOM0MyaKuNScWB7UA08hne7lVI9ssYSPg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mHMra/+se8TmXPAvXWkLhgpf0kETRB4dEaJCtUtlUTftYpe0ReqfitRfwD4MGq4+T WuzDe+k5qMfwF8Pvg7plbRdHjZuWKh+IB7lEOogeIHeGkKvwd2/EpZagMr99KeT7V+ XN7WYkTp/J6gkuhSVqd3D55QMpvT59XaPLLtFxjhlFBUF5SPdV1HoakLZQKIIo/fdH BGibgd4432V2o3DyL8VfocxjZKarY5SdEW/Gzxyc6CkyylsV/unCa5mrJJyTo1wkxn QMVCX29BeW41faad8f8MgUVR1waChaWC40npYyOs3agb3dJecKXchWeHWLYBSYXFrd nwEHrCxoK1HSw== Date: Tue, 3 Mar 2026 11:55:17 -0800 From: Eric Biggers To: Christoph Hellwig Cc: Peter Zijlstra , Andrew Morton , Richard Henderson , Matt Turner , Magnus Lindholm , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "David S. Miller" , Andreas Larsson , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Herbert Xu , Dan Williams , Chris Mason , David Sterba , Arnd Bergmann , Song Liu , Yu Kuai , Li Nan , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-arch@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: [PATCH 01/25] xor: assert that xor_blocks is not called from interrupt context Message-ID: <20260303195517.GC2846@sol> References: <20260226151106.144735-1-hch@lst.de> <20260226151106.144735-2-hch@lst.de> <20260227142455.GG1282955@noisy.programming.kicks-ass.net> <20260303160050.GB7021@lst.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260303160050.GB7021@lst.de> 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