killing kernel thread in 2.4.xx

Никак, кроме как послать ему сигнал, который тот должен
отловить и сделать do_exit() (или вернуться из функции
аргумента для kernel_thread()).

Если он надолго в TASK_UNINTERRUPTIBLE - труба, надо
менять дизайн.

Любой процесс, в том числе и user-level может сделать
do_exit() только сам. Попытка написать вариант do_exit_tsk(tsk)
приведут к необходимости сильно переписать кернел.

Проблема в том, что система открытая, любой клиент может подрегистрироваться динамически, передав лишь адрес функции-колбека и некое условие, при выполнении которого IRQ handler вызывает именно его. А код клиента вовсе не обязан отлавливать и обрабатывать сигналы. Он может вовсе и не в ТАСК_ИНТЕРРУПТИБЛЕ, этот код, а вполне раннинг, допустим, перемножает матрицы 1024х1024.

Thanks in advance mailto://finger6@yandex.ru

Этот код что, перемножает матрицы в kernel mode?
Ничего не попишешь, любой код в ядре должен сам
следить, не пора ли ему выйти.

И вообще я не понял, вопрос был про kernel_thread,
а теперь код вызывается из IRQ handler, который не
имеет процесс контекста (поэтому о TASK_RUNNING или
других состояниях просто нельзя говорить) и в любом
случае должен отрабатывать быстро.

Нет, хандлер (боттом-халф, а не непосредственный) опрашивает железо, ищет в своем списке зарегестририванного на конкретное событие клиента и, если находит, создает kernel thread. Система - открытая, за клиента мой модуль ответственности не несет, посему нет гарантии, что клиент не перемножает матрицы, не делает FFT и т.д. Именно поэтому модулю хотелось бы останавливать и running клиентов. Для прерываемых клиентов я (модуль) экспортирую специальные wait сервисы, базирующиеся на системных, но с проверкой на сигнал после выхода. Естественно, клиент должен пользоваться моими вызовами, а не системными. Решение далеко от идеального и не учитывает целую категорию потенциальных клиентов. Thanks for cooperation.

Ох... bottom halve исполняется в контексте прерывания и мало
чем от него отдичается. Поэтому в нем __низзя__ вызывать
kernel_thread(). В 2.6 это просто не будет работать, в 2.4 на
i386 будет до тех пор, пока не кончится везение.

Для того, чтобы из прерывания запустить код, который требует
process context можно использовать schedule_task(), а в
tq_struct.routine() уже вызывать kernel_thread() (иначе все
ляжет на единственный thread - keventd).

В 2.5.40+ есть workqueues, что-то подобное несложно написать
и в 2.4, если надо: см. kernel/workqueue.c.

По поводу убиения процесса мне добавить нечего. Имхо - менять
дизайн. Почему этот код не может исполняться в user-level?
Если код все время крутится в kernel-mode, он все равно должен
время от времени делать if(need_resched) schedule(), в этот
момент можно и сигналы проверить.

Ну не бывает чудес. Если система позволяет запустить некоторый
код в kernel-mode, то этот код должен быть правильным.