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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160920155601.GB3899@home>
Date:   Tue, 20 Sep 2016 17:56:02 +0200
From:   Piotr Kwapulinski <kwapulinski.piotr@...il.com>
To:     David Rientjes <rientjes@...gle.com>
Cc:     akpm@...ux-foundation.org, kirill.shutemov@...ux.intel.com,
        vbabka@...e.cz, mhocko@...nel.org, mgorman@...hsingularity.net,
        liangchen.linux@...il.com, nzimmer@....com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/mempolicy.c: forbid static or relative flags for
 local NUMA mode

On Mon, Sep 19, 2016 at 05:57:17PM -0700, David Rientjes wrote:
> On Sun, 18 Sep 2016, Piotr Kwapulinski wrote:
> 
> > The MPOL_F_STATIC_NODES and MPOL_F_RELATIVE_NODES flags are irrelevant
> > when setting them for MPOL_LOCAL NUMA memory policy via set_mempolicy.
> > Return the "invalid argument" from set_mempolicy whenever
> > any of these flags is passed along with MPOL_LOCAL.
> > It is consistent with MPOL_PREFERRED passed with empty nodemask.
> > It also slightly shortens the execution time in paths where these flags
> > are used e.g. when trying to rebind the NUMA nodes for changes in
> > cgroups cpuset mems (mpol_rebind_preferred()) or when just printing
> > the mempolicy structure (/proc/PID/numa_maps).
> > Isolated tests done.
> > 
> > Signed-off-by: Piotr Kwapulinski <kwapulinski.piotr@...il.com>
> 
> Acked-by: David Rientjes <rientjes@...gle.com>
> 
> There wasn't an MPOL_LOCAL when I introduced either of these flags, it's 
> an oversight to allow them to be passed.
> 
> Want to try to update set_mempolicy(2) with the procedure outlined in 
> https://www.kernel.org/doc/man-pages/patches.html as well?
Yes, why not ? I'll put a note about it.

--
Piotr Kwapulinski

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