Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <YWZCClDorCCM7KMG@t490s>
Date:   Wed, 13 Oct 2021 09:02:48 -0700
Cc:     Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrea Arcangeli <aarcange@redhat.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <03C026D4-EBE8-4649-9C42-63F82941B781@gmail.com>
References: <20210926170637.245699-1-namit@vmware.com>
 <YWZCClDorCCM7KMG@t490s>
To:     Peter Xu <peterx@redhat.com>
Precedence: bulk


> On Oct 12, 2021, at 7:18 PM, Peter Xu <peterx@redhat.com> wrote:
>=20
> On Sun, Sep 26, 2021 at 10:06:37AM -0700, Nadav Amit wrote:
>> From: Nadav Amit <namit@vmware.com>
>>=20
>> Non-cooperative mode is useful but only for forked processes.
>> Userfaultfd can be useful to monitor, debug and manage memory of =
remote
>> processes.
>>=20
>> 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.
>>=20
>> The syscall enforces that the caller has CAP_SYS_PTRACE to prevent
>> misuse of this feature.
>>=20
>> Cc: Andrea Arcangeli <aarcange@redhat.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
>> Cc: Peter Xu <peterx@redhat.com>
>> Signed-off-by: Nadav Amit <namit@vmware.com>
>=20
> 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.
>=20
> 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.
>=20
> 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()).
>=20
> (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..)

Fair enough. Let me get back to you once I can provide more data.

For now, I just ask you to have this patch in the back of your mind if =
any
other change to userfaultfd syscall is proposed to prevent a potential
conflict.=