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 65A55C369C2 for ; Fri, 25 Apr 2025 16:08:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 303E36B0005; Fri, 25 Apr 2025 12:08:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B2466B0007; Fri, 25 Apr 2025 12:08:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17B696B0008; Fri, 25 Apr 2025 12:08:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E95246B0005 for ; Fri, 25 Apr 2025 12:08:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8C700C752E for ; Fri, 25 Apr 2025 16:08:10 +0000 (UTC) X-FDA: 83373047940.03.A085A85 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf03.hostedemail.com (Postfix) with ESMTP id ACC1320016 for ; Fri, 25 Apr 2025 16:08:08 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WPwlJlPU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745597288; a=rsa-sha256; cv=none; b=SLb+rTN6c3HJiU8ZJhrPpx7Hu8Z1GL08PYPn4OpVCl8vY+onkt8HXcFvOe8qfPlPBkGlY+ fpsSw+tifhM+lC++g262keurAuU2qqA6oMqKq8N856lXvkIUYcaaBiWCq1NVdKRmg7w1Ke cpCJkLgc1BJ7FktFyP+YjhY/7rsLg8M= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WPwlJlPU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745597288; 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=uhtHm5TJ7Sf0WfPuEXwkbJxFSOzkS7Oo48FDFS+N83o=; b=WtubZS+ytuxvXXvWBdxcUOJvgp/BjVdjx+Q4A7hd2zP+qIhaPGncMJhruvxUiG+ltXU+X5 C4yi6iaDGJxRKRhv6JmylN5BQwiE5dp0LlGh5ziESneX3RTdVSVHm9djLqKq1l0E5oqvVh TYdXE+Cr3pvJzUsu2b8yt2Y1D4qYrBg= Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-e6dea30465aso2114402276.1 for ; Fri, 25 Apr 2025 09:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745597288; x=1746202088; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uhtHm5TJ7Sf0WfPuEXwkbJxFSOzkS7Oo48FDFS+N83o=; b=WPwlJlPUwCvrA1Xtf68UrqfEPwdfB8ZnBh+cgKAbGEYmvI5WLo7OMQPWS7sDyvPTT/ UGe6ai949O5kJ7iWDnLBamQreC2okJXbsTFALdcDj1i0By4JV6+mFl/nr0ZuO62wOy7G u7z8iHQ1cz7mBEOozq0FPDwPqrukPhfUDuITugz9E2buPJgHmQnzoQ6sfEbxi91sQtie KEHqbO3FsJNTk3AjllqccHf9CCe05C7ZSdnoJPinFuPz9N/WE5TVkIBfLKLeprODoAlm flVnlq/6RH21ojZ9JS3zWfXhc/iMcyZM2eP5c9ST5G8m8l66DAyPb/v5goB2Kiq64egb qGjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745597288; x=1746202088; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uhtHm5TJ7Sf0WfPuEXwkbJxFSOzkS7Oo48FDFS+N83o=; b=VD448Aq6My6F1Lsq2bnqasZd3/ywp6bPDcRfmE7DH03sUD/FsiZNeu4qAk+cHjMHyQ FBo0NBerdHk03olV+ijEo5FxTtSWX8xr2xTvfsbx2Yl2ylI4dzDAzJW1/Obc9qPeof0S l6LRXbW3w0Ogjhf4zXlIjnkrzBCiaidJnygixnGbqJ06l0RsVI/k6jXcpZUJ8dX7lZSt 86YKP7o3BZkxpgaT0SKvxYAtQX3YJRDFwkuTvYjKGNigJv1BDEGbUGOvwdsS0qU7kXja i/ASajQesPdOxGhpb0Edv00sqndoue98fL9VL6sBnw6xCWog7jdzLfhbiFl1Owa5JwOd sHPA== X-Forwarded-Encrypted: i=1; AJvYcCWFVIz6jJkQls8uDXDcSRkC3ZL+S0GlM7Q+5kRNiS5VhQwZyeaXYL5B3aa4fT6JS0X1ufXNKepLzA==@kvack.org X-Gm-Message-State: AOJu0Yw8F2qvTOe6znT51mhWi3hr8MBHJCKc6hf9E9bDeBLiYSwwucet Ea2DR+328wHyyfKI5Y6+Lf306OhDyFTQPbi1jW7hPeWJ8AwRDDPYCBTOsXB234fr2Q5JyRxFZzZ AWm87nS3samEEIRcSVwuGNhKsN1U9mJUhAt2d X-Gm-Gg: ASbGncuzB6HvIZLnnBy4Mwh8l5q4enRcR1woICIIj63uZ3w0TkzNDF+THMEtK5qQO3M 6IkqRitUbKwif3Cs5M9DSu2JgBw5FNGHZSupyjDYd9fHhQ1lFvw/xSoIMJOBVMiQiFHQ3kVDNhE /Qs/EDAwPDl4+JXKMDAkmPvU0b+FVE3gTQQDi7cohprdWX1zkT7yee7Ly5 X-Google-Smtp-Source: AGHT+IEatrbWqjCHU8cjshAn8KWTbq6dL1hiJ3EiouEz0VgKtWX+noIp6HQyBBmsFL4VoX2ccj6KPu1mnwPRs4oW83I= X-Received: by 2002:a05:6902:2084:b0:e6d:f1b6:f696 with SMTP id 3f1490d57ef6-e73165bf781mr3624687276.11.1745597287592; Fri, 25 Apr 2025 09:08:07 -0700 (PDT) MIME-Version: 1.0 References: <20250424215729.194656-1-peterx@redhat.com> In-Reply-To: From: James Houghton Date: Fri, 25 Apr 2025 12:07:31 -0400 X-Gm-Features: ATxdqUHADNxLtMHz3cAEkG3rEGMR6V7j-etzi4jHK5PVzArCZtZsDkvCN62uy6E Message-ID: Subject: Re: [PATCH 0/2] mm/userfaultfd: Fix uninitialized output field for -EAGAIN race To: David Hildenbrand Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , Suren Baghdasaryan , Axel Rasmussen , Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: ACC1320016 X-Stat-Signature: t4gun9jb6u1rh73ghgcdju45r91n3o81 X-HE-Tag: 1745597288-913203 X-HE-Meta: U2FsdGVkX182B/60vZLc3LIKO+XzU9J+mNB7g55jpReF0ejqy5c/dVR8S4uhtk0uPUa3Jmy1k6urI/kTNmWWkSiUo/7Q2W2PmDMyis0q+AtwgO4MIyy/Iz2fvwpsw4T8pJBKe6qd1fpu82MAoGSrcxc6964F1VhyFC8xPyp9wqba59fbcURXUAQJDOQXevwq7q0zL1Z5MVAsZO7C38n7GeXG79iRFL43mgk39H3UYErcybR/ycoP7l43G8/cGVYmbiOBdn06WeJYwgVODRWmSQ79nBjgV9FtSwylRS2LzQ9ZKtBlZC4i5KE9WBNFCU5TUn1C20VWym3TNEg61ANRV7qn+Tm0C+d4F5yrPgicogYlIIg7VyELt7zWdzStVoX+crlWlCEOznVpQgoDQj7caGNYCt1ckyXUq1LSUvo4qy59x88kBB0wgvVp/sH2Hr34H0YSopih5+5v7x9vWXSIf/kFrKoZVWDY6ti+aw68gh4sFEDjrlBk2msCmjyWEAXYK1N/k9hsAtkskbN3V3ejNdzUHvoqvyORUYhvyWQKzJ+BYeO3K+udYK9OW5A7gW2OIMc3GV9aOAtmrJlnW+f3fQaaeSIKwljsqPh/5yzH9EcGlIimYDxzyF3AnwNQznEb7RmUrlTYy17ZxgP1QrgYGyI4GX5THQTPbF4J6izePn8jYVeZiIvgRkeoCX/UrNoKlRMcqgl6OeN1ubDY6ZaP3Z8w9/2XgrfepuDzkwn/OutM+cw5wNy/vGu4ml8q0iwQsjBIo3+mjeEgZgqX6Uv1m/df+v+wsmFfmm5n6MnlZog0MlSfI6Mno/cuZ1dyqjJInRglti7N2M3iMvI+jhnYZIaiiGXU8b5hLH+nHlBllDoXAJyGUKWm6KY1KAtw1igZZ6CGJw1YrQJWfqULq1enu+KdqQxwnq86gPnQudyO6KIy1byo0N6T4815BeP7bbF8MVgmsf8C/MVdfezr6Pf iO9E/Fgu UekTcArWLZhW01WVDaHKGvG7ODItgz/X5uPeIKpoek3NH1Z9aL+CW3IPsxuI0tbYDNmme1fhpDMVaYpyRZXy/Lbp/tpu8WOKrZUTryfoZsqhBse5ma7AgbeztKj6vaneo9HYX8Xlj+03apbWlBCwD1vr2dD1ph7sfl0LXkJq2MSwbosOkGdFEovnVyOJHPyfSZhyD/I3jBBWd8fFgal9i7xXtIg== 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 Fri, Apr 25, 2025 at 11:58=E2=80=AFAM David Hildenbrand wrote: > > On 25.04.25 17:45, James Houghton wrote: > > On Thu, Apr 24, 2025 at 5:57=E2=80=AFPM Peter Xu wr= ote: > >> > >> When discussing some userfaultfd issues with Andrea, Andrea pointed ou= t an > >> ABI issue with userfaultfd that existed for years. Luckily the issue > >> should only be a very corner case one, and the fix (even if changing t= he > >> kernel ABI) should only be in the good way, IOW there should have no r= isk > >> breaking any userapp but only fixing. > > > > FWIW, my userspace basically looks like this: > > > > struct uffdio_continue uffdio_continue; > > int64_t target_len =3D /* whatever */; > > int64_t bytes_mapped =3D 0; > > int ioctl_ret; > > do { > > uffdio_continue.range =3D /* whatever */; > > uffdio_continue.mapped =3D 0; > > ioctl_ret =3D ioctl(uffd, UFFDIO_CONTINUE, &uffdio_continue); > > if (uffdio_continue.mapped < 0) { break; } > > bytes_mapped +=3D uffdio_continue.mapped; > > } while (bytes_mapped < target_len && errno =3D=3D EAGAIN); > > > > I think your patch would indeed break this. (Perhaps I shouldn't be > > reading from `mapped` without first checking that errno =3D=3D EAGAIN.) > > > > Well, that's what I would say, except in practice I never actually hit > > the mmap_changing case while invoking UFFDIO_CONTINUE. :) > > Hm, but what if mfill_atomic_continue() would already return -EAGAIN > when checking mmap_changing etc? > > Wouldn't code already run into an issue there? Ah, thanks David. You're right, my code is already broken! :( So given that we already have a case where -EAGAIN is put in the output field, I change my mind, let's keep putting -EAGAIN in the output field, and I'll go fix my code.