lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jiri Kosina]

Hi,

(Andi on CC because of the DWARF2 unwinder stuck message)

when hotplugging AverTV DVB-T tuner, I get:

=============================================
[ INFO: possible recursive locking detected ]
2.6.19-rc1-mm1 #4
---------------------------------------------
khubd/451 is trying to acquire lock:
(&adap->bus_lock){--..}, at: [<f8902177>] i2c_transfer+0x23/0x40 
[i2c_core]

but task is already holding lock:
(&adap->bus_lock){--..}, at: [<f8902177>] i2c_transfer+0x23/0x40 
[i2c_core]

other info that might help us debug this:
1 lock held by khubd/451:
#0: (&adap->bus_lock){--..}, at: [<f8902177>] i2c_transfer+0x23/0x40 
[i2c_core]

stack backtrace:
[<c0103b69>] dump_trace+0x65/0x1a2
[<c0103cb6>] show_trace_log_lvl+0x10/0x20
[<c0103f84>] show_trace+0xa/0xc
[<c0103f99>] dump_stack+0x13/0x15
[<c0132ea4>] __lock_acquire+0x7bd/0xa05
[<c01333c1>] lock_acquire+0x5c/0x7b
[<c034b683>] __mutex_lock_slowpath+0xab/0x1de
[<f8902177>] i2c_transfer+0x23/0x40 [i2c_core]
[<f88fa1bf>] dibx000_i2c_gated_tuner_xfer+0x166/0x185 [dibx000_common]
[<f8902183>] i2c_transfer+0x2f/0x40 [i2c_core]
[<f891f04b>] mt2060_readreg+0x4b/0x69 [mt2060]
[<f891f45e>] mt2060_attach+0x40/0x1ea [mt2060]
[<f895f468>] dibusb_dib3000mc_tuner_attach+0x126/0x16c 
[dvb_usb_dibusb_common]
[<d10ea000>] 0xd10ea000
DWARF2 unwinder stuck at 0xd10ea000
Leftover inexact backtrace:
[<f88f3f7f>] dvb_usb_adapter_frontend_init+0xb9/0xd7 [dvb_usb]
[<f88f36e5>] dvb_usb_device_init+0x383/0x46e [dvb_usb]
[<f895c08a>] a800_probe+0x11/0x13 [dvb_usb_a800]
[<c02bde12>] usb_probe_interface+0x5c/0x7e
[<c0257384>] really_probe+0x5e/0xbd
[<c02576c7>] __device_attach+0x0/0x5
[<c02569ba>] bus_for_each_drv+0x35/0x5d
[<c0257453>] device_attach+0x60/0x74
[<c02576c7>] __device_attach+0x0/0x5
[<c0256a2f>] bus_attach_device+0x1e/0x41
[<c0255d49>] device_add+0x347/0x4f1
[<c015ed9d>] kfree+0xb5/0xbc
[<c02bd07d>] usb_set_configuration+0x30d/0x35e
[<c02c25ec>] generic_probe+0x154/0x188
[<c02bd8cc>] usb_probe_device+0x32/0x37
[<c0257384>] really_probe+0x5e/0xbd
[<c02576c7>] __device_attach+0x0/0x5
[<c02569ba>] bus_for_each_drv+0x35/0x5d
[<c0257453>] device_attach+0x60/0x74
[<c02576c7>] __device_attach+0x0/0x5
[<c0256a2f>] bus_attach_device+0x1e/0x41
[<c0255d49>] device_add+0x347/0x4f1
[<c02b8236>] __usb_new_device+0x118/0x14a
[<c02ba166>] hub_thread+0x636/0x974
[<c012c656>] autoremove_wake_function+0x0/0x2d
[<c02b9b30>] hub_thread+0x0/0x974
[<c012c607>] kthread+0xc1/0xee
[<c012c546>] kthread+0x0/0xee
[<c01038a3>] kernel_thread_helper+0x7/0x10
=======================                                   

This could be easily solved, as this is recursive locking situation with 
child-parent hierarchy.

I would like to use the same approach we used with Peter Zijlstra to fix 
lockdep warnings in drivers/input/serio.c - i.e. taking advantage of newly 
introduced lockdep_set_subclass(), to do it in a clean way.

However the patch introducing lockdep_set_subclass() is currently only in 
Dmitry's input tree (commit 4dfbb9d8c6cbfc32faa5c71145bd2a43e1f8237c) - 
but the fix for DVB/I2C hardly belongs to input tree, so I am quite stuck.

What are the merge plans of input tree? Is it going in some short time 
into mainline or into -mm?

Thanks,

-- 
Jiri Kosina

Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Dmitry Torokhov]

