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:	Sun, 27 Aug 2006 18:42:09 +1000
From:	Keith Owens <kaos@....com>
To:	Paul Jackson <pj@....com>
cc:	ego@...ibm.com, mingo@...e.hu, nickpiggin@...oo.com.au,
	arjan@...radead.org, rusty@...tcorp.com.au, torvalds@...l.org,
	akpm@...l.org, linux-kernel@...r.kernel.org, arjan@...el.linux.com,
	davej@...hat.com, dipankar@...ibm.com, vatsa@...ibm.com,
	ashok.raj@...el.com
Subject: Re: [RFC][PATCH 4/4] Rename lock_cpu_hotplug/unlock_cpu_hotplug 

Paul Jackson (on Sun, 27 Aug 2006 00:59:44 -0700) wrote:
>The change agents (such as a system admin changing something in
>the /dev/cpuset hierarchy) are big slow mammoths that appear rarely,
>and need to single thread their entire operation, preventing anyone
>else from changing the cpuset hierarchy for an extended period of time,
>while they validate the request and setup to make the requested change
>or changes.
>
>The inhibitors are a swarm of locusts, that change nothing, and need
>quick, safe access, free of change during a brief critical section.
>
>Finally the mammoths must not trample the locusts (change what the
>locusts see during their critical sections.)

This requirement, and the similar requirement that cpu_online_mask
cannot change while anybody is reading it, both appear to cry out for
stop_machine().  Readers must be able to access the cpu related
structures at all time, without any extra locking.  Updaters (which by
definition are extremely rare) stop all other cpus, do their work then
restart_machine().  That way only kernel/stop_machine.c has to care
that the cpu masks might change underneath it, the rest of the kernel
is protected with zero overhead.

-
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