From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 77062CAC59A for ; Thu, 18 Sep 2025 18:43:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=liLJhgZknOFrb3ADlwKcsc/J07rUAwg/dZtDpx06Vic=; b=BamKedeDiNFQcRpIFq7g10a/xO pXqXfFY5eJWLJonXuIwjlVnHSvR3KRIAcDXlkJxXIJ9eJM3H8J6cGMbdj9ZwSt6n9yEGGfuqh32wp K8tcl/Qj+KJaQQG8BmDBfo3LShpqDtdo1QTP+NdHKfuQdKwvSygRSkpYksmOnxyatXWTRPha7pqwG EDcfafUydRtHUWW1Z2KHTrQOPoY9+6e8jV/4FDO4ob6ZJiWrZ2s1ayLEWmlQjejqNRG9NbBzNpQGU vO8lyKgZ54zDuzE0hJz7QovI3LoajS+pkMCRgaZnTjoFGWGMqSlf//yTt2PRl7PwYhLO5kD8xAEPo MSgF3PaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uzJbN-00000000t2T-2aRR; Thu, 18 Sep 2025 18:43:29 +0000 Received: from [50.53.25.54] (helo=[192.168.254.17]) by bombadil.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1uzJbK-00000000t2F-3Pb9; Thu, 18 Sep 2025 18:43:26 +0000 Message-ID: Date: Thu, 18 Sep 2025 11:43:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC][PATCH v3 09/16] genirq/irqdesc: Have nr_irqs as non-static To: Eugen Hristev , Thomas Gleixner , David Hildenbrand , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, andersson@kernel.org, pmladek@suse.com, corbet@lwn.net, mhocko@suse.com Cc: tudor.ambarus@linaro.org, mukesh.ojha@oss.qualcomm.com, linux-arm-kernel@lists.infradead.org, linux-hardening@vger.kernel.org, jonechou@google.com, rostedt@goodmis.org, linux-doc@vger.kernel.org, devicetree@vger.kernel.org References: <20250912150855.2901211-1-eugen.hristev@linaro.org> <20250912150855.2901211-10-eugen.hristev@linaro.org> <87cy7q9k8y.ffs@tglx> <87a52u9jyl.ffs@tglx> <8df2cf28-c15e-4692-a127-6a5c966a965e@linaro.org> <2bd45749-e483-45ea-9c55-74c5ba15b012@redhat.com> <87v7lh891c.ffs@tglx> <95ff36c2-284a-46ba-984b-a3286402ebf8@redhat.com> <24d6a51d-f5f8-44d7-94cb-58b71ebf473a@linaro.org> <7f4aa4c6-7b77-422b-9f7a-d01530c54bff@redhat.com> <87segk9az5.ffs@tglx> <87jz1w88zq.ffs@tglx> Content-Language: en-US From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 9/18/25 6:53 AM, Eugen Hristev wrote: > > > So, one direction to follow from this discussion is to have the > inspection entry and inspection table for all these entries. > Now, one burning question open for debate, is, should this reside into mm ? > mm/inspect.h would have to define the inspection entry struct, and some > macros to help everyone add an inspection entry. > E.g. INSPECTION_ENTRY(my ptr, my size); > and this would be used all over the kernel wherever folks want to > register something. > Now the second part is, where to keep all the inspection drivers ? > Would it make sense to have mm/inspection/inspection_helpers.h which > would keep the table start/end, some macros to traverse the tables, and > this would be included by the inspection drivers. > inspection drivers would then probe via any mechanism, and tap into the > inspection table. Surely someone wants to inspect more than mm/ variables. I prefer kernel/inspect/ etc. > I am thinking that my model with a single backend can be enhanced by > allowing any inspection driver to access it. And further on, each > inspection driver would register a notifier to be called when an entry > is being created or not. This would mean N possible drivers connected to > the table at the same time. ( if that would make sense...) > Would it make sense for pstore to have an inspection driver that would > be connected here to get different kinds of stuff ? > Would it make sense to have some debugfs driver that would just expose > to user space different regions ? Perhaps something similar with > /proc/kcore but not the whole kernel memory rather only the exposed > inspection entries. > Now, for the dynamic memory, e.g. memblock_alloc and friends , > would it be interesting to have a flag e.g. MEMBLOCK_INSPECT, that would > be used when calling it, and in the background, this would request an > inspection_entry being created ? Or it makes more sense to call some > function like inspect_register as a different call directly at the > allocation point ? > > Feel free to throw your opinion at each of the above. > Thanks for helping out ! In general I like the way that this is going. Thanks to all of you for this discussion. -- ~Randy