From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FFA4C433EF for ; Wed, 9 Mar 2022 16:48:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E282A8D0002; Wed, 9 Mar 2022 11:48:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD81C8D0001; Wed, 9 Mar 2022 11:48:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC6138D0002; Wed, 9 Mar 2022 11:48:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id BB55D8D0001 for ; Wed, 9 Mar 2022 11:48:03 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6D66BA15D6 for ; Wed, 9 Mar 2022 16:48:03 +0000 (UTC) X-FDA: 79225430046.27.11BC091 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf25.hostedemail.com (Postfix) with ESMTP id C8013A0011 for ; Wed, 9 Mar 2022 16:48:02 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id r12so2456092pla.1 for ; Wed, 09 Mar 2022 08:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=SfXNkkolcMJPwDp63yf81XujFSDo95hIeJu326GhdWQ=; b=RC0q0OcBEQu9ASG61IkTDmrNlwYTQDX300E7BWFYleWgmnmkyhz/MpJGbJULr1sh07 9Ha7BXxmneFsYSP/mR/gV+L9lXhtm9WOQ8XtVPRPS+epm3qPdqRu1qbKGILDHxpRoRva crxiZpmDWDgq6+3UJvjFhWpK9OH7Ke4mGcFVxy0a579gwCrc7Ifd6GL/9vwBc6YruqVI baQzqQvGyS+P7IMYrYdhP0owXMy++OQkmxh/ky24V6gXXG2rXEFjXfFI7QbZjevVxjDb g+Qm0N1Mr4u43+neLiKGsu5OBbaUc7VlR02k86o6kDWu41wxAQq2T4O10m5O+JOkt31P Aolw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=SfXNkkolcMJPwDp63yf81XujFSDo95hIeJu326GhdWQ=; b=ER4lVmIOIOaryhnZUJuyhaz53NZKAD/vmQULoEE611Umt6J9kJfD/SD5f932rZ17iu T9IxWS4l2BTKliMvnr9lLPajgVGKruHzhhtel9ymQIrK56LIvG2NnY2Cgq8AevBn0T6r SHu9MsLN8Qrf10pHji5RT8kfQWauNuLNBjpSaEdooz1jTS2sGQm77EhutxB8hInLI8D6 c4C3SngXIaKrg/JaPHwOjisHalCnqJWBie5k4erB5lWXACzPCc+crtcCAk8o0jINGEPq X1grs9QYuYk4w9OgNB+bUpibcvMzHrH5t73YmDZVvHep1o3wg9sB7VD3Pr520CboXV1k KpzA== X-Gm-Message-State: AOAM532+CxI7tHAFxPJ48+qwIqNi+sdGkbdodoLB44Utb42cRqOEkK0s bvAMsgzV6OMdSr3PbzstzOE= X-Google-Smtp-Source: ABdhPJwrS2OvbPW4zE7Gt+E9g6pb4AjJcfenCjjwXCZjVXEQ/MT81h7EtQe22hOGM83go1+bt0AMbg== X-Received: by 2002:a17:902:7b8d:b0:14f:1aca:d95e with SMTP id w13-20020a1709027b8d00b0014f1acad95emr556596pll.122.1646844481703; Wed, 09 Mar 2022 08:48:01 -0800 (PST) Received: from google.com ([2620:15c:211:201:aee3:831e:b1d0:905f]) by smtp.gmail.com with ESMTPSA id b10-20020a056a000cca00b004f6f6dd8287sm3807826pfv.18.2022.03.09.08.48.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 08:48:01 -0800 (PST) Date: Wed, 9 Mar 2022 08:47:59 -0800 From: Minchan Kim To: Charan Teja Kalla Cc: akpm@linux-foundation.org, yuehaibing@huawei.com, sfr@canb.auug.org.au, rientjes@google.com, edgararriaga@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: madvise: return correct bytes advised with process_madvise Message-ID: References: <1646803679-11433-1-git-send-email-quic_charante@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1646803679-11433-1-git-send-email-quic_charante@quicinc.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C8013A0011 X-Stat-Signature: g9ug1n8i6p6pc8irmyciirb7mqxh1thj Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RC0q0OcB; spf=pass (imf25.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspam-User: X-HE-Tag: 1646844482-228677 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 09, 2022 at 10:57:59AM +0530, Charan Teja Kalla wrote: > The process_madvise() system call returns error even after processing > some VMA's passed in the 'struct iovec' vector list which leaves the > user confused to know where to restart the advise next. It is also > against this syscall man page[1] documentation where it mentions that > "return value may be less than the total number of requested bytes, if > an error occurred after some iovec elements were already processed.". > > Consider a user passed 10 VMA's in the 'struct iovec' vector list of > which 9 are processed but one. Then it just returns the error caused on > that failed VMA despite the first 9 VMA's processed, leaving the user > confused about on which VMA it is failed. Returning the number of bytes > processed here can help the user to know which VMA it is failed on and > thus can retry/skip the advise on that VMA. > > [1]https://man7.org/linux/man-pages/man2/process_madvise.2.html. > > Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API" > Signed-off-by: Charan Teja Kalla > --- > mm/madvise.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index 38d0f51..d3b49b3 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -1426,15 +1426,21 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec, > > while (iov_iter_count(&iter)) { > iovec = iov_iter_iovec(&iter); > + /* > + * Even when [start, end) passed to do_madvise covers > + * some unmapped addresses, it continues processing with > + * returning ENOMEM at the end. Thus consider the range > + * as processed when do_madvise() returns ENOMEM. > + * This makes process_madvise() never returns ENOMEM. > + */ Looks like that this patch has two things. first, returns processed bytes instead of error in case of error. Second, keep working on rest vmas on -ENOMEM due to unmapped hole. First thing totally makes sense to me(that's exactly I wanted to do but somehow missed) so it should go stable tree. However, second stuff might be arguble so it would be great if you split the patch. > ret = do_madvise(mm, (unsigned long)iovec.iov_base, > iovec.iov_len, behavior); > - if (ret < 0) > + if (ret < 0 && ret != -ENOMEM) > break; > iov_iter_advance(&iter, iovec.iov_len); > } > > - if (ret == 0) > - ret = total_len - iov_iter_count(&iter); > + ret = (total_len - iov_iter_count(&iter)) ? : ret; > > release_mm: > mmput(mm); > -- > 2.7.4 >