Unexplained trap (from a module that modifies permissions of remapped page tables to user space)

["Naval Saini" <navalnovel@xxxxxxxxx>]

Hi:

I am facing a particular issue with non-SMP arm-linux kernel. Below i
describe the scenario and would like a discussion on it, to understand
this particular behaviour of linux.

Our module, maps a certain portion of RAM to user space with
remap_pfn_range (we have a kept a hole in memory for that). Lets call
it IOCTL call no. 1 that does a mmap.

Another IOCTL call no. 2, changes the permissions of page tables so
that they can be accessed from user space. Here we parse the mm_struct
of the current user process (being in process context) to do so.

The code was working fine until we made some changes to kernel's
memory map. After that we started getting a trap (or somethings) at
the point where we were read (before we modify) the permissions in
PTE. We got a dump and app crashed. So there must have been a sleeping
bug in there.

Since we were accessing the PTE entry inside of a spinlock
(mm->spinlock actually... spinlock disables irq as well as its a
non-SMS system), i tried by commenting the spinlock part and trying
out my app. This worked and i guess for the following reason.

The page tables i was trying to modify kept in kernel context. And i
was in an ioctl call in process context. So we required a trap to
bring the page tables from kernel context to process context.

Is this hypothesis correct ?

Also can the pmd / pgd of a process (stored in the mm_struct of the
same) change by some mechanism of the kernel ? ie. (such as the page
tables get swapped out)
Do we need to own a spinlock to be sure that these don't change?



That's all my questions, please ask for any clarification on them (if
feel the need). I would be most thankful.


Further (just to add to above), i tried to track above fault with
setting breakpoints at __die , __do_user_fault , __do_kernel_fault ,
and panic. But it didn't hit any of them, so it seems a lil' difficult
to know what is happening.


Regards,
Naval

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php