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