On 4/27/2026 7:49 PM, 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.
> 
> Thanks!
> 
> Acked-by: David Hildenbrand (Arm) <[email protected]>
> 

Thanks, David. I'll send future revisions as a new thread.

Best regards,
fujunjie


Reply via email to