netdev - Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

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, 19 Oct 2010 14:52:32 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Theodore Kilgore <kilgota@...ach.math.auburn.edu>
Cc:	Steven Rostedt <rostedt@...dmis.org>, Greg KH <greg@...ah.com>,
	codalist@...emann.coda.cs.cmu.edu, autofs@...ux.kernel.org,
	Samuel Ortiz <samuel@...tiz.org>, Jan Kara <jack@...e.cz>,
	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>,
	Arnd Bergmann <arnd@...db.de>,
	Jan Harkes <jaharkes@...cmu.edu>, netdev@...r.kernel.org,
	Anders Larsen <al@...rsen.net>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	Bryan Schumaker <bjschuma@...app.com>,
	Christoph Hellwig <hch@...radead.org>,
	ksummit-2010-discuss@...ts.linux-foundation.org,
	Petr Vandrovec <vandrove@...cvut.cz>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-fsdevel@...r.kernel.org,
	Evgeniy Dushistov <dushistov@...l.ru>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Hendry <andrew.hendry@...il.com>,
	linux-media@...r.kernel.org
Subject: Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

> I might be able to find some hardware still lying around here that uses an
> i810. Not sure unless I go hunting it. But I get the impression that if
> the kernel is a single-CPU kernel there is not any problem anyway? Don't
> distros offer a non-smp kernel as an installation option in case the user
> needs it? So in reality how big a problem is this?

Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html