[{"id":3680254,"web_url":"http://patchwork.ozlabs.org/comment/3680254/","msgid":"<9dc66010d61670dc5182062ef5f1a932f7374323.camel@mailbox.org>","list_archive_url":null,"date":"2026-04-22T07:11:08","subject":"Re: [RESEND PATCH v3 0/3] Add Devres managed IRQ vectors allocation","submitter":{"id":90407,"url":"http://patchwork.ozlabs.org/api/people/90407/","name":"Philipp Stanner","email":"phasta@mailbox.org"},"content":"Hi,\n\nI did receive your first send-out of this v3. In case of doubt it's\npossible to check on lore.kernel.org whether it was actually sent out.\n\nOn Wed, 2026-04-22 at 10:38 +0800, Shawn Lin wrote:\n> \n> There is a long-standing design issue in the PCI/MSI subsystem where the\n> implicit, automatic management of IRQ vectors by the devres framework\n> conflicts with explicit driver cleanup, creating ambiguity and potential\n> resource management bugs.\n> \n> Historically, pcim_enable_device() not only manages standard PCI resources\n> (BARs) via devres\n> \n\nJFYI, it doesn't do that anymore, since I fully removed that.\n\nWhat is left though is the weird \"plural functions\",\npcim_iomap_regions().\n\nI've done some work to also remove them, but it's a lot of work, and\nespecially the ATA subsystem is relatively difficult to port.\n\n> but also implicitly triggers automatic IRQ vector management\n> when calling pci_alloc_irq_vectors[_affinity], because pcim_enable_device()\n> sets is_managed flag, thus pcim_msi_release() will register a cleanup action.\n> \n> This creates an ambiguous ownership model. Many drivers follow a pattern of:\n> 1. Calling pci_alloc_irq_vectors() to allocate interrupts.\n> 2. Also calling pci_free_irq_vectors() in their error paths or remove routines.\n> \n> When such a driver also uses pcim_enable_device(), the devres framework may\n> attempt to free the IRQ vectors a second time upon device release, leading to\n> a double-free. Analysis of the tree shows this hazardous pattern exists widely,\n> while 35 other drivers correctly rely solely on the implicit cleanup.\n\nAlso just as an idea: for your removal strategy it's probably a good\nidea to carry a list of the problematic drivers along, if that's not\ntoo much work. Once created, you could continuously update it on your\nmachine, to keep track and later to provide evidence when you finally\nremove the API. That \"35 other drivers\" do it *correctly* isn't really\nthat useful to know; what's important is to know who might explode.\n\nI did it this way:\nhttps://lore.kernel.org/linux-pci/20250519112959.25487-2-phasta@kernel.org/\n\nThat then helps the maintainer to fearlessly merge your final removal,\nbuilding trust that the drivers are safe.\n\n> \n> This series introduces new managed APIs: pcim_alloc_irq_vectors()and\n> pcim_alloc_irq_vectors_affinity(). Drivers that wish to have devres-managed IRQ\n> vectors should use these functions. They are currently the same as non-devres\n> managed version. In the short term, the series converts two drivers within the\n> PCI subsystem to use the new APIs. The long-term goal is to convert all other\n> drivers which wish to use these managed functions, and finally to remove the\n> problematic hybrid management pattern from pcim_enable_device() and\n> pcim_setup_msi_release() entirely.\n\n10/10\n\nP.\n\n> \n> \n> Changes in v3:\n> - Rework the commit message and function doc (Philipp)\n> - Remove setting is_msi_managed flag from new APIs (Philipp)\n> \n> Changes in v2:\n> - Rebase\n> - Introduce patches only for PCI subsystem to convert the API\n> \n> Shawn Lin (3):\n>   PCI/MSI: Add Devres managed IRQ vectors allocation\n>   PCI: switchtec: Replace pci_alloc_irq_vectors() with\n>     pcim_alloc_irq_vectors()\n>   PCI: vmd: Replace pci_alloc_irq_vectors() with\n>     pcim_alloc_irq_vectors()\n> \n>  drivers/pci/controller/vmd.c   |  4 ++--\n>  drivers/pci/msi/api.c          | 47 ++++++++++++++++++++++++++++++++++++++++++\n>  drivers/pci/switch/switchtec.c |  6 +++---\n>  include/linux/pci.h            | 22 ++++++++++++++++++++\n>  4 files changed, 74 insertions(+), 5 deletions(-)\n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52926-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org\n header.b=\"kV28y8qs\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=80.241.56.171","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=mailbox.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=mailbox.org"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0r9P1JQDz1yCv\n\tfor ; Wed, 22 Apr 2026 17:15:53 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 442FE308C389\n\tfor ; Wed, 22 Apr 2026 07:11:28 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DCFB936AB72;\n\tWed, 22 Apr 2026 07:11:22 +0000 (UTC)","from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 3047C36C0AB\n\tfor ; Wed, 22 Apr 2026 07:11:19 +0000 (UTC)","from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby mout-p-201.mailbox.org (Postfix) with ESMTPS id 4g0r435Y86z9ty0;\n\tWed, 22 Apr 2026 09:11:15 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776841882; cv=none;\n b=IIYwjp9CiUAiSz7LPXbGQKXuMowFQQ+DkPpkoCgnc7Ygpn1PSFfFX009wV5KBswzjHHj0gt99tNSbsh4q2h1EWXCrGOhFzjmxbdY6WMqE89sraAb3Y8sVKnqcNeOl9/Xmoqt898USSdlJrX/2oAbVKrazp4D5D6IHkjEVpwqDMU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776841882; c=relaxed/simple;\n\tbh=FCKztHHPrRwKwFmi6IgL0OZ0vw8BFnqNPc8MOCk1CJY=;\n\th=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:\n\t Content-Type:MIME-Version;\n b=dOqSZmhVm6dnt5fO4KIv7mis4+dEqqQOFEWhAj48Hyt5j5jaj9gtLr/whxnBUgF2Y/ydyVX256PHtcDd6G8Gvec2YteuZcmYbmWiEmcZNn+eK/6QwrQ/WgMh+hb+avZK5VePuc6CH5XgWOiLBN1mxtYc8/BPkZFPl84vD4/RnRw=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=mailbox.org;\n spf=pass smtp.mailfrom=mailbox.org;\n dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org\n header.b=kV28y8qs; arc=none smtp.client-ip=80.241.56.171","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org;\n s=mail20150812;\n\tt=1776841875; h=from:from:reply-to:reply-to:subject:subject:date:date:\n\t message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n\t content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=RmfhNBwa+8iw7/m2w2odHWWyYD5Z0Obf0O6CkCtHanI=;\n\tb=kV28y8qsjeWXa6Ogd0t+2ekE8XuP41x86Q59Q5yvYAh5P7Y+zrSDX//wyUxUZGW1JCsywZ\n\t1VKr9LH4nd3OT+JrRl4cDhvorkyidVBAVkKt9vOiE+c1vuO6TqOCMzvLbwp0MKdg3lXhhO\n\tsWLQkJ5hdhfuHnQ4FMIM6nxYM7YAzL+v4jNQGPCI7rG/wTEBSknojlKI8f2Vz+/txeJgho\n\tOv0GfYiirPVkfKVBifqprLIB/+aOnLA/WcQTh4wSihNlS2M+Q1SecXz+oJkFYwyJVWeBLY\n\thLPXScX9Pth+qQjMLlnCZi6yx9LH4wFtMko0aujII2JU/SqPKgFD7zjjXVrCQA==","Message-ID":"<9dc66010d61670dc5182062ef5f1a932f7374323.camel@mailbox.org>","Subject":"Re: [RESEND PATCH v3 0/3] Add Devres managed IRQ vectors allocation","From":"Philipp Stanner ","Reply-To":"phasta@kernel.org","To":"Shawn Lin , Bjorn Helgaas ","Cc":"Nirmal Patel , Jonathan Derrick\n , Kurt Schwemmer\n , Logan Gunthorpe ,\n Philipp Stanner , linux-pci@vger.kernel.org","Date":"Wed, 22 Apr 2026 09:11:08 +0200","In-Reply-To":"<1776825522-6390-1-git-send-email-shawn.lin@rock-chips.com>","References":"<1776825522-6390-1-git-send-email-shawn.lin@rock-chips.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MBO-RS-ID":"66b62ac848d6b6fb81c","X-MBO-RS-META":"8yz1m393brjhg3zaoq1riysswp3jjd4q"}}]