{"id":2224181,"url":"http://patchwork.ozlabs.org/api/covers/2224181/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-pci/cover/1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com/","project":{"id":28,"url":"http://patchwork.ozlabs.org/api/projects/28/?format=json","name":"Linux PCI development","link_name":"linux-pci","list_id":"linux-pci.vger.kernel.org","list_email":"linux-pci@vger.kernel.org","web_url":null,"scm_url":null,"webscm_url":null,"list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>","list_archive_url":null,"date":"2026-04-17T02:26:04","name":"[v2,0/3] Add Devres managed IRQ vectors allocation","submitter":{"id":66993,"url":"http://patchwork.ozlabs.org/api/people/66993/?format=json","name":"Shawn Lin","email":"shawn.lin@rock-chips.com"},"mbox":"http://patchwork.ozlabs.org/project/linux-pci/cover/1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com/mbox/","series":[{"id":500223,"url":"http://patchwork.ozlabs.org/api/series/500223/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-pci/list/?series=500223","date":"2026-04-17T02:26:06","name":"Add Devres managed IRQ vectors allocation","version":2,"mbox":"http://patchwork.ozlabs.org/series/500223/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/2224181/comments/","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\tdkim=pass (1024-bit key;\n unprotected) header.d=rock-chips.com header.i=@rock-chips.com\n header.a=rsa-sha256 header.s=default header.b=iNJX3MJg;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52679-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com\n header.b=\"iNJX3MJg\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=220.197.31.99","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=rock-chips.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=rock-chips.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4fxfn829lxz1yD3\n\tfor ; Fri, 17 Apr 2026 13:02:20 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 58C633005D18\n\tfor ; Fri, 17 Apr 2026 03:02:17 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 84FB6199D8;\n\tFri, 17 Apr 2026 03:02:16 +0000 (UTC)","from mail-m1973199.qiye.163.com (mail-m1973199.qiye.163.com\n [220.197.31.99])\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 05C741C695\n\tfor ; Fri, 17 Apr 2026 03:02:12 +0000 (UTC)","from localhost.localdomain (unknown [58.22.7.114])\n\tby smtp.qiye.163.com (Hmail) with ESMTP id 3b1199afc;\n\tFri, 17 Apr 2026 10:26:34 +0800 (GMT+08:00)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776394936; cv=none;\n b=L/w18Hr46khvyD9mL7xim4pB+6EypICabCF0IBo7neCqJ8ZtbR09DRfAI+0rpHMdxyTBXlYy0cOwsCfFSIHjBVc+bE7Gt1oYM4D6O9VKCyymxlt38Cq6xsj6cCPFgkrVF/2byMad3N0YpfXxYq6h8HGK3KeLQA0HvxY1D0G3k5c=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776394936; c=relaxed/simple;\n\tbh=5I8iwT0tu4NPwlaMTrabKRKsi5KYVx5J+lotCNGb1Q0=;\n\th=From:To:Cc:Subject:Date:Message-Id;\n b=X4gygDv6qcx2DrumQG7f6UMKufc5aujV6ED768gVK9WrCCLQB0lXLoIpZ5NMHGatPGCaNhx0vvPnaLmbDfpGS9gzF36UgXowgTupAWqEukM9Zz0YErDboCj9nYvYiaBlUCnKQCMyiPw6O1958qIX2bUAs5r7fwWZOIOxxPehxns=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=rock-chips.com;\n spf=pass smtp.mailfrom=rock-chips.com;\n dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com\n header.b=iNJX3MJg; arc=none smtp.client-ip=220.197.31.99","From":"Shawn Lin ","To":"Bjorn Helgaas ","Cc":"Nirmal Patel ,\n\tJonathan Derrick ,\n\tKurt Schwemmer ,\n\tLogan Gunthorpe ,\n\tPhilipp Stanner ,\n\tlinux-pci@vger.kernel.org,\n\tShawn Lin ","Subject":"[PATCH v2 0/3] Add Devres managed IRQ vectors allocation","Date":"Fri, 17 Apr 2026 10:26:04 +0800","Message-Id":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>","X-Mailer":"git-send-email 2.7.4","X-HM-Tid":"0a9d9942f11a09cckunm63489ccb2f73b5","X-HM-MType":"1","X-HM-Spam-Status":"e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly\n\ttZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZGh1PTlZJHhpOTRpOSUpOT0hWFRQJFh\n\toXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0\n\thVSktLVUpCS0tZBg++","DKIM-Signature":"a=rsa-sha256;\n\tb=iNJX3MJgqqpUUcTTx+H1H3YwHpWkK0S/GDO1HEjCc4GJVa2Gx64EOwar8TNGtIvHrXpfoMvaNWdVERRXncnNVC1DM7AO22FUXPfgEpYfaaSxsMxmSN1k9SvnB0gFmRXZzkryVvyj9JRwjtH+wAeD/a3DWl2AcEGNQUvs0sHy00U=;\n c=relaxed/relaxed; s=default; d=rock-chips.com; v=1;\n\tbh=Q2FK+BWAcl4wrxF1/z88dYL9ZcSlGl63S2mjyM2zLGs=;\n\th=date:mime-version:subject:message-id:from;","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""},"content":"There is a long-standing design issue in the PCI/MSI subsystem where the\nimplicit, automatic management of IRQ vectors by the devres framework\nconflicts with explicit driver cleanup, creating ambiguity and potential\nresource management bugs.\n\nHistorically, `pcim_enable_device()` not only manages standard PCI resources\n(BARs) via devres but also implicitly triggers automatic IRQ vector management\nby setting a flag that registers `pcim_msi_release()` as a cleanup action.\n\nThis creates an ambiguous ownership model. Many drivers follow a pattern of:\n1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.\n2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.\n\nWhen such a driver also uses `pcim_enable_device()`, the devres framework may\nattempt to free the IRQ vectors a second time upon device release, leading to\na double-free. Analysis of the tree shows this hazardous pattern exists widely,\nwhile 35 other drivers correctly rely solely on the implicit cleanup.\n\nThis series introduces new managed APIs: pcim_alloc_irq_vectors()and\npcim_alloc_irq_vectors_affinity(). Drivers that wish to have devres-managed IRQ\nvectors should use these functions. They appropriately set the is_msi_managed\nflag and ensure proper automatic cleanup.\n\nIn the short term, the series converts two drivers within the PCI subsystem to\nuse the new APIs. The long-term goal is to convert all other drivers to use these\nmanaged functions, and finally to remove the problematic hybrid management pattern\nfrom pcim_enable_device() entirely.\n\n\nChanges in v2:\n- Rebase\n- Introduce patches only for PCI subsystem to convert the API\n\nShawn 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 | 26 ++++++++++++++++++++++++++\n drivers/pci/switch/switchtec.c | 6 +++---\n include/linux/pci.h | 22 ++++++++++++++++++++++\n 4 files changed, 53 insertions(+), 5 deletions(-)"}