On Thu, 23 Jul 2026 at 16:39, Bruce Richardson <[email protected]> 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
