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 0DEBB1EEA3C for ; Tue, 24 Mar 2026 20:31:59 +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=1774384320; cv=none; b=iDnyZBaqdSu8vovaDmbfmr5qxNoN0aLFgRtRl6/5jZT7lICTA1xXFQwboOg7+EIt+Moiomsltjou2wCJYgW98pgPy9btC9v91Trw9B+u3MmDouQmWbkyAjbtXwf2jzWRUmxzgG2fuErgI5d+BF7ys9gZOG2RXNhohvZQVWIsRlM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774384320; c=relaxed/simple; bh=Ev5zHtfeloLfzH4vh606gibDA+LewgNzWOXVXxwlc1o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Ja2334yQpJL0XIJadH+bNLI7F9TXoeFy72EXVAwTM4Ubci7sXD79Kxo82wLhouJvMljA+uoAqvPKrFKuhNc1kP8brWm0G05KrNc2J99NrRg8mPnrBhZgSlDLfIp3UTBCI3yQLuna8n+hTRGWSFUhqCgAlX9yqDaMXDDrlYp2hkI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G3Vu8q/5; 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="G3Vu8q/5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAA47C19424; Tue, 24 Mar 2026 20:31:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774384319; bh=Ev5zHtfeloLfzH4vh606gibDA+LewgNzWOXVXxwlc1o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G3Vu8q/5CdDKsZYinbDe1WqQ3OqE/JUSKcavFw7rhWtuPvGoad6H1lxXws3mEZdBV ObDFomfCRF/4A8NhlbrXhLEvdjMFbM8x9kIRg4sfjz00rIWsya5JIUwuvPkk9qJeDq JF9ePL1SFJnLzl8gpgWtI72EVF1LmBSTM11TLSv9c+dZPQFO6HS5ZHHAZHFA1anLTx I1Cw3Ns8+i7br9TiqgzUtwyXcyquuNdVsVpZCobZrloHGkFilFtSqgd9lP9Ugpy9al EY1Q8/aN+oZGug3RrAPSppsxGYLm/cORSbnr2f7qXde1keQBsuTJTLjTSG3nOIgs33 HFGCL0fHbCKFg== From: Thomas Gleixner To: Radu Rendec , LKML Cc: x86@kernel.org, Dmitry Ilvokhin , Neil Horman Subject: Re: [patch v2 06/14] genirq: Cache the condition for /proc/interrupts exposure In-Reply-To: <7d0dcf3dc90152a71de920dd22cc5eed57bab695.camel@rendec.net> References: <20260320131108.344376329@kernel.org> <20260320132102.431714412@kernel.org> <7d0dcf3dc90152a71de920dd22cc5eed57bab695.camel@rendec.net> Date: Tue, 24 Mar 2026 21:31:56 +0100 Message-ID: <87y0jhezpf.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 23 2026 at 16:58, Radu Rendec wrote: >> +void irq_proc_update_valid(struct irq_desc *desc) >> +{ >> + u32 set =3D _IRQ_PROC_VALID; >> + >> + if (irq_settings_is_hidden(desc) || !desc->action || >> + =C2=A0=C2=A0=C2=A0 irq_desc_is_chained(desc) || !desc->kstat_irqs) > > Can desc->kstat_irqs ever be NULL? Looking at kernel/irq/irqdesc.c, it > seems to me that it's allocated always and very early (before every > other field in struct irq_desc), and with an explicit check for NULL on > allocation. It's also deallocated late, right before struct irq_desc > itself is deallocated (in irq_kobj_release()). Well spotted. That's a left over from histerical code.