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.
Changes in V2:
-- Separated the fixes returning processed bytes in case of an error
and ENOMEM handling of process_madvise() due to unmapped hole in
the VMA, as per the Minchan comments.
-- Improved the comment for ENOMEM handling case as per Amit comments.
Changes in V1:
-- Fixed the return value of process_madvise().
-- Fixed ENOMEM handling of process_madvise() from do_madvise()
-- https://patchwork.kernel.org/project/linux-mm/patch/[email protected]/
Charan Teja Kalla (2):
mm: madvise: return correct bytes advised with process_madvise
mm: madvise: skip unmapped vma holes passed to process_madvise
mm/madvise.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--
2.7.4
On Fri, 11 Mar 2022 20:59:04 +0530 Charan Teja Kalla <[email protected]> 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.
Thanks Andrew!!
On 3/12/2022 3:12 AM, Andrew Morton 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.
We are happy to contribute here.
>