Hi Vlastimil, Thanks for your comment! On 2017/10/18 18:46, Vlastimil Babka wrote: > On 10/18/2017 11:34 AM, Yisheng Xie wrote: >>>> For MAX_NUMNODES is 4, so 0x10 nodemask will tread as empty set which makes >>>> nodes_subset(*new, node_states[N_MEMORY]) >>> >>> According to manpage of migrate_pages: >>> >>> EINVAL The value specified by maxnode exceeds a kernel-imposed >>> limit. Or, old_nodes or new_nodes specifies one or more node IDs that >>> are greater than the maximum supported node ID. Or, none of the node >>> IDs specified by new_nodes are on-line and allowed by the process's >>> current cpuset context, or none of the specified nodes contain memory. >>> >>> if maxnode parameter is 64, but MAX_NUMNODES ("kernel-imposed limit") is >>> 4, we should get EINVAL just because of that. I don't see such check in >>> the migrate_pages implementation though. >> >> Yes, that is what manpage said, but I have a question about this: if user >> set maxnode exceeds a kernel-imposed and try to access node without enough >> privilege, which errors values we should return ? For I have seen that all >> of the ltp migrate_pages01 will set maxnode to 64 in my system. > > Hm I don't think it matters much and don't know if there's some commonly > used priority. Personally I would do the checks resulting in EINVAL > first, before EPERM, but if the code is structured differently, it may > stay as it is. I see,and I have checked the code of get_nodes, which seems treat "kernel-imposed limit" as the meaning of BITS_PER_LONG * BITS_TO_LONGS(MAX_NUMNODES) instead of MAX_NUMNODES, which I have replied in another mail. As we use unsigned long to store node bitmap, so the limit should be counted in multiple of BITS_PER_LONG, fair? Thanks Yisheng Xie -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>