From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6414C2BD09 for ; Wed, 3 Jul 2024 16:21:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 493776B0098; Wed, 3 Jul 2024 12:21:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 441F36B0099; Wed, 3 Jul 2024 12:21:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E3886B009A; Wed, 3 Jul 2024 12:21:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 100EB6B0098 for ; Wed, 3 Jul 2024 12:21:32 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8D282C0393 for ; Wed, 3 Jul 2024 16:21:31 +0000 (UTC) X-FDA: 82298956782.13.58D51C8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 4E75740007 for ; Wed, 3 Jul 2024 16:21:29 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OZeRxnN8; spf=pass (imf04.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720023677; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2TqXwLn9OXaIYIeKMDadbnKhFrbWHwcgxCj/8R0iL64=; b=gINZZVbDTEUikEItAeU8YcmC+d3EOCT87NhSydTLK3xvhMEXAinE30MtXttB8uaD4vZ7xr Vys5pMMtTbNzCTq3cJLoaOe3rNdg4HzpMxoVaGD4TsW4paxML2Grkw6Jzimfk1XnNhgiSN T5ijNjhobYMM6IZ0oQyFePDR8kwMcus= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OZeRxnN8; spf=pass (imf04.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720023677; a=rsa-sha256; cv=none; b=KZrjVOb5A5HBDpUdBUpYGR3bVyf//UHlaU4jZCXXXWuwIMfXG09YocHX1jISlchx26oEeF Uj99ia7mWR9+iRmV+wjxd/xJO+V0gYyc7CbvJsgKUFHMKZqhfusrPN1sGuAuCv8v9lMF6w uo3XX04gkLX0bJi1R7ooERdYlRe4fyE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720023688; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=2TqXwLn9OXaIYIeKMDadbnKhFrbWHwcgxCj/8R0iL64=; b=OZeRxnN84xRPwlfE468aboCeUluqYRmJPb5MCM+Gtovaa2E5ALCWdhlzM32/Eb6o0y+9c5 2lBYNkFis1yB3F7oC/Xfkjz+yx1vF/nD+a6PuEEXSf+V+mPLjch55ApX8KtsPtaSs52K9q JXogISYgsFlZtGuBV8aHSibWhapjjYQ= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-487-Oc5V8QvSPtOGKYMGEvlPCA-1; Wed, 03 Jul 2024 12:21:27 -0400 X-MC-Unique: Oc5V8QvSPtOGKYMGEvlPCA-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-367988464ceso196276f8f.2 for ; Wed, 03 Jul 2024 09:21:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720023686; x=1720628486; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=2TqXwLn9OXaIYIeKMDadbnKhFrbWHwcgxCj/8R0iL64=; b=Bz34Xm/cnot9tOMjimdR0zIl4t2lg71SUrapz+dFEAwLCAymxsr4elJRTSinTBo0Ih TxG0XuTmbXCYyQynuLHaCAbnhbKM5zP4qvpgPs9nMDHeykmSgdZkmQkrnUI0UJIMU9qy v6tB5TrurtGhJI3rZomt4QcTbNvCipBx2Uu81MJpcos0JPlc/qAwD7rCxvtwvUCiQB2f 63aDAB4PZitzR4BHqDpAs9AQNh5qXQmpoFh1yzkxU+Sq+UFSoPcgtt/29mVmhA/CQhlx 6BeTrXzGQPh3X3OZDREe6/OJOrL/+31necEW536RyUqqxU057GkVfUDF6N4J8sZJSR0D czVA== X-Forwarded-Encrypted: i=1; AJvYcCWbtnEdVn9avok4dTp6f7dydiLm9tBaA1wpCzkkyWxR4FS/nntmxWqqSs6nhQCYNcH/e90di2HvZ8iFu3gxGx4hC7g= X-Gm-Message-State: AOJu0YxzrU7bRg74VCTy/10rRL4jC3UfrCH9youfVbd7+YQBN/LdGlXH D2FIIe8I1atUP3MW7rxocAz1y9g6OW/wv8JOxbK5Y5OT2J4fhLxS90TCV86o2Z5YhRkZewbOlNt 3ASvW1VnLZb9ejTctPoLujABvot8Br4xdl7ivs0qN6UFp7pYo X-Received: by 2002:a5d:598a:0:b0:367:434f:cab8 with SMTP id ffacd0b85a97d-36775724938mr12134989f8f.43.1720023685977; Wed, 03 Jul 2024 09:21:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG2z3Fw+9jy3Pmlw93VTfgKjZ54NgKbcbujJ1QQzQjar0O4FIbIqDsVY2lvaA0V/bfUwdh/Ew== X-Received: by 2002:a5d:598a:0:b0:367:434f:cab8 with SMTP id ffacd0b85a97d-36775724938mr12134966f8f.43.1720023685469; Wed, 03 Jul 2024 09:21:25 -0700 (PDT) Received: from ?IPV6:2003:cb:c709:3400:5126:3051:d630:92ee? (p200300cbc709340051263051d63092ee.dip0.t-ipconnect.de. [2003:cb:c709:3400:5126:3051:d630:92ee]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3675a0fc412sm16339957f8f.70.2024.07.03.09.21.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jul 2024 09:21:25 -0700 (PDT) Message-ID: Date: Wed, 3 Jul 2024 18:21:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hotfix] mm: fix crashes from deferred split racing folio migration To: Zi Yan , Hugh Dickins Cc: Andrew Morton , Baolin Wang , Nhat Pham , Yang Shi , Barry Song , Kefeng Wang , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <29c83d1a-11ca-b6c9-f92e-6ccb322af510@google.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 4E75740007 X-Stat-Signature: tot7j6scmo8o53796zuez3o9f59wefe4 X-HE-Tag: 1720023689-699541 X-HE-Meta: U2FsdGVkX1/4DLVghiTO48TlJ07thhqe6SfTZqCDnddDrMrMjmnN7OHAV7ixb4qTIG/F9wJwlcSMEZkPkPRHfswVTp4szPM2VqzgtNIO1U1Q0LOaLoi8x0nH7gwAYp5nK5p+N5kuGiW5JqxoEUkRzMNKS5MxryCzOoNfGlY7XTslidDC/x0msws9H7EmRZ8TdLsll+WVlwffG8jxam8LBdbFg/zlXdcLc6yTL7t514QDIGa1FTo7M+iVx9heRZCPLvA0fPyDhd/BkZRAXQD9+wvSISGApNs8WJpoMuvHOYO9gnNDMeUxfVWr7wZrot4Pb5XubVbQpSrENVhRl39rV1Km2greO6q/NpqfcIKNtQmDcv1uMMEDM5bQATbSqkUW90Q8y/Lf1ydIWpuYbg8YdwEYOC8Ii67qNjFFleSpQbrgBHvJLUOzu2SE8WKKWL1fS/v9REy1k0sPCc+hybjN4er+RaJPWpscGUsMnJ7axRA+uyzIKELLDDE2oi0Qc2HvCK7NHi65GRByY+12UXZb+k+riapb4jH+YhEE9nSmiWuy56EabaUgcQYHkWwjeJA1f2zctF/ndIjtE01Jvg5T7fKgLwKmpEUTHCf8qcAEDBCFmHnTzHqZ1B9hCZ1qdnqHzvsGphJhSxvppE5MTH5XXhhAvZlWRIb9FqHCJzhoCb/bCK6qvHAdi6YT1tdxqeIktuSDr5QqRmXmvSm59Np3cU6ocbhwFDWxPYTgRYaBeebBgDgRV4J4LFoA0+wZHADFEt1d/Fz9TmufBNQZieJ8+j3wDtKlQn4QXd5pafM/Onrfv6/qrTzUgZeHWsqisKzzJahI5t4j2n2R94yuMnynwiRdMpJFi9GfGqkL5bi9g8HdRyP1i5Z5aSjZ+jELHKOc5g9ZnUFr6cGyFyA0SplUpBEZpog9QEv9zOgO2Umxv7k+tXrJatSNpncpKvmZZjuHHFZHi0RT+BKpOpSAncr XiVvRdap T9RrhlrAp+npCdG5CAtYznD/9wktsoiGmNDEMACaARBO54ebarOd5Yzm/meYmsXeNWbJvwccyxDo8DNOS5fiYeaK5UfX+VeQ0w6YhBume5GG6sFxCBlXxHLSJQR6tomRmqTSMcQj68+IMVTX+1EOBYmUYbwm3Bmh79yMay+lK3+e2PJyjianOYDMpx9krLFlAEQa1zoR6DrUzwHGLRYXnL9RO8IsIw5Rp4hSxwwMQCbGfw93oFXaiGCZ6UYimuf/jf1CcDoi6c0nrxNkDbufos98nizfFz2lCvF4eBxRjUJ+vVVMpbXhPuZqpN0VEZnHX4hxHobZsMfgxjLjRtbGWr87mLMym+8mQxFlUZR3GAl5IROjPmsS+g1YHn9yFQDumn7X5RhC/FECKsAsSRmeRu5vecomaq1zKPGsKylgywT1Za9AiKEUC+rv/FeoHgmM2x2ss7A7FXqoipQ17r6FgNN6SKZUQPDYCosQz744KaQpw4/0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 03.07.24 16:30, Zi Yan wrote: > On 2 Jul 2024, at 3:40, Hugh Dickins wrote: > >> Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on >> flags when freeing, yet the flags shown are not bad: PG_locked had been >> set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from >> deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN >> symptoms implying double free by deferred split and large folio migration. >> >> 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large >> folio migration") was right to fix the memcg-dependent locking broken in >> 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), >> but missed a subtlety of deferred_split_scan(): it moves folios to its own >> local list to work on them without split_queue_lock, during which time >> folio->_deferred_list is not empty, but even the "right" lock does nothing >> to secure the folio and the list it is on. >> >> Fortunately, deferred_split_scan() is careful to use folio_try_get(): so >> folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable() >> while the old folio's reference count is temporarily frozen to 0 - adding >> such a freeze in the !mapping case too (originally, folio lock and >> unmapping and no swap cache left an anon folio unreachable, so no freezing >> was needed there: but the deferred split queue offers a way to reach it). >> >> Fixes: 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") >> Signed-off-by: Hugh Dickins >> Cc: stable@vger.kernel.org >> --- >> This patch against 6.10-rc6: Kefeng has commits in the mm-tree which >> which will need adjustment to go over this, but we can both check the >> result. I have wondered whether just reverting 85ce2c517ade and its >> subsequent fixups would be better: but that would be a bigger job, >> and probably not the right choice. >> >> mm/memcontrol.c | 11 ----------- >> mm/migrate.c | 13 +++++++++++++ >> 2 files changed, 13 insertions(+), 11 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 71fe2a95b8bd..8f2f1bb18c9c 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -7823,17 +7823,6 @@ void mem_cgroup_migrate(struct folio *old, struct folio *new) >> >> /* Transfer the charge and the css ref */ >> commit_charge(new, memcg); >> - /* >> - * If the old folio is a large folio and is in the split queue, it needs >> - * to be removed from the split queue now, in case getting an incorrect >> - * split queue in destroy_large_folio() after the memcg of the old folio >> - * is cleared. >> - * >> - * In addition, the old folio is about to be freed after migration, so >> - * removing from the split queue a bit earlier seems reasonable. >> - */ >> - if (folio_test_large(old) && folio_test_large_rmappable(old)) >> - folio_undo_large_rmappable(old); >> old->memcg_data = 0; >> } >> >> diff --git a/mm/migrate.c b/mm/migrate.c >> index 20cb9f5f7446..a8c6f466e33a 100644 >> --- a/mm/migrate.c >> +++ b/mm/migrate.c >> @@ -415,6 +415,15 @@ int folio_migrate_mapping(struct address_space *mapping, >> if (folio_ref_count(folio) != expected_count) >> return -EAGAIN; >> >> + /* Take off deferred split queue while frozen and memcg set */ >> + if (folio_test_large(folio) && >> + folio_test_large_rmappable(folio)) { >> + if (!folio_ref_freeze(folio, expected_count)) >> + return -EAGAIN; >> + folio_undo_large_rmappable(folio); >> + folio_ref_unfreeze(folio, expected_count); >> + } >> + > > I wonder if the patch below would make the code look better by using > the same freeze/unfreeze pattern like file-backed path. After > reading the emails between you and Baolin and checking the code, > I think the patch looks good to me. Feel free to add > Reviewed-by: Zi Yan > > BTW, this subtlety is very error prone, as Matthew, Ryan, and I all > encountered errors because of this[1][2]. Matthew has a good summary > of the subtlety: > > "the (undocumented) logic in deferred_split_scan() that a folio > with a positive refcount will not be removed from the list." > > [1] https://lore.kernel.org/linux-mm/Ze9EFdFLXQEUVtKl@casper.infradead.org/ > [2] https://lore.kernel.org/linux-mm/Ze_P6xagdTbcu1Kz@casper.infradead.org/ > > diff --git a/mm/migrate.c b/mm/migrate.c > index a8c6f466e33a..afcc0653dcb7 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -412,17 +412,15 @@ int folio_migrate_mapping(struct address_space *mapping, > > if (!mapping) { > /* Anonymous page without mapping */ > - if (folio_ref_count(folio) != expected_count) > + if (!folio_ref_freeze(folio, expected_count)) > return -EAGAIN; > > /* Take off deferred split queue while frozen and memcg set */ > if (folio_test_large(folio) && > - folio_test_large_rmappable(folio)) { > - if (!folio_ref_freeze(folio, expected_count)) > - return -EAGAIN; > + folio_test_large_rmappable(folio)) > folio_undo_large_rmappable(folio); > - folio_ref_unfreeze(folio, expected_count); > - } > + > + folio_ref_unfreeze(folio, expected_count); > The downside is freezing order-0, where we don't need to freeze, right? -- Cheers, David / dhildenb