LINUX.ORG.RU

TASK_KILLABLE: Новое состояние процесса в Linux

 ,


0

0

В ядре Linux® 2.6.25 появилось новое состояние приостановки выполнения процесса TASK_KILLABLE, представляющее собой альтернативу эффективному, но потенциально приводящему к невозможности завершения процесса состоянию TASK_UNINTERRUPTIBLE и более безопасному, но легко прерываемому TASK_INTERRUPTIBLE. Своим появлением состояние TASK_KILLABLE обязано проблеме, возникшей в 2002 г. и связанной с драйвером файловой системы OpenAFS, который блокировал все сигналы и ожидал наступления события, находясь в состоянии, допускающем прерывания. Новое состояние приостановки аналогично TASK_UNINTERRUPTIBLE, но позволяет обрабатывать фатальные сигналы. В данной статье автор освещает это нововведение и на примерах исходных текстов ядра Linux 2.6.26 и более ранней версии 2.6.18 обсуждает связанные с ним изменения и новые API.

>>> Подробности

★★★

Проверено: Shaman007 ()

а парой веток ниже линуксоиды с пеной у рта доказывали бздунам, что API ядра давно не меняется от кернела к кернелу :)

anonymous
()

Дык они ничего и не меняли. Добавили пяток новых функций...

ssvda
()

Я полный ламер в API ядра, но вопрос все-таки имею. А не проще было поправить код драйвера OpenAFS так, чтобы он не допускал таких ситуаций? ИМХО до этого ядро жило и не тужило без этого состояния процесса.

m1rag3 ★★
()
Ответ на: комментарий от anonymous

>а парой веток ниже линуксоиды с пеной у рта доказывали бздунам, что API ядра давно не меняется от кернела к кернелу :)

следует отличать расширение и изменение API, не меняли то ничего, расширили ;)

G
()
Ответ на: комментарий от m1rag3

> Я полный ламер в API ядра, но вопрос все-таки имею. А не проще было поправить код драйвера OpenAFS так, чтобы он не допускал таких ситуаций? ИМХО до этого ядро жило и не тужило без этого состояния процесса.

Случай с OpenAFS - это прецендент. Стоит задуматься о возможности его повторения с другими модулями.

anonymous
()
Ответ на: комментарий от m1rag3

Я не раз сталкивался с проблемой "подвисшего" процесса в UNINTERRUPTIBLE_SLEEP.

В основном конечно это были проблемы железа или драйверов (в основном ФС), но было бы неплохо иметь возможность пристреливать такие процессы.

Nao ★★★★★
()
Ответ на: комментарий от G

С другой стороны

С учетом вот эжтого мнения (http://www.linux.org.ru/jump-message.jsp?msgid=3496337&cid=3496483) неизбежно следует переписывание софта, и, наверняка, не одного. Т.ч. в целом и "расширение API" тоже может привести к тому же результату, что и "изменение API".

anonymous
()
Ответ на: комментарий от m1rag3

> ИМХО до этого ядро жило и не тужило без этого состояния процесса.

А вот это неправда. Использование этого флага вместо TASK_UNINTERREPTIBLE должно решить проблему неприбиваемых процессов застрявших в IO wait. Очень, очень полезная фича.

Darkman ★★★
()
Ответ на: комментарий от Darkman

>А вот это неправда. Использование этого флага вместо TASK_UNINTERREPTIBLE должно решить проблему неприбиваемых процессов застрявших в IO wait. Очень, очень полезная фича.

процессы, застрявшие в io wait никому не мешают.

dikiy ★★☆☆☆
()
Ответ на: комментарий от anonymous

> а парой веток ниже линуксоиды ...

Врёте, я вот например, с пеной у рта доказывал, что не бздунье дело указывать linux-одидам что и где делать. И что API должно меняться, ибо в том суть развития и преимущество opensource. Нельзя улучшать не меняя. Это пусть M$ тащит своё говно в 25 век - у него обязательства есть, продало продукт - должно работать, вариант 'пересобрать' недопустим, так как не из чего.

alx_me ★★☆
()
Ответ на: комментарий от anonymous

> а парой веток ниже линуксоиды с пеной у рта доказывали бздунам, что API ядра давно не меняется от кернела к кернелу :)

