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]

Date:	Wed, 20 Oct 2010 08:50:07 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Dave Young <hidave.darkstar@...il.com>
Cc:	Greg KH <greg@...ah.com>, Oliver Neukum <oliver@...kum.org>,
	Valdis.Kletnieks@...edu, Dave Airlie <airlied@...il.com>,
	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 Wednesday 20 October 2010, Dave Young wrote:
> be curious, why can't just fix the lock_kernel logic of i810? Fixing
> is too hard?
> 
> Find a i810 hardware should be possible, even if the hardware does not
> support SMP, can't we test the fix with preemption?

Yes, that should work too. My usual approach for removing the BKL without
having the hardware myself was to make locking stricter, i.e. replace
the BKL with a new spinlock or mutex. This way all the code would still
be serialized and if I did something wrong, lockdep would complain about
it, but there would be no risk of silent data corruption.

In case of i810, locking across DRM is rather complicated and there is no
way of doing this without making changes to other DRM code.

In fact, the only critical section that is actually protected by the BKL
are the few lines in i810_mmap_buffers. They look like they might not even
need the BKL to start with and we can just remove it even on SMP/PREEMPT,
except for perhaps the assignment to buf_priv->currently_mapped.
Someone who understands more about the driver than I do can probably figure
this out easily, but I couldn't come up with a way that doesn't risk
breaking in corner cases.

	Arnd
--
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/