Re: percolating ERESTARTSYS beyond PCI subsystem
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 :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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: percolating ERESTARTSYS beyond PCI subsystem
> 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 :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:
while(cond){
prepare_to_wait(&queue_head, &queue_entry, TASK_INTERRUPTIBLE);
if(condition_to_sleep)
schedule();
if(signal_pending(current))
return -ERESTARTSYS; /* up to the user level */
finish_wait(&queue_head, &queue_entry);
}
In previous versions of this driver, there was no signal management inside the
loop and the
resulting behaviour was that the loop slept at its first iteration, then it got
woken up by CTRL^C,
and then it never got put asleep again. (Or, to be precise, it was
automatically woken up as soon as
it was put asleep).
So it seems that for having it sleeping through every iteration, the pending
signal has to be cleared
at any iteration. (It seems that the in-tree documentation does not mention any
way of doing this apart
of the one used here).
Thanks to you,
Mk
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: percolating ERESTARTSYS beyond PCI subsystem
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? insmod should never return ERESTARTSYS unless some driver is doing something really odd/broken. What driver are you trying to load that does this? > Does insmod disables it explicitly? If so, how to get a similar > "restart-behaviour"? It doesn't disable it, it's just that nothing on that syscall path should be returning that value, as it doesn't make sense. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
percolating ERESTARTSYS beyond PCI subsystem
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. Does insmod disables it explicitly? If so, how to get a similar "restart-behaviour"? Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
