hi,
in my continuos learning process(?) i did with the solution to my
problem, but as said Mulyadi this thread has been a lot of useful and
collaborative... i will publish an article next days or weeks
conclusion, the real problem in my example was that i'm deamonize()'ing
after allow_signal(SIGKILL) funtion, and as i've seen in
kernel/exit.c#L272:
/*
* Let kernel threads use this to say that they
* allow a certain signal (since daemonize() will
* have disabled all of them by default).
*/
int allow_signal(int sig)
{
...
}
this two lines must be switched... and everything works fine ;)
regards,
toni
El dt 20 de 12 del 2005 a les 19:50 +0700, en/na Mulyadi Santosa va
escriure:
> Hello Toni...
>
> > thanks a lot for every comment!
>
> /me too get many new knowledge just by replying your e-mail and
> re-reading about signal (last but not least, Jan Hudec's commentary).
>
> I think this thread is one of the best discussion I ever involved in.
> every person tries to write down his/her analysis, receive feedback
> from other, "recompile" and send new feedback and finally we have nice
> solution. Cheers everybody!
>
> > i've completed a version of the code using helper functions from
> > include/linux/kthread.h file and non blocking sock_recvmsg() as
> > suggested... this is working fine, if somebody were interested in
> > reveive a copy please ask to me.
>
> Instead of sending you code, I think it will be much appreciated if you
> write some kind of short article on how to solve this kind of problem
> on wiki.kernelnewbies.org. yes, there is mailing list archieve, but I
> think someone voluntarily write his experience on kernel hacking
> journey on Wiki is also valuable. Just my 2 cents thought.
>
> > from now i will try to do a version using blocking sock_recvmsg() and
> > trying to kill it cleanly with kthread_stop helper function. at this
> > moment, i've tried it and kthread_stop() can't interrupt
> > sock_recvmsg()... i will take a deep look on how they work to get it.
>
> Somehow I began to suspect that your kernel thread is put in
> uninteruptible state and refuse to back to runnable state since it
> waits for "something" (most likely data as many as you want).
>
> regards
>
> Mulyadi
>
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
--
toni <agar9938@xxxxxxxxxxxxxxxxxx>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
