kernel threads

kernel threads

[Christian Widmer]

i'm new to in developing kernel software under linux and what to 
know if i'm write when i create kernel_threads like this:

variant I
---------
1) call kernel_thread 
2) in the thread function 
    a) get the big kernel lock
    b) call daemonize
    c) release big kernel lock


variant II
----------
schedule the call to kernel_thread using tq_schedule


- is there no need to call daemonize in the second variant - if yes why?
- can i do both variants during interupt time (when there is no valid 
current)?

chris

Re: kernel threads

[Alan Cox]

> schedule the call to kernel_thread using tq_schedule

You still want to use daemonzie

> - is there no need to call daemonize in the second variant - if yes why?

A task always has a parent, it'll just be a random task that ran the 
kernel_thread request - in fact it might be a kernel thread and then 
I dont guarantee what will occur. In fact I wouldnt try the tq_schedule one

> - can i do both variants during interupt time (when there is no valid 
> current)?

No, but you can create a thread ready in case its needed then wake it from
an IRQ

Re: kernel threads

[Christian Widmer]

On Friday 17 August 2001 00:37, you wrote:
> > schedule the call to kernel_thread using tq_schedule
>
> You still want to use daemonzie
>
> > - is there no need to call daemonize in the second variant - if yes why?
>
> A task always has a parent, it'll just be a random task that ran the
> kernel_thread request - in fact it might be a kernel thread and then
> I dont guarantee what will occur. In fact I wouldnt try the tq_schedule one

sorry i didn't say that i what to use 2.4.x
when looking to kernel/context.c there it says that (or better i looks to me 
like it sais) that all that is sheduled to tq_schedule runns under keventd. so
the parent is predicable and is demonised itsself. is that bad or good?

kernel threads

[blesson paul]

Hi all
			I am trying to compile a program which is using kernel_thread and its 
related functions.  I am not trying to compile as a standalone application. 
I am not sure  wheather I am doing right. I am able to compile the 
application. But I am not able to link. The error it shows is that, it 
cannot find the implementation of kernel_thread and all. But there is no 
libraries to link. How to tackle the problem.

	Also how to create the program as a patch to the kernel
Thanking in advance
regards
Blesson Paul



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

kernel threads.

[Vahid Fereydunkolahi]

Folks,
 I have a problem using kernel_thread. The problem is
 when I use kernel threads I see a lot of context 
switch. 
 I monitor the system activity using vmstat.

Regards,
--vahid


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Re: kernel threads.

[Masoud Sharbiani]

Hi,
Context switch happens when one of your running processes (or kernel 
threads) is running and then makes a request (like reading from a device 
and it has to wait for result). therefore scheduler selects another 
runnable process/kthread to run.
If you think you have a lot of context switches, you might want to 
redesign your thread so it blocks less (for example, make several 
requests for reading several blocks, all at the same time, and wait for 
first to complete where there is higher probability for the rest of 
blocks to be ready when you check for their readiness).
regards,
Masoud
Vahid Fereydunkolahi wrote:

>Folks,
> I have a problem using kernel_thread. The problem is
> when I use kernel threads I see a lot of context 
>switch. 
> I monitor the system activity using vmstat.
>
>Regards,
>--vahid
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>

kernel threads

[Madhavi]

Hi

Where can I get information about using linux kernel threads? Can anyone
give me some pointers?

Is there any function that I can use to exit from a thread? The
exit_thread() function of linux kernel 2.4.19 for i386 platform doesn't
seem to be doing anything.

If I can replace threads by tasklets, which would be advantageous in terms
of performance?

thanks & regards
Madhavi.

Kernel threads

[linux-os (Dick Johnson)]

Hello,

In linux-2.6.16.24, there is a problem with kernel threads
and the aic79xx.c driver.

When nash is executing /initrd/linuxrc in the initial RAM disk
during boot, it will be installing drivers. One driver, aic79xx.c
creates some kernel threads that will exit after the initialization
procedure. Actually the number of tasks depends upon the number
of disks found as the driver spawns these tasks so initialization
can occur in the background. The kernel tasks have been 'parented'
to init. This may be fine for the real init, but nash and other
shells receive the SIGCHLD signal and think that the fork()/exec()
they have executed is complete. This makes nash insert drivers
when the needed previous ones have not yet initialized. Also, when
booting a shell, the signals from the exiting kernel tasks confuse
it.

