On Tue, Mar 15, 2022 at 04:48:07PM -0700, Andrew Morton wrote:
> On Tue, 15 Mar 2022 15:58:28 -0700 Minchan Kim <minchan@xxxxxxxxxx> wrote:
>
> > 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@xxxxxxxxxxxxxxx> # 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.
>
> It's a very desirable change and it makes the code match the manpage
> and it's cc:stable. I think we should just absorb any transitory
> damage which this causes people. I doubt if there will be much - if
> anyone was affected by this they would have already told us that it's
> broken?
process_madvise fails to return exact processed bytes at several cases
if it encounters the error, such as, -EINVAL, -EINTR, -ENOMEM in the
middle of processing vmas. And now we are trying to make exception for
change for only hole? IMO, it's worth to note in man page.
In addition, this change returns positive processes bytes even though
it didn't process anything if it couldn't find any vma for the first
iteration in madvise_walk_vmas.
