How do I wakeup a kthread that's sleeping with msleep_interruptible() so I can stop it?

rszimm · 09-15-2016, 11:56 AM

My exit function looks like this:

Code:

static void __exit kMeter_exit(void){
    printk(KERN_INFO "kMeter: Requesting thread stop\n");
    if (task)
        kthread_stop(task);

    printk(KERN_INFO "kMeter: Leaving Kernel Module\n");
}

My thread function looks like this:

Code:

static int mainTask(void* data)
{
    bool allDone;
    allow_signal(SIGKILL);
    set_current_state(TASK_INTERRUPTIBLE);
    while (!kthread_should_stop())
    {
        set_current_state(TASK_RUNNING);
        allDone = mainLoop();
        set_current_state(TASK_INTERRUPTIBLE);
        if (allDone)
            msleep_interruptible(poll_interval*1000);
        else
            usleep_range(TICK_TIME, TICK_TIME+100);
    }
    return 0;
}

The problem is that when I call rmmod the thread doesn't wake up from the sleep, so I'm stuck there until the timeout happens. Depending on settings, that poll_interval timeout could be as long as 5 minutes. I thought kthread_stop() was supposed to wakeup the associated thread, and I thought msleep_interruptible was supposed to allow that wakeup to happen. What am I missing?

jpollard · 09-15-2016, 03:26 PM

I think you want to send a signal to the task. rmmod is a graceful removal - so it doesn't interrupt the task.

sundialsvcs · 09-19-2016, 07:04 AM

Also, in all such situations (kernel-side or not ...) I advise that you should use signals only to mean, "you should not be asleep right now."

To put it differently: the capability to "wait on a signal" enables the thread to avoid "busy waiting." But the thread may well "spin" a few "extra" times, every now and then, where it discovers upon waking-up that it has nothing to do.

The thread should be the proper master of its own affairs from start to finish: never hold a pistol to its head as a way of telling it to do something, because your pistol-shot, irrevocable though it will be, is not synchronized with whatever the thread was doing at the time. Instead, use a simple boolean flag which is regularly tested in the thread's main loop, to cause the thread to break out of the loop and to subsequently terminate itself, graciously.

This termination will take an indeterminate amount of time. Avoid race-conditions.

rszimm · 09-27-2016, 11:00 PM

sundialsvcs, thanks a lot. I ended up changing things around and I've got something that works now, but I'm still frustrated that I just don't understand what's going on here. For example, I just for the life of me don't understand what the difference between msleep() and msleep_interruptible() is. Digging through the code it does appear that the interruptible one will wake up on a signal, but then it just checks the timeout and goes back to sleep. So how is that any good to anyone? (I'm 99% sure I'm missing something here, but I can't figure it out). ssleep() just seems like an irresponsible function if you ever want your LKM to ever exit. Hit ssleep with a value of 300 and your module could take 5 minutes to exit and there's not a damn thing you can do about it.

Ultimately it seems that the only solution here is to bypass the whole kthread_stop() and kthread_should_stop() functions and just set a boolean that I'll check every few (hundred) milliseconds and then go back to sleep. (basically what I inferred from your suggestion).