I think the top-level thread, kthread, should be reaping children
instead of init, which in some cases isn't even running yet.

Any comments?

The current work-around of putting `sleep 10` in linuxrc after
installing each driver is a hack of the worse kind. Especially,
considering an Adaptec controller with many drives attached may
require 'sleep 60'!


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.68 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Kernel threads

[Andrew Morton]

> On Tue, 6 Mar 2007 11:03:48 -0500 "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote:
> 
> Hello,
> 
> In linux-2.6.16.24, there is a problem with kernel threads
> and the aic79xx.c driver.
> 
> When nash is executing /initrd/linuxrc in the initial RAM disk
> during boot, it will be installing drivers. One driver, aic79xx.c
> creates some kernel threads that will exit after the initialization
> procedure. Actually the number of tasks depends upon the number
> of disks found as the driver spawns these tasks so initialization
> can occur in the background. The kernel tasks have been 'parented'
> to init. This may be fine for the real init, but nash and other
> shells receive the SIGCHLD signal and think that the fork()/exec()
> they have executed is complete. This makes nash insert drivers
> when the needed previous ones have not yet initialized. Also, when
> booting a shell, the signals from the exiting kernel tasks confuse
> it.
> 
> I think the top-level thread, kthread, should be reaping children
> instead of init, which in some cases isn't even running yet.
> 
> Any comments?
> 
> The current work-around of putting `sleep 10` in linuxrc after
> installing each driver is a hack of the worse kind. Especially,
> considering an Adaptec controller with many drives attached may
> require 'sleep 60'!
> 

ug.  I've always disliked the kernel's dependence upon init to reap exitted
kernel threads.  It Just Seems Wrong.

But I'd have thought that this is really wart in nash - Linux simply
expects init to reap dead kernel threads, and as a Linux implementation of
init, nash ought to not misbehave in the presence of this logstanding
kernel behaviour.

Re: Kernel threads

[Oleg Nesterov]

Andrew Morton wrote:
>
> > On Tue, 6 Mar 2007 11:03:48 -0500 "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote:
> >
> > In linux-2.6.16.24, there is a problem with kernel threads
> > and the aic79xx.c driver.
> >
> > When nash is executing /initrd/linuxrc in the initial RAM disk
> > during boot, it will be installing drivers. One driver, aic79xx.c
> > creates some kernel threads that will exit after the initialization
> > procedure. Actually the number of tasks depends upon the number
> > of disks found as the driver spawns these tasks so initialization
> > can occur in the background. The kernel tasks have been 'parented'
> > to init. This may be fine for the real init, but nash and other
> > shells receive the SIGCHLD signal and think that the fork()/exec()
> > they have executed is complete. This makes nash insert drivers
> > when the needed previous ones have not yet initialized. Also, when
> > booting a shell, the signals from the exiting kernel tasks confuse
> > it.
>
> ug.  I've always disliked the kernel's dependence upon init to reap exitted
> kernel threads.  It Just Seems Wrong.

Yes. It is ugly to kick init to reap the kernel thread. I was going to
do this change a long ago, but I don't have time to do even a minimal
testing now.

reparent_to_init() expects that thread_group_empty() == true anyway,
we can set ->exit_signal = -1 and make this thread invisible to init.

Roland, what do you think?

Oleg.

--- WQ/kernel/exit.c~rti	2007-02-18 22:56:49.000000000 +0300
+++ WQ/kernel/exit.c	2007-03-08 19:26:39.000000000 +0300
@@ -276,8 +276,8 @@ static void reparent_to_init(void)
 	current->parent = child_reaper(current);
 	add_parent(current);
 
