[RFC 1/4] bus/pci: fix check on interrupt FD for FreeBSD

[David Marchand]

On Thu, 23 Jul 2026 at 16:39, Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> On Thu, Jul 23, 2026 at 02:31:23PM +0000, Marat Khalili wrote:
> > > > > --- a/drivers/bus/pci/bsd/pci.c
> > > > > +++ b/drivers/bus/pci/bsd/pci.c
> > > > > @@ -93,7 +93,7 @@ pci_uio_free_resource(struct rte_pci_device *dev,
> > > > >  {
> > > > >       rte_free(uio_res);
> > > > >
> > > > > -     if (rte_intr_fd_get(dev->intr_handle)) {
> > > > > +     if (rte_intr_fd_get(dev->intr_handle) >= 0) {
> > > > >               close(rte_intr_fd_get(dev->intr_handle));
> > > > >               rte_intr_fd_set(dev->intr_handle, -1);
> > > > >               rte_intr_type_set(dev->intr_handle, RTE_INTR_HANDLE_UNKNOWN);
> > > >
> > > > Unlikely that we actually have fd as 0 for this call, but change is
> > > > technically correct.
> > >
> > > Yes, this is why I did not Cc: stable.
> > > Thanks.
> >
> > Just trying to understand what's going on here out of curiosity.
> >
> > Zero fd is valid and negative (typically -1) indicating error is a standard
> > logic in Linux, but here intr_handle->fd is zero-filled by
> > rte_intr_instance_alloc, so its initial state is 0 instead of -1. Do we have
> > reasons to believe that something always sets fd to non-zero value before
> > pci_uio_free_resource is called? Should rte_intr_instance_alloc set it to -1?
>
> I believe that's what patch 3 of this set does, initializing each to -1.
> Perhaps that patch should appear before this one in the set, to avoid the
> possibility of temporary breakage.

True, in this case, it does not make sense to have this change separate.


-- 
David Marchand