linux-kernel - Re: Excessive page cache occupies DMA32 memory

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: <2025072238-unplanted-movable-7dfb@gregkh>
Date: Tue, 22 Jul 2025 07:32:08 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Matthew Wilcox <willy@...radead.org>,
	Muhammad Usama Anjum <usama.anjum@...labora.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, kernel@...labora.com,
	linux-mm@...ck.org, linux-fsdevel@...r.kernel.org
Subject: Re: Excessive page cache occupies DMA32 memory

On Mon, Jul 21, 2025 at 06:13:10PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 21, 2025 at 08:03:12PM +0500, Muhammad Usama Anjum wrote:
> > Hello,
> > 
> > When 10-12GB our of total 16GB RAM is being used as page cache
> > (active_file + inactive_file) at suspend time, the drivers fail to allocate
> > dma memory at resume as dma memory is either occupied by the page cache or
> > fragmented. Example:
> > 
> > kworker/u33:5: page allocation failure: order:7, mode:0xc04(GFP_NOIO|GFP_DMA32), nodemask=(null),cpuset=/,mems_allowed=0
> 
> Just to be clear, this is not a page cache problem.  The driver is asking
> us to do a 512kB allocation without doing I/O!  This is a ridiculous
> request that should be expected to fail.
> 
> The solution, whatever it may be, is not related to the page cache.
> I reject your diagnosis.  Almost all of the page cache is clean and
> could be dropped (as far as I can tell from the output below).
> 
> Now, I'm not too familiar with how the page allocator chooses to fail
> this request.  Maybe it should be trying harder to drop bits of the page
> cache.  Maybe it should be doing some compaction.  I am not inclined to
> go digging on your behalf, because frankly I'm offended by the suggestion
> that the page cache is at fault.
> 
> Perhaps somebody else will help you, or you can dig into this yourself.

I'm with Matthew, this really looks like a driver bug somehow.  If there
is page cache memory that is "clean", the driver should be able to
access it just fine if really required.

What exact driver(s) is having this problem?  What is the exact error,
and on what lines of code?

thanks,

greg k-h