From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E122948F84B; Tue, 25 Aug 2026 22:59:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787698769; cv=none; b=cGziSQBELNdrDYzTI760sKxnLqQ6WSXu0jGlHIZBB7ekiuS96lkQyWSmQ7iwn5DH7SnpBH19Ff9da59wAGJzhz7OUIH21IFwwrOm/q5Q2tk8thPQ+YRrY7NIDTyQvEC57sBbFJb5i/+I3EeNVaMpCbxTBYTk8KO4xf7EuEpVFDg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787698769; c=relaxed/simple; bh=LbYpFPMN1pcqFvXPJULvj/K5VWnc5rfVevnv9er32TY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=kE4gfl++qDKOGUfNEx2vdfgjXs+ztn4NO4bc116yybhMqETziCpmyFuDPlJYIBmhNcqsrLzOL3PbiXcOojCAr4lq0JdBK0cebMV7KYUUvKUZn6rRxq7RtbH6zZHpDd8xjf+6ruCSotkA8qGd7bM0hjdb1TjBprBvTACTDPsZRfE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bd/A8J1Y; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bd/A8J1Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17BB61F000E9; Tue, 25 Aug 2026 22:59:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787698768; bh=/1WyjDxnV8R2fqjDzpFfx7uZc6rlmWRJj5thL9X3KUU=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=bd/A8J1YZ8iuxak8g8EwOdzefkyigBZhxoPR5MPxEeWm6XlrZpybaRDERNv4APOp3 AROJu+LBKyJUOtZ5gfR49LIFZDgOY/XIgY/v4B4Nzf58BsYNbNTnC88W5UjVaAHFYt j2fG6kUfj0cd9jfwIwJ7Yy+WAQoZiHJwfGCno/edYG5NZ3Xo5OjrbKvWgzNhltb2EL t+uRCZfHsz40c6Gd2wDPjdawbEGIsZNUN7R3MnNmjrRwX3RpPPpVFHJWhaYoD8GLb5 S62uVTZwbGMActCSYNsWowYp9zkNT5auM5aUC0rGzLg9pHYveZZTdF4EORf1+S9IFE ImUhDWUnRg2Tw== From: Thomas Gleixner To: Boqun Feng , Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] locking: Revert switching guards to _irq_{disable,enable}() In-Reply-To: References: <20260804161447.84806-8-boqun@kernel.org> <178635226387.442315.3868294476114711805.tip-bot2@tip-bot2> <20260824104704.GA4121339@noisy.programming.kicks-ass.net> <20260824105523.GA4121620@noisy.programming.kicks-ass.net> Date: Wed, 26 Aug 2026 00:59:25 +0200 Message-ID: <877bldhkmq.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Aug 24 2026 at 18:33, Boqun Feng wrote: > On Mon, Aug 24, 2026 at 12:55:23PM +0200, Peter Zijlstra wrote: >> >> While the guards are properly nested, not all wrapped code is nice, as already >> highlighted by that fair.c hunk. >> >> Syzbot found another instance of this pattern in posix_timer_delete(), which >> does spin_unlock_irq()+spin_lock_irq() inside scoped_guard(spinlock_irq). >> Combined with this patch, that goes sideways most spectacular. >> >> Undo this change, until we've developed stronger tools / debug for such issues. >> > > Mainly hand-waving, but if we make _irq(), irqsave(), _disable() > __acquires() different contexts, we may be able to catch these issues at > compile time. I will explore a bit on this. No. Just do a wholesale conversion of all functions which affect the CPU interrupt disabled state directly (local_irq_*) and indirectly (locking functions etc.) Anything else is just a whack a mole game. TBH, I do not understand why you thought that you can get away with this lazy approach especially after you discovered the same nasty problem in do_sched_cfs_period_timer(). The resolution of that got buried in 1b0866874833 ("locking: Switch to _irq_{disable,enable}() variants in cleanup guards") without even being mentioned. When I was discussing the non-sensical syzbot messages earlier today with Peter it immediately occurred to me that this undocumented change in do_sched_cfs_period_timer() is not the only pattern which causes this to go belly up. It took me five seconds to find the posix timer one. TBH, my hope really was that the RUST people take the only valid engineering principle "Correctness first" serious, but sadly they seem to be the same lazy sods than everyone else who want to push their agenda through no matter what. Thanks, tglx