Создатель Linux Линус Торвальдс рассказал о поиске серьезного бага в драйвере Intel Xe, который мог приводить к бесконечным перезапускам графической оболочки и черному экрану.
В расследовании ему помогал ИИ. Однако, что забавно, тот несколько раз уверенно заявлял, что проблема якобы нерешаема.
Читают прямо сейчас:
Что такое плавающая ошибка — именно такой баг искал Торвальдс: ошибка, которая воспроизводится не всегда и зависит от конкретного состояния памяти
Что такое драйвер и зачем он нужен — как драйверы управляют железом и почему неправильное округление границы памяти приводит к черному экрану
Лог-файл: что такое логирование и зачем это нужно — как с помощью логов удалось за 24 патча и 18 перезагрузок сузить причину бага до одной строки кода
Драйвер отдавал видеопамять, занятую системой сжатия
Проблема оказалась в обработке памяти CCS — специального хранилища метаданных, которое используется аппаратным блоком сжатия данных. Функция get_flat_ccs_offset() вычисляла границу зарезервированной области, а затем округляла ее вверх до 128 КБ.
Именно здесь и скрывалась ошибка. Граница означала «здесь заканчивается доступная память», поэтому округление вверх заставляло драйвер считать свободным участок, который на самом деле принадлежал системе сжатия.
На Intel Battlemage G21 с 16 ГБ памяти реальная граница находилась по адресу 0x3fafff800, а после округления становилась 0x3fb000000. В результате последние 2 КБ страницы попадали в пул памяти, который драйвер считал свободным.
Когда эта страница выделялась, аппаратный блок сжатия мог самостоятельно перезаписывать ее содержимое — без участия драйвера, таблиц страниц или пользовательских процессов.
Исправление оказалось буквально в одной строке
В итоге причина нашлась в неправильном округлении границы памяти. Вместо round_up() разработчик заменил его на round_down() — границу стали округлять вниз до размера страницы.
На конкретной системе это исключило из пула доступной памяти ровно одну страницу и не позволило драйверу использовать область CCS.
Дополнительная проверка в коде тоже оказалась бесполезной: она сравнивала смещение с уже выровненным значением GSMBASE – ccs_size. Из-за этого проверка фактически не могла обнаружить именно тот случай, ради которого была написана. К тому же она отключена без CONFIG_DRM_XE_DEBUG.
До одной строки дошли после 24 патчей
Самое интересное — путь к этому простому исправлению оказался совсем не простым. По словам Торвальдса, для поиска причины потребовалось 24 отладочных патча и 18 загрузок ядра.
ИИ активно помогал с расследованием: добавлял отладочный код, анализировал полученные данные и помогал постепенно сужать круг возможных причин.
Но обошлось и без драмы. Торвальдс рассказал, что ИИ несколько раз прямо заявлял, что проблема невозможна и решить ее нельзя, предлая вместо этого просто написать отчет.
Торвальдс продолжал копать, а ИИ — добавлять диагностику и анализировать результаты. В итоге упрямство человека победило, а искусственный интеллект получил почетную должность автора commit message.
