linux-kernel - Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering tlb flush when folios get unmapped

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: <196481bb-b86d-4959-b69b-21fda4daae77@intel.com>
Date: Mon, 3 Jun 2024 09:37:46 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: David Hildenbrand <david@...hat.com>, Byungchul Park <byungchul@...com>
Cc: Byungchul Park <lkml.byungchul.park@...il.com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, kernel_team@...ynix.com,
 akpm@...ux-foundation.org, ying.huang@...el.com, vernhao@...cent.com,
 mgorman@...hsingularity.net, hughd@...gle.com, willy@...radead.org,
 peterz@...radead.org, luto@...nel.org, tglx@...utronix.de, mingo@...hat.com,
 bp@...en8.de, dave.hansen@...ux.intel.com, rjgolo@...il.com
Subject: Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering
 tlb flush when folios get unmapped

On 6/3/24 09:05, David Hildenbrand wrote:
...
>>    2. A LUF'd page's position in the page cache can't be replaced until
>>       after a luf_flush()
> 
> That's the most tricky bit. I think these are the VFS concerns like
> 
> 1) Page migration/reclaim ends up freeing the old page. TLB not flushed.
> 2) write() to the new page / write from other process to the new page
> 3) CPU reads stale content from old page
> 
> PTE markers can't handle that.

Yeah, we'd need some equivalent of a PTE marker, but for the page cache.
 Presumably some xa_value() that means a reader has to go do a
luf_flush() before going any farther.

That would actually have a chance at fixing two issues:  One where a new
page cache insertion is attempted.  The other where someone goes to look
in the page cache and takes some action _because_ it is empty (I think
NFS is doing some of this for file locks).

LUF is also pretty fundamentally built on the idea that files can't
change without LUF being aware.  That model seems to work decently for
normal old filesystems on normal old local block devices.  I'm worried
about NFS, and I don't know how seriously folks take FUSE, but it
obviously can't work well for FUSE.