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: 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