possible recursive locking detected

possible recursive locking detected

[bruno.roussel]

Hi !

Sorry for the next message without object !


I have this report in dmesg :


saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
dvb-usb: found a 'Hauppauge WinTV-NOVA-T usb2' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Hauppauge WinTV-NOVA-T usb2)
dvb-usb: MAC address: 00:0d:fe:00:00:00
DVB: registering frontend 1 (DiBcom 3000MC/P)...

=============================================
[ INFO: possible recursive locking detected ]
2.6.24.2-1mdv #1
---------------------------------------------
modprobe/2082 is trying to acquire lock:
 (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]

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

other info that might help us debug this:
1 lock held by modprobe/2082:
 #0:  (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b
[i2c_core]

stack backtrace:
Pid: 2082, comm: modprobe Not tainted 2.6.24.2-1mdv #1
 [<c01054c2>] show_trace_log_lvl+0x1a/0x2f
 [<c0105ccf>] show_trace+0x12/0x14
 [<c0105fd7>] dump_stack+0x6a/0x70
 [<c0139e5b>] __lock_acquire+0x16b/0xc32
 [<c013ad80>] lock_acquire+0x70/0x92
 [<c02c937f>] mutex_lock_nested+0xf9/0x2a4
 [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
 [<eef611fb>] dibx000_i2c_gated_tuner_xfer+0x172/0x18c [dibx000_common]
 [<eeed4140>] i2c_transfer+0x39/0x4b [i2c_core]
 [<eefbc17c>] mt2060_readreg+0x48/0x68 [mt2060]
 [<eefbc486>] mt2060_attach+0x49/0x1ef [mt2060]
 [<eefa3527>] dibusb_dib3000mc_tuner_attach+0x145/0x1fb [dvb_usb_dibusb_common]
 [<eef83c49>] dvb_usb_adapter_frontend_init+0xc4/0xe8 [dvb_usb]
 [<eef837aa>] dvb_usb_device_init+0x3e8/0x4ce [dvb_usb]
 [<eef7f01c>] nova_t_probe+0x1c/0x1e [dvb_usb_nova_t_usb2]
 [<eeeb1f51>] usb_probe_interface+0xd5/0x112 [usbcore]
 [<c02420bb>] driver_probe_device+0xca/0x14d
 [<c0242225>] __driver_attach+0x4a/0x7f
 [<c024164f>] bus_for_each_dev+0x38/0x5a
 [<c0241f25>] driver_attach+0x19/0x1b
 [<c0241966>] bus_add_driver+0x76/0x194
 [<c02423dd>] driver_register+0x67/0x6c
 [<eeeb1ae7>] usb_register_driver+0x7e/0xe5 [usbcore]
 [<eef8d01b>] nova_t_module_init+0x1b/0x38 [dvb_usb_nova_t_usb2]
 [<c0140e78>] sys_init_module+0x12c6/0x1394
 [<c0103e12>] sysenter_past_esp+0x6b/0xc9
 =======================
input: IR-receiver inside an USB DVB receiver as /class/input/input2
dvb-usb: schedule remote query interval to 100 msecs.
dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_nova_t_usb2
DVB: registering frontend 0 (ST STV0299 DVB-S)...
input: DVB on-card IR receiver as /class/input/input3
dvb-ttpci: found av7110-0.

Re: possible recursive locking detected

[Christian Kujau]

On Sun, 9 Mar 2008, bruno.roussel@free.fr wrote:
> I have this report in dmesg :
>
> saa7146_vv: saa7146 (0): registered device video0 [v4l2]
> saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
> usb-storage: device found at 2
> usb-storage: waiting for device to settle before scanning
> dvb-usb: found a 'Hauppauge WinTV-NOVA-T usb2' in warm state.
> dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
> DVB: registering new adapter (Hauppauge WinTV-NOVA-T usb2)
> dvb-usb: MAC address: 00:0d:fe:00:00:00
> DVB: registering frontend 1 (DiBcom 3000MC/P)...
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.24.2-1mdv #1
> ---------------------------------------------

Hm, strange: a similiar looking issue has been reported back in 2006, it
even comes with a patch: http://lkml.org/lkml/2006/10/14/38

..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
folks, maybe they can tell what's going on here.

C.

> modprobe/2082 is trying to acquire lock:
> (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
>
> but task is already holding lock:
> (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
>
> other info that might help us debug this:
> 1 lock held by modprobe/2082:
> #0:  (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b
> [i2c_core]
>
> stack backtrace:
> Pid: 2082, comm: modprobe Not tainted 2.6.24.2-1mdv #1
> [<c01054c2>] show_trace_log_lvl+0x1a/0x2f
> [<c0105ccf>] show_trace+0x12/0x14
> [<c0105fd7>] dump_stack+0x6a/0x70
> [<c0139e5b>] __lock_acquire+0x16b/0xc32
> [<c013ad80>] lock_acquire+0x70/0x92
> [<c02c937f>] mutex_lock_nested+0xf9/0x2a4
> [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
> [<eef611fb>] dibx000_i2c_gated_tuner_xfer+0x172/0x18c [dibx000_common]
> [<eeed4140>] i2c_transfer+0x39/0x4b [i2c_core]
> [<eefbc17c>] mt2060_readreg+0x48/0x68 [mt2060]
> [<eefbc486>] mt2060_attach+0x49/0x1ef [mt2060]
> [<eefa3527>] dibusb_dib3000mc_tuner_attach+0x145/0x1fb [dvb_usb_dibusb_common]
> [<eef83c49>] dvb_usb_adapter_frontend_init+0xc4/0xe8 [dvb_usb]
> [<eef837aa>] dvb_usb_device_init+0x3e8/0x4ce [dvb_usb]
> [<eef7f01c>] nova_t_probe+0x1c/0x1e [dvb_usb_nova_t_usb2]
> [<eeeb1f51>] usb_probe_interface+0xd5/0x112 [usbcore]
> [<c02420bb>] driver_probe_device+0xca/0x14d
> [<c0242225>] __driver_attach+0x4a/0x7f
> [<c024164f>] bus_for_each_dev+0x38/0x5a
> [<c0241f25>] driver_attach+0x19/0x1b
> [<c0241966>] bus_add_driver+0x76/0x194
> [<c02423dd>] driver_register+0x67/0x6c
> [<eeeb1ae7>] usb_register_driver+0x7e/0xe5 [usbcore]
> [<eef8d01b>] nova_t_module_init+0x1b/0x38 [dvb_usb_nova_t_usb2]
> [<c0140e78>] sys_init_module+0x12c6/0x1394
> [<c0103e12>] sysenter_past_esp+0x6b/0xc9
> =======================
> input: IR-receiver inside an USB DVB receiver as /class/input/input2
> dvb-usb: schedule remote query interval to 100 msecs.
> dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected.
> usbcore: registered new interface driver dvb_usb_nova_t_usb2
> DVB: registering frontend 0 (ST STV0299 DVB-S)...
> input: DVB on-card IR receiver as /class/input/input3
> dvb-ttpci: found av7110-0.
> --

-- 
BOFH excuse #274:

It was OK before you touched it.

Re: possible recursive locking detected

[Jiri Kosina]

On Sun, 9 Mar 2008, Christian Kujau wrote:

> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 2.6.24.2-1mdv #1
> > ---------------------------------------------
> Hm, strange: a similiar looking issue has been reported back in 2006, it 
> even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> ..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
> folks, maybe they can tell what's going on here.

I don't recall this, but from looking at the source it seems that only 
part of my patch made it upstream for some reason ... 

Bruno, does the patch below remove the warning for you? (we should rather 
used lockdep_set_class() now, when this is already available ... it wasn't 
in the time I was doping the original patch back in 2006).



Set locking depth properly (level == 0 for DVB frontend, level == 1 for 
DVB adapter).

Signed-off-by: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>

diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
index 23428cd..8c5dc35 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
@@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
 #endif
 	d->i2c_adap.algo      = d->props.i2c_algo;
 	d->i2c_adap.algo_data = NULL;
+	d->i2c_adap.level = 1;
 	d->i2c_adap.dev.parent = &d->udev->dev;
 
 	i2c_set_adapdata(&d->i2c_adap, d);
diff --git a/drivers/media/dvb/frontends/dibx000_common.c b/drivers/media/dvb/frontends/dibx000_common.c
index 315e09e..a3ed8cf 100644
--- a/drivers/media/dvb/frontends/dibx000_common.c
+++ b/drivers/media/dvb/frontends/dibx000_common.c
@@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter *i2c_adap, struct i2c_algorithm *
 	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
 	i2c_adap->algo      = algo;
 	i2c_adap->algo_data = NULL;
+	i2c_adap->level = 0;
 	i2c_set_adapdata(i2c_adap, mst);
 	if (i2c_add_adapter(i2c_adap) < 0)
 		return -ENODEV;

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: possible recursive locking detected

[Jiri Kosina]

On Sun, 9 Mar 2008, Christian Kujau wrote:

> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 2.6.24.2-1mdv #1
> > ---------------------------------------------
> Hm, strange: a similiar looking issue has been reported back in 2006, it 
> even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> ..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
> folks, maybe they can tell what's going on here.

I don't recall this, but from looking at the source it seems that only 
part of my patch made it upstream for some reason ... 

Bruno, does the patch below remove the warning for you? (we should rather 
used lockdep_set_class() now, when this is already available ... it wasn't 
in the time I was doping the original patch back in 2006).



Set locking depth properly (level == 0 for DVB frontend, level == 1 for 
DVB adapter).

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
index 23428cd..8c5dc35 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
@@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
 #endif
 	d->i2c_adap.algo      = d->props.i2c_algo;
 	d->i2c_adap.algo_data = NULL;
+	d->i2c_adap.level = 1;
 	d->i2c_adap.dev.parent = &d->udev->dev;
 
 	i2c_set_adapdata(&d->i2c_adap, d);
diff --git a/drivers/media/dvb/frontends/dibx000_common.c b/drivers/media/dvb/frontends/dibx000_common.c
index 315e09e..a3ed8cf 100644
--- a/drivers/media/dvb/frontends/dibx000_common.c
+++ b/drivers/media/dvb/frontends/dibx000_common.c
@@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter *i2c_adap, struct i2c_algorithm *
 	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
 	i2c_adap->algo      = algo;
 	i2c_adap->algo_data = NULL;
+	i2c_adap->level = 0;
 	i2c_set_adapdata(i2c_adap, mst);
 	if (i2c_add_adapter(i2c_adap) < 0)
 		return -ENODEV;

Re: possible recursive locking detected

[Jean Delvare]

On Sun, 9 Mar 2008 23:41:50 +0100 (CET), Jiri Kosina wrote:
> On Sun, 9 Mar 2008, Christian Kujau wrote:
> 
> > > =============================================
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.24.2-1mdv #1
> > > ---------------------------------------------
> > Hm, strange: a similiar looking issue has been reported back in 2006, it 
> > even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> > ..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
> > folks, maybe they can tell what's going on here.
> 
> I don't recall this, but from looking at the source it seems that only 
> part of my patch made it upstream for some reason ...

I applied the i2c-core part:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6ea23039cb1cc7c379eb5fba0ed2c53291e9bea7

But I have no idea what happened to the DVB device-driver specific part.

> 
> Bruno, does the patch below remove the warning for you? (we should rather 
> used lockdep_set_class() now, when this is already available ... it wasn't 
> in the time I was doping the original patch back in 2006).
> 
> 
> 
> Set locking depth properly (level == 0 for DVB frontend, level == 1 for 
> DVB adapter).
> 
> Signed-off-by: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
> 
> diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> index 23428cd..8c5dc35 100644
> --- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> +++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> @@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
>  #endif
>  	d->i2c_adap.algo      = d->props.i2c_algo;
>  	d->i2c_adap.algo_data = NULL;
> +	d->i2c_adap.level = 1;
>  	d->i2c_adap.dev.parent = &d->udev->dev;
>  
>  	i2c_set_adapdata(&d->i2c_adap, d);
> diff --git a/drivers/media/dvb/frontends/dibx000_common.c b/drivers/media/dvb/frontends/dibx000_common.c
> index 315e09e..a3ed8cf 100644
> --- a/drivers/media/dvb/frontends/dibx000_common.c
> +++ b/drivers/media/dvb/frontends/dibx000_common.c
> @@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter *i2c_adap, struct i2c_algorithm *
>  	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
>  	i2c_adap->algo      = algo;
>  	i2c_adap->algo_data = NULL;
> +	i2c_adap->level = 0;
>  	i2c_set_adapdata(i2c_adap, mst);
>  	if (i2c_add_adapter(i2c_adap) < 0)
>  		return -ENODEV;

Also note:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cea443a81c9c6257bf2d00f1392f7d1d4ce03b75

This patch that was applied recently to i2c-core might cause lockdep
issues. For some reason there's no "nested" variant of mutex_trylock?

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: possible recursive locking detected

[Jean Delvare]

On Sun, 9 Mar 2008 23:41:50 +0100 (CET), Jiri Kosina wrote:
> On Sun, 9 Mar 2008, Christian Kujau wrote:
> 
> > > =============================================
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.24.2-1mdv #1
> > > ---------------------------------------------
> > Hm, strange: a similiar looking issue has been reported back in 2006, it 
> > even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> > ..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
> > folks, maybe they can tell what's going on here.
> 
> I don't recall this, but from looking at the source it seems that only 
> part of my patch made it upstream for some reason ...

I applied the i2c-core part:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6ea23039cb1cc7c379eb5fba0ed2c53291e9bea7

But I have no idea what happened to the DVB device-driver specific part.

> 
> Bruno, does the patch below remove the warning for you? (we should rather 
> used lockdep_set_class() now, when this is already available ... it wasn't 
> in the time I was doping the original patch back in 2006).
> 
> 
> 
> Set locking depth properly (level == 0 for DVB frontend, level == 1 for 
> DVB adapter).
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> index 23428cd..8c5dc35 100644
> --- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> +++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> @@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
>  #endif
>  	d->i2c_adap.algo      = d->props.i2c_algo;
>  	d->i2c_adap.algo_data = NULL;
> +	d->i2c_adap.level = 1;
>  	d->i2c_adap.dev.parent = &d->udev->dev;
>  
>  	i2c_set_adapdata(&d->i2c_adap, d);
> diff --git a/drivers/media/dvb/frontends/dibx000_common.c b/drivers/media/dvb/frontends/dibx000_common.c
> index 315e09e..a3ed8cf 100644
> --- a/drivers/media/dvb/frontends/dibx000_common.c
> +++ b/drivers/media/dvb/frontends/dibx000_common.c
> @@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter *i2c_adap, struct i2c_algorithm *
>  	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
>  	i2c_adap->algo      = algo;
>  	i2c_adap->algo_data = NULL;
> +	i2c_adap->level = 0;
>  	i2c_set_adapdata(i2c_adap, mst);
>  	if (i2c_add_adapter(i2c_adap) < 0)
>  		return -ENODEV;

Also note:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cea443a81c9c6257bf2d00f1392f7d1d4ce03b75

This patch that was applied recently to i2c-core might cause lockdep
issues. For some reason there's no "nested" variant of mutex_trylock?

-- 
Jean Delvare

Re: possible recursive locking detected

[bruno.roussel]

I have switch to the new 2.6.24.3 kernel version and it's OK now
Strange ...

Thank's for all

Selon Jean Delvare <khali@linux-fr.org>:

> On Sun, 9 Mar 2008 23:41:50 +0100 (CET), Jiri Kosina wrote:
> > On Sun, 9 Mar 2008, Christian Kujau wrote:
> >
> > > > =============================================
> > > > [ INFO: possible recursive locking detected ]
> > > > 2.6.24.2-1mdv #1
> > > > ---------------------------------------------
> > > Hm, strange: a similiar looking issue has been reported back in 2006, it
> > > even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> > > ..but I cannot tell if the patch made it into mainline. I've Cc'ed the
> i2c
> > > folks, maybe they can tell what's going on here.
> >
> > I don't recall this, but from looking at the source it seems that only
> > part of my patch made it upstream for some reason ...
>
> I applied the i2c-core part:
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6ea23039cb1cc7c379eb5fba0ed2c53291e9bea7
>
> But I have no idea what happened to the DVB device-driver specific part.
>
> >
> > Bruno, does the patch below remove the warning for you? (we should rather
> > used lockdep_set_class() now, when this is already available ... it wasn't
> > in the time I was doping the original patch back in 2006).
> >
> >
> >
> > Set locking depth properly (level == 0 for DVB frontend, level == 1 for
> > DVB adapter).
> >
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> >
> > diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> > index 23428cd..8c5dc35 100644
> > --- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> > +++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> > @@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
> >  #endif
> >  	d->i2c_adap.algo      = d->props.i2c_algo;
> >  	d->i2c_adap.algo_data = NULL;
> > +	d->i2c_adap.level = 1;
> >  	d->i2c_adap.dev.parent = &d->udev->dev;
> >
> >  	i2c_set_adapdata(&d->i2c_adap, d);
> > diff --git a/drivers/media/dvb/frontends/dibx000_common.c
> b/drivers/media/dvb/frontends/dibx000_common.c
> > index 315e09e..a3ed8cf 100644
> > --- a/drivers/media/dvb/frontends/dibx000_common.c
> > +++ b/drivers/media/dvb/frontends/dibx000_common.c
> > @@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter
> *i2c_adap, struct i2c_algorithm *
> >  	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
> >  	i2c_adap->algo      = algo;
> >  	i2c_adap->algo_data = NULL;
> > +	i2c_adap->level = 0;
> >  	i2c_set_adapdata(i2c_adap, mst);
> >  	if (i2c_add_adapter(i2c_adap) < 0)
> >  		return -ENODEV;
>
> Also note:
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cea443a81c9c6257bf2d00f1392f7d1d4ce03b75
>
> This patch that was applied recently to i2c-core might cause lockdep
> issues. For some reason there's no "nested" variant of mutex_trylock?
>
> --
> Jean Delvare
>

possible recursive locking detected

[Bernd Schubert]

with 2.6.20 and almost all debugging options I get this:

[  293.840172] =============================================
[  293.847880] [ INFO: possible recursive locking detected ]
[  293.853862] 2.6.20.3-debug #11
[  293.857288] ---------------------------------------------
[  293.863243] dd/6202 is trying to acquire lock:
[  293.868192]  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff881693a6>] xfs_ilock+0x56/0x7a [xfs]
[  293.878200]
[  293.878201] but task is already holding lock:
[  293.884788]  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff881693a6>] xfs_ilock+0x56/0x7a [xfs]
[  293.894802]
[  293.894803] other info that might help us debug this:
[  293.902116] 2 locks held by dd/6202:
[  293.906114]  #0:  (&inode->i_mutex){--..}, at: [<ffffffff804adbbd>] mutex_lock+0x23/0x27
[  293.915438]  #1:  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff881693a6>] xfs_ilock+0x56/0x7a [xfs]
[  293.925977]
[  293.925978] stack backtrace:
[  293.930948]
[  293.930949] Call Trace:
[  293.935457]  [<ffffffff8024325a>] __lock_acquire+0x44d/0xc60
[  293.941707]  [<ffffffff80242699>] mark_held_locks+0x5a/0x71
[  293.956483]  [<ffffffff881693a6>] :xfs:xfs_ilock+0x56/0x7a
[  293.962537]  [<ffffffff80243e94>] lock_acquire+0x7c/0xa0
[  293.968447]  [<ffffffff881693a6>] :xfs:xfs_ilock+0x56/0x7a
[  293.974510]  [<ffffffff8023f6cb>] down_write+0x33/0x3f
[  293.980236]  [<ffffffff881693a6>] :xfs:xfs_ilock+0x56/0x7a
[  293.986315]  [<ffffffff88169895>] :xfs:xfs_iget+0x43c/0x7a8
[  293.992509]  [<ffffffff8817f4ad>] :xfs:xfs_trans_iget+0xa9/0x115
[  293.999177]  [<ffffffff8816aa74>] :xfs:xfs_ialloc+0x91/0x453
[  294.005475]  [<ffffffff8817fd6a>] :xfs:xfs_dir_ialloc+0x74/0x286
[  294.012145]  [<ffffffff88184b4b>] :xfs:xfs_create+0x347/0x626
[  294.018532]  [<ffffffff8818ee57>] :xfs:xfs_vn_mknod+0x1e2/0x432
[  294.025077]  [<ffffffff8023f733>] up_read+0x24/0x28
[  294.030501]  [<ffffffff88169f69>] :xfs:xfs_iunlock+0x74/0x79
[  294.036788]  [<ffffffff881837d1>] :xfs:xfs_access+0x43/0x4e
[  294.042943]  [<ffffffff80243a15>] __lock_acquire+0xc08/0xc60
[  294.049200]  [<ffffffff804afa5b>] _spin_unlock_irqrestore+0x3f/0x47
[  294.056083]  [<ffffffff80242699>] mark_held_locks+0x5a/0x71
[  294.062239]  [<ffffffff804afa5b>] _spin_unlock_irqrestore+0x3f/0x47
[  294.069138]  [<ffffffff802428a5>] trace_hardirqs_on+0x129/0x154
[  294.075690]  [<ffffffff881837d1>] :xfs:xfs_access+0x43/0x4e
[  294.081883]  [<ffffffff8818f0b2>] :xfs:xfs_vn_create+0xb/0xd
[  294.088139]  [<ffffffff80281eeb>] vfs_create+0xb7/0xfb
[  294.093826]  [<ffffffff80282342>] open_namei+0x1d1/0x6d3
[  294.099717]  [<ffffffff80243a15>] __lock_acquire+0xc08/0xc60
[  294.105970]  [<ffffffff80278796>] do_filp_open+0x5b/0x7e
[  294.111851]  [<ffffffff80278b2a>] do_sys_open+0x4d/0xd4
[  294.117636]  [<ffffffff80278bcc>] sys_open+0x1b/0x1d
[  294.123128]  [<ffffffff8020965e>] system_call+0x7e/0x83
[  294.128913]

Thanks,
Bernd

Re: possible recursive locking detected

[Eric Sandeen]

Bernd Schubert wrote:
> with 2.6.20 and almost all debugging options I get this:
> 
> [  293.840172] =============================================
> [  293.847880] [ INFO: possible recursive locking detected ]
> [  293.853862] 2.6.20.3-debug #11
> [  293.857288] ---------------------------------------------

Many of these have been addressed with this patch:

http://oss.sgi.com/archives/xfs/2007-04/msg00177.html

-Eric

possible recursive locking detected

[Christian Kujau]

Hi,

when I enabled a few more debug-options in the kernel (vanilla 
2.6.21-rc5), I came across:

[ INFO: possible recursive locking detected ]
2.6.21-rc5 #2
---------------------------------------------
rm/32198 is trying to acquire lock:
xfs_ilock+0x71/0xa0

but task is already holding lock:
xfs_ilock+0x71/0xa0

other info that might help us debug this:
3 locks held by rm/32198:
do_unlinkat+0x96/0x160
vfs_unlink+0x75/0xe0
xfs_ilock+0x71/0xa0

stack backtrace:
__lock_acquire+0xa99/0x1010
lock_acquire+0x57/0x70
xfs_ilock+0x71/0xa0
down_write+0x38/0x50
xfs_ilock+0x71/0xa0
xfs_ilock+0x71/0xa0
xfs_lock_dir_and_entry+0xf6/0x100
xfs_remove+0x197/0x4e0
d_instantiate+0x19/0x40
d_rehash+0x20/0x50
vfs_unlink+0x75/0xe0
xfs_vn_unlink+0x23/0x60
__mutex_lock_slowpath+0x13f/0x280
mark_held_locks+0x6b/0x90
__mutex_lock_slowpath+0x13f/0x280
__mutex_lock_slowpath+0x13f/0x280
trace_hardirqs_on+0xb9/0x160
vfs_unlink+0x75/0xe0
__mutex_lock_slowpath+0x132/0x280
vfs_unlink+0x75/0xe0
permission+0x91/0xf0
vfs_unlink+0x89/0xe0
do_unlinkat+0xd2/0x160
sysenter_past_esp+0x8d/0x99
trace_hardirqs_on+0xb9/0x160
sysenter_past_esp+0x5d/0x99
  =======================


Is this something I have to worry about?
Please see http://nerdbynature.de/bits/2.6.21-rc5/ for a few more 
details.

Thanks,
Christian.
-- 
BOFH excuse #372:

Forced to support NT servers; sysadmins quit.

Re: possible recursive locking detected

[Christian Kujau]

Hi there,

On Mon, April 2, 2007 19:18, Christian Kujau wrote:
> when I enabled a few more debug-options in the kernel (vanilla
> 2.6.21-rc5), I came across:
>
> [ INFO: possible recursive locking detected ]
> 2.6.21-rc5 #2

The same happened with -rc7, see below. Can anyone comment if this
is/could lead to a problem?


Thanks,
Christian.

Please see http://nerdbynature.de/bits/2.6.21-rc7/ for full details:

[37380.435689] =============================================
[37380.435703] [ INFO: possible recursive locking detected ]
[37380.435707] 2.6.21-rc7 #6
[37380.435710] ---------------------------------------------
[37380.435715] rm/14081 is trying to acquire lock:
[37380.435719]  (&(&ip->i_lock)->mr_lock){----}, at: [<c0246871>]
xfs_ilock+0x71/0xa0
[37380.435734]
[37380.435735] but task is already holding lock:
[37380.435739]  (&(&ip->i_lock)->mr_lock){----}, at: [<c0246871>]
xfs_ilock+0x71/0xa0
[37380.435749]
[37380.435750] other info that might help us debug this:
[37380.435755] 3 locks held by rm/14081:
[37380.435758]  #0:  (&inode->i_mutex/1){--..}, at: [<c0167196>]
do_unlinkat+0x96/0x160
[37380.435770]  #1:  (&inode->i_mutex){--..}, at: [<c0165475>]
vfs_unlink+0x75/0xe0
[37380.435782]  #2:  (&(&ip->i_lock)->mr_lock){----}, at: [<c0246871>]
xfs_ilock+0x71/0xa0
[37380.435792]
[37380.435792] stack backtrace:
[37380.435798]  [<c0134aa9>] __lock_acquire+0xa99/0x1010
[37380.435808]  [<c0135077>] lock_acquire+0x57/0x70
[37380.435814]  [<c0246871>] xfs_ilock+0x71/0xa0
[37380.435820]  [<c012e408>] down_write+0x38/0x50
[37380.435828]  [<c0246871>] xfs_ilock+0x71/0xa0
[37380.435833]  [<c0246871>] xfs_ilock+0x71/0xa0
[37380.435839]  [<c026bc06>] xfs_lock_dir_and_entry+0xf6/0x100
[37380.435847]  [<c026c287>] xfs_remove+0x197/0x4e0
[37380.435853]  [<c016dce9>] d_instantiate+0x19/0x40
[37380.435860]  [<c016db50>] d_rehash+0x20/0x50
[37380.435868]  [<c0165475>] vfs_unlink+0x75/0xe0
[37380.435875]  [<c0273ce3>] xfs_vn_unlink+0x23/0x60
[37380.435882]  [<c03ce55f>] __mutex_lock_slowpath+0x13f/0x280
[37380.435889]  [<c013394b>] mark_held_locks+0x6b/0x90
[37380.435894]  [<c03ce55f>] __mutex_lock_slowpath+0x13f/0x280
[37380.435900]  [<c03ce55f>] __mutex_lock_slowpath+0x13f/0x280
[37380.435906]  [<c0133ad9>] trace_hardirqs_on+0xb9/0x160
[37380.435913]  [<c0165475>] vfs_unlink+0x75/0xe0
[37380.435919]  [<c03ce552>] __mutex_lock_slowpath+0x132/0x280
[37380.435925]  [<c0165475>] vfs_unlink+0x75/0xe0
[37380.435931]  [<c0164a51>] permission+0x91/0xf0
[37380.435938]  [<c0165489>] vfs_unlink+0x89/0xe0
[37380.435945]  [<c01671d2>] do_unlinkat+0xd2/0x160
[37380.435953]  [<c0102938>] restore_nocheck+0x12/0x15
[37380.435959]  [<c0133ad9>] trace_hardirqs_on+0xb9/0x160
[37380.435967]  [<c0102864>] sysenter_past_esp+0x5d/0x99
[37380.435976]  =======================


-- 
BOFH excuse #442:

Trojan horse ran out of hay

Re: possible recursive locking detected

[Eric Sandeen]

Christian Kujau wrote:
> Hi there,
> 
> On Mon, April 2, 2007 19:18, Christian Kujau wrote:
>> when I enabled a few more debug-options in the kernel (vanilla
>> 2.6.21-rc5), I came across:
>>
>> [ INFO: possible recursive locking detected ]
>> 2.6.21-rc5 #2
> 
> The same happened with -rc7, see below. Can anyone comment if this
> is/could lead to a problem?
>

The consensus seems to be that it is cosmetic.

-Eric

Re: possible recursive locking detected

[Christoph Hellwig]

On Mon, Apr 23, 2007 at 02:46:43PM -0500, Eric Sandeen wrote:
> Christian Kujau wrote:
> > Hi there,
> > 
> > On Mon, April 2, 2007 19:18, Christian Kujau wrote:
> >> when I enabled a few more debug-options in the kernel (vanilla
> >> 2.6.21-rc5), I came across:
> >>
> >> [ INFO: possible recursive locking detected ]
> >> 2.6.21-rc5 #2
> > 
> > The same happened with -rc7, see below. Can anyone comment if this
> > is/could lead to a problem?
> >
> 
> The consensus seems to be that it is cosmetic.

It's not really cosmetic.  It means i_lock and i_iolock are beeing
acquired without an order that is detectable by lockdep.  At the very
first it means annotations for lockdep are missing, because acquiring
two per-inode locks at the same time is a basic fact in unix filesystems.
But deeper than that the rules for taking both locks are not very well
defined in XFS.  These rules at least need documentation in form of
lockdep annotations, and possibly some fixes and cleanups around the
more dirty areas like xfs_lock_for_rename() or xfs_lock_dir_and_entry()

Re: possible recursive locking detected

[Christian Kujau]

On Mon, April 23, 2007 22:19, Christoph Hellwig wrote:
> It's not really cosmetic.  It means i_lock and i_iolock are beeing
> acquired without an order that is detectable by lockdep.  At the very first
> it means annotations for lockdep are missing, because acquiring two
> per-inode locks at the same time is a basic fact in unix filesystems.

Thank you both for your comments, now I can sleep better again ;)

Christian.
-- 
BOFH excuse #442:

Trojan horse ran out of hay