Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Fri, 11 Mar 2022 13:42:03 -0800
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Charan Teja Kalla <quic_charante@quicinc.com>
Cc:     <surenb@google.com>, <vbabka@suse.cz>, <rientjes@google.com>,
        <sfr@canb.auug.org.au>, <edgararriaga@google.com>,
        <minchan@kernel.org>, <nadav.amit@gmail.com>, <mhocko@suse.com>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2,0/2]mm: madvise: return correct bytes processed with
 process_madvise
Message-Id: <20220311134203.47cbeab087b731bada12d0f1@linux-foundation.org>
In-Reply-To: <cover.1647008754.git.quic_charante@quicinc.com>
References: <cover.1647008754.git.quic_charante@quicinc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 11 Mar 2022 20:59:04 +0530 Charan Teja Kalla <quic_charante@quicinc.com> wrote:

> With the process_madvise(), always choose to return non zero processed
> bytes over an error. This can help the user to know on which VMA, passed
> in the 'struct iovec' vector list, is failed to advise thus can take the
> decission of retrying/skipping on that VMA.

Thanks, this is not good.

We should have added userspace tests for process_madvise() along with
the syscall itself.  But evidently that was omitted.  If someone
decides to contribute such tests, hopefully they will include checks
for these return values.