Hi,
The kthread park/unpark facility is not used in the kernel, so
one would assume that it's made for kernel modules. This patch should
definitely help most modules.
Patch untested, at your own risks...
Regards,
Jean
Signed-off-by: Jean Tourrilhes <[email protected]>
diff -u -p linux-3.18.17/kernel/kthread.j2.c linux-3.18.17/kernel/kthread.c
--- linux-3.18.17/kernel/kthread.j2.c 2015-07-08 17:01:39.010554169 -0700
+++ linux-3.18.17/kernel/kthread.c 2015-07-08 17:09:13.016096189 -0700
@@ -97,6 +97,7 @@ bool kthread_should_park(void)
{
return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
}
+EXPORT_SYMBOL(kthread_should_park);
/**
* kthread_freezable_should_stop - should this freezable kthread return now?
@@ -171,6 +172,7 @@ void kthread_parkme(void)
{
__kthread_parkme(to_kthread(current));
}
+EXPORT_SYMBOL(kthread_parkme);
static int kthread(void *_create)
{
@@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *
if (kthread)
__kthread_unpark(k, kthread);
}
+EXPORT_SYMBOL(kthread_unpark);
/**
* kthread_park - park a thread created by kthread_create().
@@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
}
return ret;
}
+EXPORT_SYMBOL(kthread_park);
/**
* kthread_stop - stop a thread created by kthread_create().
On 07/08/2015 08:40 PM, Jean Tourrilhes wrote:
> Hi,
>
> The kthread park/unpark facility is not used in the kernel
kernel/smpboot.c ?
> , so one would assume that it's made for kernel modules. This patch should
> definitely help most modules.
> Patch untested, at your own risks...
> Regards,
>
> Jean
>
> Signed-off-by: Jean Tourrilhes <[email protected]>
>
> diff -u -p linux-3.18.17/kernel/kthread.j2.c linux-3.18.17/kernel/kthread.c
> --- linux-3.18.17/kernel/kthread.j2.c 2015-07-08 17:01:39.010554169 -0700
> +++ linux-3.18.17/kernel/kthread.c 2015-07-08 17:09:13.016096189 -0700
> @@ -97,6 +97,7 @@ bool kthread_should_park(void)
> {
> return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
> }
> +EXPORT_SYMBOL(kthread_should_park);
>
> /**
> * kthread_freezable_should_stop - should this freezable kthread return now?
> @@ -171,6 +172,7 @@ void kthread_parkme(void)
> {
> __kthread_parkme(to_kthread(current));
> }
> +EXPORT_SYMBOL(kthread_parkme);
>
> static int kthread(void *_create)
> {
> @@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *
> if (kthread)
> __kthread_unpark(k, kthread);
> }
> +EXPORT_SYMBOL(kthread_unpark);
>
> /**
> * kthread_park - park a thread created by kthread_create().
> @@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
> }
> return ret;
> }
> +EXPORT_SYMBOL(kthread_park);
>
> /**
> * kthread_stop - stop a thread created by kthread_create().
On Wed, 8 Jul 2015, Jean Tourrilhes wrote:
> The kthread park/unpark facility is not used in the kernel, so
git grep kthread.*park tells a different story
> one would assume that it's made for kernel modules.
Certainly not.
> This patch should definitely help most modules.
And how exactly would this help modules?
Thanks,
tglx
On Wed, Jul 08, 2015 at 11:23:41PM -0400, Peter Hurley wrote:
> On 07/08/2015 08:40 PM, Jean Tourrilhes wrote:
> > Hi,
> >
> > The kthread park/unpark facility is not used in the kernel
>
> kernel/smpboot.c ?
Got me, I should have said hardly used.
Sorry for the gross exageration ;-)
Jean
On Thu, Jul 09, 2015 at 10:05:02AM +0200, Thomas Gleixner wrote:
>
> > This patch should definitely help most modules.
>
> And how exactly would this help modules?
Putting kthread to sleep and waking them up later is slightly
tricky :
http://www.linuxjournal.com/article/8144
The park and unpark API encapsulate this functionality in
a pretty nice and clean API, and avoid duplicating this code in
various modules. I'm all for sharing the joy ;-)
> Thanks,
>
> tglx
Regards,
Jean
On Thu, 9 Jul 2015, Jean Tourrilhes wrote:
> On Thu, Jul 09, 2015 at 10:05:02AM +0200, Thomas Gleixner wrote:
> >
> > > This patch should definitely help most modules.
> >
> > And how exactly would this help modules?
>
> Putting kthread to sleep and waking them up later is slightly
> tricky :
> http://www.linuxjournal.com/article/8144
>
> The park and unpark API encapsulate this functionality in
> a pretty nice and clean API, and avoid duplicating this code in
> various modules. I'm all for sharing the joy ;-)
If you can come up with a proper use case, i.e. patch for a module,
then we can certainly talk about the exports. But without a user it
does not make any sense.
Thanks,
tglx
On Thu, Jul 09, 2015 at 06:49:21PM +0200, Thomas Gleixner wrote:
>
> If you can come up with a proper use case, i.e. patch for a module,
> then we can certainly talk about the exports. But without a user it
> does not make any sense.
My module is currently out of the tree, so obviously it does
not count.
Regards,
Jean