То-то нвидиевский драйвер нихрена не собирается на релиз кандидатах ядер, пока драйвер не пофиксят. linux/Documentation/stable_api_nonsense читали?

http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt

или вы путаете ЭТО с ABI ядра?

sf ★★★
()
Ответ на: комментарий от dikiy

> процессы, застрявшие в io wait никому не мешают.

Дааа.... ? А если я хочу вытащить битый диск из привода ? Ребутаться ?

Darkman ★★★
()
Ответ на: комментарий от Darkman

> процессы, застрявшие в io wait никому не мешают. >> Дааа.... ? А если я хочу вытащить битый диск из привода ? Ребутаться ?

Не, просто звонишь Пиусу и он на скорой едет тебя спасать. Как в фильме про погоню.

anonymous
()

Хорошо, процесс находился в состоянии TASK_UNINTERRUPTIBLE, ввода не поступало и он висел.

Зачем разрабатывать TASK_KILLABLE, если можно было использовать TASK_INTERRUPTIBLE вместо TASK_UNINTERRUPTIBLE?

Я не придираюсь. Я хочу понять суть.

anonymous
()
Ответ на: комментарий от dikiy

> процессы, застрявшие в io wait никому не мешают.

Ну да, конечно! Попробуйте перезагрузить машину, если имеется хотя бы один такой процесс. А фигушки! Не перегрузите никак, а значит -- только жесткий резет со всеми вытекающими. Наблюдал такое регулярно в cifsd, когда отваливался сервер.

annoynimous ★★★★★
()
Ответ на: комментарий от anonymous

да чоуж там надо было докучи ввести TASK_FUCKABLE TASK_EBABLE TASK_OHUABLE TASK_ZAEBABLE TASK_IDINAHUABLE

anonymous
()

Теперь новые программы со старым ядром работать не будут?

Nxx ★★★★★
()
Ответ на: комментарий от anonymous

> Хорошо, процесс находился в состоянии TASK_UNINTERRUPTIBLE, ввода не поступало и он висел.

Он не просто висел - для него не обрабатывались никакие сигналы. Вообще. TASK_KILLABLE разерашает обрабатывать фатальные - типа 9-го и 11-го.

Darkman ★★★
()
Ответ на: комментарий от Darkman

>Дааа.... ? А если я хочу вытащить битый диск из привода ? Ребутаться ?

1) echo 0 > /proc/sys/dev/cdrom/lock 2) булавочку соотв. отверстие в дисководе вставить 3) подождать около минуты, пока таймаут не пройдет.

Любой из трех вариантов выбирай.

dikiy ★★☆☆☆
()
Ответ на: комментарий от annoynimous

>Ну да, конечно! Попробуйте перезагрузить машину, если имеется хотя бы один такой процесс. А фигушки! Не перегрузите никак, а значит -- только жесткий резет со всеми вытекающими. Наблюдал такое регулярно в cifsd, когда отваливался сервер.

Это вы так наивно полагаете.

dikiy ★★☆☆☆
()
Ответ на: комментарий от Darkman

Я и говорю, что можно было вместо TASK_UNINTERRUPTIBLE переводить его в TASK_INTERRUPTIBLE. В этом состоянии он мог быть прерван сигналом.

Я не могу понять отличие TASK_INTERRUPTIBLE от TASK_KILLABLE. По ссылке не ходил. Вернее статью не читал.

Но не могу понять - если можно перевести его в состояние когда сигналы могут прервать процесс, зачем разрабатывать еше один.

anonymous
()
Ответ на: комментарий от anonymous

Это же Open Source! Ты что, новенький штоле? :)

