On 8/27/05, Vincenzo Mallozzi <vinjunior@xxxxxxxx> wrote:
> I've applied your modifications but nothing happens.
>
> struct wrprotected_pages *mk_page(unsigned long addr)
> {
> struct wrprotected_pages *wr_page;
>
> wr_page = (struct wrprotected_pages *) kmalloc(sizeof(struct
> wrprotected_pages), GFP_ATOMIC);
> INIT_LIST_HEAD(&wr_page->list);
> wr_page->address = addr;
>
> return wr_page;
> }
>
> struct vm_wrprotected *mk_vm(struct vm_area_struct *vm)
> {
> struct vm_wrprotected *wr_vma;
>
> wr_vma = (struct vm_wrprotected*) kmalloc(sizeof(struct vm_wrprotected),
> GFP_ATOMIC);
> INIT_LIST_HEAD(&wr_vma->pages_list);
> INIT_LIST_HEAD(&wr_vma->list);
> wr_vma->vm_start = vm->vm_start;
> wr_vma->vm_end = vm->vm_end;
>
> return wr_vma;
> }
>
> void set_vm_not_writable(struct mm_struct *mm, struct vm_area_struct *vm)
> {
> struct vm_wrprotected *vma;
> struct wrprotected_pages *page;
> unsigned long addr;
> pte_t *pte;
>
> vma = mk_vm(vm);
> for (addr = vm->vm_start; addr<vm->vm_end; addr+=PAGE_SIZE){
> pte = get_pte_from_address(mm, addr);
> if (pte != NULL)
> if (pte_write(*pte)){
> set_pte(pte, pte_wrprotect(*pte));
> page = mk_page(addr);
> list_add_tail(&page->list, &vma->pages_list);
> }
> }
> list_add_tail(&vma->list, &vm_write_protected);
>
> return;
> }
>
> The last function is called between spinlock.
>
> spin_lock_irqsave(&protected_lock, flags_lock);
> set_vm_not_writable(mm, vm);
> spin_unlock_irqrestore(&protected_lock, flags_lock);
>
> Now, before I post all lines of code, I want to think about the right use of
> spin_locks in my project.
> I've a question on them.
> I use spin_lock_irqsave/spin_unlock_irqrestore from outside the page fault
> handler and spin_lock/spin_unlock from within it. What happens if I use
> spin_lock_irqsave/spin_unlock_irqrestore also form within the handler?
spin_lock_irqsave disable the interrupts on local CU and then acquire
the spinlock, disabling interrupts on local CPU provides
synchronizaion among this code and the interrupt handlers. As
interrupts are disabled on local CPU, interrupts will never occur on
local CPU, but they can occur on other CPUs. Synchronization among all
the CPUs is provided by spinlock, so spin_lock_irqsave is the safest
to use. spin_lock_irqrestore is just the opposite of it.
On other hand spin_lock only provides the synchronization among the
codes executign son different CPUs, it does not provide any protection
against the code running as interrupt handler on same CPU. On
uniprocessor machines, simple spin_lock (without irqsave) does not
serve any purpose.
In your case spin_lock_irqsave will not provide any benefit (it will
act as a simple spin_lock only), sorry for not pointing this earlier.
As you have to synchronize the code which runs in not process context
in kernel and the code which runs as a page fault exception handler,
disabling the interrupts wont give you any benefit. Exceptions still
occur when the interrupts are disabled, this means page fault can
still occur even if you have disabled the interrupts. In your case
spin_lock_irqsave will serve the same purpose as spin_lock, that means
just to synchronize between code running on different CPUs in system.
I would like to comment anything specific without seeing the whole
code. It might be that your handling of these list and use of spinlock
is ok, but your page fault handler is not complete, it need to handle
all the cases of page fault in user space as well as in kernel space.
You can read my article on
http://lkdp.blogspot.com/2005/08/back-door-entry-getting-hold-of-kernel.html
regarding page fault, it might give you some info.
Please do post the whole code so that somebody on the list can analyse
it fully and can point out the exact bug.
regards,
-Gaurav
> I've this doubt as the function that scans the lists I've created is the same
> used from within and form outside the handler. How can I resolve this
> conflicting situation? Have I to duplicate this function?
>
> Vincenzo.
>
>
> ___________________________________
> Yahoo! Messenger: chiamate gratuite in tutto il mondo
> http://it.beta.messenger.yahoo.com
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
