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 36E87C28B28 for ; Wed, 12 Mar 2025 22:04:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACA2B280003; Wed, 12 Mar 2025 18:04:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A79A7280001; Wed, 12 Mar 2025 18:04:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 969CE280003; Wed, 12 Mar 2025 18:04:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 78155280001 for ; Wed, 12 Mar 2025 18:04:13 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3A8C9A9E09 for ; Wed, 12 Mar 2025 22:04:15 +0000 (UTC) X-FDA: 83214278070.11.327AEB7 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf18.hostedemail.com (Postfix) with ESMTP id 8E9921C001B for ; Wed, 12 Mar 2025 22:04:13 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="aSM/I7sz"; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741817053; 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=v73k1FRDLve+SHhiXBlcQl7Y/jUxpapoPhhWh/+RS7U=; b=FSbdt87jr4WWLLgp2HG9MhrQaZc1myWHngKrkq6qVloZxJcwdfO0rKaaDCe2W6r0vLJVNr Rzahqc1R8aoH5rYR5EFgBzjPa8paEtTPcbz4SPNcrUJBbZOmP5wQZHCeTWUaYLZjVVw7// hVF69gEKEw4A1AalFrx6LzHCuEVi820= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="aSM/I7sz"; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741817053; a=rsa-sha256; cv=none; b=FZDlm4S0+kXQu0J++tPKe1YCU4pOb1P+o0v9raXwPviTmdXQhvcAV911nKBC7K2HNzc/mt 83hf4brbG1gaLa1PjqugTzGamzAXP/CU78M6xbT0N1jzT/WYaxRVLu1PnDAuwA04BcfXgj ktpfWv2OYRa9MSFdP1zNP6DgVGUOBhM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 11418A41AA7; Wed, 12 Mar 2025 21:58:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4460DC4CEDD; Wed, 12 Mar 2025 22:04:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1741817052; bh=q7CxZcfZDMZ1MshmmrMaaEZTfn95aPXhl6ugjT4WvEc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aSM/I7szR+8FJOMRcznJG2VoqJxSryCaOUfcmTfD7X4vQIcWZyDIfWBSX2ljEQiJ+ zjN31ndVUhzrg7wGmOy2oNPIla8OcqurfBd00hOc5kP8hPLXBxIdjnDVrOZkMF96PF 5O+PI3K8XmzAaTgzdFMFzZybm9llA10Fiy33b7S4= Date: Wed, 12 Mar 2025 15:04:11 -0700 From: Andrew Morton To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kefeng Wang , Mike Rapoport , Al Viro , Axel Rasmussen , Pavel Emelyanov , Jinjiang Tu , Dimitris Siakavaras , Andrea Arcangeli Subject: Re: [PATCH] mm/userfaultfd: Fix release hang over concurrent GUP Message-Id: <20250312150411.f4a5b406600742a49b46d04e@linux-foundation.org> In-Reply-To: <20250312145131.1143062-1-peterx@redhat.com> References: <20250312145131.1143062-1-peterx@redhat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 8E9921C001B X-Rspamd-Server: rspam03 X-Stat-Signature: gq5o1od837thxrmn4ef5hg8o3miprshd X-HE-Tag: 1741817053-118028 X-HE-Meta: U2FsdGVkX1/7Ur9paI1ktTURi+nJ3W4eQxn+QD+uUD0yDdb+F4I4aHzCvJ3hRKnv8ByvHumZMYDcr316KIJu3MVYYH6xFQsxz0k9MUuvZGva323nfUzjzENlSBRFWJg4JY/hGrMUv3fB1La5GIdQg+jyG49NJ45we/UA8/bXw2NRlphGTIy7IW5nbd+CXxwfTsKeZ0wihkLGioOcC68vUwiD4Lee4Rpd8mRehWcMtq7p4DwpmX5/ZRoiePPqgvIY3bviYXwdEFeaS/HUZffEbl9uc5QKO1XjJkpP1c88htdC4Y9XO1myWWuPaeFdN4W7dqr5ltbvI/Kgy6gTn0qFpAJSSQpFKOPoNBIOKVrez5460D4aZN4JRdtsbRF2oKhJHCIX0D4fOCY9i4cblbCKSZT9w8oAeMgTwejwftRKEFx39ifaF2YWTsCiuj+22rCAGhHR/AWEu7kNawgoVhqRMGV4bvnYtSy642sv24FG9U3bPAG+54TYvOHMnegTI794QIsreQn2kJqcdeZR5CxS3A2XtZSg8BrQ6Ry07T1CjUGSaUDzLaUz8FicHZ/E6q/eTQ5pSPX/zaUmHBCWdQmwlAGVDlCeUY81ghU+FKRFmX4S3APd87beTMHwkgGfRZkaFyG8zEAmlcTGS7WJ2cYGGYI3wV97cRtOZEYIk++B8wAszjIh/Lp5H+oF46lNhiNz3PQL/rSeqm6ChIlszPCmVwIhbg4cIc0/CMwn63rw9X6IVL5U/S9Kzzb/KEfzTkCZXpHPrccs/kfswWwAX+U1rbppvkJWNF4FKfJot9+NWdsmt4pmF1TNkjMpGXjaNwRyINILeJf6GDSCILe2QFzEo44MJQF4uMYt9Hf5RVYnexd0rk8JwhpIJoqcdBQ9805352mWHT4UQmmod+6AoyNiDGI8+jrQUTZy1WWI2886iRzynGc4R4NssNDcPFIV630M73njZ+dsoiYTtBqFIyE CsNWP06p zjUlzkJcb0KfP2MavX1WkGQa8LPXzOME6EN/kp/MPIfiyKdo2ewlgmWZecdL3SAOavO4vv2iAJ+RR4tqo+P7NOTE+5vnGuT6lpkBPeW6d/iaVJZTkOvH8KwnuwekcNCYnUw2ZokSVNTcARUmrmcyWq2ydBNXvp8jxQXMdRHql3tasz9+283ec9M/MJmXTqxnZQ9QL5BIBhP2erGkYuK9lRPkF04DBsjqfzYQnqf9a7mj1ix/SZLplUI9dezPrr64BchsgscLa6t0T1EflocMJ5DLWdQ== 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 Wed, 12 Mar 2025 10:51:31 -0400 Peter Xu wrote: > This patch should fix a possible userfaultfd release() hang during > concurrent GUP. > > This problem was initially reported by Dimitris Siakavaras in July 2023 [1] > in a firecracker use case. Firecracker has a separate process handling > page faults remotely, and when the process releases the userfaultfd it can > race with a concurrent GUP from KVM trying to fault in a guest page during > the secondary MMU page fault process. > > A similar problem was reported recently again by Jinjiang Tu in March 2025 > [2], even though the race happened this time with a mlockall() operation, > which does GUP in a similar fashion. > > In 2017, commit 656710a60e36 ("userfaultfd: non-cooperative: closing the > uffd without triggering SIGBUS") was trying to fix this issue. AFAIU, that > fixes well the fault paths but may not work yet for GUP. In GUP, the issue > is NOPAGE will be almost treated the same as "page fault resolved" in > faultin_page(), then the GUP will follow page again, seeing page missing, > and it'll keep going into a live lock situation as reported. > > This change makes core mm return RETRY instead of NOPAGE for both the GUP > and fault paths, proactively releasing the mmap read lock. This should > guarantee the other release thread make progress on taking the write lock > and avoid the live lock even for GUP. > > When at it, rearrange the comments to make sure it's uptodate. It would be good to have a Fixes: target but this bug seems to be so old that a bare cc:stable should be OK?