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]
Date:	Tue, 5 Feb 2008 14:44:33 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
cc:	Paul Jackson <pj@....com>, kosaki.motohiro@...fujitsu.com,
	andi@...stfloor.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	clameter@....com, mel@....ul.ie
Subject: Re: [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't
 works on memoryless node.

On Tue, 5 Feb 2008, Lee Schermerhorn wrote:

> The patch I just posted doesn't depend on the numactl changes and seems
> quite minimal to me.  I think it cleans up the differences between
> set_mempolicy() and mbind(), as well.  However, some may take exception
> to the change in behavior--silently ignoring dis-allowed nodes in
> set_mempolicy().
> 

If the intent of the set_mempolicy() call is going to be preserved in the 
struct mempolicy with Paul's change, then we're going to allow disallowed 
nodes anyway.  So the only nodemask errors that we should return are ones 
that are empty; nodemasks that include offlined nodes should be allowed to 
support node hotplug.  Likewise, memoryless nodes should still be saved as 
the intent of the syscall.

The change to save the intent or silently ignore disallowed nodes would 
also require applications to issue a successive get_mempolicy() call to 
know what their current mempolicy is, since it will be able to change with 
a cpusets change or node hotplug event.  There is no longer this assurance 
that if set_mempolicy() returns without an error that the memory policy is 
effected.  But in the presence of subsystems such as cpusets that allow 
those mempolicies to change from beneath the application, there is no way 
around that: the nodemask that the mempolicy acts on can dynamically 
change at any time.

So I don't see any problem with silently ignoring disallowed nodes and 
encourage it so that the kernel accomodates the intent of the mempolicy in 
the future if and when it can be effected.

		David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