On Fri, Mar 11, 2022 at 08:59:06PM +0530, Charan Teja Kalla wrote:
The process_madvise() system call is expected to skip holes in vma passed through 'struct iovec' vector list. But do_madvise, which process_madvise() calls for each vma, returns ENOMEM in case of unmapped holes, despite the VMA is processed. Thus process_madvise() should treat ENOMEM as expected and consider the VMA passed to as processed and continue processing other vma's in the vector list. Returning -ENOMEM to user, despite the VMA is processed, will be unable to figure out where to start the next madvise. Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") Cc: stable@vger.kernel.org # 5.10+
Hmm, not sure whether it's stable material since it changes semantic of API. It would be better to change the semantic from 5.19 with man page update to specify the change.
Signed-off-by: Charan Teja Kalla quic_charante@quicinc.com
Changes in V2: -- Fixed handling of ENOMEM by process_madvise(). -- Patch doesn't exist in V1.
mm/madvise.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/madvise.c b/mm/madvise.c index e97e6a9..14fb76d 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -1426,9 +1426,16 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec, while (iov_iter_count(&iter)) { iovec = iov_iter_iovec(&iter);
/** do_madvise returns ENOMEM if unmapped holes are present* in the passed VMA. process_madvise() is expected to skip* unmapped holes passed to it in the 'struct iovec' list* and not fail because of them. Thus treat -ENOMEM return* from do_madvise as valid and continue processing.*/
if (ret < 0)
if (ret < 0 && ret != -ENOMEM) break;-- 2.7.4