Сегодня научился ронять ядро.
Следующим образом:
mkfs.ext2 /dev/sdc2
mount /dev/sdc2 /mnt
iozone … -f /mnt/io #бенчмарк
В другом потоке:
dd if=/dev/zero of=/dev/sdc2 bs=1024 count=1024
mkfs.reiserfs /dev/sdc2
Вот я теперь думаю: я был не прав или всё-таки оно не должно было упасть?
Что ответит Александр ДрузьКО?
Хм… Вообще-то давно твердили о необходимости проверки результатов, возвращаемых функциями write, close и им подобным. По-моему роняет ядро процесс iozone (кстати, а где посмертный дамп?). Ибо ни dd, ни mkfs на это скорее всего не способны.
А дальше… А дальше самое интересное. По идее, ни один пользовательский процесс не должен ронять ядро. Но с другой стороны, и ошибки от ядра должны обрабатываться правильно. На ядерном уровне предусмотреть все вообще крайне сложно, а Вас, видимо, надо поздравить с нахождением очередного разименованого нулевого указателя. Обновляться до последних сборок ядра, iozone и (если не поможет) багрепорт в оба проекта.
А вообще, в таких случаях хочется увидеть oops (BUG) из логов.
Лога нет, хотя, конечно, стоило бы попробовать воспроизвести с серийной консолью. Может как-нибудь даже сделаю. Но, боюсь, что не факт, что получится.
Естественно iozone свалился где-то в потрохах ext2, так что он сам тут ни при чем.
Ядро 2.6.32 то есть довольно свежее, что несколько удивляет.
По идее структуры памяти в ext2 я же не трогаю, только издеваюсь в реальном времени над содержимым примонтированного диска. То есть баг в ext2, которая поверила данным с диска. Но с другой стороны, вдруг она имеет право им верить, если предварительно какие-то проверки были сделаны при монтировании, например. Вот ответ на этот вопрос мне интересен. Вдруг кто в код файловых систем лазил и в курсе. Я – нет.
Стоп! А с чего Вы взяли, что iozone не при делах? ЛЮБАЯ ПРОГРАММА ДОЛЖНА ВЕСТИ СЕБЯ КОРРЕКТНО, По ОТНОШЕНИЮ К ОС. iozone наверняка получает ошибку от ОС, но не реагирует на нее, тупо продолжая читать/писать. И именно это ее действие роняет (дырявое) ядро. Так что по любому, обоюдка =)
И потом, Ваши выводы без CallStack’а (минимум) ничего не говорят. Ну да, дебри EXT2, но попасть туда можно из sys_write, которую вызвает iozone. Так что… Кстати, а в syslog оно не попадает при соответствующей настройке?
Хотя, еще раз – я не спорю. Ядро должно не в корку падать, а iozone завершать с SIGFAULT’ом или, возможно, SIGBUS (но, таки и iozone не должен доводить ядро до такого, он сам должен нормально завершаться в случае ошибок).
Но в целом, слава богу тестеры еще не перевелись =) Мне бы и в голову не пришло забивать нулями примонтированный диск, а уж ежели на нем еще и бенч какой крутится, то и подавно. Так что полюбому респект (и уважуха).
ОС должна переживать любое неадекватное поведение юзерспейса.
Нда… Вот и столкнулись точки зрения разработчиков ядра и прикладного софта. Я же сразу написал – баг репорт в ОБА проекта. Понятно, что идеальная ОС никогда не будет падать от пользовательского софта. Но проверка всех возможных входных данных во всех возможных системных вызовах? И разарботчиков ядра на это подвигают те, кому в своей прикладнухе результат операций ввода-вывода проверить сложно. Как обычно, насрать (простите) – это мы запросто, а убирает пусть дядя. В целом обычная ситуация… Каждый “уровень” винит соседний в некоректной работе, но уверяю Вас – такие баги не бывают чисто ядерными – иначе ни о каком “Линуксе на проакшене” и речи бы не шло.
Чем больше стен, тем больше расслабляются защитники города. И в один прекрасный момент оказывается, что все ворота открыты и враг в городе. Каждый уровень просто обязан позаботиться о себе сам, не надеясь и не расчитывая ни на кого. Но это совершенно идеологически неверно, когда крыша выполняет роль фундамента. Это как запрет на доступ к файлам в винде через запрет на запуск эксплорера. Но другие то программы и незнают, что эксплореру запрещено запускаться и знать не должны. Иначе кто здесь операционная система и в доме хозяин?
да, в ext2 полно таких багов. никто его особо не тестирует.
Вероятно, что так.
вероятно, если параллельно писать в /dev/sda нули, будет то же самое
но это, как бы, давно известное поведение – фича
Чья фича? Ext2 или вообще подсистемы fs?
Доступ к памяти ядра – фича???
Помню, было смешно, когда через DMA можно было всё что угодно с ядром вытворять, но это проблема аппаратная и похоже до сих пор не полностью изжитая. А позволять обманывать процессы ядра и назвать это фичей??
Кстати, хоть поделитесь линкой на фичу – если таковая официально описана.
Я бы всё же ещё на рейзер погрешил, как на менее используемуй и менее вычитанный. Хотя да, тут скорее сильно удивился драйвер ext, всё же. Другое дело,. что даже если они оба и удивились, ядру-то от этого сильно плохо становиться не должно, oops максимум.
Вообще, судя по описанию, картина выглядит таким образом: мы тут во всю стараемся, шифруем память ядра, такскаем её по памяти туды сюды, прячем, так сказать, от товарищей, которые нам совсем не товарищи, стек маркируем, файрволы возводим, виртуальную реально виртуально реализуем, а тут – какой-то процесс, инспирированный дырявым говноскриптом в PHP, подменяет через диск блоки памяти ядра (а fs – она таки часть ядра с высокими привилегиями, иначе тормоза) и в определённой комбинации вполне себе пишет туда код с ядрёными правами.
Хм, php с правом записи на диск это уже само по себе пугает. Но подменяются всё-таки не блоки памяти, а содержимое некоторых структур, которые почему-то не проверяются.
Что страшного в доступе к диску PHP? Все языки имеют таковой доступ, кроме, наверно, javascript в v8 и то не уверен – не работал с ним.
Впрочем, в описанной ситуации – действительно страшно )
Особенно после сколковского сайта ))
ты путаешь диск как блочное устройство и диск как фс.
Эээ, а где кнопка Reply на том сообщении?
Что значит путаю? Ничего не путаю ))
ФС заняла блочное устройство – больше там никого не должно быть, все остальные идут на диск через ФС, которая умеет разграничивать доступ, в отличие от блочного устройства, которому в общем-то пофиг, кто, что, куда и в каком порядке друг за другом перезапишет.
Для чего собственно ФС и создаются – управлять записью. От банального “что где лежит и где свободное место”, до всяких квот, блокировок и контроля целостности.
Сам же пишешь:
Там ограничение по глубине стоит.
Таки, каким образом обсуждение доступа к диску из ПО указывает на то, что я путаю файлы устройств и файлы ФС?
Перечитай тред
Что-то я вообще не понял, а с какого, извините, вот это:
dd if=/dev/zero of=/dev/sdc2 bs=1024 count=1024
mkfs.reiserfs /dev/sdc2
получило вообще хоть какой-то доступ на запись при вот этом:
mount /dev/sdc2 /mnt
???????
device /dev/sdc2 is busy и нефиг другим процессам что-то трогать в деликатной структуре файловой системы, а тем более ронять всю core, они ж не имеют права открывать файл устройства. А если могут, то извините, к кому вопрос???
Но я уже как-то привык, что разные версии ядра могут то тупо не видеть UUID, то замирать на загрузке без ответа и привета, то вдруг по разному определять порядок устройств (при одной и той же версии grub’а), поэтому эта новость – тоже как бы не из разряда вон. Багрепорт и в unstable релиз ядра.
P.S. Кстати, конечно, история давняя, но с чего Вы вдруг мунистами заинтересовались? Я самой предыстории не видел, не читал, но судя по всему “действие отдавания-принятия” явно вызвало свечение на нити накала? ))
Я что-то не припомню, чтобы когда-то такие ограничения были. Да и по логике как минимум на чтение доступ нужен. Насчет записи не знаю, можно, конечно, в lkml спросить, но мне как-то неохота это исследовать.
Ну ладно, доступ на чтение я ещё понимаю и возможно соглашусь, хотя он тоже бессмысленен – если устройству назначен драйвер, то и доступ должен идти через этот драйвер, но совместный доступ на запись…
Сегодня вечером наверно проведу эксперимент с записью на монтированный диск. Хотя, что-то сомнения появились, вспоминаются смутно сообщения fsck, что исправление смонтированной файловой системы окончательно её добьёт…
Как-то это неправильно.
Если мне кто-то запретит сдампить блочное устройство под предлогом, что оно кем-то там еще примонтировано, то он долго не проживет.
fsck на примонтированной в ro файловой системе должен быть корректным. Если это не так – бить автора фс.
Почему нельзя сдампить согласованно с ФС?
Тупой дамп недосохранённой системы не гарантирует целостность данных – для чего он нужен? Если во время дампа часть данных меняется – тоже как-то не то выйдет, но тут LVM и ему подобные в помощь, которые, собственно, сами являются менеджерами доступа к диску и эту самую функцию записи согласовывают, где им доступно.
Опять же fsck вполне мог бы выполнять необходимые операции через соответствующий интерфейс ФС и на вполне writable ФС (что отчасти было, например, в XFS, когда она была вообще без fsck и все функции коррекции ложились на ФС).
Это значит, что надо значительную часть логики переносить в kernel space, что малоосмысленно.
Ты много знаешь ФС, которые такое предоставляют? Я кроме ext2 не знаю, да и у той вроде в какой-то момент дамп отломали.
А это уже другой вопрос. Главное, что задача сдампить синкнутый и неактивный раздел вполне реалистична.
Это не я ими интересовался первично. Это они интересовались мной и моей сексуальной жизнью. =)
Ну, в принципе да, они такие )))