Программирование ядра Linux: попытка получить vm_area_struct-> vm_start приводит к сбою ядра - PullRequest
4 голосов
/ 20 марта 2010

это для задания в школе, где мне нужно определить размер процессов в системе, используя системный вызов. Мой код выглядит следующим образом:

...
struct task_struct *p;
struct vm_area_struct *v;
struct mm_struct *m;
read_lock(&tasklist_lock);
for_each_process(p) {
    printk("%ld\n", p->pid);
    m = p->mm;
    v = m->mmap;
    long start = v->vm_start;
    printk("vm_start is %ld\n", start);
}
read_unlock(&tasklist_lock);
...

Когда я запускаю программу уровня пользователя, которая вызывает этот системный вызов, я получаю вывод:

1
vm_start - 134512640
2

EIP: 0073: [<0806e352>] ЦП: 0 не испорчен ESP: 007b: 0f7ecf04 EFLAGS: 00010246 Не испорчен
EAX: 00000000 EBX: 0fc587c0 ECX: 081fbb58 EDX: 00000000
ESI: bf88efe0 EDI: 0f482284 EBP: 0f7ecf10 DS: 007b ES: 007b
081f9bc0: [<08069ae8>] show_regs + 0xb4 / 0xb9
081f9bec: [<080587ac>] segv + 0x225 / 0x23d
081f9c8c: [<08058582>] segv_handler + 0x4f / 0x54
081f9cac: [<08067453>] sig_handler_common_skas + 0xb7 / 0xd4
081f9cd4: [<08064748>] sig_handler + 0x34 / 0x44
081f9cec: [<080648b5>] handle_signal + 0x4c / 0x7a
081f9d0c: [<08066227>] hard_handler + 0xf / 0x14
081f9d1c: [<00776420>] 0x776420


Паника ядра - не синхронизируется: ошибка режима ядра по адресу 0x0, ip 0x806e352


EIP: 0073: [<400ea0f2>] ЦП: 0 не испорчен ESP: 007b: bf88ef9c EFLAGS: 00000246 Не испорчен
EAX: ffffffda EBX: 00000000 ECX: bf88efc8 EDX: 080483c8
ESI: 00000000 EDI: bf88efe0 EBP: bf88f038 DS: 007b ES: 007b
081f9b28: [<08069ae8>] show_regs + 0xb4 / 0xb9
081f9b54: [<08058a1a>] panic_exit + 0x25 / 0x3f
081f9b68: [<08084f54>] notifier_call_chain + 0x21 / 0x46
081f9b88: [<08084fef>] __atomic_notifier_call_chain + 0x17 / 0x19
081f9ba4: [<08085006>] atomic_notifier_call_chain + 0x15 / 0x17
081f9bc0: [<0807039a>] паника + 0x52 / 0xd8
081f9be0: [<080587ba>] segv + 0x233 / 0x23d
081f9c8c: [<08058582>] segv_handler + 0x4f / 0x54
081f9cac: [<08067453>] sig_handler_common_skas + 0xb7 / 0xd4
081f9cd4: [<08064748>] sig_handler + 0x34 / 0x44
081f9cec: [<080648b5>] handle_signal + 0x4c / 0x7a
081f9d0c: [<08066227>] hard_handler + 0xf / 0x14
081f9d1c: [<00776420>] 0x776420

Первый процесс (pid = 1) дал мне vm_start без каких-либо проблем, но когда я пытаюсь получить доступ ко второму процессу, ядро ​​падает. Может кто-нибудь сказать мне, что не так, и, возможно, как это исправить? Большое спасибо!

(извините за плохое форматирование ....)

edit: Это делается в ядре Fedora 2.6 в среде uml.

Ответы [ 4 ]

5 голосов
/ 20 марта 2010

Некоторые потоки ядра могут не заполняться mm - проверьте p->mm для NULL.

2 голосов
/ 20 марта 2010

Изменен код проверки нулевых указателей:

m = p->mm;
if (m != 0) {
    v = m->mmap;
    if (v != 0) {
        long start = v->vm_start;
        printk("vm_start is %ld\n", start);
    }
}
1 голос
/ 03 декабря 2013

Для ядерных потоков mm будет нулевым . Поэтому всякий раз, когда вы читаете мм, делайте это следующим образом.

    down_read(&p->mm->mmap_sem)
          if(mm) {
                 /* read the contents of mm*/
          }
    up_read(&p->mm->mmap_sem)

Также вы можете использовать get_task_mm () . С get_task_mm () вам не нужно получать блокировку. Вот как вы это используете:

   struct mm_struct *mm;
   mm = get_task_mm(p);
   if (mm) {
           /* read the mm contents */
   }
1 голос
/ 05 февраля 2012

Вся связанная с процессом информация может быть найдена в файловой системе / proc на уровне пользовательского пространства. Внутри ядра эта информация генерируется через fs / proc / *. C

http://lxr.linux.no/linux+v3.2.4/fs/proc/

Глядя на файл task_mmu.c, который печатает всю информацию vm_start, вы можете заметить, что при любой обработке поля vm_start всегда требуется блокировка mmap_sem:

           down_read(&mm->mmap_sem);
            for (vma = mm->mmap; vma; vma = vma->vm_next) {
                    clear_refs_walk.private = vma;
...
                    walk_page_range(vma->vm_start, vma->vm_end,
                                    &clear_refs_walk);
...