percolating ERESTARTSYS beyond PCI subsystem

[greg@kroah.com (Greg KH)]

On Sun, Apr 19, 2015 at 07:14:26PM +0200, Milton Krutt wrote:
> > On Sat, Apr 18, 2015 at 01:40:57PM +0200, Milton Krutt wrote:
> > > Hi. The scenario is a PCI driver on a kernel 3.19.2: 
> > > 
> > > is it possible, in case pending_signal(current) is true, to return -ERESTARTSYS
> > > to insmod process, in order to get it restart (as expectable)?
> > > 
> > > After some attempts (with pending_signal(current) being true), it seems that -ERESTARTSYS
> > > is caught by the "pci layer" that complains saying something like "probing failed ..
> > > unexpectedly returns -512" and nothing is restarted as expected.
> > 
> > What is the exact error message?
>  
>  probe of 0000:01:0a:0 failed with error code -512
> 
> > insmod should never return ERESTARTSYS unless some driver is doing
> > something really odd/broken.  What driver are you trying to load that
> > does this?
> 
> It's an experimental driver. For debugging purposes, it has a loop, inside which the
> process is put asleep by the mean of a wait queue, and the desired behaviour is to manually
> wake up the process by pressing CTRL^C at any iteration. It's something like:

Ick, don't do that in a probe function.  You can't sleep like this, nor
return this return value, it makes no sense from a probe standpoint.

Please fix the driver to not do this.  Either bind to the device or not,
that's all the probe function needs to do.

greg k-h