From: Simon Horman <horms@kernel.org>
To: Yuho Choi <dbgh9129@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
Eric Dumazet <edumazet@google.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Marco Crivellari <marco.crivellari@suse.com>,
linux-kernel@vger.kernel.org, Myeonghun Pak <mhun512@gmail.com>,
Ijae Kim <ae878000@gmail.com>, Taegyu Kim <tmk5904@psu.edu>
Subject: Re: [PATCH v1] net: liquidio: resolve VF pci_dev on demand for FLR requests
Date: Tue, 21 Apr 2026 16:33:38 +0100 [thread overview]
Message-ID: <20260421153338.GE651125@horms.kernel.org> (raw)
In-Reply-To: <20260420023304.57105-1-dbgh9129@gmail.com>
On Sun, Apr 19, 2026 at 10:33:04PM -0400, Yuho Choi wrote:
> The PF SR-IOV enable path caches VF pci_dev pointers in
> dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those
> entries do not own a reference, because the iterator drops the previous
> device reference on each step. The cached pointer is then dereferenced
> later when handling OCTEON_VF_FLR_REQUEST.
>
> This can leave stale VF pci_dev pointers in the lookup table and makes
> the FLR path rely on a PCI device object whose lifetime is not pinned.
>
> Drop the long-lived lookup table and resolve the VF pci_dev only when an
> FLR request arrives. Use the PF's SR-IOV metadata to derive the VF's
> bus/devfn, get a referenced pci_dev for immediate use, issue the FLR,
> and then drop the reference.
>
> Fixes: ca6139ffc67ee ("liquidio CN23XX: sysfs VF config support")
> Fixes: 8c978d059224 ("liquidio CN23XX: Mailbox support")
> Co-developed-by: Myeonghun Pak <mhun512@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Co-developed-by: Taegyu Kim <tmk5904@psu.edu>
> Signed-off-by: Taegyu Kim <tmk5904@psu.edu>
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
As this fixes code present in the net tree, it should be targeted
at that tree, like this:
Subject: [PATCH net] ...
In this case the CI defaulted to the net-next tree.
Which might be harmless. But please keep this in mind for next time.
...
> diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
> index ad685f5d0a136..b967c7928b4a7 100644
> --- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
> +++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
> @@ -26,6 +26,29 @@
> #include "octeon_mailbox.h"
> #include "cn23xx_pf_device.h"
>
> +static struct pci_dev *lio_vf_pci_dev_by_qno(struct octeon_device *oct, u32 q_no)
> +{
> + int vfidx, bus, devfn;
> +
> + if (!oct->sriov_info.rings_per_vf)
> + return NULL;
> +
> + if (q_no % oct->sriov_info.rings_per_vf)
> + return NULL;
> +
> + vfidx = q_no / oct->sriov_info.rings_per_vf;
> + if (vfidx >= oct->sriov_info.num_vfs_alloced)
> + return NULL;
> +
> + bus = pci_iov_virtfn_bus(oct->pci_dev, vfidx);
When applied against net-next this causes a linker error with x86_64
allmodconfig (at least) because pci_iov_virtfn_bus is not defined.
> + devfn = pci_iov_virtfn_devfn(oct->pci_dev, vfidx);
> + if (bus < 0 || devfn < 0)
> + return NULL;
> +
> + return pci_get_domain_bus_and_slot(pci_domain_nr(oct->pci_dev->bus),
> + bus, devfn);
> +}
> +
> /**
> * octeon_mbox_read:
> * @mbox: Pointer mailbox
--
pw-bot: changes-requested
next prev parent reply other threads:[~2026-04-21 15:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 2:33 [PATCH v1] net: liquidio: resolve VF pci_dev on demand for FLR requests Yuho Choi
2026-04-21 15:33 ` Simon Horman [this message]
2026-04-21 18:39 ` 최유호
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260421153338.GE651125@horms.kernel.org \
--to=horms@kernel.org \
--cc=ae878000@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dbgh9129@gmail.com \
--cc=edumazet@google.com \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=mhun512@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tmk5904@psu.edu \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox