[RFC HACK] rtl2832: implement own lock for RegMap
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2001
09/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49 +++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..2ee5bcf 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1028,6 +1028,31 @@ static int rtl2832_regmap_gather_write(void *context,
const void *reg,
return 0;
}
+/*
+ * FIXME: Implement own RegMap locking in order to silence lockdep recursive
+ * lock warning. That happens when RegMap I2C client calls I2C mux adapter,
+ * which leads demod I2C repeater enable via demod RegMap. Operation takes two
+ * RegMap locks recursively - but those are different RegMap instances in a two
+ * different I2C drivers, so it should be deadlock.
+ */
+static void rtl2832_regmap_lock(void *__dev)
+{
+ struct rtl2832_dev *dev = __dev;
+ struct i2c_client *client = dev-client;
+
+ dev_dbg(client-dev, \n);
+ mutex_lock(dev-regmap_mutex);
+}
+
+static void rtl2832_regmap_unlock(void *__dev)
+{
+ struct rtl2832_dev *dev = __dev;
+ struct i2c_client *client = dev-client;
+
+ dev_dbg(client-dev, \n);
+ mutex_unlock(dev-regmap_mutex);
+}
+
static struct dvb_frontend *rtl2832_get_dvb_frontend(struct i2c_client *client)
{
struct rtl2832_dev *dev =
Re: [RFC HACK] rtl2832: implement own lock for RegMap
Em Thu, 18 Dec 2014 12:29:46 +0200
Antti Palosaari cr...@iki.fi escreveu:
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
Please do not add a hack just to silence a lockdep warning.
Please take a look at: Documentation/locking/lockdep-design.txt
There are some documentation there about the usage of nested locks and
how to avoid lockdep to complain.
Regards,
Mauro
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS
200109/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49
+++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..2ee5bcf 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1028,6 +1028,31 @@ static int rtl2832_regmap_gather_write(void *context,
const void *reg,
return 0;
}
+/*
+ * FIXME: Implement own RegMap locking in order to silence lockdep recursive
+ * lock warning. That happens when RegMap I2C client calls I2C mux adapter,
+ * which leads demod I2C repeater enable via demod RegMap. Operation takes
two
+ * RegMap locks recursively - but those are different RegMap instances in a
two
+ * different I2C drivers, so it should be deadlock.
+ */
+static void rtl2832_regmap_lock(void *__dev)
+{
+ struct rtl2832_dev *dev = __dev;
+ struct i2c_client *client = dev-client;
+
+
Re: [RFC HACK] rtl2832: implement own lock for RegMap
On 12/18/2014 01:21 PM, Mauro Carvalho Chehab wrote:
Em Thu, 18 Dec 2014 12:29:46 +0200
Antti Palosaari cr...@iki.fi escreveu:
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
Please do not add a hack just to silence a lockdep warning.
Please take a look at: Documentation/locking/lockdep-design.txt
There are some documentation there about the usage of nested locks and
how to avoid lockdep to complain.
I cannot see any way how those lockdep things could be used on my driver
as problematic lock itself is located inside RegMap. I think it is
RegMap which needs some special lockdep things in order to allow nested
locking of different instances.
So I think demod I2C adapter is good place for that kind of hack until
better solution is find. Defining own RegMap lock here in I2C repeater
allows all the clients be hack free using default RegMap lock.
regards
Antti
Regards,
Mauro
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2001
09/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49 +++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..2ee5bcf 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1028,6 +1028,31 @@ static int rtl2832_regmap_gather_write(void *context,
const void *reg,
return 0;
}
+/*
+ * FIXME: Implement own RegMap
Re: [RFC HACK] rtl2832: implement own lock for RegMap
Em Thu, 18 Dec 2014 16:41:28 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/18/2014 01:21 PM, Mauro Carvalho Chehab wrote:
Em Thu, 18 Dec 2014 12:29:46 +0200
Antti Palosaari cr...@iki.fi escreveu:
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
Please do not add a hack just to silence a lockdep warning.
Please take a look at: Documentation/locking/lockdep-design.txt
There are some documentation there about the usage of nested locks and
how to avoid lockdep to complain.
I cannot see any way how those lockdep things could be used on my driver
as problematic lock itself is located inside RegMap. I think it is
RegMap which needs some special lockdep things in order to allow nested
locking of different instances.
Ok. So, do a patch for RegMap and send for its maintainers.
Regards,
Mauro
So I think demod I2C adapter is good place for that kind of hack until
better solution is find. Defining own RegMap lock here in I2C repeater
allows all the clients be hack free using default RegMap lock.
regards
Antti
Regards,
Mauro
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS
200109/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49
+++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git
