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 67AFDC5AD49 for ; Wed, 28 May 2025 20:26:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 835746B007B; Wed, 28 May 2025 16:26:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E6EB6B0082; Wed, 28 May 2025 16:26:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6ADA86B0083; Wed, 28 May 2025 16:26:13 -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 4B65E6B007B for ; Wed, 28 May 2025 16:26:13 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7FBB9C15B3 for ; Wed, 28 May 2025 20:26:12 +0000 (UTC) X-FDA: 83493448584.20.833E7DC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 044EF1A0016 for ; Wed, 28 May 2025 20:26:09 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="G2APl22/"; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748463970; a=rsa-sha256; cv=none; b=n+N5B7+J1qaxA3pOKTKyCjxsgrT/ZUmGTRE0e9Ufuw7blDmbbB+CCTwMqEkaMBGSICHzqn ZL0XuUolEIFH/KBi3Y92mkbA0bVqSjg05DThvR2tH+3CM5KDJuawZxggtpyp4xxRzrXL6s /Y3bAyeDXIxhjwJQEvwjI+DFXSJpxyg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="G2APl22/"; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1748463970; 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=FC7FWOIvZGBtznnKQ9ub2nhNjZp56JzMAsF9Q1073Xk=; b=hxSUdCYe09Ge6LUh1Za5Vr+a0p+z1uKelceohvld9THCLdxzk9UBz+OIxjbaL5RSf1uaGJ M3zeldUOxGW7l3ZgxChS5sBgw3q1Pd0ilZarWVyd+iXvZkJcpOACnGtqV2/vVBD4wxkz9c IeFKy6h+O5lRcGmp0daQw8UIDUBjvNw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1748463969; 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=FC7FWOIvZGBtznnKQ9ub2nhNjZp56JzMAsF9Q1073Xk=; b=G2APl22/YqJgVlHrqQsPdRnMgwcZP5l6Gh8kknzrlwJOfd0tuBI7YqG80aY7KlF78G7qJB K9DgXkxZ5UByaDV2Foras6gT6S8cFFoQ8StxtuJ4PHLt59Cm2V9mvsq5UkD4d8jsBIrj51 rsb/rzuk2qtovdfjLvpOBlXtN23Yy1A= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-311-_DfQfohMNUOVooxJriDFDg-1; Wed, 28 May 2025 16:26:07 -0400 X-MC-Unique: _DfQfohMNUOVooxJriDFDg-1 X-Mimecast-MFC-AGG-ID: _DfQfohMNUOVooxJriDFDg_1748463967 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-442f4a3851fso2124585e9.1 for ; Wed, 28 May 2025 13:26:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748463967; x=1749068767; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=FC7FWOIvZGBtznnKQ9ub2nhNjZp56JzMAsF9Q1073Xk=; b=T/fxsz3q9ShRMYz0tBzSRpRkzOroxFACSN2AHPG7kkNQAZOzisdA1Yf2dphfG1Q3d2 ULJszn8plcWFcnwrkkLE00JxDNpef4qLrGM1Q02V105D8TtdWyXvMUYM5VoOi3kP8C5N 30JDZMX72u+B9XpFzAUrjA63t/T6wSJrzcx2EIde4c3foaWg4+eF8RrK4z+9y5AX1VN9 q2MITaz+15OkqEMsYXkRwoGfrBJx9Vo/cIcqUCdJVMvpjSK7xBHpzd+pXDEDPnSN2O7a c81dmy+OlzUUKMfu120wQLrSQuiylzF9CuOrWBM0H1JWqMIgcRe+9ge+6Bl+CHex1J4O 1ehQ== X-Forwarded-Encrypted: i=1; AJvYcCWNTFTMQsyh0B3HNnMhCnQbJG7/SDerQYVquq50A3mGgZKHlJwJtBrdWQVH7gpyXok/xFpiDb5UNw==@kvack.org X-Gm-Message-State: AOJu0Yy1Lal2lz8y9jIiuEB02lwqfbKk7sUknw1xAMNCFJ56yeJctie2 vq+HrYpXxrvVt3rr/7HWiOrd615lXxBL7SG51Ph0T3SUaEMnEbrBAOGlSbvByD/9rRP1JtgpZTY m8+qkiwnFsd476z/CRTNpQcaolDk4yMEasSenKXKefwycmRt1X+80 X-Gm-Gg: ASbGncsRlk6uwqqPAtF5kR6HFsblrwI9Z1uO31wMeqXEoi59mYBgoaZjjBL3layhls7 9NW7Abp1bPajIGnt5GuYNTRb2JIQKAoDsj5sI0XAfC0JD6O1L6NG6mJIs/llPGh74DTs8nmJUBz C3g9Krzadi1bqcDrXNLmIgHRAm7CAASG0nnHGMo76jVFz0toJtQaOjtNrbzfJaZ/g34akuC92fh l7HXcF+jFP2hDhd+XKtd5nb6WFxGMwBMHWtZT7QHO+AGkbxJ+CazloB1cBMCu1oSZM1e6Z8/wgp nM30cOTgltVAa2I2YFfrmvIRn3Tzz7TdU5TJUnMuNntUV7bvo6ZY74M1CU/0Jmv/wAX0qx2J+pX k+A6D9TcTAgjgtzb5XzvJ3QBkRjIGCfd1tf2BHaQ= X-Received: by 2002:a05:600c:4684:b0:43c:f87c:24ce with SMTP id 5b1f17b1804b1-44c955dc476mr165327255e9.21.1748463966595; Wed, 28 May 2025 13:26:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFl9iKLxUdb8Lx653EW40oPpCh5HAsCocZ1VcQx/sJxTqqrIx/uvv3RMhUjhg1voWirB1ECYA== X-Received: by 2002:a05:600c:4684:b0:43c:f87c:24ce with SMTP id 5b1f17b1804b1-44c955dc476mr165327105e9.21.1748463966158; Wed, 28 May 2025 13:26:06 -0700 (PDT) Received: from ?IPV6:2003:d8:2f30:ec00:8f7e:58a4:ebf0:6a36? (p200300d82f30ec008f7e58a4ebf06a36.dip0.t-ipconnect.de. [2003:d8:2f30:ec00:8f7e:58a4:ebf0:6a36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450cfc0344asm1185555e9.11.2025.05.28.13.26.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 May 2025 13:26:05 -0700 (PDT) Message-ID: <04ecf2e3-651a-47c9-9f30-d31423e2c9d7@redhat.com> Date: Wed, 28 May 2025 22:26:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table From: David Hildenbrand To: Oscar Salvador Cc: Peter Xu , Gavin Guo , linux-mm@kvack.org, linux-kernel@vger.kernel.org, muchun.song@linux.dev, akpm@linux-foundation.org, mike.kravetz@oracle.com, kernel-dev@igalia.com, stable@vger.kernel.org, Hugh Dickins , Florent Revest , Gavin Shan References: <20250528023326.3499204-1-gavinguo@igalia.com> <629bb87e-c493-4069-866c-20e02c14ddcc@redhat.com> <4cc7e0bb-f247-419d-bf6f-07dc5e88c9c1@redhat.com> 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: <4cc7e0bb-f247-419d-bf6f-07dc5e88c9c1@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sYV78X9nRchEGXp8rLylxPZCaQZq-stqPQMr1sBDr1s_1748463967 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: rspam08 X-Rspamd-Queue-Id: 044EF1A0016 X-Stat-Signature: 3ps31z8qo8ugdypq71c6767wikfz77f6 X-Rspam-User: X-HE-Tag: 1748463969-372538 X-HE-Meta: U2FsdGVkX19K5LwNpoyBD1ULuQiWNl1v4I0k+GniBDILFYGdXLC/ETJe//MRpfjU5n209I0ImjytMJhsfpYHzAzjNZNQVCL1kDMN7NDe4updudh8iG1iz5zGI/3aCa0mytanSUNNydQjeJi22Bh0BSWanbpkC4YqU+CZXR82oQ2fjr1t3XbdIv0amw9jGgqvnEGApR8/H13v12rV7krVq45GcTpNY1hirjDq4P4sXIpsk4lmKWUj781vXAseteL/MWcxSC0wZ2L8PXVFakh5hVMtpbWxTNFrlaKgcHK6xepr5G/1a4mtkE2V4dw0JDnWR29okjv/Q+3VdJwWz+0ydOLrcNLAQsiQLD2E8AKkikHZZE6kBt+7Jr65orRAaTaQoV/D9hSkEoy2cdMLGqqlCNodUSCbX8yu2Zl+8iqP+O5uiLFpefQxT117t1Pt2wg3aNVCyIqpKs3Gj+h0IZ0ZwiXFNX4tnWed3zYF7t2baNffI8cUkwHofdA6/usSGAI9TRVZ4jlebS7XmrpLkGiykizOiPUQJakXSfixUeqpZZY/VEwaIYgCMUEr9IWnPC71MXwpZjrBkBqgUEuN5r1jruaDJ8HQnjCFC04DTdDb590O4Idmqf6n2k/46VkhtRVE81GPcD276mlTMZaa2uXGieIuQCSFOofynGloIEwMjy7gc6iHQktwSGy7HhyA7fVSRAanzuYZQrn3gMbzZd0WACMeWP/NYWvxg7/N1smf/TmFxM/Klkdo3zKKLY6BdpRgcK0j491njzp5FsTq097MaNx/K9XKtb1yKbfL2qGDeYrZ1rFhhmdvie3p78ftXXyPhIB1XzDFqPtDvVoaDZ+e2+C3ln96EALTghvreZi8w2iZDGsfqF2cMGz3tEoRmVywDGMqzJxS3raBdaRqc1t5viyMPnkQbPVec/L0WEp1xkN5Br88cPXi46lNssr6zqEEtaBnNuGwd5ePtkzlD9p 20YR2m+o Q05WVb5O/cT/ieVjGD5XBkfusK4Em4YstZznzppIiGKbLyReriZY28U2d8NVqwJF26fIqL1qPcosa0/doXkWR9zOvQoluc5/WlCNP/ZRA5Br+uyp+4yfq+ydDu6tgIxcKfZowBL6v4BzAit2soFcWeqTvC18zMRD/MugHJaUna0t8/ti8gXfiiruxtcMwdesLvpciK35gxXBM6BdJDAzjYB0OE7V04XWi3oPFYzBEx7sZxzo1LUA9ypYDsEIBlxRRo0nSxI1I6tqHxGC6eFAzoG8imZjZqwAY3oxsmX79kcVGY4kCK780mM5CSdYhpd4NF+n2q6DtF+htp83Ew2kIEG8BY7fNlG4jBfqL2T6bmP9631NPJ1psBaZU/0qCxedKEjNqjnldquS3zuqkbydivH6QfpQu1L5zn5m5R/eLHVmq23nGROjOtzvHoLWt/zmcymu9gY8XkqI+m6aer0oGjgFUV8jB++REKe59IPynFgTfwU39kM/L/ELbfSABfABdQYlc 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 28.05.25 22:00, David Hildenbrand wrote: > On 28.05.25 17:45, Oscar Salvador wrote: >> On Wed, May 28, 2025 at 05:09:26PM +0200, David Hildenbrand wrote: >>> On 28.05.25 17:03, Peter Xu wrote: >>>> So I'm not 100% sure we need the folio lock even for copy; IIUC a refcount >>>> would be enough? >>> >>> The introducing patches seem to talk about blocking concurrent migration / >>> rmap walks. >> >> I thought the main reason was because PageLock protects us against writes, >> so when copying (in case of copying the underlying file), we want the >> file to be stable throughout the copy? > > Well, we don't do the same for ordinary pages, why should we do for hugetlb? > > See wp_page_copy(). > > If you have a MAP_PRIVATE mapping of a file and modify the pagecache > pages concurrently (write to another MAP_SHARED mapping, write() ...), > there are no guarantees about one observing any specific page state. > > At least not that I am aware of ;) > > >> >>> Maybe also concurrent fallocate(PUNCH_HOLE) is a problem regarding >>> reservations? Not sure ... >> >> fallocate()->hugetlb_vmdelete_list() tries to grab the vma in write-mode, >> and hugetlb_wp() grabs the lock in read-mode, so we should be covered? > > Yeah, maybe that's the case nowadays. Maybe it wasn't in the past ... > >> >> Also, hugetlbfs_punch_hole()->remove_inode_hugepages() will try to grab the mutex. >> >> The only fishy thing I see is hugetlbfs_zero_partial_page(). >> >> But that is for old_page, and as I said, I thought main reason was to >> protect us against writes during the copy. > > See above, I really wouldn't understand why that is required. > >> >>> For 2) I am also not sure if we need need the pagecache folio locked; I >>> doubt it ... but this code is not the easiest to follow. >> >> I have been staring at that code and thinking about potential scenarios >> for a few days now, and I cannot convice myself that we need >> pagecache_folio's lock when pagecache_folio != old_folio because as a >> matter of fact I cannot think of anything it protects us against. >> >> I plan to rework this in a more sane way, or at least less offusctaed, and then >> Galvin can fire his syzkaller to check whether we are good. Digging a bit: commit 56c9cfb13c9b6516017eea4e8cbe22ea02e07ee6 Author: Naoya Horiguchi Date: Fri Sep 10 13:23:04 2010 +0900 hugetlb, rmap: fix confusing page locking in hugetlb_cow() The "if (!trylock_page)" block in the avoidcopy path of hugetlb_cow() looks confusing and is buggy. Originally this trylock_page() was intended to make sure that old_page is locked even when old_page != pagecache_page, because then only pagecache_page is locked. Added the comment + /* + * hugetlb_cow() requires page locks of pte_page(entry) and + * pagecache_page, so here we need take the former one + * when page != pagecache_page or !pagecache_page. + * Note that locking order is always pagecache_page -> page, + * so no worry about deadlock. + */ And commit 0fe6e20b9c4c53b3e97096ee73a0857f60aad43f Author: Naoya Horiguchi Date: Fri May 28 09:29:16 2010 +0900 hugetlb, rmap: add reverse mapping for hugepage This patch adds reverse mapping feature for hugepage by introducing mapcount for shared/private-mapped hugepage and anon_vma for private-mapped hugepage. While hugepage is not currently swappable, reverse mapping can be useful for memory error handler. Without this patch, memory error handler cannot identify processes using the bad hugepage nor unmap it from them. That is: - for shared hugepage: we can collect processes using a hugepage through pagecache, but can not unmap the hugepage because of the lack of mapcount. - for privately mapped hugepage: we can neither collect processes nor unmap the hugepage. This patch solves these problems. This patch include the bug fix given by commit 23be7468e8, so reverts it. Added the real locking magic. Not that much changed regarding locking until COW support was added in commit 1e8f889b10d8d2223105719e36ce45688fedbd59 Author: David Gibson Date: Fri Jan 6 00:10:44 2006 -0800 [PATCH] Hugetlb: Copy on Write support Implement copy-on-write support for hugetlb mappings so MAP_PRIVATE can be supported. This helps us to safely use hugetlb pages in many more applications. The patch makes the following changes. If needed, I also have it broken out according to the following paragraphs. Confusing. Locking the *old_folio* when calling hugetlb_wp() makes sense when it is an anon folio because we might want to call folio_move_anon_rmap() to adjust the rmap root. Locking the pagecache folio when calling hugetlb_wp() if old_folio is an anon folio ... does not make sense to me. Locking the pagecache folio when calling hugetlb_wp if old_folio is a pageache folio ... also doesn't quite make sense for me. Again, we don't take the lock for ordinary pages, so what's special about hugetlb for the last case (reservations, I assume?). -- Cheers, David / dhildenb