[{"id":3686707,"web_url":"http://patchwork.ozlabs.org/comment/3686707/","msgid":"<20260505211722.09ACFC2BCB4@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-05T21:17:21","subject":"Re: [PATCH 3/3] PCI/IOV: Restore initial VF ReBAR sizes on PF\n release","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:\n- [High] Unsafe hardware configuration writes during kobject .release callback and incorrect lifecycle hook.\n--\n\ncommit b1af88a89dd13b3ede54e65628a75befe1b43cf4\nAuthor: Marcin Bernatowicz \n\nPCI/IOV: Restore initial VF ReBAR sizes on PF release\n\nThis commit attempts to restore the per-VF BAR sizes to their initial\nvalues when sriov_release() is called. It aims to handle the case where\nVF BARs were resized but SR-IOV was not enabled when the PF driver is\nunbound.\n\n> sriov_disable() and sriov_enable() error paths restore the per-VF BAR\n> sizes saved at probe time. They do not cover the case where the PF\n> driver is unbound while VF BARs were resized but SR-IOV was never\n> enabled (or was already disabled).\n> \n> On the next bind, sriov_init() re-reads the SR-IOV capability and\n> captures the current (inflated) BAR registers as the new initial sizes\n> in iov->barsz_orig[]. The restore logic becomes a no-op for that boot\n> and the kernel may reserve MMIO for the inflated VF aperture multiplied\n> by TotalVFs.\n\nIs sriov_release() the correct place for this restoration?\n\nThe commit message states it covers when the PF driver is unbound and mentions\nthe next bind, but sriov_release() is called by pci_release_dev() which is\nthe kobject .release callback.\n\nThis executes when the pci_dev reference count drops to 0 (such as during\ndevice destruction), not during a driver unbind via sysfs. Furthermore,\nsriov_init() is called during device enumeration, not driver bind.\n\n> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c\n> index a05c1be388d2f..794f956910886 100644\n> --- a/drivers/pci/iov.c\n> +++ b/drivers/pci/iov.c\n> @@ -969,6 +969,8 @@ static void sriov_release(struct pci_dev *dev)\n> {\n> \tBUG_ON(dev->sriov->num_VFs);\n> \n> +\tsriov_restore_vf_rebar_initial_sizes(dev);\n\nIs it safe to access the hardware configuration space here?\n\nSince sriov_release() executes as a .release callback, it can run at an\narbitrary time, such as being delayed indefinitely by an open sysfs file\ndescriptor.\n\nIf the device has been surprise-removed or placed in D3cold (suspended), won't\nPCIe config space reads return ~0 (0xFFFF)?\n\nIn that case, pci_iov_is_memory_decoding_enabled() would evaluate\n0xFFFF & PCI_SRIOV_CTRL_MSE as true, causing pci_iov_vf_bar_set_size() to\nreturn -EBUSY.\n\nThis could trigger a pci_warn() in sriov_restore_vf_rebar_initial_sizes() for\nevery resized VF BAR, spamming the kernel log with false-positive warnings, and\npotentially causing PCIe Unsupported Requests or bus errors.\n\n> +\n> \tif (dev != dev->sriov->dev)\n> \t\tpci_dev_put(dev->sriov->dev);","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 (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=XgD0COQT;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-53792-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"XgD0COQT\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9BDT2xTsz1yJq\n\tfor ; Wed, 06 May 2026 07:17:29 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id D516B30173B7\n\tfor ; Tue, 5 May 2026 21:17:24 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C1C5D175A70;\n\tTue, 5 May 2026 21:17:22 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\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 9F18E54654\n\tfor ; Tue, 5 May 2026 21:17:22 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 09ACFC2BCB4;\n\tTue, 5 May 2026 21:17:21 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778015842; cv=none;\n b=PBnoxa02Ti0pl9621eBpPQa6mBRTIaKrQfV9oCqND2QmoPociHMagPXIeBvvKODe1ub6yFHokZS6a46fvh9xx9iOlJhwPUl4IXwu1QSJC6HOSx87fokEToGBP6KNi6AWn2/ZgGWFYp1Axed3xYx+pQiOpUgvyrFEJHJkEfUPbp0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778015842; c=relaxed/simple;\n\tbh=09TV64aT53CBvqXv7ZN33RPVZjLa8iVFbVwTfw7dzy0=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=i8RxVelc7nllA0/zJnQGNLoZyD5pX5CS2CkXjiW9s+/EvFEGhauD2rGEuWgbNctMiAwf+bpcs3vMXIdUeCEq0i2xkT9QCtLhry8x/Piya05j6oukbAo9DQ9BCN8aC9Jj+e/AKFvMYW8cq1HhkGtDlpADRU23eyQlWYShRqTSA+w=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=XgD0COQT; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778015842;\n\tbh=09TV64aT53CBvqXv7ZN33RPVZjLa8iVFbVwTfw7dzy0=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=XgD0COQTx8d5NgSfBy7fLNfRfnyoLL0f0fxUpNUEDNdhsgsegCnKHTixeNcqY6z9V\n\t I4zRNeFD9epTqfsTerBif2hOLyh8QJxyXaW1cWkkoi4PYQwZoHbG08bPq+5gDwKUk3\n\t mz0oM+TLHbWc6xPvGZBzybl7pFixrok1x+vcMpMYXGqcD6iYdk/NQ3MfDgwFbTIbvL\n\t 5wUpx9ntA0s42bpb1vTDJkBeTN37GOWs3W2rkldC5kblG0jXRVCLOGr9r0rYjBkThm\n\t B9tdAvMZzwsdJ+vdBA1lbFHff2IsXFWFNY1Gpz0Z6ZJQLnUToWhQNEOasCpngWb+Kz\n\t XT44v1v5TGbgQ==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH 3/3] PCI/IOV: Restore initial VF ReBAR sizes on PF\n release","Reply-To":"sashiko@lists.linux.dev","To":"\"Marcin Bernatowicz\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260505170010.3414074-4-marcin.bernatowicz@linux.intel.com>","References":"<20260505170010.3414074-4-marcin.bernatowicz@linux.intel.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Tue, 05 May 2026 21:17:21 +0000","Message-Id":"<20260505211722.09ACFC2BCB4@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}}]