linux-kernel - Re: [PATCH v1 0/3] s390/uv: handle folios that cannot be split while dirty

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: <8811fc8a-5f1a-4a1b-883b-f006da844e55@redhat.com>
Date: Fri, 16 May 2025 20:55:27 +0200
From: David Hildenbrand <david@...hat.com>
To: Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
 kvm@...r.kernel.org, linux-mm@...ck.org,
 Christian Borntraeger <borntraeger@...ux.ibm.com>,
 Janosch Frank <frankja@...ux.ibm.com>, Heiko Carstens <hca@...ux.ibm.com>,
 Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev
 <agordeev@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>,
 Thomas Huth <thuth@...hat.com>, Matthew Wilcox <willy@...radead.org>,
 Zi Yan <ziy@...dia.com>, Sebastian Mitterle <smitterl@...hat.com>
Subject: Re: [PATCH v1 0/3] s390/uv: handle folios that cannot be split while
 dirty

On 16.05.25 19:07, Claudio Imbrenda wrote:
> On Fri, 16 May 2025 14:39:43 +0200
> David Hildenbrand <david@...hat.com> wrote:
> 
>>  From patch #3:
>>
>> "
>> Currently, starting a PV VM on an iomap-based filesystem with large
>> folio support, such as XFS, will not work. We'll be stuck in
>> unpack_one()->gmap_make_secure(), because we can't seem to make progress
>> splitting the large folio.
>>
>> The problem is that we require a writable PTE but a writable PTE under such
>> filesystems will imply a dirty folio.
>>
>> So whenever we have a writable PTE, we'll have a dirty folio, and dirty
>> iomap folios cannot currently get split, because
>> split_folio()->split_huge_page_to_list_to_order()->filemap_release_folio()
>> will fail in iomap_release_folio().
>>
>> So we will not make any progress splitting such large folios.
>> "
>>
>> Let's fix one related problem during unpack first, to then handle such
>> folios by triggering writeback before immediately trying to split them
>> again.
>>
>> This makes it work on XFS with large folios again.
>>
>> Long-term, we should cleanly supporting splitting such folios even
>> without writeback, but that's a bit harder to implement and not a quick
>> fix.
> 
> yet another layer of duck tape
> 
> I really dislike the current interaction between secure execution and
> I/O, I hope I can get a cleaner solution as soon as possible

I'll be more than happy to review such a series -- hoping we can just 
support large folios naturally :)

> 
> Reviewed-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
> 
> 

Thanks!

> David: thanks for fixing this mess!


NP; I had a prototype of patch #3 for a long time. But after rebasing on 
top of your work I saw these weird validation errors and just couldn't 
find the issue. And I only saw them with patch #3 on ordinary pagecache 
folios, not with shmem, which severely confused.

... gave it another try today after ~1month and almost immediately 
spotted the issue.

Some things just need time :)

-- 
Cheers,

David / dhildenb