[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f889d39f-ca1f-9239-dc95-4e1806a6345f@suse.cz>
Date: Wed, 18 Oct 2017 12:46:41 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Yisheng Xie <xieyisheng1@...wei.com>, akpm@...ux-foundation.org,
mhocko@...e.com, mingo@...nel.org, rientjes@...gle.com,
n-horiguchi@...jp.nec.com, salls@...ucsb.edu
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
will.deacon@....com, tanxiaojun@...wei.com,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages
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.
Powered by blists - more mailing lists