From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 7F4553328ED; Mon, 23 Feb 2026 17:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771868336; cv=none; b=S0TDDsvzZx6kNRvbVQgbRkKM8whhRbD1pOF1b8Qh5ncKju18ZJ1Hbz9RP1NOs8xq/4FSDTMxBza9tuPy2PsrFsjUP0OGDCBVC8QmRHJamUDbiq4ImrTmyQTQgGChdBN6PvUreolfdM3m83/vBxR7LVSjmBMoheYxCv95brtT2aM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771868336; c=relaxed/simple; bh=OFs+F2i4fpeRmsTH7tUJ5hO0npgCDxBo25FPhTX/hFs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FE0pNcsIdieHenKdz4s0nolqaxsrB3RIVp71Iabx+AgxS75Z5+p/sIj9saDfKA97vI9w7LRFRfYShrGoDlpMBS2btFk5miAzjNNuM0oxvFeZjOXtPCxARM2sACeTlCqWH0jJIlKbNeP5II3760TLhyAk6qLk8VEY7qaBCBoSV4k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=NvMPcrsr; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="NvMPcrsr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771868335; x=1803404335; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=OFs+F2i4fpeRmsTH7tUJ5hO0npgCDxBo25FPhTX/hFs=; b=NvMPcrsrscxq4yCJYNHBwma5dXpYiaLlpl5YaiHU4AbKmW1dss4zVpgH eKc6wHV4HSpKqyOZ8UlLVlghXkur2gCHm4j/0tVPiKMiMs8WIyTYBU/2a 6yowW4cOU55qzj4P1UFjG06x85lKFyOgcBuajicG0+hQ7xUZWW5IVie0T CzejcQppfEPzmSpHn0vPl0BWBUbMvv0s0ke5e+Qjssqu807Hmk7eyaE7j rAcT4p6XKH7FNn0xujYAvGZ00DAcOtrZCn+DLE46UjHdqz7MQNGpBv4ef eZ4zNkJ8cO1QoE+PCo+ORxkR4NcdogZJ2/EBVMiLNS/FtyyTrgvpBtjZv g==; X-CSE-ConnectionGUID: jsfaBeNbRdOcjkAScBt/AA== X-CSE-MsgGUID: qC3ahawxSriUb3w5OK63yQ== X-IronPort-AV: E=McAfee;i="6800,10657,11710"; a="73050398" X-IronPort-AV: E=Sophos;i="6.21,307,1763452800"; d="scan'208";a="73050398" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2026 09:38:54 -0800 X-CSE-ConnectionGUID: i7eZdD4uRr+gNr/ct2htpA== X-CSE-MsgGUID: B0cv0ytAS2ClRPRHaDlf4w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,307,1763452800"; d="scan'208";a="214708424" Received: from abityuts-desk.ger.corp.intel.com (HELO localhost) ([10.245.245.222]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2026 09:38:36 -0800 Date: Mon, 23 Feb 2026 19:38:33 +0200 From: Andy Shevchenko To: Shawn Lin Cc: Andy Shevchenko , Bjorn Helgaas , "Vaibhaav Ram T . L" , Kumaravel Thiagarajan , Even Xu , Xinpeng Sun , Srinivas Pandruvada , Jiri Kosina , Alexandre Belloni , Zhou Wang , Longfang Liu , Vinod Koul , Lee Jones , Jijie Shao , Jian Shen , Sunil Goutham , Andrew Lunn , Heiner Kallweit , "David S . Miller" , Jeff Hugo , Oded Gabbay , Maciej Falkowski , Karol Wachowski , Min Ma , Lizhi Hou , Andreas Noever , Mika Westerberg , Tomasz Jeznach , Will Deacon , Xinliang Liu , Tian Tao , Davidlohr Bueso , Jonathan Cameron , Srujana Challa , Bharat Bhushan , Antoine Tenart , Herbert Xu , Raag Jadav , Hans de Goede , Greg Kroah-Hartman , Jiri Slaby , Andy Shevchenko , Manivannan Sadhasivam , Mika Westerberg , Andi Shyti , Robert Richter , Mark Brown , Nirmal Patel , Kurt Schwemmer , Logan Gunthorpe , Linus Walleij , Bartosz Golaszewski , Sakari Ailus , Bingbu Cao , Ulf Hansson , Arnd Bergmann , Benjamin Tissoires , linux-input@vger.kernel.org, linux-i3c@lists.infradead.org, dmaengine@vger.kernel.org, Philipp Stanner , netdev@vger.kernel.org, nic_swsd@realtek.com, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-usb@vger.kernel.org, iommu@lists.linux.dev, linux-riscv@lists.infradead.org, David Airlie , Simona Vetter , linux-cxl@vger.kernel.org, linux-crypto@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-serial@vger.kernel.org, mhi@lists.linux.dev, Jan Dabros , linux-i2c@vger.kernel.org, Daniel Mack , Haojian Zhuang , linux-spi@vger.kernel.org, Jonathan Derrick , linux-pci@vger.kernel.org, linux-gpio@vger.kernel.org, Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-mmc@vger.kernel.org Subject: Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free Message-ID: References: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Tue, Feb 24, 2026 at 12:09:37AM +0800, Shawn Lin wrote: > 在 2026/02/23 星期一 23:50, Andy Shevchenko 写道: > > On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin wrote: > > > > > > This patch series addresses a long-standing design issue in the PCI/MSI > > > subsystem where the implicit, automatic management of IRQ vectors by > > > the devres framework conflicts with explicit driver cleanup, creating > > > ambiguity and potential resource management bugs. > > > > > > ==== The Problem: Implicit vs. Explicit Management ==== > > > Historically, `pcim_enable_device()` not only manages standard PCI resources > > > (BARs) via devres but also implicitly triggers automatic IRQ vector management > > > by setting a flag that registers `pcim_msi_release()` as a cleanup action. > > > > > > This creates an ambiguous ownership model. Many drivers follow a pattern of: > > > 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts. > > > 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines. > > > > > > When such a driver also uses `pcim_enable_device()`, the devres framework may > > > attempt to free the IRQ vectors a second time upon device release, leading to > > > a double-free. Analysis of the tree shows this hazardous pattern exists widely, > > > while 35 other drivers correctly rely solely on the implicit cleanup. > > > > Is this confirmed? What I read from the cover letter, this series was > > only compile-tested, so how can you prove the problem exists in the > > first place? > > Yes, it's confirmed. My debug of a double free issue of a out-of-tree > PCIe wifi driver which uses > pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose > it. And we did have a TODO to cleanup this hybrid usage, targeted in > this cycle[1] suggested by Philipp: Okay, fair enough. I think this bit was missing in the cover letter. > [1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi > > > ==== The Solution: Making Management Explicit ==== > > > This series enforces a clear, predictable model: > > > 1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and > > > pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ > > > vectors should use these functions, which set the is_msi_managed flag and > > > ensure automatic cleanup. > > > 2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside > > > pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead > > > make an explicit call to pcim_alloc_irq_vectors(). > > > 3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release() > > > to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from > > > pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*() > > > are now solely the driver's responsibility to free with pci_free_irq_vectors(). > > > > > > With these changes, we clear ownership model: Explicit resource management eliminates > > > ambiguity and follows the "principle of least surprise." New drivers choose one model and > > > be consistent. > > > - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control. > > > - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup. > > > > Have you checked previous attempts? Why is your series better than those? > > There seems not previous attempts. Maybe we are looking to the different projects... https://lore.kernel.org/all/?q=pcim_alloc_irq_vectors > > > ==== Testing And Review ==== > > > 1. This series is only compiled test with allmodconfig. > > > 2. Given the substantial size of this patch series, I have structured the mailing > > > to facilitate efficient review. The cover letter, the first patch and the last one will be sent > > > to all relevant mailing lists and key maintainers to ensure broad visibility and > > > initial feedback on the overall approach. The remaining subsystem-specific patches > > > will be sent only to the respective subsystem maintainers and their associated > > > mailing lists, reducing noise. -- With Best Regards, Andy Shevchenko