Re: kthread_stop always returning -EINTR?
On Tue, 18 Jul 2017 17:11:19 -0300, Martin Galvan said: > task_struct, it's not clear to me why I didn't get to see the thread > function printks. If the thread function finished before reaching > kthread_stop, I should be able to see them, right? The only way I can > see them is by removing the call to kthread_stop altogether. This > makes it seem like kthread_stop kills the new thread before it gets a > chance to run, yet that goes against the description in the comments. That's another way the race condition can play out - you wake it up, then re-stop it, before it gets a first shot at running. Remember, waking up and stopping processes is *not* a synchronous process. There's also the possibility that with the busted kthread_stop, you're managing to trample on something related to kernel logging. Really - if that thread is gone, the kthread_stop() is corrupting random memory, and all bets are off... And of course, double-check that you've got your syslog/dmesg/etc actually configured to log KERN_DEBUG messages - if changing them to KERN_ALERT makes them magically appear, that's your problem. pgpKJ_pkJDJc1.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kthread_stop always returning -EINTR?
Still, going back to this issue: even though I made make a mistake and incorrectly called kthread_stop on a (possibly) non-existent task_struct, it's not clear to me why I didn't get to see the thread function printks. If the thread function finished before reaching kthread_stop, I should be able to see them, right? The only way I can see them is by removing the call to kthread_stop altogether. This makes it seem like kthread_stop kills the new thread before it gets a chance to run, yet that goes against the description in the comments. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kthread_stop always returning -EINTR?
Understood. Thanks a lot! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kthread_stop always returning -EINTR?
On Tue, 18 Jul 2017 15:13:08 -0300, Martin Galvan said:
> I thought kthread_create/bind don't actually run the thread function?
> At least that's what the comment says.
It's the wake_up_process() that causes the problem...
> > * If threadfn() may call do_exit() itself, the caller must ensure
> > * task_struct can't go away.
> >
> > Your function calls do_exit() itself. It's surprising that your kernel
> > didn't explode when the tasx_struct went away.
>
> Yeah, my bad. I'm guessing I should've just returned zero?
That's not the problem. The problem is the task_struct went away when
you called do_exit(), and it can do so in between the two lines
wake_up_process()
and kthread_stop(). Classic race condition.
> > Looking at the code of
> > kthread_stop, there's phenomenally little error checking (as most
> > heavily-called
> > kernel functions tend to be). It just assumes that 'thread' points at
> > a valid thread structure and runs with it, with the result that you get back
> > possibly random trash as 'result'.
>
> Would it be worth it to send out a patch to add some error checking?
> I'd be happy to fix this.
It will be NAK'ed *really* fast. It's assumed that kernel programmers know
what they're doing, so if their kernel breaks because they call kthread_stop()
on a non-existent thread, it's their own fault. It *tells* you flat out:
* If threadfn() may call do_exit() itself, the caller must ensure
* task_struct can't go away.
> > Two important kernel concepts: Locking and reference counting. Use them
> > wisely.
>
> Will do, though I'm not sure how those would apply here since (AFAIK)
> there are no variables shared between the threads.
It's not variables shared between the threads. What you're doing here is more
the equivalent of returning the address of a variable in the stack:
int *dont_do_this()
{
int a;
return ();
}
Except here, it's not an int, it's a whole task_struct that you're doing a
use-after-release.
pgptYCdVTjekK.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kthread_stop always returning -EINTR?
On Tue, 18 Jul 2017 13:00:11 -0300, Martin Galvan said:
> Hi everyone! I'm doing a bit of testing on the Linux kthread functions, and h
> int function(void *data)
> {
> printk(KERN_DEBUG "CPU: %u\n", smp_processor_id());
>
> do_exit(0); /* Not sure if this is ok */
> }
Note that this will go bye-bye pretty much immediately.
> /* Start the thread */
> wake_up_process(thread);
Aaannnd... it's possibly gone already, before you get to the next line of code..
> /* Wait for the thread function to complete */
> result = kthread_stop(thread);
So it's going to be hard to stop a thread that's not there anymore. Note this
comment from kernel/kthreads.c:
/**
* kthread_stop - stop a thread created by kthread_create().
* @k: thread created by kthread_create().
*
* Sets kthread_should_stop() for @k to return true, wakes it, and
* waits for it to exit. This can also be called after kthread_create()
* instead of calling wake_up_process(): the thread will exit without
* calling threadfn().
*
* If threadfn() may call do_exit() itself, the caller must ensure
* task_struct can't go away.
Your function calls do_exit() itself. It's surprising that your kernel
didn't explode when the tasx_struct went away. Looking at the code of
kthread_stop, there's phenomenally little error checking (as most heavily-called
kernel functions tend to be). It just assumes that 'thread' points at
a valid thread structure and runs with it, with the result that you get back
possibly random trash as 'result'.
Two important kernel concepts: Locking and reference counting. Use them wisely.
pgp3Dvfir4iMh.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
kthread_stop always returning -EINTR?
Hi everyone! I'm doing a bit of testing on the Linux kthread functions, and
have the following module:
#include
#include
#include
#include
#include
#include
MODULE_LICENSE("GPL");
int function(void *data)
{
printk(KERN_DEBUG "CPU: %u\n", smp_processor_id());
do_exit(0); /* Not sure if this is ok */
}
/* Function executed upon loading driver */
int __init init_module(void)
{
unsigned int cpu;
printk(KERN_DEBUG "init\n");
for_each_present_cpu(cpu)
{
struct task_struct *thread = kthread_create(function, NULL, "Thread
%u", cpu);
if (!IS_ERR(thread))
{
int result;
/* Bind the thread to the current core */
kthread_bind(thread, cpu);
/* Start the thread */
wake_up_process(thread);
/* Wait for the thread function to complete */
result = kthread_stop(thread);
printk(KERN_DEBUG "Thread %u stopped with result %d\n", cpu,
result);
}
else
{
printk(KERN_ALERT "Could not create a thread bound to core number
%u\n", cpu);
break;
}
}
return 0;
}
/* Function executed when unloading module */
void cleanup_module(void)
{
printk(KERN_DEBUG "exit\n");
}
>From what I understood, I should be able to see all the "CPU: ..." prints
>before init_module ends. However, kthread_stop is always returning -EINTR, as
>if wake_up_process wasn't actually being called. What am I doing wrong?
(Please CC me directly when you answer this)
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: new sysctl tunable knob for tcpip
On Thu, 06 Jul 2017 09:23:46 +0200, Massimo Sala said: > I have an idea about a new sysctl knob. It is under net.ipv4. Step 0: Identify whether it is even a good idea. TCP/IP is tougher than you think, especially when you get into congestion control. Step 0.1: Figure out if your brilliant idea is also applicable to IPv6. Step 0.2: You'll get more guidance if you explained what the knob is supposed to do. pgpWNrXkTCkZt.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
