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 indee
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 console_unlock.
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 p
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, eithe
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, eithe
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 indee
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 console_unlock.
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 p
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 whi
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 whi
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.
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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.
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
lo
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
lo
14 matches
Mail list logo
