pte_unmap(ptep);
falta justo antes de que salga la etiqueta. Intenta cambiar el código de esta manera:
...
page = pte_page(pte);
if (page)
printk(KERN_INFO "page frame struct is @ %p", page);
pte_unmap(ptep);
out:
Mira /proc/<pid>/smaps
sistema de archivos, puede ver la memoria del espacio de usuario:
cat smaps
bfa60000-bfa81000 rw-p 00000000 00:00 0 [stack]
Size: 136 kB
Rss: 44 kB
y como se imprime es a través de fs/proc/task_mmu.c
(de la fuente del núcleo):
http://lxr.linux.no/linux+v3.0.4/fs/proc/task_mmu.c
if (vma->vm_mm && !is_vm_hugetlb_page(vma))
walk_page_range(vma->vm_start, vma->vm_end, &smaps_walk);
show_map_vma(m, vma.....);
seq_printf(m,
"Size: %8lu kB\n"
"Rss: %8lu kB\n"
"Pss: %8lu kB\n"
Y su función es algo así como la de walk_page_range(). Mirando walk_page_range() puede ver que la estructura smaps_walk no debe cambiar mientras camina:
http://lxr.linux.no/linux+v3.0.4/mm/pagewalk.c#L153
For eg:
}
201 if (walk->pgd_entry)
202 err = walk->pgd_entry(pgd, addr, next, walk);
203 if (!err &&
204 (walk->pud_entry || walk->pmd_entry || walk->pte_entry
Si el contenido de la memoria cambiara, todas las comprobaciones anteriores podrían volverse inconsistentes.
Todo esto solo significa que debe bloquear mmap_sem al caminar por la tabla de páginas:
if (!down_read_trylock(&mm->mmap_sem)) {
/*
* Activate page so shrink_inactive_list is unlikely to unmap
* its ptes while lock is dropped, so swapoff can make progress.
*/
activate_page(page);
unlock_page(page);
down_read(&mm->mmap_sem);
lock_page(page);
}
y luego seguido por el desbloqueo:
up_read(&mm->mmap_sem);
Y, por supuesto, cuando emite printk() de la tabla de páginas dentro de su módulo kernel, el módulo kernel se ejecuta en el contexto del proceso de su proceso insmod (simplemente imprima "comm" y podrá ver "insmod"), lo que significa que mmap_sem es lock, también significa que el proceso NO se está ejecutando y, por lo tanto, no hay salida de la consola hasta que se completa el proceso (toda la salida de printk() va solo a la memoria).
¿Suena lógico?