Сегодня научился ронять ядро.
Следующим образом:
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
Вот я теперь думаю: я был не прав или всё-таки оно не должно было упасть?
Что ответит Александр ДрузьКО?
Полный RSS
Хм… Вообще-то давно твердили о необходимости проверки результатов, возвращаемых функциями 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?
Я бы всё же ещё на рейзер погрешил, как на менее используемуй и менее вычитанный. Хотя да, тут скорее сильно удивился драйвер ext, всё же. Другое дело,. что даже если они оба и удивились, ядру-то от этого сильно плохо становиться не должно, oops максимум.