@@ -21,7 +21,7 @@ static struct gen_pool *atomic_pool_kernel __ro_after_init;
static unsigned long pool_size_kernel;
/* Size can be defined by the coherent_pool command line */
-static size_t atomic_pool_size;
+static unsigned long atomic_pool_size = -1;
/* Dynamic background expansion when the atomic pool is near capacity */
static struct work_struct atomic_pool_work;
@@ -188,11 +188,14 @@ static int __init dma_atomic_pool_init(void)
{
int ret = 0;
+ if (!atomic_pool_size)
+ return 0;
+
/*
* If coherent_pool was not used on the command line, default the pool
* sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1.
*/
- if (!atomic_pool_size) {
+ if (atomic_pool_size == -1) {
unsigned long pages = totalram_pages() / (SZ_1G / SZ_128K);
pages = min_t(unsigned long, pages, MAX_ORDER_NR_PAGES);
atomic_pool_size = max_t(size_t, pages << PAGE_SHIFT, SZ_128K);
In the current code, three atomic memory pools are provided, atomic_pool_kernel, atomic_pool_dma, atomic_pool_dma32, initialized with flag GFP_KERNEL, GFP_KERNEL|GFP_DMA, GFP_KERNEL|GFP_DMA32. And they are always enabled, even though 'coherent_pool=0' is specified in kernel command line. In some cases, atomic pool may not be needed. And worse, it even will cause problem. E.g in kdump kernel of x86_64, it will cause OOM for atomic_pool_dma initialization. Because there isn't available memory for buddy allocatory in DMA zone of kdump kernel since commit f1d4d47c5851 ("x86/setup: Always reserve the first 1M of RAM"). The OOM will cause panic if panic_on_oom is added into kdump kernel. So change code to adjust the existing coherent_pool to allow user to disable atomic pool by specifying 'coherent_pool=0'. Signed-off-by: Baoquan He <bhe@redhat.com> --- kernel/dma/pool.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)