Re: [PATCH v6] uio: Fix uio driver to refcount device

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Mar 19, 2015 at 04:19:26PM +0000, Brian Russell wrote:
> 
> 
> On 19/03/15 15:14, Greg Kroah-Hartman wrote:
> > On Thu, Mar 19, 2015 at 02:49:21PM +0000, Brian Russell wrote:
> >> On 19/03/15 14:23, Greg Kroah-Hartman wrote:
> >>> On Thu, Mar 19, 2015 at 02:11:19PM +0000, Brian Russell wrote:
> >>>>  	if (info->irq && (info->irq != UIO_IRQ_CUSTOM)) {
> >>>> -		ret = devm_request_irq(idev->dev, info->irq, uio_interrupt,
> >>>> +		ret = request_irq(info->irq, uio_interrupt,
> >>>>  				  info->irq_flags, info->name, idev);
> >>>
> >>> Why move this away from the device lifecycle?
> >>>
> >>
> >> I ran into a problem here: after device unregister the parent module (in my case igb_uio in DPDK) can call pci_disable_msi. From the PCI MSI how to:
> >>
> >> "Before calling this function, a device driver must always call free_irq()
> >> on any interrupt for which it previously called request_irq().
> >> Failure to do so results in a BUG_ON(), leaving the device with
> >> MSI enabled and thus leaking its vector."
> >>
> >> So I need the free_irq, but the device may still have open fds and therefore be around a bit longer waiting for them to be released.
> > 
> > Note, please wrap your email lines...
> > 
> > Anyway, ok, that makes sense.  But put in a big comment in here about
> > this so that someone doesn't try to convert it to devm_* in the future.
> > 
> > Can you do this in a separate patch first as well?  Burrying it in a
> > pointer conversion patch isn't good.
> > 
> 
> I've separated out the irq bits into a separate patch, which depends
> on patching on top of the first patch. I'm a bit unsure how to go about
> sending the update now the patches are broken out and only one featured
> in the previous versions. Does this seek ok?
> 
> 3 separate mails:
> 
> [PATCH v8 0/2] uio: Fix uio hotplug issues
> summary of patches
> 
> [PATCH v8 1/2] uio: Fix uio driver to refcount device
> original patch minus irq and include version changes
> 
> [PATCH v8 2/2] uio: Request/free irq separate from dev lifecycle
> broken out irq bits, no other version info
> 
> 
> ... or should the v8 only go on the first patch?

Good question.  v8 applies to the whole "series", so you can just put
that in the 0/2 email, along with the changelog there.

I would recommend putting the irq change in the first patch, it
shouldn't depend on the device pointer change.  That way you never end
up with a "broken" driver at any point in the commit cycle.

Remember, any point in time the kernel tree should work properly, we
don't knowingly commit bad patches to fix them up in later ones.

thanks,

greg k-h