-	/* Set the exit signal to SIGCHLD so we signal init on exit */
-	current->exit_signal = SIGCHLD;
+	/* make the task autoreap */
+	current->exit_signal = -1;
 
 	if (!has_rt_policy(current) && (task_nice(current) < 0))
 		set_user_nice(current, 0);

Re: Kernel threads

[Roland McGrath]

Your change seems fine to me.  I certainly concur that it seems insane
for init to be responsible for tasks created magically inside the
kernel.  The history I've found says that the setting to SIGCHLD was
introduced as part of "v2.5.1.9 -> v2.5.1.10", without detailed
commentary in the log.  This was probably before the auto-reaping
semantics worked as they do now.  So like the man said, at the time,
it seemed the logical thing to do.

To be paranoid, I wouldn't make this change in any stable kernel series.
It changes behavior visible to userland (init) from how it has been
consistently for five years, so, who knows, something might notice.  
The old behavior is pretty harmless, albeit changing it seems both
preferable and harmless.


Thanks,
Roland

Re: Kernel threads

[Oleg Nesterov]

On 03/08, Roland McGrath wrote:
>
> Your change seems fine to me.  I certainly concur that it seems insane
> for init to be responsible for tasks created magically inside the
> kernel.  The history I've found says that the setting to SIGCHLD was
> introduced as part of "v2.5.1.9 -> v2.5.1.10", without detailed
> commentary in the log.  This was probably before the auto-reaping
> semantics worked as they do now.  So like the man said, at the time,
> it seemed the logical thing to do.
>
> To be paranoid, I wouldn't make this change in any stable kernel series.
> It changes behavior visible to userland (init) from how it has been
> consistently for five years, so, who knows, something might notice.
> The old behavior is pretty harmless, albeit changing it seems both
> preferable and harmless.

Yes sure, this change shoud be tested in -mm tree (I'll send the patch
on Sunday after some testing). The only (afaics) problem is that with
this change a kernel thread must not do do_fork(CLONE_THREAD). I think
it should not, but currently this is technically possible. Perhaps it
makes sense to add BUG_ON(CLONE_THREAD && group_leader->exit_signal==-1)
in copy_process().

On a related note,

	zap_other_threads:

		if (t != p->group_leader)
			t->exit_signal = -1;

