Looking at schedule_work() below:
fs/file.c:
fddef = &get_cpu_var(fdtable_defer_list);
spin_lock(&fddef->lock);
fdt->next = fddef->next;
fddef->next = fdt;
/* vmallocs are handled from the workqueue context */
schedule_work(&fddef->wq);===>
spin_unlock(&fddef->lock);
can schedule_work() sleep? if so, then holding a spin_lock (which is
supposed to be used for quick turnaround operation) across a sleepable
functions look risky here (though it is possible to design this way,
but the classic CPU 100% bug is possible - sleep and never wake up,
resulting in another CPU going into spin_lock mode - churning up 100%
CPU time). Or may be I am wrong?
Can calling this function schedule_work() ever ended the entire task
being reassigned to another CPU? If so, then, will it not defeats
the purpose of using the per_cpu function get_cpu_var()?
How about schedule() -->ever ended the entire task being reassigned to
another CPU? ?
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
