Peter Zijlstra wrote:
>>> Only kswapd can do this, direct reclaim has deadlock potential.
>> Yes, but not in all cases, do you want to add any gfp_mask
>> based smartness for direct reclaim?
>
> gfp_mask doesn't carry the needed information. It depends on whether
> the current context holds a rcu_read_lock().
>
What I meant was that nobody would hold rcu_read_lock() and pass
gfp_mask of GFP_KERNEL in scan_control or to do_try_to_free_pages()
> so something like:
>
> rcu_read_lock()
> foo = kmalloc(sizeof(foo))
At this point, you really can't use GFP_KERNEL, since rcu_read_lock()
disables pre-emption in the current kernel, ideally you should see
a might_sleep() BUG.
> new_slab()
> __alloc_pages()
> try_to_free_pages()
> synchronise_rcu() <-- deadlock
> rcu_read_unlock()
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
