Re: [PATCH v3] mm/madvise: unrestrict process_madvise() for current process

On Thu, Sep 26, 2024 at 08:52:32AM GMT, Shakeel Butt wrote:

On Thu, Sep 26, 2024 at 04:10:19PM GMT, Lorenzo Stoakes wrote:

quoted

The process_madvise() call was introduced in commit ecb8ac8b1f14
("mm/madvise: introduce process_madvise() syscall: an external memory
hinting API") as a means of performing madvise() operations on another
process.

However, as it provides the means by which to perform multiple madvise()
operations in a batch via an iovec, it is useful to utilise the same
interface for performing operations on the current process rather than a
remote one.

Commit 22af8caff7d1 ("mm/madvise: process_madvise() drop capability check
if same mm") removed the need for a caller invoking process_madvise() on
its own pidfd to possess the CAP_SYS_NICE capability, however this leaves
the restrictions on operation in place.

Resolve this by only applying the restriction on operations when accessing
a remote process.

Moving forward we plan to implement a simpler means of specifying this
condition other than needing to establish a self pidfd, perhaps in the form
of a sentinel pidfd.

Also take the opportunity to refactor the system call implementation
abstracting the vectorised operation.

Signed-off-by: Lorenzo Stoakes <redacted>

Acked-by: Shakeel Butt <shakeel.butt@linux.dev>

Thanks!

quoted

---
v3:
* Avoid introducing PR_MADV_SELF and defer a non-pidfd version until later.

Seems like a good plan to decouple this patch from PR_MADV_SELF vs
PIDFD_SELF decision. I am hoping to see the follow up patch as well.

thanks,
Shakeel

Yes agreed, this gets an important part of the change in, and gives us room
to take our time on that side of things.

Plan right now is I will work on a sentinel solution in parallel to other
stuff and see how that goes, if it integrates well can bring it in in a
separate patch series.

Cheers, Lorenzo