Re: [PATCH] mm/madvise: reject invalid process_madvise() advice for zero-length vectors

["David Hildenbrand (Arm)" <david@kernel.org>]

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 <fujunjie1@qq.com>
> ---
> 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