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 388CBC77B7F for ; Tue, 24 Jun 2025 11:39:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB9A46B00B2; Tue, 24 Jun 2025 07:39:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B91496B00B3; Tue, 24 Jun 2025 07:39:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A80696B00B4; Tue, 24 Jun 2025 07:39:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 94A1B6B00B2 for ; Tue, 24 Jun 2025 07:39:18 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E4FD2103BAA for ; Tue, 24 Jun 2025 11:39:17 +0000 (UTC) X-FDA: 83590098354.03.C40183C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 770CF40008 for ; Tue, 24 Jun 2025 11:39:15 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TfdcslCg; spf=pass (imf12.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750765155; a=rsa-sha256; cv=none; b=JZvDYosIMYF4wVeQHxvTi/JfJz7Hn7dGKZDjxLulgehgyhePD5rrwu4IG5/HKKDcKqMpsC CaXgLrn/xxaU0fcoQ7ePQ/29wl33IouzHrx6ewPfiicTajGerteQ0IY32gu4nfm1fd4RPS p6DIZrNbrv071CiNA84ZgoRoSQ2CffI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TfdcslCg; spf=pass (imf12.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750765155; 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=AXIga1bkzrBMFrY8HFgs7axgfA9Z09Pf3kfYJmY6hOo=; b=6S1xOBVIrcwGbGM2kABovBE5G5hdhvJiuE2/PMdT9Y6Gbkacu5SqU4qqv8y5uuzcLUpCTj aRmOIABOXh+az4TrPVtG/anbM5AVUSMg7UwHY7fDrOCRDmZ2mMvTJB+qhqHNvBgevWldXg U4c3dLFz1jZlxRF00Ez0pMPMGTLkuqI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750765154; 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=AXIga1bkzrBMFrY8HFgs7axgfA9Z09Pf3kfYJmY6hOo=; b=TfdcslCgGQ/PFBIhGGqF2CacYzcAfnPGARAaD13qogvzGVZo/RbxtnoOk7hSjGKX8lOSfb pxLBvrryRCdbwqVhmhb097jGxU75H8Q1vzFBIet44fQa+fzXaTU/eOlRVN3N1AJXQA5+hv DXltTSVxLdsN3pNSUKWclpqiF9zw2RA= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-343-4LAWXT_mPT2DdOHYvn4iOA-1; Tue, 24 Jun 2025 07:39:13 -0400 X-MC-Unique: 4LAWXT_mPT2DdOHYvn4iOA-1 X-Mimecast-MFC-AGG-ID: 4LAWXT_mPT2DdOHYvn4iOA_1750765152 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-450db029f2aso1762135e9.3 for ; Tue, 24 Jun 2025 04:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750765152; x=1751369952; 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=AXIga1bkzrBMFrY8HFgs7axgfA9Z09Pf3kfYJmY6hOo=; b=XUsrLdLRvE7THbtwQnTgekHw+yIQIXVX7IWypaIfdTmW1KA1mD3/WrLecLAY1BWRCu fVxG30LnxourXLWfl0PGT1s3H84OncW9qO5SQNiL744t7pV5uGQcdns6hs4k59NgI2kw ievye3pKnZKdkrV/zPVeE63MMjMKfXcH6AyTzScwSqotyRPn1Oj6o+vBVHVOdXDDC2zo j6zeE1+mPGqBeJXVmmpYQLLm8uJvEN4IwexKSs6pq5F6vCHKjoLQZ/Z03+eDUnyVPeaD rO/ID0LpUyQX0ZYCc1RAHpNCAtT9OYzYoySsZ5RxqJfdlQUXjMKoMxDEcWtJ4wtvY+hO rfTA== X-Forwarded-Encrypted: i=1; AJvYcCXOAlS+yvaCOAEwEYm0cCScKCQcQyFF4mA8WCZudzIgmVtt5+ox/CLi4sPympf5kI15/ZgDkv9Oxw==@kvack.org X-Gm-Message-State: AOJu0YwLHhJfj2R9Da0OmRiaQ1/QhAmx0vncAlJgnv1oRYyUxVTKiQD0 da4pVDHSSTH3NCKlhKoJkyx5hdf6efLCWXReRocalYiALNwRlQrzw2UAunntJEvigInnS1OEo0q VW8d4hIQhax70mcHKmtWpOdFu8QVUBOhMhHONLL4UFTrlzzprE10g X-Gm-Gg: ASbGncssBwbnqH0XQLHpMhIZFyMoIDGnDqRf3coz9GXqorIeeaHwsdExo1b+l9DZGJa r2jp9VflTZNobn+JXaqNIm83sFsJPp4UUQqLxPfZwQFHT9bxX3d0USoCG2JfsiM1oBdtDdAqTYZ PI6soOerqr7IENkRjGJo7BSm59T4EPIlWSuWFjVFPzxMF/vbUcmEp6avuYNuhQ1i6UZaOQu6zyF jGow1fQNna1sgU8qn00+46Xm2yQ5OYw+ibJ0VkA5PxkglRg/HQjURJ5TpqSSt4aCiKg00T5S/Zy ea43H6WM7QG2kXGjXiKunr7TBQjPSNUAWLyk6fL3RU62gyEQlY0Kk5I= X-Received: by 2002:a05:600c:1f14:b0:453:5d8d:d1b8 with SMTP id 5b1f17b1804b1-453659c4169mr165567175e9.30.1750765152065; Tue, 24 Jun 2025 04:39:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IErMOyF7WaU24rVgpkQqumxg1Yg3KftcabGR+eBnLPstGAHmjKS0ym0uqBvGrttUZVbn2hA9w== X-Received: by 2002:a05:600c:1f14:b0:453:5d8d:d1b8 with SMTP id 5b1f17b1804b1-453659c4169mr165566765e9.30.1750765151613; Tue, 24 Jun 2025 04:39:11 -0700 (PDT) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4535e98b48asm174446585e9.16.2025.06.24.04.39.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jun 2025 04:39:10 -0700 (PDT) Message-ID: <239f75e4-1868-4ac9-882f-664a8863b781@redhat.com> Date: Tue, 24 Jun 2025 13:39:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] selftests/mm: Fix UFFDIO_API usage with proper two-step feature negotiation To: Nadav Amit Cc: Li Wang , Andrew Morton , linux-kselftest@vger.kernel.org, "open list:MEMORY MANAGEMENT" , Peter Xu , Aruna Ramakrishna , Bagas Sanjaya , Catalin Marinas , Dave Hansen , Joey Gouly , Johannes Weiner , Keith Lucas , Ryan Roberts , Shuah Khan References: <20250622081035.378164-1-liwang@redhat.com> <20250624042411.395285-1-liwang@redhat.com> <4fd18a1c-aba2-468a-881f-0507953f2904@redhat.com> <611F9598-A1A4-47B6-B37E-09BF7B4D17D0@gmail.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: <611F9598-A1A4-47B6-B37E-09BF7B4D17D0@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EG-5xWDzIzcgD3pfDOV3kHJMCYJPCsm--Yoh74ejQjU_1750765152 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: j18iwxbhsi57ohgw8gmc1w7nzz8x4h78 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 770CF40008 X-Rspam-User: X-HE-Tag: 1750765155-202319 X-HE-Meta: U2FsdGVkX18L8kkKTPtG0uElsxuwUCx/TwTBPtKeMW5WHQSGr+xXZjguAFC5fcaRJzdP6/cLQg9WsJSgsoVzRPiRR0eLvtaD05RAS020mG7sVxdSU0An0UDqi9I2mcNAU7dgpdwqrkjk+yaJznqX4u8wOZI9ObxoHm6DdZjEKHDjOQBY3QuMImQq3NrdnWMm2+uYEvQWDFrXA8mnzobncukQAX1l+cH40SKJlre8e/j4CBA/W9vezaWf7L4xaYFdHeg+iqV48iLA+Q+8Fz58fW5SZ5cvyYaDNeMExqOwgWLK5++NsqBfOZUBsbfx186oEzwpGwsW/pIuSGoipqg17itdnZa508WgAmuAMmqlVP7aqHQ5eV1IdO1Y9lpBdX7tHlhNIYOYJKpkxvT8gMu+xlNFFLBKxT+KIXdd0FYAS8N3HierutCACcO7a45zrHccwLGf3MK8/vS0e87kAgDjGxYA7Infza+I8XbJoUSOvJQ2JQFe+E2w+pe3sbH4ExFUcENJtjzefoiRc3aLZt1WEcA5TUHVx0zwCbJvwEIuQbMhbkJiMCYIvp8QV6vAi/6iISE8ayYhy4lqtvaQ+YHWphTIMfLBa171x1jOEQyy8urM1O7sZxHK46t7Qed3QPFsAPdpOhrK4fANKBuHA2bczdhDIvKKSgDLY3ckSJ60WB1bj5pyIbeYiRyNFBDxgsJGIlUAfR4RMkySLj+m5UmX5Q4xaXW+mTwZPvibDHAC7ZlA062QcU0oshNTPqo+V5G/7+IhC3c0wji6iEeD4cdrMCtmfDDo2Wy48aMgsDQ7yLAaefWafup+jv4w3lao0v1qb1PptLgOR9q1rDpyUSTVdLhfG1tSvSYVNYB32jTI4MbGXSH4G7SPN3NGsIhJWW/4NTrzETSmXmGlNvM9zJQE0Nx9KjRm0WmtvEX3Ae/CEZDccUpXCSlCgGjE3emcTstd9W6IE2HSepGxVr7ArKW 1gwYxEgm Fzpo9OcLdWFA/EscbxFWwdkndiBTFcDLxg/9rZqEC8XBc60SQvHjT0yE4shGDKQfaPHv7s8+ayJJbjWepWuWVNcgIr8khtRItTdR7VUdlU2UVGW2D9S3cjf9WeDaBrYcRlddCSPAPCEyZbbHF8QM/SE+JwdNsxIZl/9IBYrXxhSKIxQn+hAPO4RDS4aniEaSVM3NGqtmN7QZldxtiDPt6jWnnWRfqzIB/XuCmQJw9eR0BNs6LImujbPPt416cANyFj6abrqEtgkZX4sG36/uFkhqiv5vPeJIwrGzEiWAG5XJ6c6JiDPMsJFb/ZwIAZm0CTGtrpwxn0OFmGTRyDGeEVI5yfr2e2WNI/FjfkwhwoR+bp34b5iRko7wEhKTxfTn35ryCP2VTflyRYGlGuR8DYHzdsLKxNDc4GaCsygUZDFcXPIuKLf8Hhd8RkmMSUcM5/AFDzyH28DDxTw+I77GdLkDSI+zZ1CmXIbhiQ1jDHOXDgohZT1AVg3MhbHH9ToWH2qARFKX+CIO3Lx5zJJupLJ8DAFRberUzqCU6HS1y/GDAO72KDJn2Moenyf/Y3mE2bkddiiRtlQ4pyzEJP90uBotperXbOvK4ZnIbtWfuEZAENpE8VWXXioPGsg== 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 24.06.25 13:29, Nadav Amit wrote: > > >> On 24 Jun 2025, at 11:22, David Hildenbrand wrote: >> >> On 24.06.25 10:07, David Hildenbrand wrote: >>>> >>> Is that actually required? >>> The man page explicitly documents: >>> " EINVAL A previous UFFDIO_API call already enabled one or more >>> features for this userfaultfd. Calling UFF‐ >>> DIO_API twice, the first time with no features set, is >>> explicitly allowed as per the two-step feature >>> detection handshake. >>> " >>> So if that doesn't work, something might be broken. >> >> CCing Nadav and Peter: >> >> Could it be that >> >> commit 22e5fe2a2a279d9a6fcbdfb4dffe73821bef1c90 >> Author: Nadav Amit >> Date: Thu Sep 2 14:58:59 2021 -0700 >> >> userfaultfd: prevent concurrent API initialization >> userfaultfd assumes that the enabled features are set once and never >> changed after UFFDIO_API ioctl succeeded. >> However, currently, UFFDIO_API can be called concurrently from two >> different threads, succeed on both threads and leave userfaultfd's >> features in non-deterministic state. Theoretically, other uffd operations >> (ioctl's and page-faults) can be dispatched while adversely affected by >> such changes of features. >> Moreover, the writes to ctx->state and ctx->features are not ordered, >> which can - theoretically, again - let userfaultfd_ioctl() think that >> userfaultfd API completed, while the features are still not initialized. >> To avoid races, it is arguably best to get rid of ctx->state. Since there >> are only 2 states, record the API initialization in ctx->features as the >> uppermost bit and remove ctx->state. >> >> Accidentally broke the documented two-step handshake in the man page where we >> can avoid closing + reopening the fd? > > I agree the code is not correct (and my patch didn’t address this issue), > but I don’t see it broke it either. > > Unless I’m missing something the code before my patch, when > uffdio_api.features == 0, also set ctx->state to UFFD_STATE_RUNNING, which > meant another invocation would see (ctx->state != UFFD_STATE_WAIT_API) and > fail. You might be right, I only checked the cmpxchg, assuming it was working before that. ... but staring at the history of the "ctx->state = UFFD_STATE_RUNNING;", I am not sure if it ever behaved that way. Do maybe, the man page is simply wrong (although I wonder why that case was described that detailed) > >> >> Without testing, the following might fix it if I am right: >> >> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c >> index 22f4bf956ba1c..f03e7c980e1c5 100644 >> --- a/fs/userfaultfd.c >> +++ b/fs/userfaultfd.c >> @@ -1944,9 +1944,9 @@ static int userfaultfd_move(struct userfaultfd_ctx *ctx, >> static int userfaultfd_api(struct userfaultfd_ctx *ctx, >> unsigned long arg) >> { >> + unsigned int new_features, old_features = 0; >> struct uffdio_api uffdio_api; >> void __user *buf = (void __user *)arg; >> - unsigned int ctx_features; >> int ret; >> __u64 features; >> @@ -1990,9 +1990,12 @@ static int userfaultfd_api(struct userfaultfd_ctx *ctx, >> goto out; >> /* only enable the requested features for this uffd context */ >> - ctx_features = uffd_ctx_features(features); >> + new_features = uffd_ctx_features(features); >> + /* allow two-step handshake */ >> + if (userfaultfd_is_initialized(ctx)) >> + old_features = UFFD_FEATURE_INITIALIZED; >> ret = -EINVAL; >> - if (cmpxchg(&ctx->features, 0, ctx_features) != 0) >> + if (cmpxchg(&ctx->features, old_features, new_features) != old_features) >> goto err_out; >> ret = 0; > > I am not sure it is right since you would return EINVAL in this case. > It also looks a bit overly complicated - are you concerned about a race? Yes. > My whole concern about race was that somebody would exploit it to > overcome non-cooperative UFFD (IIRC). > > So perhaps just add a check for the case features if 0 and be done with > it? Something like adding: > > ret = 0; > if (ctx->features == 0 && features == 0) > goto err_out; /* no error but copying of uffdio_api required */ Probably would also work. But let's find out first if we even want to fix this, given that it never seemed to have behaved that way from a quick glimpse. -- Cheers, David / dhildenb