Andrew Morton wrote:
> Poor ttm guys - this is a bit of a trap we set for them.
Commit a91576d7916f6cce (\"drm/ttm: Pass GFP flags in order to avoid deadlock.\")
changed to use sc->gfp_mask rather than GFP_KERNEL.
- pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
- GFP_KERNEL);
+ pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
But this bug is caused by sc->gfp_mask containing some flags which are not
in GFP_KERNEL, right? Then, I think
- pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
+ pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
would hide this bug.
But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag) for
two reasons when __alloc_pages_nodemask() is called from shrinker functions.
(1) Stack usage by __alloc_pages_nodemask() is large. If we unlimitedly allow
recursive __alloc_pages_nodemask() calls, kernel stack could overflow
under extreme memory pressure.
(2) Some shrinker functions are using sleepable locks which could make kswapd
sleep for unpredictable duration. If kswapd is unexpectedly blocked inside
shrinker functions and somebody is expecting that kswapd is running for
reclaiming memory, it is a memory allocation deadlock.
Speak of ttm module, commit 22e71691fd54c637 (\"drm/ttm: Use mutex_trylock() to
avoid deadlock inside shrinker functions.\") prevents unlimited recursive
__alloc_pages_nodemask() calls.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