anonymous
()
Ответ на: комментарий от anonymous

> Я и говорю, что можно было вместо TASK_UNINTERRUPTIBLE переводить его в TASK_INTERRUPTIBLE. В этом состоянии он мог быть прерван сигналом.

> Я не могу понять отличие TASK_INTERRUPTIBLE от TASK_KILLABLE. По ссылке не ходил. Вернее статью не читал.

> Но не могу понять - если можно перевести его в состояние когда сигналы могут прервать процесс, зачем разрабатывать еше один.

аналогично :(

никак не могу понять зачем _целое новое состояние_ задачи, только для того чтобы отфильтровать сигналы

rudchenkos
()
Ответ на: комментарий от rudchenkos

> никак не могу понять зачем _целое новое состояние_ задачи, только для того чтобы отфильтровать сигналы

Не принимайте так близко к сердцу. Это не "целое новое состояние", а просто ещё одно состояние. Наверняка это проще, чем склеивать три состояния в одно и заводить дополнительно маску обрабатываемых (ядром) сигналов.

const86 ★★★★★
()
Ответ на: комментарий от anonymous

> Я и говорю, что можно было вместо TASK_UNINTERRUPTIBLE переводить его в TASK_INTERRUPTIBLE. В этом состоянии он мог быть прерван сигналом.

Тогда, например, вызов write может быть прерван SIGINT'ом и будет вынужден вернуть управление юзерспейсу на полпути. А это не по хигу^W посиксу.

> Я не могу понять отличие TASK_INTERRUPTIBLE от TASK_KILLABLE. По ссылке не ходил. Вернее статью не читал.

Второе позволяет ловить только те сигналы, после которых всё равно управление в юзерспейс не возвращается.

const86 ★★★★★
()
Ответ на: комментарий от dikiy

>процессы, застрявшие в io wait никому не мешают.

процессы, застрявшие увеличивают счётчик использования модуля на отличное от нуля значение. тем самым, модуль можно выгрузить только с опцией CONFIG_MODULE_FORCE_UNLOAD, а иной раз и с этой опцией модуль выгружаться отказывается.

а так, если прибить userspace процесс, который использует данный модуль ядра, то тот можно выгрузить его штатными средствами, он отработает сценарии деинициализации, kfree там и всё такое. потом может быть загружен снова.

на самом же деле, грамотно написаный модуль ядра не будет позволять userspace процессам подвисать навсегда со статуом io_wait. но это уже совсем другой вопрос, это уже тема "как правильно составить багрепорт"

swar0g ★★★★
()
Ответ на: комментарий от dikiy

> 1) echo 0 > /proc/sys/dev/cdrom/lock 2) булавочку соотв. отверстие в дисководе вставить 3) подождать около минуты, пока таймаут не пройдет.

А если это SCSI HDD ? Там отнюдь не минута. А сервак раком стоит. Или мы админ локалхоста ?

Darkman ★★★
()
Ответ на: комментарий от anonymous

> Но не могу понять - если можно перевести его в состояние когда сигналы могут прервать процесс, зачем разрабатывать еше один.

Не просто сигналы, а _фатальные_ сигналы. Чувствуем разницу ?

Darkman ★★★
()
Ответ на: комментарий от dikiy

> 1) echo 0 > /proc/sys/dev/cdrom/lock 2) булавочку соотв. отверстие в дисководе вставить 3) подождать около минуты, пока таймаут не пройдет.

Как-то раз xfburn с кривой болванкой загнал привод в состояние, из которого ни 1 ни 3 не действовали. Делать 2 при бешено вращающемся диске для механики не полезно, имхо.

question4 ★★★★★
()
Ответ на: комментарий от question4

> Как-то раз xfburn с кривой болванкой загнал привод в состояние, из которого ни 1 ни 3 не действовали. Делать 2 при бешено вращающемся диске для механики не полезно, имхо.

Выдернуть питание из привода :)

const86 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.