From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out162-62-58-211.mail.qq.com (out162-62-58-211.mail.qq.com [162.62.58.211]) (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 1563637C113 for ; Tue, 3 Feb 2026 06:30:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.62.58.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770100233; cv=none; b=WDLfhuaAYymVIH877npEJTK1hRo1/wnmwjAfQzhtqoEwg0sCpUo+yBU58SX0GEVG5K23WXgU+lEolfhFUewT7lrXLDPKt/2YjwLThSE+8h13htJt88FHMhrQX8leJd6OAYvtOKgJtzrRaJiv+JilasxeFZK3iRb5vIDRuBMKmfc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770100233; c=relaxed/simple; bh=0ahih13/8CzL4DmNtyTIPaOxjMHfVV5fe8gQRJSL15Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Odp4PNRLKJKUmt7m9wIHS1RbHkQXVYB1Xm/6NP2P4EU+L77xirCPKPtK2ZxI1RSMuDOW5lmuPFypntPLLbuCmAZWS17p2WzM9Avm9vMp4FxYmgg0HZW+9thXQCaJB68bhjbBh+ySpDd0TV9nB+Pi8J5YABCRBz2Ddh9qOW/RBdw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cyyself.name; spf=pass smtp.mailfrom=cyyself.name; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=buNFLbiE; arc=none smtp.client-ip=162.62.58.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=cyyself.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cyyself.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="buNFLbiE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1770100218; bh=J6i3SfJy1FFq5zoEP4voxTguXwnbJkmRIJOWhslnr74=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=buNFLbiExkpWrXSazEoRpZYaYYal/nml1t3sfSAsTRQRumAUsnhBKWEXWG8aXFAGT i4aO/H2WdrD/Tv+jRcYq7cRcCgtj5m8bYI6HGGXFIh40u/keyYLe+9YB1wEImEWv5m /ikZpXS+qMnyuK4yRzJcPDOt5VQNKMwEfyZs8ZEs= Received: from [IPV6:240e:379:2263:bd00:24ee:5528:4309:3f25] ([240e:379:2263:bd00:24ee:5528:4309:3f25]) by newxmesmtplogicsvrsza63-0.qq.com (NewEsmtp) with SMTP id 78E2C081; Tue, 03 Feb 2026 14:30:14 +0800 X-QQ-mid: xmsmtpt1770100214tp5rxqopx Message-ID: X-QQ-XMAILINFO: M+5cKLn0wXDt3xkmsxyjSlflhvV2t9Ocg0tpqPZuFCAS51hJIkp1YY0Ypoz0fW CBI9lLSvMQT9LPOt8R2iOX9B7FkuzRDSgRT0QEYlJhZvZUbF9ze+3z9pcBxci+dUwlJs5L+0CX2P YsIvDmnYmlh014o4bCjQUlIlaJZUQ9BiiiExzWb4h0DW7Oeje3PbkcxMOSpeA23aNYhnhvH/QfUM a0j0ZfxfXBGKxHMh/yMpaStjxTdiBmZtgv6o6Lx1tWh+aGuAwcLOT9ISyyxt7+0r+/DTYPwfl7vA fsLc6NeRWxXJ4o5m5kfid+hkKKGm3LRyhpkQT86rkrzrn6Wwz2poKIDimhPuYYTdbDnVzLbt+d7v WVRQM7Y+GBdbzU91cricdJylXH38GGCcx8Br1kwBpGbbPbXzJjGjLdKSQYp/yC3O1mx73T2q70tl Am5SOum/0HA/s6mELWIAvW6giOuB0sEr6OzykGGfc45Vy5eqvhGaYhZsdZZVxFslVBbjO99gx4LB JINkdhONNymxifNkzifXdsuzZaFyUh4aIR3FxTCIvR/J2CzsHK3ch0U+S+Ppi76MsmplouILxyja 2fBT+Sj5tWeEyTxMN72ey02TKDRaKAVeHnWIiNtuyYiIgF7TGSCSWygJ86yWguzHmsw1PGfQn5Rh dWJ3pKBPnJir4bnXlsRitdR4XKmoMMZA3jnklCsc8Ci5dhw5aRgi8uSbe4KD5iRxpPitmZBCwfb9 g2DYijdRCRIJi9w9Pb9+7ZWaOncFu8329/vb40+1EWfYaaH4esv5LXC2cXpHG7GOlBuTeaXL62pV r4o+vuKK3MjsQsBZduJyrvNdU+JI/Enhu6tVGCztupw3FZVXH7OpNYqoQudxplO/7C9fCKxIAIKs zW3wAj434TtBVWtUZgfXHsl6xhs+pB4xhYMUCGiM094IwftybX5OMqfpNot7hZkhY2iQXu6xY5NB tE7fTrt9OvFiVzoEQlwYMky0UjeR/PvGAXOtNQ4A70u3jxyAxG5ZhQYvVDydOXDFOmutmnLEvxBa +xudE6YxaQ9vv4CwUOZ4T92YhOL22bLsqSXFhA0ChGzh2SOEcstCourlhhgcA= X-QQ-XMRINFO: MSVp+SPm3vtSI1QTLgDHQqIV1w2oNKDqfg== X-OQ-MSGID: <58510fbb-f3ed-4b79-8acb-082fed1ea4b2@cyyself.name> Date: Tue, 3 Feb 2026 14:30:14 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] irqchip/sifive-plic: Fix insufficient irq_groups allocation To: Thomas Gleixner , linux-riscv@lists.infradead.org Cc: linux-kernel@vger.kernel.org, Anup Patel , Samuel Holland , Charles Mirabile , Lucas Zampieri , Paul Walmsley , Palmer Dabbelt , Mason Huo , Zhang Xincheng , Charlie Jenkins , Marc Zyngier , Sia Jee Heng , Ley Foon Tan References: <87bjifavyu.ffs@tglx> Content-Language: en-US From: Yangyu Chen In-Reply-To: <87bjifavyu.ffs@tglx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 27/1/2026 23:58, Thomas Gleixner wrote: > On Wed, Jan 21 2026 at 13:45, Yangyu Chen wrote: >> Since the first irq source is 1 instead of 0, when the number of >> irqs is multiple of 32, the last irq group will be ignored during >> allocation, saving, and restoring. This lead to memory corruption >> when accessing enable_save beyond allocated memory after commit >> 14ff9e54dd14 ("irqchip/sifive-plic: Cache the interrupt enable state") >> which will access enable_save for all sources during plic_probe. >> Thus, we should allocate irq_groups based on (nr_irqs + 1) instead of >> nr_irqs to avoid this issue. >> >> This is an long standing bug since Linux v6.4 but since the last irq >> source is rarely used, it may not be triggered in practice until commit >> 14ff9e54dd14 ("irqchip/sifive-plic: Cache the interrupt enable state"). > > I'm absolutely not convinced that this is the right fix. The handling of > nr_irqs in this driver is completely inconsistent: > > 1) > > static int plic_irq_suspend(void *data) > /* irq ID 0 is reserved */ > for (unsigned int i = 1; i < priv->nr_irqs; i++) { > > 2) > static void plic_irq_resume(void *data) > /* irq ID 0 is reserved */ > for (unsigned int i = 1; i < priv->nr_irqs; i++) { > ... > for (i = 0; i < DIV_ROUND_UP(priv->nr_irqs, 32); i++) { > > 3) > > static irq_hw_number_t cp100_get_hwirq(struct plic_handler *handler, void __iomem *claim) > int nr_irq_groups = DIV_ROUND_UP(handler->priv->nr_irqs, 32); > > for (i = 0; i < nr_irq_groups; i++) { > 4) > > static int plic_probe(struct fwnode_handle *fwnode) > > priv->prio_save = bitmap_zalloc(nr_irqs, GFP_KERNEL); > ... > for (int j = 0; j <= nr_irqs / 32; j++) > writel(0, enable_base + j); > ... > handler->enable_save = kcalloc(DIV_ROUND_UP(nr_irqs, 32),... > ... > for (hwirq = 1; hwirq <= nr_irqs; hwirq++) { > ... > priv->irqdomain = irq_domain_create_linear(fwnode, nr_irqs + 1, > > So can the SIFIVE people please clarify once and forever what's the > actual meaning of nr_irqs: > > A) The actual number of hardware interrupts available for drivers > starting from hwirq=1 > > B) The total number of hardware interrupts, where hwirq=0 is reserved > and therefore the number of interrupts available to drivers is > nr_irqs - 1. > > That needs to be clarified first and then subsequently every single > instance which deals with nr_irqs has to be updated accordingly. > Totally agree! But there is no comment after 1 week. There's also some consideration of the actual device tree. I discovered that the Canaan K210 has only 64 interrupt sources (excluding 0), but its device tree (dts) has PLIC with ndev=65. [1] On the other hand, the ESWIN EIC7700 has 520 interrupt sources, but its dts has ndev=520. [2] This indicates that existing device trees already have some issues. Fortunately, other platforms like the cv1800b [3] have ndev=101 and the source ID 101 is used for mbox. Popular platforms like the JH7110 [4] and SG2042 [5] also show additional interrupts in their device trees that the SoC doesn’t actually use. In my opinion, the best practice would be option A and: 1. Note that the "riscv,ndev" value for PLIC represents the actual number of hardware interrupts available for drivers in the dt-binding. (This aligns with your option A.) 2. Fix all existing drivers to meet option A. 3. Since the K210 is only used in M-Mode with its built-in dts, we can modify its dts to change the "riscv,ndev" value from 65 to 64. I will make such changes for this patch revision if there are no objections. [1] https://cdn.hackaday.io/files/1654127076987008/kendryte_datasheet_20181011163248_en.pdf [2] https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases/download/v1.0.0-20250103/EIC7700X_SoC_Technical_Reference_Manual_Part1.pdf [3] https://github.com/milkv-duo/duo-files/blob/main/duo/datasheet/CV1800B-CV1801B-Preliminary-Datasheet-full-en.pdf [4] https://doc-en.rvspace.org/JH7110/PDF/JH7110_Datasheet.pdf [5] https://github.com/milkv-pioneer/pioneer-files/blob/main/hardware/SG2042-TRM.pdf Thanks, Yangyu Chen > A random fix which cures the symptom of an out of bounds memory access > is not helpful at all to cure the underlying root cause of > inconsistency. > > Thanks, > > tglx >