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 7872EC61CE8 for ; Thu, 12 Jun 2025 15:51:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 164B96B007B; Thu, 12 Jun 2025 11:51:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 116606B008C; Thu, 12 Jun 2025 11:51:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0053D6B0096; Thu, 12 Jun 2025 11:50:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D5DFE6B007B for ; Thu, 12 Jun 2025 11:50:59 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 838F31D8DB2 for ; Thu, 12 Jun 2025 15:50:59 +0000 (UTC) X-FDA: 83547187038.25.243A06F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf03.hostedemail.com (Postfix) with ESMTP id B539F2000F for ; Thu, 12 Jun 2025 15:50:56 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CVHml6J4; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf03.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749743457; 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=XkOVcsQFLACiyPL8TaOWVC3fryHfhKobAgix/Ghr4pc=; b=1oNx/fz08sSGp/3mNH0ERf3HHpwESny/mH4hWx1r/sPpGW1qNTltYq8ChhYA8UroikaFv2 f+T9JZfStv5HviYhgr50ltLBumGc/gRsQti1+sq7e6sDWnheJg/zjY8tjdP85OaRMPwF0h Ob7ZhSIiw4FB7BPN+/0kKnvSBWkzVQ0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749743457; a=rsa-sha256; cv=none; b=xlLGJwmBRsDExHeCZP65YoElRGAYc2TNUoRsoOsttna8z4ElxjvPLTWZAU3ydwdcgIj5bx MCCoFrSO5v/WLiv1VClr7t6m+BXe4bwi323pkMEU80VUKz/klGDrt3R4wflJnEdir7ZkJJ VlfKzIVbw2pryj3obmjVll3VbXyUERY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CVHml6J4; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf03.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749743456; 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=XkOVcsQFLACiyPL8TaOWVC3fryHfhKobAgix/Ghr4pc=; b=CVHml6J4eMfPKN0sjB4jNA2GLosbqNcEICaRKdup/MvtIU8GVv0qxFC0s6fqdsJKTqYzzZ Ul8l0q9aLwTWI2F579Sro0KEtLUkKyItnHYFHiaieU+truMtx7BjKQTVHaXTV0rGLTXqrj ZQc6DyMLgG5S7HHsBSJgnSYaMIxId9Y= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-36-N8fKForjMsutcSNeJjgZsg-1; Thu, 12 Jun 2025 11:50:54 -0400 X-MC-Unique: N8fKForjMsutcSNeJjgZsg-1 X-Mimecast-MFC-AGG-ID: N8fKForjMsutcSNeJjgZsg_1749743454 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-450eaae2934so8690645e9.2 for ; Thu, 12 Jun 2025 08:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749743453; x=1750348253; 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=XkOVcsQFLACiyPL8TaOWVC3fryHfhKobAgix/Ghr4pc=; b=ibZKcW2qPRdn3mwQf2fC6EU34tphoWGuRk9YH5QVXla/I1A1wiHbeKh3hijXXE3HtC Cf+u0TGDwrPovkjDFWc81Czw1UhYQhQOZCNc1I1pEwQ4UfXcHo/cEc0TDnFhkH/lxv/Q 9vWvq0thY9IOWyFp7xLQpsLspo9Xta0w+Lca2gruECSGrtEL6VAeE/Rkj1lqvSeQzPA5 8OEu+6kRrB15I1tT7XrGX5eTad8io1c9RQi90I1ZH2eZIkNuoYmPFPKziezpmlB1vqTp ZHB12AM/Kg9ahtNcQLbwUx0pYw97x2Bvx9/YOWEM2bRCS11kT8JTnAzj2EShKPrnuUbk NpSQ== X-Forwarded-Encrypted: i=1; AJvYcCXriPJHPu0rqc3XKJMfCJOSa4Tq49ZDHogwiweSHXdP7EckzPCYsK8ezgwpUB4KEFAacSvu/Hn1tw==@kvack.org X-Gm-Message-State: AOJu0YxRNYKGQTZd5Qd59DtTbVsIVXNrGGU+ek5c2kkDxsPwI8S4iAPn EWZHYSZnyVrKSFcgvvSkDRxXyG3AbDpbsiqSPpNPG7vzK2El4iOaY7CUMcXqgNetNOorJcuMjmj vSlTta9p64D8v64oEHkX1OnevMe+oWa+2x0bVHes9yqlS1OmwprVm X-Gm-Gg: ASbGncvTcrvVn8TPZHlqd4GM7Bs5UZ8jxZRuu+ue3SbtHnmqGKohg6OFOPgMaIBCCt2 mQeFJC9eVED5eo40JHkw34F4m3II5moYAnuF4ueoPUrnd+p/47HCYgC5RDrG/k41Rebu9zM0Yto vslAog7dW2vCnBSg/ZsNGYz1LLJYpHQoEvMfqIUYlH62F5Ie3L9yZxFIOk+J9hNeNb86xI6Aqfo LXeW5r+LqXhnX4iPniPcdb0Jx+Yp+0SGogw7oLQOqP/TkRZ0S1f48OftAwOPU+0ZEM2tEA9pyrH JAi4Bj6w5uf13n8+lbOUtK5Zufe5i1j8p3AiRSKmNeS4mNpcodiSsRVrZZYa0ck4zO36f/rX/ud ryog5R9Xh6SAY59WVNe6vd+s7SuXNu0jUWekILThYX4GmSbsJ2g== X-Received: by 2002:a05:600d:1:b0:450:d3c6:84d8 with SMTP id 5b1f17b1804b1-4532c0cd520mr35166565e9.14.1749743453588; Thu, 12 Jun 2025 08:50:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHpim2SbqP8vPNnzoYisAsTRwCDTGGrS2SYjGpdFI8XoOlkpmwpLSRLioDfqRumkvmQ9Ccp2A== X-Received: by 2002:a05:600d:1:b0:450:d3c6:84d8 with SMTP id 5b1f17b1804b1-4532c0cd520mr35166425e9.14.1749743453137; Thu, 12 Jun 2025 08:50:53 -0700 (PDT) Received: from ?IPV6:2003:d8:2f2c:1e00:1e1e:7a32:e798:6457? (p200300d82f2c1e001e1e7a32e7986457.dip0.t-ipconnect.de. [2003:d8:2f2c:1e00:1e1e:7a32:e798:6457]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4532e13d009sm24710155e9.20.2025.06.12.08.50.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Jun 2025 08:50:52 -0700 (PDT) Message-ID: <94438931-d78f-4d5d-be4e-86938225c7c8@redhat.com> Date: Thu, 12 Jun 2025 17:50:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list To: Zi Yan , Jinjiang Tu Cc: akpm@linux-foundation.org, linmiaohe@huawei.com, linux-mm@kvack.org, wangkefeng.wang@huawei.com References: <20250611074643.250837-1-tujinjiang@huawei.com> <1f0c7d73-b7e2-4ee9-8050-f23c05e75e8b@redhat.com> <62e1f100-0e0e-40bc-9dc3-fcaf8f8d343f@redhat.com> <849e1901-82d3-4ba3-81ac-060fa16ed91e@redhat.com> <90112dc7-8f00-45ec-b742-2f4e551023ca@redhat.com> <839731C1-90AE-419E-A1A7-B41303E2F239@nvidia.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: <839731C1-90AE-419E-A1A7-B41303E2F239@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zNGpDWlM7Z2bniZwSgyCI80YmbNwbNuUG3znCTyS5v4_1749743454 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: rspam02 X-Rspamd-Queue-Id: B539F2000F X-Stat-Signature: mnsajhx5mbgikzyqzh111ontr31kt9no X-Rspam-User: X-HE-Tag: 1749743456-226239 X-HE-Meta: U2FsdGVkX192zTIZdxXzYjBC9xQvrOzhQKEXM2ccrTYBtGBTm62FTzn4PHinehwHXCS6/XwR1oxsxT4mtTD9stOAcLyOD7ant/jI8VjuWvXzi2vhxhYNctM7cd8ifWx3z3xsc6hrAuDOsCfr9gkLcAm5qakJTSNL/6Dj0AtqcKl2h9rB+0i7Xpol5EUiWCrO0OeGn1tyrcP2TPSNx+YWo4aLPQegGBF8+0cQJvHCoWVgKvDTHl5TC67IEhGJVEbhT7xjB3D9ktL1yi8isybyf3KINB4x8CQfANzEZrZM+fPeoWucB9nTHJPet7IUlad/VDjWp2PUNb36wtHzKl5GByO2xS5R73rrjKtMKVPIjgZMDH7u0tdSOrhxzqwljBmjP5rPtxVTJPFGwLFccOYUMfa5sJvp1YoFWFUAzdNz66KlDmbIxQHOyl/W7fZOPpF/hHUi+snC0UDwd9kGFF0X0OA8K/uKXgtvZoeij7GxzVo7OddWd6pDIXAzRuk/fygjoTV6hCsaIihy3kmtrV+ZW2/GlzcqmVVTnU0WQEGaMaKqvO785X7cExrdIZ7iJ5oPK3RmgVUQn9gWyuVVvTXsuVGCXzDpBEAES51hqAmQtPVAxGw1C/IxQezXtiYKWy1c7lDsCfk+iT0ufGQusPYlnpF0L3vJH2G0sZx5/O+0XNHFq0wOmeZc8lDaLThua7prc7lWgO7UXNMsa9qyqaGWxvZ3R/lCW0xBvQAsSRV4rnn1naKF+wl+zFp47JsnjRUx9IrYJNXjbwpCO6yAEPmRyZjyLPYQ1Ypj3yNb/F9mgyjVx6G79b5BSf4gDgMRGYva6sEI/Hyh5DW//JyhJVr2pAyZOD5RHNvHX1op0tW8fZ6AoRDFdD/TJ4pogQnsV/WeBl2ArZ5UQPBEfQjUJCUnWL1uaXZesyJgRySDbmXuXRDtFUBizjCdSn4aIM0MZvgBFJD1O9oklVJfZhd93mJ yrPUa9HQ TZfSlrrYdanfP3jnXzBP4doHi2UaoOlV7J0wCMmDW5d38RhD2ucC5RAxwIInt+Uc21gmWOHBmW+hriMnpeBmK4XdkTYLWjgSDu9DR92k3siqO24ByzwYADaxWtcER+r4O4TBFv8QNRu+wq4eN8BhKz47osmmLRq75Y7SOUc2dufn7J1AvDakDZuVSpni+IKzJkppMok1hbG2mTvLYZdAEEtv03FzYdZkVzMiZgRvZ1kK3PXIILSDqMpFcNJGog883udunhfIUynQRNEp+r0jmstnoM9HheBa7nlmih1fqJzcODl6SNIAQhsV6lJbHSJ80HEQWR3/OkC/q0WiccAm33MVsfQilcwsmpmJcxv1erBLxygwExALRQHvLsm/ihDWhHxesNrVJNJfNbhAj3y/Gizuj+CoASvstV8jgD+3H+GX95tSnY+opUs8mZxOpWmMosJ6a 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 12.06.25 17:35, Zi Yan wrote: > On 12 Jun 2025, at 3:53, David Hildenbrand wrote: > >> On 11.06.25 19:52, Zi Yan wrote: >>> On 11 Jun 2025, at 13:34, David Hildenbrand wrote: >>> >>>>> So __folio_split() has an implicit rule that: >>>>> 1. if the given list is not NULL, the folio cannot be on LRU; >>>>> 2. if the given list is NULL, the folio is on LRU. >>>>> >>>>> And the rule is buried deeply in lru_add_split_folio(). >>>>> >>>>> Should we add some checks in __folio_split()? >>>>> >>>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>>>> index d3e66136e41a..8ce2734c9ca0 100644 >>>>> --- a/mm/huge_memory.c >>>>> +++ b/mm/huge_memory.c >>>>> @@ -3732,6 +3732,11 @@ static int __folio_split(struct folio *folio, unsigned int new_order, >>>>> VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); >>>>> VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); >>>>> >>>>> + if (list && folio_test_lru(folio)) >>>>> + return -EINVAL; >>>>> + if (!list && !folio_test_lru(folio)) >>>>> + return -EINVAL; >>>>> + >>>> >>>> I guess we currently don't run into that, because whenever a folio is otherwise isolated, there is an additional reference or a page table mapping, so it cannot get split either way (e.g., freezing the refcount fails). >>>> >>>> So maybe these checks would be too early and they should happen after we froze the refcount? >>> >>> But if the caller does the isolation, the additional refcount is OK and >>> can_split_folio() will return true. In addition, __folio_split() does not >>> change folio LRU state, so these two checks are orthogonal to refcount >>> check, right? The placement of them does not matter, but earlier the better >>> to avoid unnecessary work. I see these are sanity checks for callers. >> >> In light of the discussion in this thread, if you have someone that takes the folio off the LRU concurrently, I think we could still run into a race here. Because that could happen just after we passed the test in __folio_split(). >> >> That's why I think the test would have to happen when there are no such races possible anymore. > > Make sense. Thanks for the explanation. > >> >> But the real question is if it is okay to remove the folio from the LRU as done in the patch discussed here ... > > I just read through the email thread. IIUC, when deferred_split_scan() split > a THP, it expects the THP is on LRU list. I think it makes sense since > all these THPs are in both the deferred_split_queue and LRU list. > And deferred_split_scan() uses split_folio() without providing a list > to store the after-split folios. > > In terms of the patch, since unmap_poisoned_folio() does not handle large > folios, why not just split the large folios and add the after-split folios > to folio_list? That's what I raised, but apparently it might not be worth it for that corner case (splitting might fail). Then, the while loop will go over all the after-split folios > one by one. > > BTW, unmap_poisoned_folio() is also used in do_migrate_range() from > memory_hotplug.c and there is no guard for large folios either. That > also needs a fix? Yes, that was mentioned, and I was hoping we could let unmap_poisoned_folio() check+fail in that case. -- Cheers, David / dhildenb