Re: [v2 PATCH] move_pages.2: Returning positive value is a new error case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/30/20 5:48 AM, Michal Hocko wrote:
On Thu 30-01-20 13:56:20, Vlastimil Babka wrote:
On 1/30/20 1:02 PM, Michal Hocko wrote:
On Thu 30-01-20 10:06:28, Vlastimil Babka wrote:
On 1/29/20 10:48 PM, Yang Shi wrote:
Since commit a49bd4d71637 ("mm, numa: rework do_pages_move"),
the semantic of move_pages() has changed to return the number of
non-migrated pages if they were result of a non-fatal reasons (usually a
busy page).  This was an unintentional change that hasn't been noticed
except for LTP tests which checked for the documented behavior.

There are two ways to go around this change.  We can even get back to the
original behavior and return -EAGAIN whenever migrate_pages is not able
The manpage says EBUSY, not EAGAIN? And should its description be
updated too?
The idea was that we _could_ return EAGAIN from the syscall if
migrate_pages > 0.

I.e. that it's no longer returned since 4.17?
I am pretty sure this will require a deeper consideration. Do we return
EIO/EINVAL?
I thought the manpage says we return -EBUSY, but I misread it, this part
was not about errno, but the status array. So there's nothing to update
there, sorry about the noise.

BTW, the suggestion to "Pre-initialization of the array to -1" means
effectively it's pre-initialized to -EPERM. That's fine now as -EPERM is
not one of the codes listed as possible to be returned via the array,
but perhaps it's not entirely future-proof?
Hmm, I didn't realize EPERM is refering to 1. The wording however
suggests also any other value that cannot represent a valid NUMA node.
So maybe we should just drop the node about -1.

Or maybe we just say "any value which doesn't represent a valid NUMA node or valid error of status array"?





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux