linux-kernel - Re: [PATCH hotfix v2 2/2] mm/thp: fix deferred split unqueue naming and locking

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: <aa16f931-8244-4afe-a744-fa52c0b2fdee@redhat.com>
Date: Mon, 28 Oct 2024 18:26:37 +0100
From: David Hildenbrand <david@...hat.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Usama Arif <usamaarif642@...il.com>, Yang Shi <shy828301@...il.com>,
 Wei Yang <richard.weiyang@...il.com>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 Matthew Wilcox <willy@...radead.org>, Johannes Weiner <hannes@...xchg.org>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Barry Song <baohua@...nel.org>,
 Kefeng Wang <wangkefeng.wang@...wei.com>, Ryan Roberts
 <ryan.roberts@....com>, Nhat Pham <nphamcs@...il.com>,
 Zi Yan <ziy@...dia.com>, Chris Li <chrisl@...nel.org>,
 Shakeel Butt <shakeel.butt@...ux.dev>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [PATCH hotfix v2 2/2] mm/thp: fix deferred split unqueue naming
 and locking

>> https://lkml.kernel.org/r/20241025012304.2473312-3-shakeel.butt@linux.dev
>>
>> So I wonder ... as a quick fix should we simply handle it like the code
>> further down where we refuse PTE-mapped large folios completely?
> 
> (I went through the same anxiety attack as you did, wondering what
> happens to the large-but-not-PMD-large folios: then noticed it's safe
> as you did.  The v1 commit message had a paragraph pondering whether
> the deprecated code will need a patch to extend it for the new feature:
> but once Shakeel posted the ripout, I ripped out that paragraph -
> no longer any need for an answer.)

Ah, missed that.

> 
>>
>> "ignore such a partial THP and keep it in original memcg"
>>
>> ...
>>
>> and simply skip this folio similarly? I mean, it's a corner case either way.
> 
> I certainly considered that option: it's known to give up like that
> for many reasons.  But my thinking (in the commit message) was "Not ideal,
> but moving charge has been requested, and khugepaged should repair the THP
> later" - if someone is still using move_charge_at_immigrate, I thought
> this change would generate fewer surprises - that huge charge likely
> to be moved as it used to be.

Fair enough, I'd have kept it simpler for this almost-dead code :)

Looks good to me, thanks!

Acked-by: David Hildenbrand <david@...hat.com>

-- 
Cheers,

David / dhildenb