Читать онлайн «Разработка ядра Linux». Страница 113

Программа ksymoops включена в большинство поставок операционной системы Linux.

К счастью, больше нет необходимости использовать программу ksymoops. Это очень полезно, потому что, хотя, у разработчиков обычно нет проблем с ее использованием, пользователи часто указывают неправильный файл System.map, или неправильно декодируют сообщение oops.

В разрабатываемой серии ядра 2.5 была введено новая возможность kallsyms, которая включается с помощью конфигурационного параметра CONFIG_KALLSYMS. Эта функция включает в исполняемый образ ядра информацию для отображения адресов памяти в соответствующие имена функций ядра, что дает возможность ядру самостоятельно декодировать информацию обратной трассировки. Следовательно, декодирование сообщений oops больше не требует файла System.map, или утилиты kallsyms. Как недостаток такого подхода следует отметить некоторое увеличение объема памяти, используемой ядром, так как таблица перевода адресов памяти в имена функций загружается в постоянно отображаемую память ядра. На такое увеличение объемов используемой памяти стоит пойти, по крайней мере, на этапе разработки ядра.

Существует несколько конфигурационных параметров, которые помогают в отладке и тестировании кода ядра и которые включаются во время компиляции. Эти параметры доступны в пункте Kernel hacking меню редактора конфигурации ядра. Все эти параметры зависят от параметра CONFIG_DEBUG_KERNEL. Для разработки кода ядра следует включать только те параметры, которые необходимы.

Некоторые из этих параметров достаточно полезны, такие как отладка работы со слябовым распределителем памяти (slab layer debugging), отладка работы с верхней памятью (high memory debugging), отладка работы с отображаемым на память вводом-выводом (I/O mapping debugging), отладка работы со спин-блокировками (spin-lock debugging) и проверка переполнения стека (stack overflow checking). Однако, один из самых полезных параметров — это проверка перехода в состояние ожидания при захваченной спин-блокировке (sleep-inside-spinlock checking), которая на самом деле выполняет значительно больше работы.

Начиная с серии 2.5 в ядре появилась отличная инфраструктура для определения всех типов нарушения атомарности. Вспомните из главы 8, "Введение в синхронизацию выполнения кода ядра", что атомарность означает неделимое выполнение, то есть код выполняется без перерыва до завершения, или не завершается вообще. Код, который удерживает спин-блокировку, или выполняется при запрещенной преемптивности ядра, является атомарным. Во время атомарного выполнения нельзя переходить в состояние ожидания. Ожидание при удерживаемой спин-блокировке — один из вариантов взаимоблокировки.

Благодаря свойствам преемптивности, ядро имеет глобальный счетчик преемптивности. Ядро может быть настроено так, что, если выполняется переход в состояние ожидания, или даже выполняется код, который потенциально может переходить в состояние ожидания при выполнении атомарной операции, то ядро выводит предупреждающее сообщение и обратную трассировку. Потенциальные ошибки, которые детектируются таким образом, включают вызов функции schedule () при удерживаемой блокировке, выполнение блокирующего выделения памяти при удерживаемой блокировке, или переход в состояние ожидания при удерживаемой ссылке на данные, связанные с процессором. Эта отладочная инфраструктура может обнаружить очень много ошибок и ее очень рекомендуется использовать.

Следующие конфигурационные параметры позволяют полностью использовать данную возможность.

CONFIG_PREEMPT=y

CONFIG_DEBUG_KERNEL=y

CONFIG_KALLSYMS=y

CONFIG_SPINLOCK_SLEEP=y

Существует несколько подпрограмм ядра, которые позволяют легко сигнализировать о наличии дефектов кода, обеспечивать объявления об ошибках и выводить необходимую информацию. Две наиболее часто используемые — это BUG() и BUG_ON(). При вызове эти функции создают ситуацию oops, которая проявляется в выводе обратной трассировки стека ядра и сообщения об ошибке. Каким образом эти вызовы генерируют ситуацию oops зависит от аппаратной платформы. Для большинства аппаратных платформ вызовы BUG() и BUG_ON() определяются как некоторая недопустимая машинная команда, которая приводит к выводу желаемого сообщения oops.

