> On Sep 27, 2021, at 2:24 AM, David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 26.09.21 18:12, Nadav Amit wrote: >> From: Nadav Amit <namit@xxxxxxxxxx> >> 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. > > 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?
