I've been looking at the kernel threads that use daemonize() and have
some questions about the proper use of this call:
1: Some threads use the lock_kernel() calls around the daemonize()
call. Is this necessary? I thought the BKL was phasing out.
2: Some threads do their setup (like changing the comm string, setting
the signal masks, etc) before daemonize(), some do it after. Is there
any benefit to a particular order of operations? I can't see one.
3: Some threads set current->tty to NULL. Why would a thread *not* do
this?
4: Some threads grab the sigmask_lock before manipulating their masks.
Is this necessary? If so, some threads have bugs. If not, why do some
threads bother?
5: Some threads do flush_signals() or recalc_sigpending() before
updating their blocked mask, some do it after. Does the order matter?
I suspect not.
6: MOD_INC_USE_COUNT should be used by all threads that could be in
drivers built as modules, correct?
7: If you're not spawning a permanent kernel thread (like kswapd frex)
is the any benefit to using reparent_to_init()? I can't see one.
Thanks,
..Stu
On Wed, 2004-10-06 at 11:18, Stuart MacDonald wrote:
> I've been looking at the kernel threads that use daemonize() and have
> some questions about the proper use of this call:
>
> 1: Some threads use the lock_kernel() calls around the daemonize()
> call. Is this necessary?
It's only necessary if you can't be bothered to do proper locking.
Probably that code is old and someone did not have time to implement
correct locking to make it work on SMP so just threw lock/unlock kernel
around it.
> I thought the BKL was phasing out.
>
Well, it's not going to phase itself out ;-) But, patches that
introduce new uses of the BKL will almost certainly go to /dev/null.
Lee
* Stuart MacDonald ([email protected]) wrote:
> I've been looking at the kernel threads that use daemonize() and have
> some questions about the proper use of this call:
What kernel are you looking at? Take a look at current 2.6 and you
should find it much more uniform.
> 1: Some threads use the lock_kernel() calls around the daemonize()
> call. Is this necessary? I thought the BKL was phasing out.
I don't see why it'd be necessary.
> 2: Some threads do their setup (like changing the comm string, setting
> the signal masks, etc) before daemonize(), some do it after. Is there
> any benefit to a particular order of operations? I can't see one.
Current daemonize api includes name.
> 3: Some threads set current->tty to NULL. Why would a thread *not* do
> this?
Current daemonize function does this.
> 4: Some threads grab the sigmask_lock before manipulating their masks.
> Is this necessary? If so, some threads have bugs. If not, why do some
> threads bother?
Yes it's required.
> 5: Some threads do flush_signals() or recalc_sigpending() before
> updating their blocked mask, some do it after. Does the order matter?
> I suspect not.
Current daemonize gets this right.
> 6: MOD_INC_USE_COUNT should be used by all threads that could be in
> drivers built as modules, correct?
Not necessarily, modules can handle this in other ways (killing thread
on unload, for example).
> 7: If you're not spawning a permanent kernel thread (like kswapd frex)
> is the any benefit to using reparent_to_init()? I can't see one.
To give thread proper security credentials.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net