linux-kernel - RE: [PATCH v1] mm/memory: fix folio_set_dirty() vs. folio_mark_dirty() in zap_pte

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: 
 <PUZPR04MB6316745B9234C3B5781AEA1381742@PUZPR04MB6316.apcprd04.prod.outlook.com>
Date: Tue, 23 Jan 2024 08:49:16 +0000
From: "Yuezhang.Mo@...y.com" <Yuezhang.Mo@...y.com>
To: David Hildenbrand <david@...hat.com>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Ryan Roberts
	<ryan.roberts@....com>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton
	<akpm@...ux-foundation.org>
Subject: RE: [PATCH v1] mm/memory: fix folio_set_dirty() vs.
 folio_mark_dirty() in zap_pte_range()

Reviewed-by: Yuezhang Mo <Yuezhang.Mo@...y.com>

Without this fix, testing the latest exfat with xfstests, test cases generic/029
and generic/030 will fail.

> -----Original Message-----
> From: owner-linux-mm@...ck.org <owner-linux-mm@...ck.org> On Behalf
> Of David Hildenbrand
> Sent: Tuesday, January 23, 2024 1:18 AM
> To: linux-kernel@...r.kernel.org
> Cc: linux-mm@...ck.org; David Hildenbrand <david@...hat.com>; Ryan
> Roberts <ryan.roberts@....com>; Matthew Wilcox <willy@...radead.org>;
> Andrew Morton <akpm@...ux-foundation.org>
> Subject: [PATCH v1] mm/memory: fix folio_set_dirty() vs. folio_mark_dirty() in
> zap_pte_range()
> 
> The correct folio replacement for "set_page_dirty()" is
> "folio_mark_dirty()", not "folio_set_dirty()". Using the latter won't
> properly inform the FS using the dirty_folio() callback.
> 
> This has been found by code inspection, but likely this can result in
> some real trouble when zapping dirty PTEs that point at clean pagecache
> folios.
> 
> Reported-by: Ryan Roberts <ryan.roberts@....com>
> Closes:
> https://lkml.kernel.org/r/2445cedb-61fb-422c-8bfb-caf0a2beed62@arm.com
> Fixes: c46265030b0f ("mm/memory: page_remove_rmap() ->
> folio_remove_rmap_pte()")
> Cc: Matthew Wilcox (Oracle) <willy@...radead.org>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Signed-off-by: David Hildenbrand <david@...hat.com>
> Reviewed-by: Ryan Roberts <ryan.roberts@....com>
> ---
>  mm/memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 7e1f4849463aa..89bcae0b224d6 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1464,7 +1464,7 @@ static unsigned long zap_pte_range(struct
> mmu_gather *tlb,
>  			delay_rmap = 0;
>  			if (!folio_test_anon(folio)) {
>  				if (pte_dirty(ptent)) {
> -					folio_set_dirty(folio);
> +					folio_mark_dirty(folio);
>  					if (tlb_delay_rmap(tlb)) {
>  						delay_rmap = 1;
>  						force_flush = 1;