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 31AE5E74918 for ; Mon, 2 Oct 2023 19:34:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16ACC6B017E; Mon, 2 Oct 2023 15:34:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 119736B017F; Mon, 2 Oct 2023 15:34:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFBF76B0180; Mon, 2 Oct 2023 15:34:15 -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 E00CB6B017E for ; Mon, 2 Oct 2023 15:34:15 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A955BC0421 for ; Mon, 2 Oct 2023 19:34:15 +0000 (UTC) X-FDA: 81301522470.17.8E6E989 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf21.hostedemail.com (Postfix) with ESMTP id E2A4B1C0011 for ; Mon, 2 Oct 2023 19:34:12 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=19yutztI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696275253; 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=4Pz/zszYZyE+z1VL1nxPoO+pF7/bzU2CO2PuRnZJXyI=; b=By0v/NKsrXTApMi5k+xx1cMkHNO2qW8ifgd/Ws5E1Yhw6tIxoSoCacLHN1bGB/9cQ8hEY5 x6flwhTjuSTEVJohOTDvAc8rVdaG1IQoktYr22C6JodYviGowpzfEUyb8LsZehrKkXLrb0 5jdsvLvN7ht3Dx6StRDzVxTSEMJYRZ8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=19yutztI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696275253; a=rsa-sha256; cv=none; b=Qu0SHdx6MuIOiUFyjxzyfHXzptux+cvZ9BC4Q0o/zQDZvTXRJDjCeykHQf4RMhJy68n8UT g4hxtgqFnG6a0D4jXnfMqELhNtplnV4ifCW38OC7dy3mvZuY685F2j9rWLtnRMFAU40J18 /PjI+hRH8pLMbRJuCWlhEbQgd71opSI= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4066692ad35so1332585e9.1 for ; Mon, 02 Oct 2023 12:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696275251; x=1696880051; 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=4Pz/zszYZyE+z1VL1nxPoO+pF7/bzU2CO2PuRnZJXyI=; b=19yutztIUXan23hUkOY/qN6acBANPvz/9SJvXMHBeS8gn9TAu+g8SOG1gfsfQ7dGfC kN9QiO8xYg1Yyx2E9cMYX9aq7tD/XbMr5rnsZR40hTE1Mqpj2Y/oMXc3KUKUrZ5k7QZd dcLsmdajKv7InrYAOdvJNMCi7dOlNGu2WCrKrK8cLX6TY7r+GSvS1AdfePFCya6r8TyW ofw8Bnb8xWEdhXLD0nvha6Bogp79mPhIXLzYYKAd3ppnJn6GZqcIoHRmA1hnDROQLIxi CqMYOy8FDDvD9wIyqGnw5ytQmzG5FZG7yVz96I9k/YEUsyKhlZa4VFjGhd6NXhlM1qyg YGOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696275251; x=1696880051; 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=4Pz/zszYZyE+z1VL1nxPoO+pF7/bzU2CO2PuRnZJXyI=; b=Qa/EoQrYtjcjKTdEiZqnboMwdMbZ9crWbcveKr4PUSBbk/JDD56ntTFXFMU1KmS1qn o+gHJNtH+AYWw5qgXKqQPvOCj8JzBcXyqvsco4oCCGuPSUDr3o33kh6PID63P7xmNWO+ VSa0bHVO9y0xDdwpntCE6zrTyH6bO6PXfAG76r+dlbiRxSgj/G4PwGEHyF5r0ZAyn4GQ mZN72D/liCt+SxDjcnEDRV+jX8I06hhq0YUFYDRbWbraKa68r664qOXbz9af+23aZBpj kDbEPkGEL373oAKUYDwJMeHO/6W4F4MH0/Pw6Qq1uzorAlERzqd+6jerm0c3KYZwXAXd CZSg== X-Gm-Message-State: AOJu0YxFdFUTtcVEBy3mwReKfshgIAhJmT0dkGB35yUPL+LK7NbzZViB /kO4csVBuU6dX+KU+Pjpb6/ZTeMLpUlUDolqXeTDvA== X-Google-Smtp-Source: AGHT+IE/XDcbApgyGi2vWDALA9HVtbtfsl01C0bACjHSTSMxs1si+IYmi0/4MCZOMnKZuuCpOGdPMN+KIKfh0A4NSTs= X-Received: by 2002:a05:6000:184:b0:31f:ea18:6f6b with SMTP id p4-20020a056000018400b0031fea186f6bmr10781947wrx.19.1696275250982; Mon, 02 Oct 2023 12:34:10 -0700 (PDT) MIME-Version: 1.0 References: <20230923013148.1390521-1-surenb@google.com> <20230923013148.1390521-3-surenb@google.com> <03f95e90-82bd-6ee2-7c0d-d4dc5d3e15ee@redhat.com> <98b21e78-a90d-8b54-3659-e9b890be094f@redhat.com> <85e5390c-660c-ef9e-b415-00ee71bc5cbf@redhat.com> <9434ef94-15e8-889c-0c31-3e875060a2f7@redhat.com> In-Reply-To: <9434ef94-15e8-889c-0c31-3e875060a2f7@redhat.com> From: Lokesh Gidra Date: Mon, 2 Oct 2023 20:33:58 +0100 Message-ID: Subject: Re: [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI To: David Hildenbrand Cc: Peter Xu , Jann Horn , Suren Baghdasaryan , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, shuah@kernel.org, aarcange@redhat.com, hughd@google.com, mhocko@suse.com, axelrasmussen@google.com, rppt@kernel.org, willy@infradead.org, Liam.Howlett@oracle.com, zhangpeng362@huawei.com, bgeffon@google.com, kaleshsingh@google.com, ngeoffray@google.com, jdduke@google.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E2A4B1C0011 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: umh3kosy5iz8ym1itdd577d86t3isoss X-HE-Tag: 1696275252-553706 X-HE-Meta: U2FsdGVkX18YLU51CuShchApk4w5/5p9tA6FisAbCeWNlHzxpkO/0tzuj9BVFyMi6s4DPys5nAhJHHEX8Y+9D59CnUYKsldUvW+s2zHs3Y+lZ9oKnD42pr/1gQSF3Bua9H2K3W0OJPSx1B2l41NT8oWw41y4SLBPGv43Dn20Ys0zDINC9iV5oStvE96g6OZlvqB13Jfz8bQqFTmwK+d7bF27tH1eyN43sm/ZC1y8yGXIe2wbT6oCauA0xujQ4Moma0CeyogIOnOquj27qqriQ2Lavh4u29DwUJG9AFR5CD+UHDHY7Ord5Ozt3fo1eiYoR8/6J27QBCfE4zwlR9Q6VWzmsshUfhXkavUOkC27LhcssIuLJ1pocVAVCJXuueg7a5WF5hmk1iVkstivV041uRms2q8cWiGPKPzF3oz3wnIqFKxBmCbTnladV5mf/VxSAo0HQU4GPpKQtNWSteD5u1fZZcA9l46YeCKDFKwm6QHja4+ASJjhlmijv+Kfqzb0tAsSTAHMez8Rqug4wHT2SMo+Ad7YDvsGUNLtT2y6q80aFAdNAAu2ZxtYSs3rRJjl/G0oKUz+ANdz8SPXv0ZR50Mm6dTqCrSnZlN2856X1Y5wid5B0L7qxDuKQExZpeslnoS4Bfk7E911o0L6GrBlGQZ+D4zcW5yneTkTBdy0ReSKSSaOb1ng+tkbDtQe/3/Xu+3Ll1O87oKuTd5/EL7pT4dPgj2aKp1uyCkELt1xTRqYGUx3me364bNRdNz2zdEVTE5ChpdVVrtmhiIaFrDwRccY5qgraaIKgZyg7zkyPFfpmaX0FQmMicFM4V+mjob0TbNdGREWAAVxulcDdWJoX5Cys8mBQRDF4PDZsWivSGV9kLVmB18/RIIOCDZ5SdTRjYvBkep8ZroLHDhcgwGs1wJXicgXRQd5gljbpMPPUhh3RXQlDlnbO46DV90MsicBvXAwdv+1qjEC2M1K2gM ySaUf2nl hXq6c46czRAK24L7X7ovUR+Gh2vLEjWe5WkTY3/xQZqW5+Cik0jo06Rzcpmp0ksdVcreZy5wWfXHrcDAc+6UGlr2U/iP1v783ZTf/8GY7hV67arX2lvLg4RbDkTyOp2cXDMAfEzDz/BnWttkwmDXGYw9543o6nEPQDNdMGe3Xt97/Ccv95xu4mNHtpYt3ul1008mdt+6EjV0Gszk/vGocXxesTERDy1PIVAixxIog7IsJpm84O1lvLVWMZmrhcTVeWQhjniQ16wN+/hbDnMNUh+ashxJDZWS0DI1pv+UuYpTEggzbKQkMHpHQhUdNRmIlQuiQ 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: On Mon, Oct 2, 2023 at 6:43=E2=80=AFPM David Hildenbrand = wrote: > > On 02.10.23 17:55, Lokesh Gidra wrote: > > On Mon, Oct 2, 2023 at 4:46=E2=80=AFPM Lokesh Gidra wrote: > >> > >> On Mon, Oct 2, 2023 at 4:21=E2=80=AFPM Peter Xu wr= ote: > >>> > >>> On Mon, Oct 02, 2023 at 10:00:03AM +0200, David Hildenbrand wrote: > >>>> In case we cannot simply remap the page, the fallback sequence (from= the > >>>> cover letter) would be triggered. > >>>> > >>>> 1) UFFDIO_COPY > >>>> 2) MADV_DONTNEED > >>>> > >>>> So we would just handle the operation internally without a fallback. > >>> > >>> Note that I think there will be a slight difference on whole remap > >>> atomicity, on what happens if the page is modified after UFFDIO_COPY = but > >>> before DONTNEED. > >>> > >>> UFFDIO_REMAP guarantees full atomicity when moving the page, IOW, thr= eads > >>> can be updating the pages when ioctl(UFFDIO_REMAP), data won't get lo= st > >>> during movement, and it will generate a missing event after moved, wi= th > >>> latest data showing up on dest. > >>> > >>> I'm not sure that means such a fallback is a problem, Suren may know > >>> better with the use case. > >> > >> Although there is no problem in using fallback with our use case but > >> as a user of userfaultfd, I'd suggest leaving it to the developer. > >> Failing with appropriate errno makes more sense. If handled in the > >> kernel, then the user may assume at the end of the operation that the > >> src vma is completely unmapped. And if not correctness issues, it > >> could lead to memory leaks. > > > > I meant that in addition to the possibility of correctness issues due > > to lack of atomicity, it could also lead to memory leaks, as the user > > may assume that src vma is empty post-operation. IMHO, it's better to > > fail with errno so that the user would fix the code with necessary > > changes (like using DONTFORK, if forking). > > Leaving the atomicity discussion out because I think this can just be > handled (e.g., the src_vma would always be empty post-operation): > > It might not necessarily be a good idea to only expose micro-operations > to user space. If the user-space fallback will almost always be > "UFFDIO_COPY+MADV_DONTNEED", then clearly the logical operation > performed is moving data, ideally with zero-copy. > IMHO, such a fallback will be useful only if it's possible that only some pages in the src vma fail due to this. But even then it would be really useful to have a flag maybe like UFFDIO_REMAP_FALLBACK_COPY to control if the user wants the fallback or not. OTOH, if this is something that can be detected for the entire src vma, then failing with errno is more appropriate. Given that the patch is already quite complicated, I humbly suggest leaving the fallback for now as a TODO. > [as said as reply to Peter, one could still have magic flags for users > that really want to detect when zero-copy is impossible] > > With a logical MOVE API users like compaction [as given in the cover > letter], not every such user has to eventually implement fallback paths. > > But just my 2 cents, the UFFDIO_REMAP users probably can share what the > exact use cases are and if fallbacks are required at all or if no-KSM + > DONTFORK just does the trick. > > -- > Cheers, > > David / dhildenb >