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: <4846FC21.10304@firstfloor.org>
Date:	Wed, 04 Jun 2008 22:33:37 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Paul Jackson <pj@....com>
CC:	maxk@...lcomm.com, ioe-lkml@...eria.de, sivanich@....com,
	a.p.zijlstra@...llo.nl, linux-kernel@...r.kernel.org,
	kernel@...ivas.org, dfults@....com, devik@....cz, dino@...ibm.com,
	emmanuel.pacaud@...v-poitiers.fr, deweerdt@...e.fr, mingo@...e.hu,
	colpatch@...ibm.com, nickpiggin@...oo.com.au, rostedt@...dmis.org,
	oleg@...sign.ru, paulmck@...ibm.com, menage@...gle.com,
	rddunlap@...l.org, suresh.b.siddha@...el.com, tglx@...utronix.de
Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may
 have realtime uses)


> I was responding to a need you noticed to isolate memory nodes (such as
> from stray glibc pages placed by init or the shell running early
> scripts), not to the need to isolate CPUs:

Yes, but in practice (enough memory for bootup) isolating CPUs
is equivalent to isolating nodes. So isolcpus=... tended to work.

I occasionally recommended it to people because it was much easier
to explain than replacing init.

The perfect solution would be probably just fix it in init(8)
and make it parse some command line option that then sets up
the right cpusets.

But you asked for isolcpus=... use cases and I just wanted to describe
one.

> So perhaps it boils down to a question of which is easiest to do,
> the answer to which will vary depending on where you are in the food
> chain of distributions.  Here "easy" means least likely to break
> something else.  All these mechanisms are relatively trivial, until
> one has to deal with conflicting software packages, configurations and
> distributions, changing out from under oneself.

One solution would be to move isolcpus=/isonodes= into init(8) and make
sure it's always statically linked. But failing that keeping it in the
kernel is not too bad. It's certainly not a lot of code.

On the other hand if the kernel implemented a isolnodes=... it would
be possible to exclude those nodes from the interleaving the kernel
does at boot, which might be also beneficial and give slightly
more isolation.

-Andi
--
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