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 1C07FC369C2 for ; Fri, 25 Apr 2025 15:55:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E54C6B0005; Fri, 25 Apr 2025 11:55:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 292C56B0007; Fri, 25 Apr 2025 11:55:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15D246B0008; Fri, 25 Apr 2025 11:55:26 -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 EF3166B0005 for ; Fri, 25 Apr 2025 11:55:25 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 04CD2C1A87 for ; Fri, 25 Apr 2025 15:55:25 +0000 (UTC) X-FDA: 83373015852.09.31C56EC Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf03.hostedemail.com (Postfix) with ESMTP id 1FF7920005 for ; Fri, 25 Apr 2025 15:55:23 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sK13+NEW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745596524; a=rsa-sha256; cv=none; b=77z/igLTUmneWzQkf91U50mBKKKVv8aPGLqNDoukQzBvbdaVn5Dwj0OYLxAV0UlbN/WCN4 HhlVIMs5Cu4Eu5b8RIPyB2c6tj5zvJ7ZpAWRQ/9XnZ3rFYzYNR7mxNsAQdmBtWGJUNdwez yJ3Cv13AMT9Zg6bk+q69osv0ty5LRl0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sK13+NEW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.171 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=1745596524; 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=equNRy2Ut79NJN2sDP6xqBGeq0YSptRz7fSGMn5os4g=; b=Q3/2XjGiWXkL+pRQPw0X0L/Dua0al8C8PR1yyvyG3VBi4cDUbqXkikKpzJNiKOtuKuz09d CO+1m0xUIEKY0HvmxkYyP3AXbBEsKncJZR7Eeo6Y2qnwqnw7VOKkFPfAFof0uXGS3dz1Wn 5Sk912+PvzZ6Uz9W3i0HnbepZm7dKcM= Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-e72cc45d99cso2395308276.3 for ; Fri, 25 Apr 2025 08:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745596523; x=1746201323; 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=equNRy2Ut79NJN2sDP6xqBGeq0YSptRz7fSGMn5os4g=; b=sK13+NEWw3ile1EjkKXcXsIgMRkUVDzrK32M+Gw3RN3WpLkEiBD8ODTfa2te39RWpC sl3mKLXfsbXDbnmoxLWg3/BHNyjPKlj8QMEdNwfsEdXICq2KU/MkPu/1EL7sOE2k1M2I mXXE01XnoLlCctM7iqYL+zKQufzqnaNqq8dMZ12mYhqqaMkYHOiv7iq/SRy2cCVDJj1d GJww8bmu1YHyHdOUG5ohQMbY7voGK2AEUUE/oiabayPlJ8qDggkwKGlRzUUGIu4gvNyM nSS0bNe4i0iARr5NjMIPoRT+l1hg+9igf7pnony9bLucnUGl/KZWhRRPCkhRAZa2PohM Hgyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745596523; x=1746201323; 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=equNRy2Ut79NJN2sDP6xqBGeq0YSptRz7fSGMn5os4g=; b=nWG2pAJWiQWKTuB4ECgZ5qv8dHkuAqIpNZyPrBGnSwa1OIo14EbFu8anBuPS2IL7vT jaE2tPd4sqZKyVhVLd74KAX7HdJX5BbRqDYPD6ecZRyizWdsooC02/PkuXRUeatT2gfj sSFH4DCE79JTXjc8ioyETtz90MKI7UfucYn15GiKU7RCSKGjipf4n6xAp2JCaITV3jqv R42zMwh9MgRBOn+8Y5z8U9WN3M1e3EDegxq+ILSTFCZrY2OIzo5JBLFfxl+mXH7FVzl4 12xqGImz3wwfO65kbgMUnoj6tU1I4kipbMiRt4U2lxyqLI+N/6TY7QP4SrjEFX65aQ+I 6jjQ== X-Forwarded-Encrypted: i=1; AJvYcCXOR1z7RrhLdEz+k/edVNSwOZKkgCGQTvfKg/x4oUnlqFjEMY0wtx+j6OoJQg7F6a1zHDITtKWlbA==@kvack.org X-Gm-Message-State: AOJu0YwEu0+bSuICZMwRoa4ZLaSrnoAbilPLYdPFYJTrtT9u3XFgJJ69 oPuIMS10qj+uEQ6291yVl40pk4huuk3DH3u/iF8Wpbkp0ymQbsjF+/am31XH0788xP5fEY3ZDzg QSF44R4Ny7Wqyqn/T1TujIr7byVDQQVISr+D1 X-Gm-Gg: ASbGncul43ypsDJsvC9HydvGuvTsTGG1MhVqNSSjNtKDHLF3Svlq11FDs593YJSbhc9 5O0zlaLM8h1q6KrGxx42G8h6pUyrH/4SY1gPAM0P4Pih8ZXAaMtz/63tdgepyLNTkuBKug18Rmm aaffcWAXjGcXlyK/lYz7LfQ5a6+OJZ4uh90H5gTUcAu/jG8j+ZrlaNxMvg8yzP/cmqbu0= X-Google-Smtp-Source: AGHT+IFbSWFLOzO0de+Qmq+o8sPNVbjGnv8OZRwULddVfXenpCOwJ+oWDAqKSNBbQKWyy3jfg7lS46FR84wKLdfsvy8= X-Received: by 2002:a05:6902:1ac3:b0:e70:a69b:8c64 with SMTP id 3f1490d57ef6-e73168d2ee6mr3698647276.37.1745596522988; Fri, 25 Apr 2025 08:55:22 -0700 (PDT) MIME-Version: 1.0 References: <20250424215729.194656-1-peterx@redhat.com> <20250424215729.194656-2-peterx@redhat.com> <23e2d207-58ac-49d3-b93e-4105a0624f9d@redhat.com> In-Reply-To: <23e2d207-58ac-49d3-b93e-4105a0624f9d@redhat.com> From: James Houghton Date: Fri, 25 Apr 2025 11:54:47 -0400 X-Gm-Features: ATxdqUGMo1N6HL1wdN1Fca0HJC6TdmBNw41BQzP939UVRxX0ow9CTuSFoGXA_uo Message-ID: Subject: Re: [PATCH 1/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 , linux-stable , Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1FF7920005 X-Stat-Signature: fdte4oxfmu5ob8oskwy9fehuxpx93aiw X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1745596523-928990 X-HE-Meta: U2FsdGVkX1/ZmgQZBSx5/qRpuDlh0LSHRaD6PL/z2bI3+JWi4NBCwgyj1udYwZ0qGgJO7T/d/1rPjgJ4oJU/7uc09R9xLqIODeT4QjmGnjiaEc6D4/Ansuqrcgseh7ZDcmYTTldRgpHJvwwIUQM+IyLWNQW+s4w4BYiRMPn7YBDsxhXtN0QESO++9cuMLu85MpZ2SfTGxlWM/kmM8tRLHZuOfgIQWN+2iXznfZbkLcTxax4Bsfr1yIYzGaTxojSzRxjj1hVfAKhgCJoCig9ZxUx8JOrh/do8V6iN8ucnexpZujWt/bxmpz/eRAZ/lqL9xN6VpHabmWbWaJmHJK/GxwYAjyD8sBlXGyVWXNov01Ovjt0lne7bLWtFsbALcnPs/M2NqDbwt3+4ee5o9gRdcYoG9VytGFsgzNBLbE+mVnu6Ei7chFOVRRI07zUdne73lOb1a4ZDe4WtEb5wgZkMUdlCnlfENsT8xBpQnTLobYNQ6Fe0ApLxCxUenuoAxUAggz9lmJ4kfCnomygirOh1SLCNzf/7B7AdYALPv0/FLuvB7hxWy9yxwQa2wDEIDuNA1BfhfRuQCc92EM1IID0tdIq7+cG/mrazWehvoTl2couwJOP8d/NP5pcw1P+6xOndf9h/yjFnM3Rg6ZRNKxJxyhjCyeA2/PYpHD7IMHlta5XVaUTEHJCJ0JC//JijD0ViQHTpfVidqIA/qq4AIUmQnEWJY/6W2QX/TooW5E/TGw9GWBg8zVQQB9SzbE95Pf7Qx+J4eH6h0nwLzFM3fpPMYTdmpeMMahfOyJ3mQGo3BxPiG7Sx44efTYyYSJNvD5dxHMGg/iNrHBGyMe+xaB8CEmYeXOSQTgRxeuqx6qjl+eKv4rE9Outb9/fwUhOOpTtEC8U+mjP5jZIi0bpy7u6k9DpBwqboykxRGaEcf/FCA/P7p/o4NlgukThzMC+JoN+XVo60T/xRyo7CdRzPA0N cRzG8Nc3 bQRimOcog8TccCpoTz/2oP66zYn291Inatl/sj8l+nbDJ0acObsMS5klNQyyD3Lejx1uRO1GuvUNuqMkOUSz/qPAiQr3aygmkL2C9brFNiTUNxayay9cuijShaAgeydnG1K5DtATIi5wwEUlPL1iEUD4j+ArC/uO0yFycZgvrDVtzUd/Q66sSiqnPGRSYKLHM9rbXRKnzBItNOKdbgGqCnTKaewkcZfkItGSHk0K80oEvvHOqrXTTPtnF1Uo1S29631k8Ot51+jjgkto= 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:12=E2=80=AFAM David Hildenbrand wrote: > > On 24.04.25 23:57, Peter Xu wrote: > > While discussing some userfaultfd relevant issues recently, Andrea noti= ced > > a potential ABI breakage with -EAGAIN on almost all userfaultfd ioctl()= s. > > I guess we talk about e.g., "man UFFDIO_COPY" documentation: > > "The copy field is used by the kernel to return the number of bytes that > was actually copied, or an error (a negated errno-style value). The > copy field is output-only; it is not read by the UFFDIO_COPY operation." > > I assume -EINVAL/-ESRCH/-EFAULT are excluded from that rule, because > there is no sense in user-space trying again on these errors either way. > Well, there are cases where we would store -EFAULT, when we receive it > from mfill_atomic_copy(). > > So if we store -EAGAIN to copy.copy it says "we didn't copy anything". > (probably just storing 0 would have been better, but I am sure there was > a reason to indicate negative errors in addition to returning an error) IMHO, it makes more sense to store 0 than -EAGAIN (at least it will mean that my userspace[1] won't break). Userspace will need to know from where to restart the ioctl, and if we put -EAGAIN in `mapped`/`copy`/etc., userspace will need to know that -EAGAIN actually means 0 anyway. [1]: https://lore.kernel.org/linux-mm/CADrL8HXuZkX0CP6apHLw0A0Ax4b4a+-=3DXE= t0dH5mAKiN7hBv3w@mail.gmail.com/