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 E7824C54ED1 for ; Fri, 23 May 2025 20:32:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51BE96B0089; Fri, 23 May 2025 16:32:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CC146B00A3; Fri, 23 May 2025 16:32:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E34B6B00A4; Fri, 23 May 2025 16:32:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1CC6E6B0089 for ; Fri, 23 May 2025 16:32:51 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 83453160F09 for ; Fri, 23 May 2025 20:32:50 +0000 (UTC) X-FDA: 83475321300.18.85378C3 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf11.hostedemail.com (Postfix) with ESMTP id A71C54000D for ; Fri, 23 May 2025 20:32:48 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="K8v/XLqQ"; spf=pass (imf11.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748032368; 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=2pMiDeMVs0fzVOomIpahcrje2YzoGJzAVTfniCnIw70=; b=D7+B2fIalyKZQC+WPto+GMpYFYfGu6xKI5d1+7/OCVVRVFnhkHf2yB66VOIUw4VYA0OkWR l96yFH/iWM9M1LJyS9f6X9dcZLRIfTlblJWgyu/0a7TnyneEjqkpA9VmhCiJXK6eeB2NFc XB8tGLnm890Truo2enIR8TLEz6jy2fw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="K8v/XLqQ"; spf=pass (imf11.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748032368; a=rsa-sha256; cv=none; b=YbmErjEJvHehGUJKXfLlmUzWv0xg6l2bH7PGtpquB/dRnmwsNClptIiXuqUujgkf9sYo97 U20GRRz/PFLi2M5qNuNjbYOpD0tVQF6vkBqM5XsxcKQqIlJ633U15i7ZapBOzalbPJsM8T IawxVzs6gJcJ0y2gpTakCyD1x5vrgo8= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-48b7747f881so18191cf.1 for ; Fri, 23 May 2025 13:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1748032368; x=1748637168; 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=2pMiDeMVs0fzVOomIpahcrje2YzoGJzAVTfniCnIw70=; b=K8v/XLqQbEW8VVNftuL6x2iIoYmlnSRY/ob62uv73nvyLjqmoDwUN2unpEMsrORHxQ LW+FFd2c/ynByJAO/9+LnuydDARC6ktZVt65naUw3mB0Cno8KtmKwurR7zZbXD0oVNVO xzZYBs5k9HLK+g3Ay6DEdCp+a/nidopBS224MHTtjLkOgY1RRn2nVDPgpZK3NhSznIaT wApw7R5VCfIEca7BsCZTZJ2Fp+Uk6tL+tr+TkKvB5tU4G3du00oFOOdnt0OF53ONSe6a dPiyC8+0Z3rtYpSMOFlDZ4/mu+y01Bk11fpkVfk9CjAyWktCDIq6Csjq1pwTi+egzhzO X6mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748032368; x=1748637168; 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=2pMiDeMVs0fzVOomIpahcrje2YzoGJzAVTfniCnIw70=; b=OW+Zgdv+/3SdkFvDmxTcZ9Dgy/m9SvZq8JzcqFzsc6kBP4as9PMIrmqK9xuXCfIKIe 8hVOmfKifPsWv0S3v0FNR4WfJk5Fk+TCRhxc5DW2fXA66go5ReNgdxHznE2vXDDV4bnw 36KVugtgW7hY8oF6DfuhfSRDAtglxashLwznCbUDzCWub6AWago+IAsNFkrTBq5jwe1M zmTTaGEdXsA9AEOt7FGsJUuwYSqB+k7Hk+xozmaYmtxi4Jp3TUCxm9JnpehsWRGnqUPz biV6hnavbEkXse6lXAvCtcvguYJy2o+eyFY2KA14Co75ZpEyb3JDpYyDBTI+zoYILgEz FRUw== X-Forwarded-Encrypted: i=1; AJvYcCVqOmlSzOxZyHU7Qz9w++jRMh1YxiCl2BZboSUU49ygOvDKP+RBOQpTWCwUroYhcR/LQ3Z4RbR9TA==@kvack.org X-Gm-Message-State: AOJu0YziyasQuicS3gfuYTU6vEu91LzyEfon0qo1ew1dPwZTD6O/2z7D JDOKlh+2H7VeAb5k/vVAClDPU6vjea4n7CCxyARkzZy8w2MWOIca6w7lyVgXGzAZMF48cTxZmiN R6MMDJcZw7yXJj9JEPaurjWxMe3ga30O23isAy245 X-Gm-Gg: ASbGncszoWjhtxJdEFZgJv1vv1w/+ANkm7kFpagJgvrfFD2bAeZwtgnOmCxhbhP4hlG 7UAkwOy5ilLRyGAvyJA6fhreNhEeeTU0H0997qU8M10zUXMlvNcUSYSGMePZt52mLYX8KgFniD0 8lKOEEeOTu+S4Pj2C3NjthNcDT078s6G8dC+3iyKlAbx9fbjh5qsszrbov0HgQFrz2+yusrfST X-Google-Smtp-Source: AGHT+IGrVZM04XvgPaseySOZs3bNAx9IWsIGdKJgbBIh7931NB51szk/oOGmgDnpT1nAaRLP3Tcbk8fCMZNDMwITH9M= X-Received: by 2002:a05:622a:50a:b0:47e:a6ff:a215 with SMTP id d75a77b69052e-49f48a80470mr730551cf.0.1748032367629; Fri, 23 May 2025 13:32:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Axel Rasmussen Date: Fri, 23 May 2025 13:32:11 -0700 X-Gm-Features: AX0GCFuei6DlMWnYUe6pjJG86zq4kdI3WzoC1j39chgxgqjWjmM9AKKx8Ot51F0 Message-ID: Subject: Re: Suppress pte soft-dirty bit with UFFDIO_COPY? To: Peter Xu Cc: Kyle Huey , Andrew Morton , open list , linux-mm@kvack.org, criu@lists.linux.dev, "Robert O'Callahan" , Mike Rapoport , Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A71C54000D X-Stat-Signature: rtwidyua3djhafwbe7chmibc76xy4n7d X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1748032368-981074 X-HE-Meta: U2FsdGVkX19cVpAicovcrHkZEZ7Pgj8RToBFXoVmoBmZGKu6jM3D6RbyWQbI7eBnte5dxoreOyHd4s9mnu9q7uetQDBUVNdbVVmr97Z0MwNnz+xwtWnEpDHuRogoB+u0Kr8VBJEz66jgvBNEU16bcRrqBICdYlqVquLd6HRAbtRsTNWDq6uD/LahxqycXTt4HPjnbIwwHjz+GI5flaHpki7KbVNCb8HvCqESkNHzS+XR53CR8iY7pJkLKhb4Ze1nYKfZzxC1dEPN70dWm1Mo+JgPUcVYBD1kfxwvU7qAeC9QdKqOyoM5Hhow55BiT9L0f7teBjjmdvxfU7ZfzZBvWAyjxMqUiyDl6zXzl+PiRx3IThMsZqxAT7f8gU0+rbCsrujqeN3jQUqb9ThFrpB8NWvGjyw53sB1MfoXu9d09f9WKia3c4PzRoJ8gKBXKu1OjnVtEBHOmR3RparICj7cqNw2LEl0OCtV+KK7kF3srWL7AKHTxXgxhqyeAltD4wfbtblx6d527HOa47pgF+yjaVs0gRQVVuzV2Nlg80s546ypyZPWLZFAVAJcX4wvTiul5Cwc3acyMWe8ke7e+kYK53e9d5LqdkOgbeETV9kS77i0moH2yYJfiHofUBE0UPnE5QaiPgGPKb47PK54utroYNmDsecWfSorBl++EBDxf39xM/IvU3gbkvlS2Ey8Nx5CGa4WOHjFpC896W3+EmMEIBRZZcJN3/HFj7hq1zEZrb30tZlOi8uDV8QtkyKZ2SBp6FSaZT+wvnuwfy1/ym5hoPb7I7wW2hf5Dp5uKMB/kaXeDr1Y+wju53zl0Qr6/+S2259gGKdmMcZ36W3CZz4uFJYczrdHAVWYPqnJzv4wtvHQe9N+J/Rk/hoh0cmk25CKcgagTbfjJXAp0Eax2LRGKtH7fiXo0/5tkAdvzjebzjQUEbyooiXV7efocvcXOTqC0jkIedBwbQ2j5QAANUT UvCyO3VJ QCzDgAJpAh6ffnKWQY6bS3w3ln5B+8qzA7qBIdIsdpe0v/jTn7XTJctb2fBXEgEDrx/p1NxuqVGu1n4/jv7dr9TX/ouIgxUtPgWP5BnAvVJNQw8rA26a/PcF7bj2UXWf0SIiI0MFQvwq6pGPkGkq0e1zIzxkHdZ4FVZoiG827ZNs4m3V74U8ImlnW2iFIPpb9Xq8PQ8eOh8uTG8JMddhKhMqccxQSP6WXsq35IkBeopN68mOZUAN986BQqbXCJkv6ZCvjqi4hVS/MkgY4G8nVK+JwCdu/3aQvezCmZbzQ/URdqG+v6FbPxumancG6Nert3qDw5sSYdjygvQ0= 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 Tue, May 13, 2025 at 6:25=E2=80=AFAM Peter Xu wrote: > > On Mon, May 12, 2025 at 10:16:12AM -0700, Kyle Huey wrote: > > Personally I don't think it's a real issue to have to create a > > sacrificial fd once at process initialization to see what features are > > available. I wouldn't have even said anything if the man page hadn't > > explicitly told me there was another way. > > Yes, that's indeed the part that could be confusing and needs fixing. Ju= st > to keep a record (I have you copied), I sent the man-pages changes here: > > https://lore.kernel.org/r/20250512171922.356408-1-peterx@redhat.com Agreed, at a high level I think this is the right fix. I believe I just forgot the probing required a separate FD when I wrote that version of the man page. :) > > We can stick with the sacrificial fd until there's a solid clue showing > that we should introduce a new way to probe. For what it's worth, I'm still convinced the whole handshake / probing thing is overcomplicated, and it would be simpler to just do: 1. Userspace asks for the features it wants (UFFDIO_API) 2. Kernel responds (fills in the struct) with the (possibly subset) of features it supports 3. Userspace can react as it sees fit if it gets a subset (fail with error, gracefully degrade, ...) But, based on previous discussion of that I believe I'm in the minority. :) If we are sticking with the handshake approach, I agree needing a second uffd is no big deal. We could add an ioctl to just probe without configuring, but that would purely be for convenience, and I don't think it saves many lines of code in userspace. So, on balance / considering the small benefit I would probably prefer keeping the kernel simpler. > > Thanks, > > -- > Peter Xu > On Tue, May 13, 2025 at 6:25=E2=80=AFAM Peter Xu wrote: > > On Mon, May 12, 2025 at 10:16:12AM -0700, Kyle Huey wrote: > > Personally I don't think it's a real issue to have to create a > > sacrificial fd once at process initialization to see what features are > > available. I wouldn't have even said anything if the man page hadn't > > explicitly told me there was another way. > > Yes, that's indeed the part that could be confusing and needs fixing. Ju= st > to keep a record (I have you copied), I sent the man-pages changes here: > > https://lore.kernel.org/r/20250512171922.356408-1-peterx@redhat.com > > We can stick with the sacrificial fd until there's a solid clue showing > that we should introduce a new way to probe. > > Thanks, > > -- > Peter Xu >