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] [day] [month] [year] [list]

Message-ID: <A0EB7412-743A-4B6E-9FBC-FB21AEF40CE6@nvidia.com>
Date: Tue, 10 Dec 2024 15:50: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:41, Zi Yan wrote:

> 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.

I am going to add two functions: split_huge_page_supported(folio, new_order)
and folio_split_support(folio, new_order) to perform the order and folio->mapping
checks at the beginning of __folio_split(). So truncate and other potential
callers can make the right function call.

Best Regards,
Yan, Zi