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: <201010200850.07906.arnd@arndb.de>
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