On Thursday 12 October 2006 09:33, Jiri Kosina wrote:

> 
> What are the merge plans of input tree? Is it going in some short time 
> into mainline or into -mm?
> 

The patch os in my tree and Andrew pulled it in -mm. I am planning to ask
Linus to pull in the next couple of days.

-- 
Dmitry

Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Ingo Molnar]

* Jiri Kosina <jikos@jikos.cz> wrote:

> However the patch introducing lockdep_set_subclass() is currently only 
> in Dmitry's input tree (commit 
> 4dfbb9d8c6cbfc32faa5c71145bd2a43e1f8237c) - but the fix for DVB/I2C 
> hardly belongs to input tree, so I am quite stuck.

It looks good to me - i'd suggest to get that commit upstream, either 
directly or via the input tree.

	Ingo

dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Andi Kleen]

On Thursday 12 October 2006 15:33, Jiri Kosina wrote:
> Hi,
> 
> (Andi on CC because of the DWARF2 unwinder stuck message)
> 
> when hotplugging AverTV DVB-T tuner, I get:
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.19-rc1-mm1 #4
> ---------------------------------------------
> khubd/451 is trying to acquire lock:
> (&adap->bus_lock){--..}, at: [<f8902177>] i2c_transfer+0x23/0x40 
> [i2c_core]
> 
> but task is already holding lock:
> (&adap->bus_lock){--..}, at: [<f8902177>] i2c_transfer+0x23/0x40 
> [i2c_core]
> 
> other info that might help us debug this:
> 1 lock held by khubd/451:
> #0: (&adap->bus_lock){--..}, at: [<f8902177>] i2c_transfer+0x23/0x40 
> [i2c_core]
> 
> stack backtrace:
> [<c0103b69>] dump_trace+0x65/0x1a2
> [<c0103cb6>] show_trace_log_lvl+0x10/0x20
> [<c0103f84>] show_trace+0xa/0xc
> [<c0103f99>] dump_stack+0x13/0x15
> [<c0132ea4>] __lock_acquire+0x7bd/0xa05
> [<c01333c1>] lock_acquire+0x5c/0x7b
> [<c034b683>] __mutex_lock_slowpath+0xab/0x1de
> [<f8902177>] i2c_transfer+0x23/0x40 [i2c_core]
> [<f88fa1bf>] dibx000_i2c_gated_tuner_xfer+0x166/0x185 [dibx000_common]
> [<f8902183>] i2c_transfer+0x2f/0x40 [i2c_core]
> [<f891f04b>] mt2060_readreg+0x4b/0x69 [mt2060]
> [<f891f45e>] mt2060_attach+0x40/0x1ea [mt2060]
> [<f895f468>] dibusb_dib3000mc_tuner_attach+0x126/0x16c 
> [dvb_usb_dibusb_common]
> [<d10ea000>] 0xd10ea000
> DWARF2 unwinder stuck at 0xd10ea000

Hmm, no assembly code or anything. Jan, do you have any ideas?
This looks just like a simple callback that goes over a module
boundary.

-Andi

> Leftover inexact backtrace:
> [<f88f3f7f>] dvb_usb_adapter_frontend_init+0xb9/0xd7 [dvb_usb]
> [<f88f36e5>] dvb_usb_device_init+0x383/0x46e [dvb_usb]
> [<f895c08a>] a800_probe+0x11/0x13 [dvb_usb_a800]
> [<c02bde12>] usb_probe_interface+0x5c/0x7e
> [<c0257384>] really_probe+0x5e/0xbd
> [<c02576c7>] __device_attach+0x0/0x5
> [<c02569ba>] bus_for_each_drv+0x35/0x5d
> [<c0257453>] device_attach+0x60/0x74
> [<c02576c7>] __device_attach+0x0/0x5
> [<c0256a2f>] bus_attach_device+0x1e/0x41
> [<c0255d49>] device_add+0x347/0x4f1
> [<c015ed9d>] kfree+0xb5/0xbc
> [<c02bd07d>] usb_set_configuration+0x30d/0x35e
> [<c02c25ec>] generic_probe+0x154/0x188
> [<c02bd8cc>] usb_probe_device+0x32/0x37
> [<c0257384>] really_probe+0x5e/0xbd
> [<c02576c7>] __device_attach+0x0/0x5
> [<c02569ba>] bus_for_each_drv+0x35/0x5d
> [<c0257453>] device_attach+0x60/0x74
> [<c02576c7>] __device_attach+0x0/0x5
> [<c0256a2f>] bus_attach_device+0x1e/0x41
> [<c0255d49>] device_add+0x347/0x4f1
> [<c02b8236>] __usb_new_device+0x118/0x14a
> [<c02ba166>] hub_thread+0x636/0x974
> [<c012c656>] autoremove_wake_function+0x0/0x2d
> [<c02b9b30>] hub_thread+0x0/0x974
> [<c012c607>] kthread+0xc1/0xee
> [<c012c546>] kthread+0x0/0xee
> [<c01038a3>] kernel_thread_helper+0x7/0x10
> =======================                                   
> 
> This could be easily solved, as this is recursive locking situation with 
> child-parent hierarchy.
> 
> I would like to use the same approach we used with Peter Zijlstra to fix 
> lockdep warnings in drivers/input/serio.c - i.e. taking advantage of newly 
> introduced lockdep_set_subclass(), to do it in a clean way.
> 
> However the patch introducing lockdep_set_subclass() is currently only in 
> Dmitry's input tree (commit 4dfbb9d8c6cbfc32faa5c71145bd2a43e1f8237c) - 
> but the fix for DVB/I2C hardly belongs to input tree, so I am quite stuck.
> 
> What are the merge plans of input tree? Is it going in some short time 
> into mainline or into -mm?
> 
> Thanks,
> 

dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jan Beulich]

>> stack backtrace:
>> [<c0103b69>] dump_trace+0x65/0x1a2
>> [<c0103cb6>] show_trace_log_lvl+0x10/0x20
>> [<c0103f84>] show_trace+0xa/0xc
>> [<c0103f99>] dump_stack+0x13/0x15
>> [<c0132ea4>] __lock_acquire+0x7bd/0xa05
>> [<c01333c1>] lock_acquire+0x5c/0x7b
>> [<c034b683>] __mutex_lock_slowpath+0xab/0x1de
>> [<f8902177>] i2c_transfer+0x23/0x40 [i2c_core]
>> [<f88fa1bf>] dibx000_i2c_gated_tuner_xfer+0x166/0x185 [dibx000_common]
>> [<f8902183>] i2c_transfer+0x2f/0x40 [i2c_core]
>> [<f891f04b>] mt2060_readreg+0x4b/0x69 [mt2060]
>> [<f891f45e>] mt2060_attach+0x40/0x1ea [mt2060]
>> [<f895f468>] dibusb_dib3000mc_tuner_attach+0x126/0x16c 
>> [dvb_usb_dibusb_common]
>> [<d10ea000>] 0xd10ea000
>> DWARF2 unwinder stuck at 0xd10ea000
>
>Hmm, no assembly code or anything. Jan, do you have any ideas?
>This looks just like a simple callback that goes over a module
>boundary.

No, except if this was compiled with gcc 4.0.x (or maybe earlier), in which
case inspection of the unwind data might be needed to tell if it's one of the
mis-generated cases that we saw earlier.

Again - a stack trace alone (as above) will never be likely to yield anything,
raw stack data and in some (most?) cases the relevant unwind data are also
needed.

Jan

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jiri Kosina]

On Mon, 16 Oct 2006, Jan Beulich wrote:

> >> [<c0103b69>] dump_trace+0x65/0x1a2
> >> [<c0103cb6>] show_trace_log_lvl+0x10/0x20
> >> [<c0103f84>] show_trace+0xa/0xc
> >> [<c0103f99>] dump_stack+0x13/0x15
> >> [<c0132ea4>] __lock_acquire+0x7bd/0xa05
> >> [<c01333c1>] lock_acquire+0x5c/0x7b
> >> [<c034b683>] __mutex_lock_slowpath+0xab/0x1de
> >> [<f8902177>] i2c_transfer+0x23/0x40 [i2c_core]
> >> [<f88fa1bf>] dibx000_i2c_gated_tuner_xfer+0x166/0x185 [dibx000_common]
> >> [<f8902183>] i2c_transfer+0x2f/0x40 [i2c_core]
> >> [<f891f04b>] mt2060_readreg+0x4b/0x69 [mt2060]
> >> [<f891f45e>] mt2060_attach+0x40/0x1ea [mt2060]
> >> [<f895f468>] dibusb_dib3000mc_tuner_attach+0x126/0x16c 
> >> [dvb_usb_dibusb_common]
> >> [<d10ea000>] 0xd10ea000
> >> DWARF2 unwinder stuck at 0xd10ea000
> >Hmm, no assembly code or anything. Jan, do you have any ideas? This 
> >looks just like a simple callback that goes over a module boundary.
> No, except if this was compiled with gcc 4.0.x (or maybe earlier), in which
> case inspection of the unwind data might be needed to tell if it's one of the
> mis-generated cases that we saw earlier.

Hi,

(strippped CC list a bit)

