Программирование ядра Linux: «Невозможно обработать разыменование нулевого указателя ядра в виртуальном адресе [адрес]» - PullRequest
1 голос
/ 02 октября 2010

Для назначения класса мы пишем пользовательский системный вызов, который извлекает определенную информацию о существующем дереве процессов.Системный вызов работает нормально по большей части и получает соответствующую информацию.Тем не менее, некоторые из них обрабатывают его в аварийных ситуациях с сообщением об ошибке «Невозможно обработать разыменование указателя NULL в ядре по виртуальному адресу [адресу]».Чего я не понимаю, так это того, что я проверяю, имеет ли указатель значение NULL перед тем, как получить к нему доступ, и все же он все еще не работает.

Пример: в приведенном ниже коде current_process является действительным указателем на task_struct иk_buf действителен

printk("Setting parent process\n");
parent_process = current_process->real_parent;
printk("Parent process set\n");
if (parent_process != NULL) {
printk("Parent process is not null and getting pid\n");
    k_buf[i].parent_pid = parent_process->pid;
} else {
    k_buf[i].parent_pid = 0;
}
printk("Done with parent process\n");

При запуске программа печатает:

Setting parent process
Parent process set
Parent process is not null and getting pid
Done with parent process

пару раз, а затем

Setting parent process
Parent process set
Parent process is not null and getting pid

, прежде чем выдать ошибку и перейтив панику ядра.

Что я делаю не так?Есть мысли?

РЕДАКТИРОВАТЬ:

В настоящее время я закомментировал приведенный выше код, чтобы я мог продолжить работу над остальной частью системного вызова.Когда я пытаюсь получить доступ к pid дочернего процесса (снова после нескольких успешных попыток), он выдает ошибку «Невозможно обработать пейджинговый запрос ядра по виртуальному адресу».Насколько я понимаю, у меня есть правильные блокировки для чтения этих данных.Однако, есть ли что-то еще, что мне нужно сделать, чтобы проверить память, прежде чем я получу к ней доступ?

Ответы [ 3 ]

1 голос
/ 02 октября 2010

Я размышляю здесь, но могло ли parent_process->pid быть NULL быть причиной вашей "паники ядра"? Если это так, вы можете проверить это тоже.

Это либо проблема, либо некоторая проблема с доступом к i -ому элементу массива k_buf, т.е. *(k_buf+i)

1 голос
/ 03 октября 2010

Вы не проверяете kbuf из kbuf[i] перед доступом. Кроме того, вы можете printk эти указатели, чтобы вы могли ловить ненулевые, но явно недействительные адреса (такие как 0xbfff0c3a)

0 голосов
/ 02 октября 2010

У меня два вопроса. Каковы возможные значения для real_parent? Возможно ли, что это не NULL? Можете ли вы напечатать это значение и проверить, что это такое, прежде чем ядро ​​паникует?

Кроме того, вы уверены, что k_buf [i] правильно разыменовывается? Я не уверен, просто пытаюсь выдвинуть некоторые идеи.

Редактировать: я согласен с crypto
parent_process-> pid, вероятно, равен нулю.

...