codedot | Entries tagged with linux kernel

Обновление временных штампов при работе с отображаемыми в память файлами, скорректированное в ядре 2.6.24 принятием части восьмой версии решения для файловых систем, использующих общеядерный механизм file_update_time(), все еще остается для RAMFS и TMPFS. Между версиями ядра 2.6.31 и 2.6.32-rc4 подобную проблему в XFS удалось разрешить Christoph Hellwig.

После закрытия соответствующего бага 2645 ("msync() does not update the st_mtime and st_ctime fields") в январе 2008 года, к этому вопросу в LKML вернулись, когда было обнаружено, что при переходе от версии 2.6.24 к версии 2.6.26 ошибочное поведение временных штампов при использовании mmap() для работы с файлами проявилось снова. В последовавшем обсуждении проблемы в Kernel Bug Tracker вместо переоткрытия 2645 было предложено открыть новые баги против конкретных файловых систем.

Так как поведение XFS относительно значений atime и mtime стало корректным, возможно, пришло время попробовать разобраться с файловыми системами, лишенными запоминающего устройства (RAM-based), такими как RAMFS и TMPFS.

The kernel.org site: "Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance" - the "What is Linux?" section.

Andrew Morton, LKML: "I don't know how important all this is, really - we've had this bug for ever and presumably we've already trained everyone to work around it", "... the "standard" is so vague as to be useless" - discussing the bug #2645 (msync() does not update the st_mtime and st_ctime fields).

Один из четырех патчей, в котором сконцентрированы функциональные изменения, был принят в "upstream kernel" и вошел в недавно вышедшее ядро 2.6.24. После этого баг 2645 был закрыт. Тем не менее, часть поставленной задачи не была решена: повторные вызовы msync() с ключом MS_ASYNC после записи в память, на которую отображен файл, некорректно обрабатываются - во второй раз штампы не обновляются. Длительные обсуждения в LKML путей реализации так и не привели к решению из-за неоднозначности требований стандарта POSIX, многофакторности задачи и сложности реализации данной опции в Linux. Однако, задача остается до сих пор открытой.

После пятой и шестой версий решения для бага 2645, при обсуждении которых не только были предложены ценные замечания, но и заданы вопросы от людей, не перечитывающих обсуждения предыдущих вариантов изменений, решил опубликовать дизайн-документ, подводящий итоги обсуждений, описывающий важные принятые решения, устанавливающий связи и следствия между компонентами системы. Также было проведено тестирование на производительность для файловых систем Ext3 и Ext4. После публикации дизайн-документа, патча с чисткой кода, патча с функциональными изменениями и результатов тестирования была отправлена очередная серия писем в LKML. Хочется верить, что эта версия будет, наконец, принята.

Отправил в LKML четвертую версию решения для бага 2645, учтя все замечания к предыдущему. Как и прежде, оно разделено на чистку кода и функциональные изменения.

При работе над багом N в ядре, можно после получения последней его версии с помощью запуска, находясь в директории /usr/src:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux

или обновления уже загруженной копии командой "git pull" создать отдельную "ветку" и сразу перейти на нее с помощью "git checkout -b bugN". Сделав необходимые изменения для очередного патча в будущей серии, следует внести их в локальную версию репозитария, написав соответствующий "changelog": "git commit --all" - предварительно создав секцию "user" в конфигурационном файле Git и задав корректные значения переменным "name" и "email" внутри нее.

После завершения подготовки изменений, легко сформировать патчи с помощью команды "git format-patch -n -o ~/bugN master" по сравнению с последней версией ядра. Чтобы отправить последовательность писем в виде, который принят в LKML, самостоятельно составив текст главного письма, обобщающего изменения, рекомендуется такая команда:

git send-email --suppress-from --no-signed-off-by-cc --no-chain-reply-to --compose ~/bugN

После довольно продолжительного обсуждения второй версии патчей, подготовил новое решение для бага 2645, включающее опцию автоматического обновления временных штампов без необходимости явного вызова функции msync(). Перед отправкой существенно изменил тестовую программу так, что теперь она показывает успешный результат или сообщает об ошибке для каждого из пяти рассмотренных в ней случаев работы с файлом, отображенным в память. Менее чем через полчаса после отправления серии патчей (как и в предыдущем решении, состоящей из чистки кода и функциональных изменений) в LKML был получен "Acked-by" от Rik van Riel из RedHat. Но судьба патчей пока не решена.

Отправил вторую версию решения для бага 2645, разбив его на две части: чистку кода и функциональные изменения. Также изменил тестовую программу, учтя замечание в LKML. Надеюсь, это решение будет, наконец, принято.

На предложение закрыть баг 2645 выступил тот, кто его открыл, с просьбой отправить решение еще раз. После того как последовал его совету, он поддержал в LKML своими сообщениями ветку обсуждения, как и обещал. Наконец, через некоторое время ответил Jesper Juhl, что патч выглядит нормально, но он собирается тестировать изменения. Вероятно, он не заметил один абзац в первом письме об уже проведенном тестировании, на что обратил его внимание, поблагодарив за ответ, который уже и не надеялся получить.

Провел небольшую работу над багом с номером 2645, которую долгое время откладывал из-за недостатка энтузиазма. Предварительно назначив этот баг себе, подготовил патч, разрешающий проблему и содержащий чистку кода в файле, в котором функция sys_msync() единственная. После этого отправил письмо в LKML и заявил об этом в Kernel Bug Tracker. Спустя несколько дней, не получив ни малейшей реакции в списке рассылки, отправил повторно, но и во второй раз не был удостоен внимания.

Поэтому решил предложить закрыть баг как "WONTFIX", упомянув, что с частотой примерно раз в год присылаемые с 2006 года решения не принимались. Сейчас, похоже, остается лишь ждать ответа в Kernel Bug Tracker, так как в ответ LKML на свое письмо уже не верится.

Просмотрев первые 32 из почти полутора тысяч открытых багов, зарегистрированных в "Linux Kernel Tracker", заметил, что примерно три четверти из них связаны со специфическим оборудованием. Это наталкивает на мысль о введении системы тэгов, по которым можно разделить огромное количество багов на те, что требуют редкого оборудования для работы, и те, которые можно воспроизвести и проанализировать на среднестатистической машине или эмуляторе Qemu. Очевидно, что большая часть сообщества не идет на то, чтобы покупать дорогостоящее или просто редкое оборудование. Поэтому, я считаю, не следует ждать от него разрешения более тысячи проблем, о которых сказано выше.

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

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

Неправильно написав тест для проверки порядка доставки сигналов процессу, который специфицирован в стандарте POSIX, изменил код функции next_signal() в ядре Linux и послал патч в LKML. Через некоторое время мне указали на проблему в тестовой программе. Измененный тест прошел нормально, поэтому изменения были отклонены. Оказалось, что если не блокировать сигналы в обработчике, то порядок доставки сигналов процессу может измениться на противоположный тому, который определяет стандарт. Этот пример демонстрирует, к каким серьезным ошибкам может привести неаккуратность в работе с неатомарными операциями.