lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <79f20d60-dd8d-2545-5a9b-09871ad8ee4e@huawei.com>
Date:   Fri, 20 Oct 2017 14:42:38 +0800
From:   Yisheng Xie <xieyisheng1@...wei.com>
To:     Vlastimil Babka <vbabka@...e.cz>, <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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