On Mon, Apr 27, 2026 at 01:49:46PM +0200, David Hildenbrand (Arm) wrote:
> On 4/27/26 11:43, fujunjie wrote:
> > process_madvise() used to validate the advice while walking each
> > imported iovec. If the vector has zero total length, vector_madvise()
> > does not enter the loop and can return success without checking whether
> > the advice value is valid.
> >
> > For a local mm, such as process_madvise(PIDFD_SELF, ...), the remote-only
> > process_madvise_remote_valid() check is skipped. As a result, an invalid
> > advice can be reported as success when the vector has zero total length.
> > This differs from madvise(), which rejects an invalid advice before
> > returning success for a zero-length range.
> >
> > Validate the generic madvise behavior at the syscall-facing entry points
> > before any vector walk. In process_madvise(), do this before the
> > remote-only advice restriction so unsupported advice is rejected with the
> > same priority for local and remote mm. Then keep the per-range helper
> > focused on address/length validation, avoiding repeated behavior checks
> > for every iovec.
> >
> > Valid zero-length requests remain no-ops and continue to return 0. Add a
> > selftest that covers invalid advice with a zero-length iovec and an empty
> > vector, while also checking that a valid zero-length request still
> > succeeds.
> >
> > Fixes: 021781b01275 ("mm/madvise: unrestrict process_madvise() for current
> > process")
> > Signed-off-by: fujunjie <[email protected]>
> > ---
>
>
> Next time, please don't send new revisions as reply to previous submissions.
Also this :P email sucks for all this but it makes it easy for me to miss your
reply :(
Thanks, Lorenzo
