On Tue, Jul 22, 2008 at 2:59 AM, Arn <cse.syslab@xxxxxxxxx> wrote:
> Hi,
>
> I was looking through UTLD3 and have some queries related the linux
> memory management code (kernel 2.6.26)
>
> I need to get a pointer to the task (process) that faulted and needs
> to have a page swapped in, so inside the handle_pte_fault()
> function I declared "struct task_struct *ptr" and just before
> do_swap_page() is called I assign "ptr = current" and do a printk of
> ptr->pid.
>
> I repeated the above inside the do_swap_page() function, just before
> grab_swap_token() is called.
>
> The question is : is the output of the printk statments as shown above
> giving me the correct pid, that is the pid of the task that caused the
> major page fault ?
>
Look here: Documentation/preempt-locking.txt:
"Note that you do not need to explicitly prevent preemption if you are holding
any locks or interrupts are disabled, since preemption is implicitly disabled
in those cases."
So long as spin lock (and CPU > 1 is concerned) is used, within the
spin lock u are guaranteed not to be preempted ......in the current
CPU.......but then the same procedure may be executed by another
CPU.....and that will blocked (by definition of spin lock right?).
So if u printk within spin lock twice.....the two printk values are
from the same CPU without preemption.....but not if one printk is
inside and another is outside the spinlock.
another variation is local_irq_disable()....whenever it is called,
interrupt preemption is disabled.
> Putting this another way, I need to know if the functions mentioned
> above can go to sleep or be blocked i.e. can be preempted ?
not easy.....absence of spinlock does not mean it is preemptible
either....as spinlock can come before the function is called. if
CONFIG_PREEMPT=y (default is no) then this is possible: the function
preempt_enable() can be nested, so preempt_enable() does not
immediately mean that preemption is enabled, as the preempt count has
to reach zero first.
> Also, how can I know by looking at the kernel code if a function is
> preemptible or not ?
>
Generally, when u see the function: cond_resched(), or many other
similar function (eg, schedule()), or any form of mutex usage (which
will call schedule()) then it mean that CPU can be reschedule to
execute other tasks - which means that the current tasks can be
blocked.
So in particular for you:
This happened in memory.c:
cond_resched();
while (!(page = follow_page(vma, start, foll_flags))) {
int ret;
ret = handle_mm_fault(mm, vma, start,
foll_flags & FOLL_WRITE);
if (ret & VM_FAULT_ERROR) {
if (ret & VM_FAULT_OOM)
return i ? i : -ENOMEM;
else if (ret
where handle_mm_fault() will call handle_pte_fault(), so outside of
handle_mm_fault(), it is potentially possible to be blocked.
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
