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: <YvS+8wLU093QWQCL@dhcp22.suse.cz>
Date:   Thu, 11 Aug 2022 10:33:55 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Christoph Hellwig <hch@....de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Baoquan He <bhe@...hat.com>,
        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 Thu 11-08-22 10:21:32, Christoph Hellwig wrote:
> On Thu, Aug 11, 2022 at 10:20:43AM +0200, Michal Hocko wrote:
> > Meminfo part says
> > Node 0 DMA free:160kB 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:15996kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > 
> > So the zone has 15MB of managed memory (by the page allocator), yet only
> > 160kB is free early boot during the allocation. So it is mostly consumed
> > by somebody. I haven't really checked by whom.
> > 
> > Does that exaplain the above better?
> 
> Yes.  I'm really curious who eats up all the GFP_DMA memory early during
> boot, though.

Sorry, no idea and I do not have direct access to the machine. I can try
to dig out more but, honestly, I am not sure I will find time for that.
My main motivation was to reduce a shouting warning for something that
doesn't indicate any real problem as this has been second (maybe third)
time somebody has been complaining/asking about it.

I do get your point that the sizing is probably wrong and I agree this
is something that can be tuned better but I would rather vote for a
useful warning when the explicit request fails rather than being to
eager and warn when it is not really clear this is a problem in the
first place. In both cases admin cannot really do much other than
report. For the early boot we can only tell, this is not an immediate
problem, just ignore. For the later we know the device and see whether
we can do something about that.

Just my 2c

-- 
Michal Hocko
SUSE Labs