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 0/8] mm/madvise: support
 process_madvise(MADV_DONTNEED)
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <7ce823c8-cfbf-cc59-9fc7-9aa3a79740c3@redhat.com>
Date:   Mon, 27 Sep 2021 03:41:18 -0700
Cc:     Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Peter Xu <peterx@redhat.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Minchan Kim <minchan@kernel.org>,
        Colin Cross <ccross@google.com>,
        Suren Baghdasarya <surenb@google.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E8A03DD-175F-4A21-BCD7-383D61344521@gmail.com>
References: <20210926161259.238054-1-namit@vmware.com>
 <7ce823c8-cfbf-cc59-9fc7-9aa3a79740c3@redhat.com>
To:     David Hildenbrand <david@redhat.com>
Precedence: bulk


> On Sep 27, 2021, at 2:24 AM, David Hildenbrand <david@redhat.com> =
wrote:
>=20
> On 26.09.21 18:12, Nadav Amit wrote:
>> From: Nadav Amit <namit@vmware.com>
>> The goal of these patches is to add support for
>> process_madvise(MADV_DONTNEED). Yet, in the process some (arguably)
>> useful cleanups, a bug fix and performance enhancements are =
performed.
>> The patches try to consolidate the logic across different behaviors, =
and
>> to a certain extent overlap/conflict with an outstanding patch that =
does
>> something similar [1]. This consolidation however is mostly =
orthogonal
>> to the aforementioned one and done in order to clarify what is done =
in
>> respect to locks and TLB for each behavior and to batch these =
operations
>> more efficiently on process_madvise().
>> process_madvise(MADV_DONTNEED) is useful for two reasons: (a) it =
allows
>> userfaultfd monitors to unmap memory from monitored processes; and =
(b)
>> it is more efficient than madvise() since it is vectored and batches =
TLB
>> flushes more aggressively.
>=20
> MADV_DONTNEED on MAP_PRIVATE memory is a target-visible operation; =
this is very different to all the other process_madvise() calls we =
allow, which are merely hints, but the target cannot be broken . I don't =
think this is acceptable.

This is a fair point, which I expected, but did not address properly.

I guess an additional capability, such as CAP_SYS_PTRACE needs to be
required in this case. Would that ease your mind?