Yes, it was compiled using gcc 4.0.2, specifically gcc (GCC) 4.0.2 
20051125 (Red Hat 4.0.2-8). I can easily reproduce this, what additional 
information do you need? Or should I just try with newer gcc?

-- 
Jiri Kosina

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jan Beulich]

>Yes, it was compiled using gcc 4.0.2, specifically gcc (GCC) 4.0.2 
>20051125 (Red Hat 4.0.2-8). I can easily reproduce this, what additional 
>information do you need? Or should I just try with newer gcc?

Two possible paths:
a) Try with gcc 4.1.x.
b) Send me the offending .o (presumably the one containing dibusb_dib3000mc_tuner_attach)

Jan

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jiri Kosina]

On Mon, 16 Oct 2006, Jan Beulich wrote:

> >Yes, it was compiled using gcc 4.0.2, specifically gcc (GCC) 4.0.2 
> >20051125 (Red Hat 4.0.2-8). I can easily reproduce this, what 
> >additional information do you need? Or should I just try with newer 
> >gcc?
> Two possible paths:
> a) Try with gcc 4.1.x.

Will do probably later today.

> b) Send me the offending .o (presumably the one containing 
> dibusb_dib3000mc_tuner_attach)

You can get it from http://www.jikos.cz/jikos/junk/dibusb-common.o

-- 
Jiri Kosina

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jan Beulich]

>>> Jiri Kosina <jikos@jikos.cz> 16.10.06 15:08 >>>
>On Mon, 16 Oct 2006, Jan Beulich wrote:
>
>> >Yes, it was compiled using gcc 4.0.2, specifically gcc (GCC) 4.0.2 
>> >20051125 (Red Hat 4.0.2-8). I can easily reproduce this, what 
>> >additional information do you need? Or should I just try with newer 
>> >gcc?
>> Two possible paths:
>> a) Try with gcc 4.1.x.
>
>Will do probably later today.
>
>> b) Send me the offending .o (presumably the one containing 
>> dibusb_dib3000mc_tuner_attach)
>
>You can get it from http://www.jikos.cz/jikos/junk/dibusb-common.o 

Yes, unfortunately this is another instance of gcc 4.0 generating bad
unwind data when optimizing and not accumulating outgoing args.
Andi - did you already create a patch implementing Michael's suggestion?

Jan

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Andi Kleen]

On Monday 16 October 2006 15:30, Jan Beulich wrote:
> >>> Jiri Kosina <jikos@jikos.cz> 16.10.06 15:08 >>>
> >On Mon, 16 Oct 2006, Jan Beulich wrote:
> >
> >> >Yes, it was compiled using gcc 4.0.2, specifically gcc (GCC) 4.0.2 
> >> >20051125 (Red Hat 4.0.2-8). I can easily reproduce this, what 
> >> >additional information do you need? Or should I just try with newer 
> >> >gcc?
> >> Two possible paths:
> >> a) Try with gcc 4.1.x.
> >
> >Will do probably later today.
> >
> >> b) Send me the offending .o (presumably the one containing 
> >> dibusb_dib3000mc_tuner_attach)
> >
> >You can get it from http://www.jikos.cz/jikos/junk/dibusb-common.o 
> 
> Yes, unfortunately this is another instance of gcc 4.0 generating bad
> unwind data when optimizing and not accumulating outgoing args.
> Andi - did you already create a patch implementing Michael's suggestion?

You mean using -maccumulate-outgoing-args ? Not yet.

I guess we can do it unconditionally for all gccs on both i386
and x86-64, right?

-Andi

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Jan Beulich]

>> Yes, unfortunately this is another instance of gcc 4.0 generating bad
>> unwind data when optimizing and not accumulating outgoing args.
>> Andi - did you already create a patch implementing Michael's suggestion?
>
>You mean using -maccumulate-outgoing-args ? Not yet.
>
>I guess we can do it unconditionally for all gccs on both i386
>and x86-64, right?

Yes, I concluded this from Michael's description; what I don't know is
whether the option isn't available on very old gcc-s.

Jan

Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans?

[Andi Kleen]

On Monday 16 October 2006 16:24, Jan Beulich wrote:
> >> Yes, unfortunately this is another instance of gcc 4.0 generating bad
> >> unwind data when optimizing and not accumulating outgoing args.
> >> Andi - did you already create a patch implementing Michael's suggestion?
> >
> >You mean using -maccumulate-outgoing-args ? Not yet.
> >
> >I guess we can do it unconditionally for all gccs on both i386
> >and x86-64, right?
> 
> Yes, I concluded this from Michael's description; what I don't know is
> whether the option isn't available on very old gcc-s.

Mainline only supports gcc 3.1+ these days, so we don't really care
about those.

I did the change. 

-Andi