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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F7A6C433EF for ; Wed, 13 Oct 2021 02:19:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8D2E60E53 for ; Wed, 13 Oct 2021 02:19:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C8D2E60E53 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 204366B006C; Tue, 12 Oct 2021 22:19:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B44F900002; Tue, 12 Oct 2021 22:19:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02DA46B0072; Tue, 12 Oct 2021 22:19:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id E45786B006C for ; Tue, 12 Oct 2021 22:19:01 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9E89D8249980 for ; Wed, 13 Oct 2021 02:19:01 +0000 (UTC) X-FDA: 78689806482.10.9D5D55B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 17C76F000090 for ; Wed, 13 Oct 2021 02:19:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634091540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Wcg8uv0C3xyyk65eRbzrMi+K/zZRYWFm2h8Sqmj3wMU=; b=SiYxrXddZTqyXliqDeYXgfmZ3Xj4SzYcVFjDOoLS3Mc+r0XKg6jRD9qBpmlj/3Q+Tnvmej /xMQ27G+1v9yuBYlnyRNwxzz3HPkxaBK+K1JSnk6OAgpzchRgmA5yYQYEmj5JPurrN1fbP oIPBG9FBeuHY+l0b4nY6ny9Rb69ko4k= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-413-dXp-8qvsNVOq1qS0IeMtlg-1; Tue, 12 Oct 2021 22:18:59 -0400 X-MC-Unique: dXp-8qvsNVOq1qS0IeMtlg-1 Received: by mail-pj1-f71.google.com with SMTP id nv1-20020a17090b1b4100b001a04861d474so902638pjb.5 for ; Tue, 12 Oct 2021 19:18:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Wcg8uv0C3xyyk65eRbzrMi+K/zZRYWFm2h8Sqmj3wMU=; b=ssFTdYetDhtrMRnI3kDDgifJ0AqwqXCyjHVUMauu329uXhlAOS5IvxbwH6sWYzqcE6 F6/sA/BKOJLQk6WJQhfQ+2Ez/cBizPrPbeeRHYAJX7VmzsPzB13pu9so2ceeNAC+N3l4 O+Q3LFI69YidMZCiiCL6jgKUNBJGZKngq278oKeOYs0vYtwOY9svSOyCBc5FykPTxcUL vm0ymD6ExGSJ9wXD3JKQORM+8QAHhbY+NkMZ9D4izaCptvqCMdt0+YfBqz/hfSltINnN szN569b6QNAZ71BXl6uo4ByGWO4U4SgRixFR1WnP2381PyxY9wmRRahvO3kz5zcoly6a rVWA== X-Gm-Message-State: AOAM530lWSOb/x4Tr0TUYY6+zco0TijmKVM19qP3p/khL4zjaPGJgvOw Ms6XrMLyUMh+VjPPNRZvnyfmPhPLf/uv21pI3i4g81YLi0rNqSF13XI/10FTgcQig/SL9BOguZm vREgEENsOBSU= X-Received: by 2002:a17:90b:34a:: with SMTP id fh10mr10255612pjb.51.1634091538057; Tue, 12 Oct 2021 19:18:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyx7vhHBd0uMwE25QMwUcweWXCRlis6s+sUV3hVb0B0kmMTX/EAjx0MTIPg+pR0k1K2hWHfIA== X-Received: by 2002:a17:90b:34a:: with SMTP id fh10mr10255583pjb.51.1634091537771; Tue, 12 Oct 2021 19:18:57 -0700 (PDT) Received: from t490s ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id p189sm12159497pfp.167.2021.10.12.19.18.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 19:18:57 -0700 (PDT) Date: Wed, 13 Oct 2021 10:18:50 +0800 From: Peter Xu To: Nadav Amit Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nadav Amit , Andrea Arcangeli , Mike Rapoport Subject: Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs Message-ID: References: <20210926170637.245699-1-namit@vmware.com> MIME-Version: 1.0 In-Reply-To: <20210926170637.245699-1-namit@vmware.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 17C76F000090 X-Stat-Signature: sgpwc8siq45bm778gwbpw7mef4edqg5y Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SiYxrXdd; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com X-HE-Tag: 1634091540-575910 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 Sun, Sep 26, 2021 at 10:06:37AM -0700, Nadav Amit wrote: > From: Nadav Amit > > Non-cooperative mode is useful but only for forked processes. > Userfaultfd can be useful to monitor, debug and manage memory of remote > processes. > > To support this mode, add a new flag, UFFD_REMOTE_PID, and an optional > second argument to the userfaultfd syscall. When the flag is set, the > second argument is assumed to be the PID of the process that is to be > monitored. Otherwise the flag is ignored. > > The syscall enforces that the caller has CAP_SYS_PTRACE to prevent > misuse of this feature. > > Cc: Andrea Arcangeli > Cc: Andrew Morton > Cc: Mike Rapoport > Cc: Peter Xu > Signed-off-by: Nadav Amit I think this patch from one pov looks just likes the other patch of the process_madvise on DONTNEED - the new interface definitely opens new way to do things, however IMHO it would be great to discuss some detailed scenario that we can do with it better than the existing facilities. The thing is uffd already provides some mechanism for doing things like customized swapping, so that's not something new IMHO that this patch brings (neither is what the DONTNEED patch brings), just like when I raised in the other thread about umap. So IMHO it'll be great if there can be some elaboration on how the "remote" capability could help us do things better (e.g., use cases that we may not solve with linking against another uffd-supported library, or we can't do with register uffd then fork()). (I skipped the security side of things, as I replied in the other thread that I think I buy in your point on depending on PTRACE capability and also the examples you gave on ptrace() and process_vm_writev() are persuasive to me, but no expert on that..) Thanks, -- Peter Xu