Обычно эти вызовы используются в качестве объявления о наличие ошибки (assertion), чтобы сигнализировать о ситуации, которая не должна произойти.

if (bad_thing)

 BUG();

Или даже так.

BUG_ON(bad_thing);

О более критичной ошибке можно сигнализировать с помощью функции panic(). Функция panic() печатает сообщение об ошибке и останавливает ядро. Ясно, что эту функцию следует использовать только в самой плохой ситуации.

if (terrible_thing)

 panic("foo is %ld!\n", foo);

Иногда необходимо просто вывести на консоль трассировку стека, чтобы облегчить отладку. В этих случаях используется функция dump_stack(). Эта функция отображает на консоль содержимое регистров процессора и обратную трассировку вызовов функций.

if (!debug_check) {

 printk(KERN_DEBUG "выдать некоторую информацию...\n");

 dump_stack();

}

Использование магической клавиши SysRq, которую можно активизировать с помощью конфигурационного параметра CONFIG_MAGIC_SYSRQ на этапе компиляции, часто позволяет значительно облегчить жизнь. Клавиша SysRq является стандартной на многих клавиатурах. Для аппаратных платформ i386 и PPC ей соответствует комбинация клавиш ALT-PrintScreen. Если указанный конфигурационный параметр активизирован, то специальные комбинации клавиш позволяют взаимодействовать с ядром независимо от того, чем ядро в данный момент нанимается. Это в свою очередь позволяет выполнять некоторые полезные операции даже на неработоспособной системе.

В дополнение к конфигурационному параметру существует вызов sysctl для включения и выключения этого свойства.

echo 1 > /proc/sys/kernel/sysrq

Список возможных комбинаций клавиш можно получить с консоли путем нажатия комбинации клавиш SysRq-h. Комбинация клавиш SysRq-s выполняет синхронизацию не сохраненных буферов файловых систем на диск, комбинация SysRq-u размонтирует все файловые системы, a SysRq-b — перегружает машину. Последовательное использование этих комбинаций клавиш позволяет более безопасно перегрузить машину, которая зависла, чем простое нажатие кнопки reset.

Если машина заблокирована очень сильно, то она может не отвечать на магические комбинации клавиш SysRq, или соответствующая операция не будет выполнена. Если же повезет, то эти комбинации клавиш смогут помочь при отладке, а также сохранить данные. В табл. 18.2 приведен список поддерживаемых команд SysRq.

Таблица 18.2. Список поддерживаемых команд SysRq

Команда Описание SysRq-b Перегрузить машину (reboot) SysRq-e Послать сигнал SIGTERM всем процессам, кроме процесса init SysRq-h Отобразить на консоли помощь по использованию комбинаций клавиш SysRq SysRq-i Послать сигнал SIGKILL всем процессам, кроме процесса init SysRq-k Клавиша безопасного доступа: завершить все процессы, связанные с текущей консолью SysRq-l Послать сигнал SIGKILL всем процессам, включая процесс init SysRq-m Отобразить на консоли дамп информации по использованию памяти SysRq-o Завершить работу машины (shutdown) SysRq-p Отобразить на консоли дамп регистров памяти SysRq-r Отключить прямой режим работы клавиатуры (raw mode) SysRq-s Синхронизировать данные смонтированных файловых систем с дисковыми устройствами SysRq-t Отобразить на консоли дамп информации о заданиях SysRq-u Размонтировать все смонтированные файловые системы

В файле Documentation/sysrq.txt, который находится в каталоге исходных кодов ядра, приводится более полное описание. Реализация поддержки магической комбинации клавиш находится в файле drivers/char/sysrq.с. Магические комбинации клавиш SysRq — жизненно необходимый инструмент, который помогает в отладке и сохранении "гибнущей" системы, так как предоставляет большие возможности для любого пользователя при работе с консолью. Тем не менее необходимо соблюдать осторожность при его использовании на критичных машинах. Если же машина используется для разработок, то польза от этих команд огромная.