looks like another leftover to me, we already depend on the fact that
all sub-threads have ->exit_signal == -1 (otherwise, for example, a
thread group just can't exit properly).


While we are talking about kernel threads, there is something I can't
undestand. kthread/daemonize use sigprocmask(SIG_BLOCK) to protect
against signals. This doesn't look right to me, because this doesn't
prevent the signal delivery, this only blocks signal_wake_up(). Every
"killall -33 khelper" means a "struct siginfo" leak.

Imho, the kernel thread shouldn't play with ->blocked at all. Instead
it should set SIG_IGN for all handlers. If it really needs, say, SIGCHLD,
it should call allow_signal() anyway. Do you see any problems with this
approach?

Oleg.

Re: Kernel threads

[Roland McGrath]

> Yes sure, this change shoud be tested in -mm tree (I'll send the patch
> on Sunday after some testing). The only (afaics) problem is that with
> this change a kernel thread must not do do_fork(CLONE_THREAD). 

To clarify, the danger here is that an exit_signal=-1 leader would
self-reap and leave behind live threads with dangling ->group_leader
pointers.  This danger doesn't exist for normal user group leaders with
parents ignoring SIGCHLD, because exit_signal is never set to -1 until
do_notify_parent, which is never called until the last thread in the group
dies (except when ptrace'd, but then do_notify_parent never resets
exit_signal at all).  Is that right?

> I think it should not, but currently this is technically
> possible. Perhaps it makes sense to add BUG_ON(CLONE_THREAD &&
> group_leader->exit_signal==-1) in copy_process().

It probably wouldn't hurt to make it:

	if (user_mode(regs))
		BUG_ON(current->group_leader->exit_signal == -1);
	else
		BUG_ON((clone_flags & (CLONE_THREAD|CLONE_UNTRACED))
		       != CLONE_UNTRACED);

> 	zap_other_threads:
> 
> 		if (t != p->group_leader)
> 			t->exit_signal = -1;
> 
> looks like another leftover to me, we already depend on the fact that
> all sub-threads have ->exit_signal == -1 (otherwise, for example, a
> thread group just can't exit properly).

Yes, I agree it looks superfluous.

> While we are talking about kernel threads, there is something I can't
> undestand. kthread/daemonize use sigprocmask(SIG_BLOCK) to protect
> against signals. This doesn't look right to me, because this doesn't
> prevent the signal delivery, this only blocks signal_wake_up(). Every
> "killall -33 khelper" means a "struct siginfo" leak.

It does prevent the delivery (signal_pending() never set), but not the queuing.

> Imho, the kernel thread shouldn't play with ->blocked at all. Instead
> it should set SIG_IGN for all handlers. If it really needs, say, SIGCHLD,
> it should call allow_signal() anyway. Do you see any problems with this
> approach?

That sounds reasonable to me generally.  However, if kernel threads ever
spawn user children, they may not want the self-reaping behavior of
ignoring SIGCHLD even if they never dequeue the signal (because they want
to call do_wait).  There might be other strange caveats like that I'm not
thinking of.  


Thanks,
Roland

Re: Kernel threads

[Oleg Nesterov]

On 03/09, Roland McGrath wrote:
>
> > Yes sure, this change shoud be tested in -mm tree (I'll send the patch
> > on Sunday after some testing). The only (afaics) problem is that with
> > this change a kernel thread must not do do_fork(CLONE_THREAD). 
> 
> To clarify, the danger here is that an exit_signal=-1 leader would
> self-reap and leave behind live threads with dangling ->group_leader
> pointers.  This danger doesn't exist for normal user group leaders with
> parents ignoring SIGCHLD, because exit_signal is never set to -1 until
> do_notify_parent, which is never called until the last thread in the group
> dies (except when ptrace'd, but then do_notify_parent never resets
> exit_signal at all).  Is that right?

I think yes.

> > I think it should not, but currently this is technically
> > possible. Perhaps it makes sense to add BUG_ON(CLONE_THREAD &&
> > group_leader->exit_signal==-1) in copy_process().
>
> It probably wouldn't hurt to make it:
>
> 	if (user_mode(regs))
> 		BUG_ON(current->group_leader->exit_signal == -1);

Well, this is of course right, but a bit strange. Because we can add
this check to any function which can't be called after exit_notify().

> 	else
> 		BUG_ON((clone_flags & (CLONE_THREAD|CLONE_UNTRACED))
> 		       != CLONE_UNTRACED);

I think this _should_ be right, but please note that fork_idle() does
copy_process(CLONE_VM). Also, we may have some external driver which
plays with do_fork/copy_process.

> > While we are talking about kernel threads, there is something I can't
> > undestand. kthread/daemonize use sigprocmask(SIG_BLOCK) to protect
> > against signals. This doesn't look right to me, because this doesn't
> > prevent the signal delivery, this only blocks signal_wake_up(). Every
> > "killall -33 khelper" means a "struct siginfo" leak.
>
> It does prevent the delivery (signal_pending() never set), but not the queuing.

Yep.

> > Imho, the kernel thread shouldn't play with ->blocked at all. Instead
> > it should set SIG_IGN for all handlers. If it really needs, say, SIGCHLD,
> > it should call allow_signal() anyway. Do you see any problems with this
> > approach?
>
> That sounds reasonable to me generally.  However, if kernel threads ever
> spawn user children, they may not want the self-reaping behavior of
> ignoring SIGCHLD even if they never dequeue the signal (because they want
> to call do_wait).

Yes. That is why wait_for_helper() does allow_signal(SIGCHLD). I think a
kernel thread must not make any assumption about ->action[SIGCHLD] if it
wants to call wait4, but we may break some "buggy" external driver.

In fact, most threads inherit action[SIGCHLD] == SIG_IGN from worker_thread().

BTW, wait_for_helper() does do_sigaction() before allow_signal(). Looks
unneeded to me.

>                    There might be other strange caveats like that I'm not
> thinking of.

Yes, this makes me worry too :)

Oleg.