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

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

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

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

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

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

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

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

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

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

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

скорее не переписывание , а дописывание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понял мало, но одобряю!

ниче не понял

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

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

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

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

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

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

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

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