linux-kernel - Re: [PATCH] dma/pool: do not complain if DMA pool is not allocated

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yj28gjonUa9+0yae@dhcp22.suse.cz>
Date:   Fri, 25 Mar 2022 13:58:42 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>, Baoquan He <bhe@...hat.com>
Cc:     John Donnelly <john.p.donnelly@...cle.com>,
        David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dma/pool: do not complain if DMA pool is not allocated

On Fri 25-03-22 13:25:59, Michal Hocko wrote:
> From: Michal Hocko <mhocko@...e.com>
> 
> we have a system complainging about order-5 allocation for the DMA pool.
> This is something that a674e48c5443 ("dma/pool: create dma atomic pool
> only if dma zone has managed pages") has already tried to achieve but I
> do not think it went all the way to have it covered completely. In this
> particular case has_managed_dma() will not work because:
> [    0.678539][    T0] Initmem setup node 0 [mem 0x0000000000001000-0x000000027dffffff]
> [    0.686316][    T0] On node 0, zone DMA: 1 pages in unavailable ranges
> [    0.687093][    T0] On node 0, zone DMA32: 36704 pages in unavailable ranges
> [    0.694278][    T0] On node 0, zone Normal: 53252 pages in unavailable ranges
> [    0.701257][    T0] On node 0, zone Normal: 8192 pages in unavailable ranges

Dang, I have just realized that I have misread the boot log and it has
turned out that a674e48c5443 is covering my situation because the
allocation failure message says:
Node 0 DMA free:0kB boost:0kB min:0kB low:0kB high:0kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:636kB managed:0kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB

I thought there are only few pages in the managed by the DMA zone. This
is still theoretically possible so I think __GFP_NOWARN makes sense here
but it would require to change the patch description.

Is this really worth it?

> 
> The allocation failure on the DMA zone shouldn't be really critical for
> the system operation so just silence the warning instead.
> 
> Signed-off-by: Michal Hocko <mhocko@...e.com>
> ---
>  kernel/dma/pool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 4d40dcce7604..1bf6de398986 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -205,7 +205,7 @@ static int __init dma_atomic_pool_init(void)
>  		ret = -ENOMEM;
>  	if (has_managed_dma()) {
>  		atomic_pool_dma = __dma_atomic_pool_init(atomic_pool_size,
> -						GFP_KERNEL | GFP_DMA);
> +						GFP_KERNEL | GFP_DMA | __GFP_NOWARN);
>  		if (!atomic_pool_dma)
>  			ret = -ENOMEM;
>  	}
> -- 
> 2.30.2

-- 
Michal Hocko
SUSE Labs