linux-kernel - Re: cpusets not cpu hotplug aware

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20060823191947.76a6f8ac.pj@sgi.com>
Date:	Wed, 23 Aug 2006 19:19:47 -0700
From:	Paul Jackson <pj@....com>
To:	Nathan Lynch <ntl@...ox.com>
Cc:	akpm@...l.org, anton@...ba.org, simon.derr@...l.net,
	linux-kernel@...r.kernel.org
Subject: Re: cpusets not cpu hotplug aware

Nathan wrote:
> # echo 1 > /sys/devices/system/cpu/cpu3/online
> # taskset 0x8 foo
> 
> has a race condition, depending on your kernel's configuration.

Good point.  That's not a nice race to force on users.

I relent -- not udev.

> Maybe the cpuset code should just stay out of the way unless the admin
> has instantiated one?

I really don't like where such special case, modal behaviour leads us.

Let's say we have two systems, side by side.  Both have been up for
many months.  On one of these systems,  one time, a few months ago, the
sysadmin briefly made and removed a cpuset:

	mkdir /dev/cpuset
	mount -t cpuset cpuset /dev/cpuset
	mkdir /dev/cpuset/foo
	rmdir /dev/cpuset/foo
	umount /dev/cpuset
	rmdir /dev/cpuset

On the other of these systems, the sysadmin never did any such thing.
These two systems are now identical in every other aspect that might
matter to this discussion.

The sched_setaffinity call should behave the same on these two systems.

If the kernel has to impose a trivial bit of policy (such as forcing
the top cpuset to track what's online) in order to provide uniformally
consistent (not modal) and race free behaviour, then it should.

And besides, as someone else noted, it's alot easier than dealing with
udev ;).

Conclusion - the kernel should simply force the top_cpuset to track the
online maps.  See further my response to your patch.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.925.600.0401
-
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/