On 4/26/26 13:08, fujunjie wrote:
> process_madvise() validates the advice while walking the imported iovec.
> If the iovec has zero total length, vector_madvise() never enters the
> loop and returns 0 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.
>
> Reject invalid advice before walking the vector. 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]>
> ---
> Testing:
> - Built bzImage.
> - Built tools/testing/selftests/mm/process_madv.
> - Ran tools/testing/selftests/mm/process_madv in QEMU:
> # PASSED: 7 / 7 tests passed.
>
> mm/madvise.c | 3 +++
> tools/testing/selftests/mm/process_madv.c | 29 +++++++++++++++++++++++
> 2 files changed, 32 insertions(+)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 69708e953cf56..83fe9e651a907 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -2046,6 +2046,9 @@ static ssize_t vector_madvise(struct mm_struct *mm,
> struct iov_iter *iter,
>
> total_len = iov_iter_count(iter);
>
> + if (!madvise_behavior_valid(behavior))
> + return -EINVAL;
> +
I'd suggest performing the check just before the !process_madvise_remote_valid()
check, such that "invalid/unsupported" orders are reported in the same priority,
independent of local vs. non-local MM.
Or is there a good reason to not do it there?
--
Cheers,
David
