July 18th, 2007

nepal

история бага

Уже написал по-английски, теперь попытаюсь по-русски рассказать историю, как OpenVZ team пофиксила один малюсенький баг в линуксовом ядре.

У нас в OpenVZ есть такая подсистема -- beancounters, это, грубо говоря, набор счётчиков и лимитов на всякие ресурсы. У каждой VE есть свои лимиты и счётчики (которые показывают текущее потребление ресурсов). Когда VE останавливается, счётчики должны приходить к нулевым значениям. Если не приходят -- где-то что-то ликает, течёт, то бишь, где-то кто-то что-то взял, а потом забыл отдать.

Так вот, три месяца назад команда тестеров обнаружила, что параметр kmemsize.held (который отвечает за память ядра, использованную для VE) после остановки одного ВЕ остался 78 байт (что несколько больше нуля). Значит, утекло 78 байт ядерной памяти.

Хорошо, что у нас в бинкаунтерах есть дебаг, который показывает, что именно утекло. Утекла одна struct user. Баг воспроизвести никак не удалось, поэтому его на время отложили, однако, багрепорт не закрыли.

Через какое-то время Паша к нему вернулся и понял, что единственный способ найти баг -- это прогрепать исходники на те места, где берутся и освобождаются struct user, и глазуально проверить логику всех тех мест. На это у него ушло полдня -- проверив практически всё, он нашёл место, где при некоторых условиях ссылка на объект struct user теряется.

Дальше уже проще -- написать код, воспроизводящий те самые условия. Убедиться, что течёт. Написать фикс (однострочный, кстати). Убедиться, что починил. Отправить патч и описание в LKML.

Что тут интересного:
1. Эндрю Мортон поинтересовался, как это так, откуда мы находим столько багов (наших патчей в ядро попало примерно 300 за последний год -- это почти всё багфиксы).
2. В данном случае помогли наши бинкаунтеры -- если б не они, хрен бы кто заметил утечку ядерной памяти смешным размером в 78 байт.
3. В данном случае также помогло упорство членов кернель тима (конкретно, Паши) -- они никогда не закрывают баги просто так, всегда докапываясь до причин (в большинстве случаев это удаётся, но бывают, правда, и "висяки").

Вот так. За каждым багом стоит, как правило, интересная история, но ту историю, как правило, никто не знает.