linux-kernel - Re: [PATCH RESEND v3 6/9] mm/truncate: use folio

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: <9DDA4D1A-8546-4B70-BCEB-7D98E69375ED@nvidia.com>
Date: Tue, 10 Dec 2024 15:41:54 -0500
From: Zi Yan <ziy@...dia.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org,
 "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 Ryan Roberts <ryan.roberts@....com>, Hugh Dickins <hughd@...gle.com>,
 Yang Shi <yang@...amperecomputing.com>, Miaohe Lin <linmiaohe@...wei.com>,
 Kefeng Wang <wangkefeng.wang@...wei.com>, Yu Zhao <yuzhao@...gle.com>,
 John Hubbard <jhubbard@...dia.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v3 6/9] mm/truncate: use folio_split() for truncate
 operation.

On 10 Dec 2024, at 15:12, David Hildenbrand wrote:

> On 05.12.24 01:18, Zi Yan wrote:
>> Instead of splitting the large folio uniformly during truncation, use
>> buddy allocator like split at the start of truncation range to minimize
>> the number of resulting folios.
>>
>> For example, to truncate a order-4 folio
>> [0, 1, 2, 3, 4, 5, ..., 15]
>> between [3, 10] (inclusive), folio_split() splits the folio to
>> [0,1], [2], [3], [4..7], [8..15] and [3], [4..7] can be dropped and
>> [8..15] is kept with zeros in [8..10].
>
> But isn't that making things worse that they are today? Imagine fallocate() on a shmem file where we won't be freeing memory?

You mean [8..10] are kept? Yes, it is worse. And the solution would be
split at both 3 and 10. For now folio_split() returns -EINVAL for
shmem mappings, but that means I have a bug in this patch. The newly added
split_folio_at() needs to retry uniform split if buddy allocator like
split returns with -EINVAL, otherwise, shmem truncate will no longer
split folios after this patch.

Thank you for checking the patch. I will fix it in the next version.

In terms of [8..10] not being freed, I need to think about a proper interface
to pass more than one split points as a future improvement.

Best Regards,
Yan, Zi