From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pz2-f1.google.com (mail-pz2-f1.google.com [74.125.228.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FC851B4138 for ; Sun, 16 Aug 2026 15:58:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786895899; cv=none; b=ZOofQUtwLeN1c2pJdiYadD56ZKvpPF4AlcVsxo74thoFlkKxVRq9e8gWN0Nj2unFtemSOKdtcO1naCFiRPqiKxTixYbZfOFMytbP5zkOMKfUm9Tj9RhvoYZk/OBnyqwhElc8fPPJKodjsgTnZ5nTnTVloHQLhP9FIp0eN522Rzw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786895899; c=relaxed/simple; bh=+l2noRp6tYzsjhaBYgPr82idnlieKF+cJTuG63G350o=; h=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=NMUBzON25MS6tIx+PK/KqDtlpGERcC28ae/sqP7zltv7ftAQzVT4jwoHAq1RbY54RUBAnHNNPlFvr9SXzlUorfrG1FvHi2CHu1yszLVdBH2xPD3jk6fSwk2IpQzG4GWeDAf80/omgERqt/FIg710dVNbnMwOe1m5e6LIpDWYfyE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CWa5sDIF; arc=none smtp.client-ip=74.125.228.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CWa5sDIF" Received: by mail-pz2-f1.google.com with SMTP id 41be03b00d2f7-ca7d1dc4554so708448a12.1 for ; Sun, 16 Aug 2026 08:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786895897; x=1787500697; darn=vger.kernel.org; h=content-type:mime-version:references:message-id:in-reply-to:subject :cc:to:date:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LR0TtAas/eFnB61nrylzS+NbRXuds/iGjGALOg9xS1U=; b=CWa5sDIF1aX1DJOD57lEY1qfE/3mgpt2t60HQ56rikXFxwTDM9UDmdj5CxbZ3x0ivC PJVeuNO1JMar7v4jNyCYegxWuJaTm9F4SfvzF06Le/m0EYTymPWkVf8cThAoVdrEu6xF QD1PpVgths6D6Jm1EQ0Uo1HS7G7O2vthrOvnczIgu/irO3DbKd82hhjuuakjTta7dkQs kpjDbi6MFtUr7Ern65Pce8vqPT4m9n1bs8Yi/48yslr6FIO4SE2b9OMlAyjfIbMQk4Ds CCJiDuOsLYXlcbgv9jJWk4L8H4szKXaYUoCFds8QBE/cKikg3LEtVEj+4pud+VSelEuz KUBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786895897; x=1787500697; h=content-type:mime-version:references:message-id:in-reply-to:subject :cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LR0TtAas/eFnB61nrylzS+NbRXuds/iGjGALOg9xS1U=; b=cW0bMmRYiScc+mgYwj4UYyCbZ22I5s6cAFcRcpX4TDnSOy8f50dW0B1ARn36YMJ1Rd sMDNLB7UF7tjQ91eqnfhPHpVR7L5fE9eLjgk+W/VX4Jg7PY5f3T924jl0KqMfVbTwbqF 2yZ0PAxBoynclQHvNZ59kLPn/9Pi5BSxrArGhLzzRxSeY9R+SQ0NM3A65L2dkzXf5gp9 g+nXXIgaZ6KwvOGTeTg1htJ4qgu9kHVtJua1AxIkkzSIYzJ+j0cbt3PygfJgOJAflbGd uEaWvNaeoEB41eszJvgoRF4TBtxJU6k95quUomDMrrHw0e1LAZKmBc4g+m6qcl9sfeBN fLWA== X-Forwarded-Encrypted: i=1; AHgh+RqjDKztfkHXPLHEMT9pWIWIRbryb14U+0IntFFNhlcbF4nuHRTqdffSg9CwDcosdERX090l8XGYw0ec9Vw=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+GY2whcyM6IswD8k2y2cuuK6Mhz6x8ea40Ms5p7R18IlEYIOE ju0pw/k5ilgrdhWnGugNARmR66yB8QfzQk+VutDFvkMksuy8/f6DAE3y X-Gm-Gg: AR+sD13c4Tx7N8ZTSrTVXsX0wSEjQj1SvsvZCOFH4JE3T10WD2YlOvnYJbsgpqMcft2 G3eez7LHbZH/JhSQbQlpbvGoRJJegaYHKDvAuKt/Q3OSO27cILLl0Lfd6X47DuR/5pAFp61tS9j S0qNNXs5ok0GW4iRYbVU7NnprO3J6rJj7qm9j+LBH99T9xrzUQGSjgBbdD4aUiKnCqx5b8KJqvY BysIh2Lo+hus7IM15GNWjQ481gfHKpxiDouTnhxWGFV+oShIKVRvvvWa/t6VjAKGkgY5VyaDE3Q JuPaQno5SfIYUk3dvovvSiUB2e6PDRu/lxhlswdnjxOzyajFTVDQSw+zUR+5kYfIdWLXNUqSBRW FTHfgAu2sn9a5mv/A1xuZfgt4xSTGDWyS4BADoX7/DReEah9X7VEJMeEghdsXxvfD9uuNSb2P5+ WBoUc3/gqj4/E4lqSqT5W4PoXRxjtzhoC4zAS0sZXDEBY0SzIJu+9+ X-Received: by 2002:a05:6a20:3ca3:b0:3bf:9142:ba3a with SMTP id adf61e73a8af0-3cc71d27285mr22710312637.26.1786895897321; Sun, 16 Aug 2026 08:58:17 -0700 (PDT) Received: from 192.168.1.2 ([157.85.198.7]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-320d61e1568sm26721326eec.11.2026.08.16.08.58.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 08:58:16 -0700 (PDT) From: Foxie Flakey X-Google-Original-From: Foxie Flakey Date: Sun, 16 Aug 2026 22:58:13 +0700 (WIB) To: Suren Baghdasaryan cc: Mike Rapoport , akpm@linux-foundation.org, peterx@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] userfaultfd: reset err to be 0 when move_pages_ptes succeeded In-Reply-To: Message-ID: References: <9c936a9f-ed27-e510-872f-5b3b8c680975@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1371841975-1786895896=:23962" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1371841975-1786895896=:23962 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Sun, 16 Aug 2026, Suren Baghdasaryan wrote: > On Sun, Aug 16, 2026 at 2:15 AM Mike Rapoport wrote: > > > > (adding Suren) > > Thanks Mike! > > > > > On Sat, Aug 15, 2026 at 05:42:12PM +0700, Foxie Flakey wrote: > > > > > > An fix for edge case can occur if move_pages_ptes return -EAGAIN, later > > > when checked and it is EAGAIN, outer loop would retry again on same page > > > and succeeded but the err isn't reset so the outer loop would think need > > > to retry again so it goes back again and move pages again. On third attempt > > > move_pages_ptes will fail because it already moved and returns an error > > > that is not EAGAIN when outer loop checks again it sees non EAGAIN so it > > > dont retry and break out of loop. When loop is terminated it did not update > > > the "moved" variable from successful 2nd iteration. > > > > > > That behaviour manifested into this at userspace > > > > > > Source: [ .. unmapped .. ][ .. mapped ..] > > > Destination: [ .. mapped .. ][ .. unmapped ..] > > > ^ ^ > > > \ Kernel moved this far in actuality > > > What is reported to userspace on struct > > > uffdio_move's move field > > > > > > When the previous behaviour is > > > Source: [ .. unmapped .. ][ .. mapped ..] > > > Destination: [ .. mapped .. ][ .. unmapped ..] > > > ^ > > > Reported to user space via uffdio_move's > > > move field > > This description left me scratching my head. If I understand the > problem correctly, the issue is that the err is not cleared after we > decided that we need to retry. If so, how about a simpler explanation: Sorry for the bad explanation, but that is correct. To repeat again to make sure I understood correct, move_pages() wrongfully retries to move again due stale err. > During move_pages() operation, when move_pages_ptes() returns EAGAIN, > the error code is not cleared even after we processed it. This leads > to a successful retry but then the same pages are retried again due to > the stale error code. This time move fails because pages are already > moved, loop is terminated and move_pages() reports a failure. > Clear the error code once we processes EAGAIN. Thank you, I'll update in v2. I'm waiting for answer from Mike whether Foxie Flakey is fine in Signed-off-by so I don't create too many revisions when I can combine feedbacks into one. > > > > > > Fixes: 50944692052b ("userfaultfd: opportunistic TLB-flush batching for present pages in MOVE") > > > Signed-off-by: Foxie Flakey > > > > Is Foxie Flakey your real name? > > Signed-off-by should be using a known identity (sorry, no anonymous contributions.) > > > > > --- > > > mm/userfaultfd.c | 6 ++++-- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > > > index c3adedaaf7d5..595e7e232f90 100644 > > > --- a/mm/userfaultfd.c > > > +++ b/mm/userfaultfd.c > > > @@ -2069,10 +2069,12 @@ static ssize_t move_pages(struct userfaultfd_ctx *ctx, unsigned long dst_start, > > > ret = move_pages_ptes(mm, dst_pmd, src_pmd, > > > dst_vma, src_vma, dst_addr, > > > src_addr, src_end - src_addr, mode); > > > - if (ret < 0) > > > + if (ret < 0) { > > > err = ret; > > > - else > > > + } else { > > > + err = 0; > > > step_size = ret; > > > + } > > This fix is wrong. It resets the err before we process it and > determine that a retry is needed. > A proper fix is to reset it later here: > > if (err) { > - if (err == -EAGAIN) > + if (err == -EAGAIN) { > + err = 0; > continue; > + } > break; > } I see, that one make more sense after thinking about it that retry should clear err before retrying. > > > } > > > > > > cond_resched(); > > > > > > base-commit: 62cc90241548d5570ee68e01aaba6506964e9811 > > > -- > > > 2.55.0 > > > > > > > -- > > Sincerely yours, > > Mike. > --0-1371841975-1786895896=:23962--