linux-kernel - 回复: [PATCH] mm/compaction: add check mechanism to avoid cma alloc fail

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]

Date: Wed, 24 Jan 2024 07:20:53 +0000
From: Haiqiang Gong (龚海强)
	<Haiqiang.Gong@...iatek.com>
To: Matthew Wilcox <willy@...radead.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mike Zhang (张伟伟) <Mike.Zhang@...iatek.com>,
	Andrew Morton <akpm@...ux-foundation.org>, Matthias Brugger
	<matthias.bgg@...il.com>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>, "linux-mm@...ck.org"
	<linux-mm@...ck.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>
Subject: 回复: [PATCH] mm/compaction: add check mechanism to avoid cma alloc fail

> I don't understand.  You say that the memory isn't movable, but then you 
> say that it's migrated in.  So it was movable, but it's no longer
> movable after being moved once?  
Sorry for not expressing clearly
When doing memory migration, the kernel will determine whether the current 
page can be moved based on the refcount and mapcount of the current page.
This memory can be moved during kernel compaction. At this time, refcount 
is less than or equal to mapcount.
After this memory is kcompacted and placed in the cma buffer, under 
certain special conditions, the refcount may be greater than the mapcount
（ex:the current page is being used by fs）, and then migrate will fail.

> Why would folio_mapping() be the right way to determine if memory is
> unmovable?  The vast majority of filesystem data is movable.
We found that the final problem was in the __buffer_migrate_page() 
function. This function seems to be a callback registered by fs that will 
be called during migration. The reason for migrate fail is that the 
refcount of the current page is greater than mapcount.


发件人: Matthew Wilcox <willy@...radead.org> 
发送时间: 2024年1月22日 11:31
收件人: Haiqiang Gong (龚海强) <Haiqiang.Gong@...iatek.com>
抄送: linux-kernel@...r.kernel.org; Mike Zhang (张伟伟) <Mike.Zhang@...iatek.com>; Andrew Morton <akpm@...ux-foundation.org>; Matthias Brugger <matthias.bgg@...il.com>; AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>; linux-mm@...ck.org; linux-arm-kernel@...ts.infradead.org; linux-mediatek@...ts.infradead.org
主题: Re: [PATCH] mm/compaction: add check mechanism to avoid cma alloc fail


External email : Please do not click links or open attachments until you have verified the sender or the content.

On Mon, Jan 22, 2024 at 10:23:17AM +0800, Haiqiang Gong wrote:
> cma alloc may fail when we doing cma alloc/free test on kernel 5.10/5.15.
> 
> We found that the next memory cannot be migrated because of the alloc of
> fs as next backtrace:
> __alloc_pages_nodemask
> pagecache_get_page
> grow_dev_page
> __getblk_gfp
> ext4_sb_breadahead_unmovable
> __ext4_get_inode_loc
> __ext4_iget
> ext4_lookup
> __lookup_slow
> walk_component
> path_lookupat
> filename_lookup
> vfs_statx
> This kind of unmovable memory is not placed in the cma buffer when kernel
> memory alloc but is migrated in by kcompactd when the kernel migration.
> It will cause memory can't be migrate when cma alloc.

I don't understand.  You say that the memory isn't movable, but then you
say that it's migrated in.  So it was movable, but it's no longer
movable after being moved once?  

> Add check mechanism in the compaction_alloc() where kcompaced alloc for
> memory. Will return NULL and give up this memory migration if the
> allocated memory is in the cma buffer and the memory is unmovable.

> +static bool forbid_move_to_cma_range(struct folio *src, struct folio *dst)
> +{
> +if (folio_mapping(src) && is_in_cma_range(dst))
> +return true;
> +
> +return false;
> +}

Why would folio_mapping() be the right way to determine if memory is
unmovable?  The vast majority of filesystem data is movable.