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 7F545346E43 for ; Thu, 26 Mar 2026 21:26:03 +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=1774560363; cv=none; b=sIH0k9rZ6KWPK6eSOAMJ3yr9a53YwY2K13JGCnnD/owtiEAuKaZKq+RafmtcquP0J2Nm5fd9wTQ+Gg/+em00TcBhgSiNZQDfu22AFFBaI3/aGvq3VBkk3pUSI49SvOrQIaP7V5lUC5JD0fmWkT7Flyaj6gd2+HN7OPCzrlkQYuI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774560363; c=relaxed/simple; bh=YPVvb69Ct7P7pLfRFhk8qYx5XApaGilAwT+4xfL/A58=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=E2itLT0fZck1zmmM76wWywd6+wxeO4ufrDFlBleqjQgC5hJKBcxLuL1bWenf2mVLbRLe++fWQFu+vh0TimTwVdRYiWRZCI4bOchuxslvFG05sJd9pcHR6iJybnWkTPL4YfvpyNY99a32t9QhLCr5I0HCgLDVFlKz+2hkN8x8N2M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=je481RJa; 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="je481RJa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0AB5C116C6; Thu, 26 Mar 2026 21:26:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774560363; bh=YPVvb69Ct7P7pLfRFhk8qYx5XApaGilAwT+4xfL/A58=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=je481RJay1VUNfuIKpOKAXXoRKSW3Js5w0SgX/2hcYdm0q12nQ2t6rMcxXFqoxVeT tcv7aL5G6QEbx2cDSJEPTn1SWaWn32H51dijnIcU7UU3tq/dkqsCtxBRQvAMHiKvkU /37RNvZAb7LRhfsNwN96rMdyfbkYsJn+Rl6+RFNgsiiHlXo1hNXo8sYFw4DIcJgT1j CYH27BdnClv6SUE4DZdJbxd/x8fo8w4Sedbhx6Fa/Qie2LbxL6J7omkeYgVcyGt7Jt PtXC7spTCNnbdQMUPfgKxTK+3DboLgE2jU3+5oJ2FzB02knI+lPOWbl1gq+mh7affj xdpwEuzdbDYmA== From: Thomas Gleixner To: Dmitry Ilvokhin Cc: LKML , x86@kernel.org, Neil Horman , Radu Rendec Subject: Re: [patch v2 09/14] genirq: Expose irq_find_desc_at_or_after() in core code In-Reply-To: <87h5q2cn4f.ffs@tglx> References: <20260320131108.344376329@kernel.org> <20260320132102.638201987@kernel.org> <87h5q2cn4f.ffs@tglx> Date: Thu, 26 Mar 2026 22:25:58 +0100 Message-ID: <87ecl6cmft.ffs@tglx> 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 Thu, Mar 26 2026 at 22:11, Thomas Gleixner wrote: > On Thu, Mar 26 2026 at 19:13, Dmitry Ilvokhin wrote: >>> -static unsigned int irq_find_at_or_after(unsigned int offset) >>> +struct irq_desc *irq_find_desc_at_or_after(unsigned int offset) >>> { >>> unsigned long index = offset; >>> - struct irq_desc *desc; >>> - >>> - guard(rcu)(); >> >> Is the drop of guard(rcu)() intentional here? irq_get_next_irq() >> dereferences the returned pointer after mt_find() has dropped >> rcu_read_unlock(). Should it hold its own guard(rcu)() to keep the same >> behaviour as before? > > Good catch. The caller of irq_find_at_or_after() needs to hold it. Just double checked. I have lockdep enabled, but it can't catch it the way the code is written. The new iterater code holds it otherwise rcuref_get() would have triggered it. I've added it back and added a lockdep assert into irq_find_at_or_after(). You just caught it before I was preparing the V3 post. Let me re-run the test before I do so. Thanks, tglx