Re: [PATCH] move_pages.2: not return ENOENT if the page are already on the target nodes

[Yang Shi]

On 12/17/19 11:36 PM, John Hubbard wrote:
> On 12/13/19 5:55 PM, Michael Kerrisk (man-pages) wrote:
> ...
> > > > whoa, hold on. If I'm reading through the various error paths
> > > > correctly, then this
> > > > code is *never* going to return ENOENT for the whole function. It can
> > > > fill in that
> > > > value per-page, in the status array, but that's all. Did I get that
> > > > right?
> > >
> > > Nice catch. Yes, you are right.
> > >
> > > > If so, we need to redo this part of the man page.
> > >
> > > Yes.
> >
> > So where are things at with this? Is an improved man-pages
> > patch on the way, or is some other action (on the API) planned?
>
> I was waiting to see if Yang was going to respond...anyway, I think
> we're looking at approximately this sort of change:

Hi John,

I apologize for the delay, just came back from vacation. Thanks for 
taking care of the patch.

> diff --git a/man2/move_pages.2 b/man2/move_pages.2
> index 2d96468fa..1bf1053f2 100644
> --- a/man2/move_pages.2
> +++ b/man2/move_pages.2
> @@ -191,12 +191,6 @@ was specified or an attempt was made to migrate 
> pages of a kernel thread.
> Â.B ENODEV
> ÂOne of the target nodes is not online.
> Â.TP
> -.B ENOENT
> -No pages were found that require moving.
> -All pages are either already
> -on the target node, not present, had an invalid address or could not be
> -moved because they were mapped by multiple processes.
> -.TP
> Â.B EPERM
> ÂThe caller specified
> Â.B MPOL_MF_MOVE_ALL
>
> ...But I'm not sure if we should change the implementation, instead, so
> that it *can* return ENOENT. That's the main question to resolve before
> creating any more patches, I think.
>
> In addition, Michal mentioned that the page states in the status array 
> also
> need updated documentation.
>
>
> thanks,