Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Subject: Re: [PATCH] mm: madvise: return correct bytes advised with
 process_madvise
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <YijaP7cC6Sclxc29@google.com>
Date:   Wed, 9 Mar 2022 10:50:24 -0800
Cc:     Andrew Morton <akpm@linux-foundation.org>, yuehaibing@huawei.com,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        David Rientjes <rientjes@google.com>, edgararriaga@google.com,
        Michal Hocko <mhocko@suse.com>, Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B156E4D9-C3DD-4EBD-ACE2-CA55A8B3A3F5@gmail.com>
References: <1646803679-11433-1-git-send-email-quic_charante@quicinc.com>
 <YijaP7cC6Sclxc29@google.com>
To:     Charan Teja Kalla <quic_charante@quicinc.com>,
        Minchan Kim <minchan@kernel.org>
Precedence: bulk


> On Mar 9, 2022, at 8:47 AM, Minchan Kim <minchan@kernel.org> wrote:
>=20
> 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.".
>>=20
>> 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.
>>=20
>> [1]https://man7.org/linux/man-pages/man2/process_madvise.2.html.
>>=20
>> Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: =
an external memory hinting API"
>> Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
>> ---
>> mm/madvise.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>=20
>> 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,
>>=20
>> 	while (iov_iter_count(&iter)) {
>> 		iovec =3D 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.
>> +		 */
>=20
> 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.
>=20
> 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.

I fully understand and relate to the basic motivation of this
patch.

The ENOMEM that this patch checks for, IIUC, is the ENOMEM that is
returned on unmapped holes. Such ENOMEM does not appear, according to
the man page, to be a valid reason to return ENOMEM to userspace.
Presumably process_madvise() is expected to skip unmapped holes
and not to fail because of them.

Having said that, I do not think that the check that the patch does
is clean or clearly documented.

In addition, this patch (and some work on process_madvise()) raise
in my mind a couple of questions:

1. There are other errors that process_madvise might encounter
   and can be propagated back to userspace, but are not
   documented. For instance if can_madv_lru_vma() fails on
   MADV_COLD, userspace will get EINVAL. EINVAL is not documented
   as a valid error-code for such case in either madvise() and
   process_madvise() man pages.

2. If an advice fails due to other reason, specifically
   split_huge_page(), there might be partial success within a
   VMA. I guess for now it is fine to ignore such failures
   since there is no guarantee on the OS behavior following
   most advices (excluding MADV_DONTNEED).

Regards,
Nadav=