linux-kernel - 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]

Message-ID: <AANLkTi=ffaihP5-yNYFKAbAbX+XbRgWRXXfCZd4J3KwQ@mail.gmail.com>
Date:	Tue, 19 Oct 2010 10:57:43 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	Arnd Bergmann <arnd@...db.de>, codalist@...emann.coda.cs.cmu.edu,
	ksummit-2010-discuss@...ts.linux-foundation.org,
	autofs@...ux.kernel.org, Jan Harkes <jaharkes@...cmu.edu>,
	Samuel Ortiz <samuel@...tiz.org>, Jan Kara <jack@...e.cz>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	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>,
	Petr Vandrovec <vandrove@...cvut.cz>,
	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>,
	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

On Tue, Oct 19, 2010 at 10:40 AM, Greg KH <greg@...ah.com> wrote:
> On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH <greg@...ah.com> wrote:
>> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>> >>
>> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
>> >> up not getting fixed at all, we can either mark them non-SMP or move them
>> >> to drivers/staging once all the others are done.
>> >
>> > I recommend moving them to staging, and then retire them from there if
>> > no one steps up to maintain them.
>>
>> I think this sets a bad precedent, these drivers work fine. Removing
>> BKL from them is hard, and involves finding and booting hw that
>> developers don't have much time/interest in at the moment. Anyone who
>> has access to the i810 hw and has time to work out the locking has
>> more important things to be doing with modern hw, however it doesn't
>> mean we should just drop support for old drivers because they don't
>> have active maintainers. Removing the BKL from the kernel is a great
>> goal, but breaking userspace ABI by removing drivers isn't.
>
> Should we just restrict such drivers to only be able to build on UP
> machines with preempt disabled so that the BKL could be safely removed
> from them?
>
> Or what other idea do you have as to what could be done here?
>
> I do have access to this hardware, but its on an old single processor
> laptop, so any work that it would take to help do this development,
> really wouldn't be able to be tested to be valid at all.

There is only very rare case where the i830 driver might get used with
SMP and really I think that case is in the don't care place, since if
you have that hw you probably should be using i915 on it anyways.

So it really only leaves the problem case of what do distros do if we
mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
when you boot the SMP kernels on UP they don't run as SMP so not
having the driver load on those is a problem. Maybe we just need some
sort of warn on smp if a smp unfriendly driver is loaded and we
transition to SMP mode. Though this sounds like either (a) something
we do now and I don't about it, (b) work.

Dave.

>
> thanks,
>
> greg k-h
>
--
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/