On Mon, 2012-09-24 at 14:54 +0200, Daniel Vetter wrote:
> I've read through the patches and I'm hoping you don't volunteer me to
> pick these up ... ;-)
Worth a try, right? :-)
> But there doesn't seem to be anything that would
> get worse through this lockdep annotation patch, right?
No
On Mon, Sep 24, 2012 at 2:24 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
>> On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
>> > - In the printk code there's a special trylock, only used to kick off
>> > the logbuffer printk'ing in
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
> On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
> > - In the printk code there's a special trylock, only used to kick off
> > the logbuffer printk'ing in console_unlock. But all that happens
> > while lockdep is disable (since
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
> - In the printk code there's a special trylock, only used to kick off
> the logbuffer printk'ing in console_unlock. But all that happens
> while lockdep is disable (since printk does a few other evil
> tricks). So no issue there,
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk
On Mon, Sep 24, 2012 at 2:24 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in
On Mon, 2012-09-24 at 14:54 +0200, Daniel Vetter wrote:
I've read through the patches and I'm hoping you don't volunteer me to
pick these up ... ;-)
Worth a try, right? :-)
But there doesn't seem to be anything that would
get worse through this lockdep annotation patch, right?
No indeed,
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk does a few other evil
tricks). So no issue there, either.
On Tue, Sep 18, 2012 at 10:33:28AM +0300, Jani Nikula wrote:
> On Tue, 18 Sep 2012, Daniel Vetter wrote:
> > +#ifdef CONFIG_LOCKDEP
> > +struct lockdep_map console_lock_dep_map = {
> > + .name = "console_lock"
> > +};
> > +#endif
>
> static?
Yeah, static. I'm travelling atm, so will take a
On Tue, Sep 18, 2012 at 10:33:28AM +0300, Jani Nikula wrote:
On Tue, 18 Sep 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map console_lock_dep_map = {
+ .name = console_lock
+};
+#endif
static?
Yeah, static. I'm travelling atm, so will
On Tue, 18 Sep 2012, Daniel Vetter wrote:
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map console_lock_dep_map = {
> + .name = "console_lock"
> +};
> +#endif
static?
BR,
Jani.
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
On Tue, 18 Sep 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map console_lock_dep_map = {
+ .name = console_lock
+};
+#endif
static?
BR,
Jani.
___
dri-devel mailing list
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
14 matches
Mail list logo
