Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

11 messages, 4 authors, 2013-01-17 · open the first message on its own page

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Sedat Dilek <hidden>
Date: 2013-01-05 12:13:30

Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Takashi Iwai <hidden>
Date: 2013-01-15 14:25:22

At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)


thanks,

Takashi

=
[    3.228454] [drm] Initialized drm 1.1.0 20060810
[    3.317144] [drm] radeon defaulting to kernel modesetting.
[    3.330546] [drm] radeon kernel modesetting enabled.
[    3.343942] checking generic (c0000000 1000000) vs hw (c0000000 10000000)
[    3.343946] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
[    3.357376] 
[    3.357377] ===========================
[    3.357378] [ INFO: possible circular locking dependency detected ]
[    3.357380] 3.8.0-rc3-test+ #82 Not tainted
[    3.357381] -------------------------------------------------------
[    3.357383] udevd/137 is trying to acquire lock:
[    3.357394]  (console_lock){+.+.+.}, at: [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[    3.357395] 
[    3.357395] but task is already holding lock:
[    3.357402]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[    3.357403] 
[    3.357403] which lock already depends on the new lock.
[    3.357403] 
[    3.357404] 
[    3.357404] the existing dependency chain (in reverse order) is:
[    3.357407] 
[    3.357407] -> #1 ((fb_notifier_list).rwsem){.+.+.+}:
[    3.357411]        [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[    3.357417]        [<ffffffff81643dc2>] down_read+0x42/0x57
[    3.357419]        [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[    3.357422]        [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[    3.357426]        [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[    3.357428]        [<ffffffff8138e302>] register_framebuffer+0x1c2/0x2f0
[    3.357433]        [<ffffffff81d1748e>] vesafb_probe+0x6e0/0x760
[    3.357437]        [<ffffffff8142afbe>] platform_drv_probe+0x3e/0x70
[    3.357440]        [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[    3.357442]        [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[    3.357445]        [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[    3.357447]        [<ffffffff814286a9>] driver_attach+0x19/0x20
[    3.357450]        [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[    3.357452]        [<ffffffff81429792>] driver_register+0x72/0x170
[    3.357455]        [<ffffffff8142a7e1>] platform_driver_register+0x41/0x50
[    3.357458]        [<ffffffff8142a806>] platform_driver_probe+0x16/0xa0
[    3.357460]        [<ffffffff81d16d6b>] vesafb_init+0x215/0x258
[    3.357464]        [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[    3.357468]        [<ffffffff816258ec>] kernel_init+0x1fc/0x370
[    3.357471]        [<ffffffff8164e1fc>] ret_from_fork+0x7c/0xb0
[    3.357474] 
[    3.357474] -> #0 (console_lock){+.+.+.}:
[    3.357476]        [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
[    3.357478]        [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[    3.357482]        [<ffffffff81048fbf>] console_lock+0x6f/0x80
[    3.357485]        [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[    3.357489]        [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
[    3.357492]        [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
[    3.357495]        [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
[    3.357497]        [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[    3.357500]        [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[    3.357502]        [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
[    3.357505]        [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
[    3.357507]        [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
[    3.357532]        [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
[    3.357536]        [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
[    3.357539]        [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
[    3.357542]        [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[    3.357544]        [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[    3.357547]        [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[    3.357549]        [<ffffffff814286a9>] driver_attach+0x19/0x20
[    3.357552]        [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[    3.357554]        [<ffffffff81429792>] driver_register+0x72/0x170
[    3.357557]        [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
[    3.357577]        [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
[    3.357594]        [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
[    3.357597]        [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[    3.357600]        [<ffffffff810c4b53>] load_module+0x1043/0x1510
[    3.357603]        [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
[    3.357605]        [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f
[    3.357606] 
[    3.357606] other info that might help us debug this:
[    3.357606] 
[    3.357607]  Possible unsafe locking scenario:
[    3.357607] 
[    3.357608]        CPU0                    CPU1
[    3.357609]        ----                    ----
[    3.357611]   lock((fb_notifier_list).rwsem);
[    3.357613]                                lock(console_lock);
[    3.357615]                                lock((fb_notifier_list).rwsem);
[    3.357616]   lock(console_lock);
[    3.357617] 
[    3.357617]  *** DEADLOCK ***
[    3.357617] 
[    3.357619] 5 locks held by udevd/137:
[    3.357624]  #0:  (&__lockdep_no_validate__){......}, at: [<ffffffff81429083>] __driver_attach+0x53/0xb0
[    3.357628]  #1:  (&__lockdep_no_validate__){......}, at: [<ffffffff81429091>] __driver_attach+0x61/0xb0
[    3.357633]  #2:  (registration_lock){+.+.+.}, at: [<ffffffff8138e45b>] remove_conflicting_framebuffers+0x2b/0x60
[    3.357637]  #3:  (&fb_info->lock){+.+.+.}, at: [<ffffffff8138d0c1>] lock_fb_info+0x21/0x60
[    3.357642]  #4:  ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[    3.357643] 
[    3.357643] stack backtrace:
[    3.357645] Pid: 137, comm: udevd Not tainted 3.8.0-rc3-test+ #82
[    3.357646] Call Trace:
[    3.357652]  [<ffffffff8163b136>] print_circular_bug+0x1fb/0x20c
[    3.357655]  [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
[    3.357658]  [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[    3.357661]  [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
[    3.357664]  [<ffffffff810b2b0d>] ? trace_hardirqs_on+0xd/0x10
[    3.357667]  [<ffffffff81048fbf>] console_lock+0x6f/0x80
[    3.357670]  [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
[    3.357673]  [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[    3.357676]  [<ffffffff8134c01e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    3.357680]  [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
[    3.357683]  [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
[    3.357685]  [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
[    3.357688]  [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[    3.357690]  [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[    3.357693]  [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
[    3.357696]  [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
[    3.357698]  [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
[    3.357717]  [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
[    3.357721]  [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
[    3.357724]  [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
[    3.357727]  [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[    3.357729]  [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[    3.357732]  [<ffffffff81429030>] ? driver_probe_device+0x390/0x390
[    3.357734]  [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[    3.357737]  [<ffffffff814286a9>] driver_attach+0x19/0x20
[    3.357740]  [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[    3.357744]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357747]  [<ffffffff81429792>] driver_register+0x72/0x170
[    3.357749]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357752]  [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
[    3.357762]  [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
[    3.357764]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357767]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357784]  [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
[    3.357786]  [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[    3.357789]  [<ffffffff810c4b53>] load_module+0x1043/0x1510
[    3.357792]  [<ffffffff8135d260>] ? ddebug_proc_open+0xb0/0xb0
[    3.357796]  [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
[    3.357798]  [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Takashi Iwai <hidden>
Date: 2013-01-15 14:47:23

At Tue, 15 Jan 2013 15:25:18 +0100,
Takashi Iwai wrote:
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
The fix patch for coding issue is below.
Feel free to fold into the original patch.


Takashi

=
From: Takashi Iwai <redacted>
Subject: [PATCH] fb: Fix coding style and remove stray non-ascii chars

Signed-off-by: Takashi Iwai <redacted>
---
 drivers/tty/vt/vt.c           | 4 ++--
 drivers/video/console/fbcon.c | 3 +--
 drivers/video/fbmem.c         | 4 ++--
 3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f307196..1db1c8d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3653,7 +3653,7 @@ int do_take_over_console(const struct consw *csw, int first, int last, int deflt
 	/*
 	 * If we get an busy error we still want to bind the console driver
 	 * and return success, as we may have unbound the console driver
-	 * but not unregistered it.
+	 * but not unregistered it.
 	 */
 	if (err = -EBUSY)
 		err = 0;
@@ -3679,7 +3679,7 @@ int take_over_console(const struct consw *csw, int first, int last, int deflt)
 	/*
 	 * If we get an busy error we still want to bind the console driver
 	 * and return success, as we may have unbound the console driver
-	 * but not unregistered it.
+	 * but not unregistered it.
 	 */
 	if (err = -EBUSY)
 		err = 0;
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index c75f8ce..4bd7820 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -546,9 +546,8 @@ static int do_fbcon_takeover(int show_logo)
 				fbcon_is_default);
 
 	if (err) {
-		for (i = first_fb_vc; i <= last_fb_vc; i++) {
+		for (i = first_fb_vc; i <= last_fb_vc; i++)
 			con2fb_map[i] = -1;
-		}
 		info_idx = -1;
 	} else {
 		fbcon_has_console_bind = 1;
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 564ebe9..d8d9831 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1650,9 +1650,9 @@ static int do_register_framebuffer(struct fb_info *fb_info)
 	event.info = fb_info;
 	if (!lock_fb_info(fb_info))
 		return -ENODEV;
-        console_lock();
+	console_lock();
 	fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
-        console_unlock();
+	console_unlock();
 	unlock_fb_info(fb_info);
 	return 0;
 }
-- 
1.8.1

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Takashi Iwai <hidden>
Date: 2013-01-15 16:46:55

At Tue, 15 Jan 2013 15:47:18 +0100,
Takashi Iwai wrote:
At Tue, 15 Jan 2013 15:25:18 +0100,
Takashi Iwai wrote:
quoted
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
The fix patch for coding issue is below.
Feel free to fold into the original patch.
... and the additional patch below fixed the lockdep warning on my
machine.


Takashi

=
From: Takashi Iwai <redacted>
Subject: [PATCH] fb: Yet another band-aid for fixing lockdep mess

I've still got lockdep warnings even after Alan's patch, and it seems
that yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack,
lockdep warnings are finally gone.

Signed-off-by: Takashi Iwai <redacted>
---
 drivers/tty/vt/vt.c           | 43 ++++++++++++++++++++++++++++---------------
 drivers/video/console/fbcon.c |  4 ++--
 drivers/video/fbmem.c         |  4 ++++
 include/linux/console.h       |  1 +
 include/linux/vt_kern.h       |  2 ++
 5 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1db1c8d..3947e8d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3135,6 +3135,18 @@ static int con_is_graphics(const struct consw *csw, int first, int last)
  */
 int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
 {
+	int retval;
+
+	console_lock();
+	retval = do_unbind_con_driver(csw, first, last, deflt);
+	console_unlock();
+	return retval;
+}
+EXPORT_SYMBOL(unbind_con_driver);
+
+/* unlocked version of unbind_con_driver() */
+int do_unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
+{
 	struct module *owner = csw->owner;
 	const struct consw *defcsw = NULL;
 	struct con_driver *con_driver = NULL, *con_back = NULL;
@@ -3143,7 +3155,7 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
 	if (!try_module_get(owner))
 		return -ENODEV;
 
-	console_lock();
+	WARN_CONSOLE_UNLOCKED();
 
 	/* check if driver is registered and if it is unbindable */
 	for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
@@ -3156,10 +3168,8 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
 		}
 	}
 
-	if (retval) {
-		console_unlock();
+	if (retval)
 		goto err;
-	}
 
 	retval = -ENODEV;
 
@@ -3175,15 +3185,11 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
 		}
 	}
 
-	if (retval) {
-		console_unlock();
+	if (retval)
 		goto err;
-	}
 
-	if (!con_is_bound(csw)) {
-		console_unlock();
+	if (!con_is_bound(csw))
 		goto err;
-	}
 
 	first = max(first, con_driver->first);
 	last = min(last, con_driver->last);
@@ -3212,13 +3218,12 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
 
 	/* ignore return value, binding should not fail */
 	do_bind_con_driver(defcsw, first, last, deflt);
-	console_unlock();
 err:
 	module_put(owner);
 	return retval;
 
 }
-EXPORT_SYMBOL(unbind_con_driver);
+EXPORT_SYMBOL_GPL(do_unbind_con_driver);
 
 static int vt_bind(struct con_driver *con)
 {
@@ -3605,9 +3610,18 @@ EXPORT_SYMBOL(register_con_driver);
  */
 int unregister_con_driver(const struct consw *csw)
 {
-	int i, retval = -ENODEV;
+	int retval;
 
 	console_lock();
+	retval = do_unregister_con_driver(csw);
+	console_unlock();
+	return retval;
+}
+EXPORT_SYMBOL(unregister_con_driver);
+
+int do_unregister_con_driver(const struct consw *csw)
+{
+	int i, retval = -ENODEV;
 
 	/* cannot unregister a bound driver */
 	if (con_is_bound(csw))
@@ -3633,10 +3647,9 @@ int unregister_con_driver(const struct consw *csw)
 		}
 	}
 err:
-	console_unlock();
 	return retval;
 }
-EXPORT_SYMBOL(unregister_con_driver);
+EXPORT_SYMBOL_GPL(do_unregister_con_driver);
 
 /*
  *	If we support more console drivers, this function is used
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 4bd7820..2aef9ca 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3004,7 +3004,7 @@ static int fbcon_unbind(void)
 {
 	int ret;
 
-	ret = unbind_con_driver(&fb_con, first_fb_vc, last_fb_vc,
+	ret = do_unbind_con_driver(&fb_con, first_fb_vc, last_fb_vc,
 				fbcon_is_default);
 
 	if (!ret)
@@ -3077,7 +3077,7 @@ static int fbcon_fb_unregistered(struct fb_info *info)
 		primary_device = -1;
 
 	if (!num_registered_fb)
-		unregister_con_driver(&fb_con);
+		do_unregister_con_driver(&fb_con);
 
 	return 0;
 }
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index d8d9831..070b9a1 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1668,8 +1668,10 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
 
 	if (!lock_fb_info(fb_info))
 		return -ENODEV;
+	console_lock();
 	event.info = fb_info;
 	ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
+	console_unlock();
 	unlock_fb_info(fb_info);
 
 	if (ret)
@@ -1684,7 +1686,9 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
 	num_registered_fb--;
 	fb_cleanup_device(fb_info);
 	event.info = fb_info;
+	console_lock();
 	fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
+	console_unlock();
 
 	/* this may free fb info */
 	put_fb_info(fb_info);
diff --git a/include/linux/console.h b/include/linux/console.h
index 4ef4307..47b858c 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -77,6 +77,7 @@ extern const struct consw prom_con;	/* SPARC PROM console */
 int con_is_bound(const struct consw *csw);
 int register_con_driver(const struct consw *csw, int first, int last);
 int unregister_con_driver(const struct consw *csw);
+int do_unregister_con_driver(const struct consw *csw);
 int take_over_console(const struct consw *sw, int first, int last, int deflt);
 int do_take_over_console(const struct consw *sw, int first, int last, int deflt);
 void give_up_console(const struct consw *sw);
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 50ae7d0..dbbc6bf 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -130,6 +130,8 @@ void vt_event_post(unsigned int event, unsigned int old, unsigned int new);
 int vt_waitactive(int n);
 void change_console(struct vc_data *new_vc);
 void reset_vc(struct vc_data *vc);
+extern int do_unbind_con_driver(const struct consw *csw, int first, int last,
+			     int deflt);
 extern int unbind_con_driver(const struct consw *csw, int first, int last,
 			     int deflt);
 int vty_init(const struct file_operations *console_fops);
-- 
1.8.1

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Sedat Dilek <hidden>
Date: 2013-01-16 09:21:51

On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai [off-list ref] wrote:
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
[ CCing Rafael as he asked in another thread if I had sent a patch ]

I noticed also some these "strange" chars in the patch from Andrew and
a patch of mine was sent as
"fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
to the lists.

It is strange to me that Andrew or other maintainers himself did not
check with "checkpatch.pl".
This should be a common testcase!
Hey, noone is perfect :-).
( /me has also not checked with that script - I just saw it. )

Just as a note to the issue in general:
Andrew took over the patch from Alan which is very honest - he is not
the active TTY maintainer!
Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
If this is true, why the hell is Greg not CCed?

Thanks for the real patch in the followup of this thread!
Who will take care of it :-)?

- Sedat
thanks,

Takashi

=>
[    3.228454] [drm] Initialized drm 1.1.0 20060810
[    3.317144] [drm] radeon defaulting to kernel modesetting.
[    3.330546] [drm] radeon kernel modesetting enabled.
[    3.343942] checking generic (c0000000 1000000) vs hw (c0000000 10000000)
[    3.343946] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
[    3.357376]
[    3.357377] ===========================
[    3.357378] [ INFO: possible circular locking dependency detected ]
[    3.357380] 3.8.0-rc3-test+ #82 Not tainted
[    3.357381] -------------------------------------------------------
[    3.357383] udevd/137 is trying to acquire lock:
[    3.357394]  (console_lock){+.+.+.}, at: [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[    3.357395]
[    3.357395] but task is already holding lock:
[    3.357402]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[    3.357403]
[    3.357403] which lock already depends on the new lock.
[    3.357403]
[    3.357404]
[    3.357404] the existing dependency chain (in reverse order) is:
[    3.357407]
[    3.357407] -> #1 ((fb_notifier_list).rwsem){.+.+.+}:
[    3.357411]        [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[    3.357417]        [<ffffffff81643dc2>] down_read+0x42/0x57
[    3.357419]        [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[    3.357422]        [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[    3.357426]        [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[    3.357428]        [<ffffffff8138e302>] register_framebuffer+0x1c2/0x2f0
[    3.357433]        [<ffffffff81d1748e>] vesafb_probe+0x6e0/0x760
[    3.357437]        [<ffffffff8142afbe>] platform_drv_probe+0x3e/0x70
[    3.357440]        [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[    3.357442]        [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[    3.357445]        [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[    3.357447]        [<ffffffff814286a9>] driver_attach+0x19/0x20
[    3.357450]        [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[    3.357452]        [<ffffffff81429792>] driver_register+0x72/0x170
[    3.357455]        [<ffffffff8142a7e1>] platform_driver_register+0x41/0x50
[    3.357458]        [<ffffffff8142a806>] platform_driver_probe+0x16/0xa0
[    3.357460]        [<ffffffff81d16d6b>] vesafb_init+0x215/0x258
[    3.357464]        [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[    3.357468]        [<ffffffff816258ec>] kernel_init+0x1fc/0x370
[    3.357471]        [<ffffffff8164e1fc>] ret_from_fork+0x7c/0xb0
[    3.357474]
[    3.357474] -> #0 (console_lock){+.+.+.}:
[    3.357476]        [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
[    3.357478]        [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[    3.357482]        [<ffffffff81048fbf>] console_lock+0x6f/0x80
[    3.357485]        [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[    3.357489]        [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
[    3.357492]        [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
[    3.357495]        [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
[    3.357497]        [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[    3.357500]        [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[    3.357502]        [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
[    3.357505]        [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
[    3.357507]        [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
[    3.357532]        [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
[    3.357536]        [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
[    3.357539]        [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
[    3.357542]        [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[    3.357544]        [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[    3.357547]        [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[    3.357549]        [<ffffffff814286a9>] driver_attach+0x19/0x20
[    3.357552]        [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[    3.357554]        [<ffffffff81429792>] driver_register+0x72/0x170
[    3.357557]        [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
[    3.357577]        [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
[    3.357594]        [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
[    3.357597]        [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[    3.357600]        [<ffffffff810c4b53>] load_module+0x1043/0x1510
[    3.357603]        [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
[    3.357605]        [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f
[    3.357606]
[    3.357606] other info that might help us debug this:
[    3.357606]
[    3.357607]  Possible unsafe locking scenario:
[    3.357607]
[    3.357608]        CPU0                    CPU1
[    3.357609]        ----                    ----
[    3.357611]   lock((fb_notifier_list).rwsem);
[    3.357613]                                lock(console_lock);
[    3.357615]                                lock((fb_notifier_list).rwsem);
[    3.357616]   lock(console_lock);
[    3.357617]
[    3.357617]  *** DEADLOCK ***
[    3.357617]
[    3.357619] 5 locks held by udevd/137:
[    3.357624]  #0:  (&__lockdep_no_validate__){......}, at: [<ffffffff81429083>] __driver_attach+0x53/0xb0
[    3.357628]  #1:  (&__lockdep_no_validate__){......}, at: [<ffffffff81429091>] __driver_attach+0x61/0xb0
[    3.357633]  #2:  (registration_lock){+.+.+.}, at: [<ffffffff8138e45b>] remove_conflicting_framebuffers+0x2b/0x60
[    3.357637]  #3:  (&fb_info->lock){+.+.+.}, at: [<ffffffff8138d0c1>] lock_fb_info+0x21/0x60
[    3.357642]  #4:  ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[    3.357643]
[    3.357643] stack backtrace:
[    3.357645] Pid: 137, comm: udevd Not tainted 3.8.0-rc3-test+ #82
[    3.357646] Call Trace:
[    3.357652]  [<ffffffff8163b136>] print_circular_bug+0x1fb/0x20c
[    3.357655]  [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
[    3.357658]  [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[    3.357661]  [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
[    3.357664]  [<ffffffff810b2b0d>] ? trace_hardirqs_on+0xd/0x10
[    3.357667]  [<ffffffff81048fbf>] console_lock+0x6f/0x80
[    3.357670]  [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
[    3.357673]  [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[    3.357676]  [<ffffffff8134c01e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    3.357680]  [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
[    3.357683]  [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
[    3.357685]  [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
[    3.357688]  [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[    3.357690]  [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[    3.357693]  [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
[    3.357696]  [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
[    3.357698]  [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
[    3.357717]  [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
[    3.357721]  [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
[    3.357724]  [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
[    3.357727]  [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[    3.357729]  [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[    3.357732]  [<ffffffff81429030>] ? driver_probe_device+0x390/0x390
[    3.357734]  [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[    3.357737]  [<ffffffff814286a9>] driver_attach+0x19/0x20
[    3.357740]  [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[    3.357744]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357747]  [<ffffffff81429792>] driver_register+0x72/0x170
[    3.357749]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357752]  [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
[    3.357762]  [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
[    3.357764]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357767]  [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[    3.357784]  [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
[    3.357786]  [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[    3.357789]  [<ffffffff810c4b53>] load_module+0x1043/0x1510
[    3.357792]  [<ffffffff8135d260>] ? ddebug_proc_open+0xb0/0xb0
[    3.357796]  [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
[    3.357798]  [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Takashi Iwai <hidden>
Date: 2013-01-16 09:35:19

At Wed, 16 Jan 2013 10:21:46 +0100,
Sedat Dilek wrote:
On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai [off-list ref] wrote:
quoted
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
[ CCing Rafael as he asked in another thread if I had sent a patch ]

I noticed also some these "strange" chars in the patch from Andrew and
a patch of mine was sent as
"fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
to the lists.

It is strange to me that Andrew or other maintainers himself did not
check with "checkpatch.pl".
This should be a common testcase!
Hey, noone is perfect :-).
( /me has also not checked with that script - I just saw it. )

Just as a note to the issue in general:
Andrew took over the patch from Alan which is very honest - he is not
the active TTY maintainer!
Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
If this is true, why the hell is Greg not CCed?
Let's do it :)

Greg, Jiri, this bug hits already quite a few people.

I can reproduce the bug easily on a machine with a radeon graphics.
It appears always at boot when lockdep is enabled.

Thanks for the real patch in the followup of this thread!
Who will take care of it :-)?
Either tty maintainer, or fb maintainer, or Andrew?

FWIW, Andrew took my patch in mm:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch


thanks,

Takashi

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Sedat Dilek <hidden>
Date: 2013-01-16 09:52:17

On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai [off-list ref] wrote:
At Wed, 16 Jan 2013 10:21:46 +0100,
Sedat Dilek wrote:
quoted
On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai [off-list ref] wrote:
quoted
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
[ CCing Rafael as he asked in another thread if I had sent a patch ]

I noticed also some these "strange" chars in the patch from Andrew and
a patch of mine was sent as
"fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
to the lists.

It is strange to me that Andrew or other maintainers himself did not
check with "checkpatch.pl".
This should be a common testcase!
Hey, noone is perfect :-).
( /me has also not checked with that script - I just saw it. )

Just as a note to the issue in general:
Andrew took over the patch from Alan which is very honest - he is not
the active TTY maintainer!
Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
If this is true, why the hell is Greg not CCed?
Let's do it :)

Greg, Jiri, this bug hits already quite a few people.

I can reproduce the bug easily on a machine with a radeon graphics.
It appears always at boot when lockdep is enabled.

quoted
Thanks for the real patch in the followup of this thread!
Who will take care of it :-)?
Either tty maintainer, or fb maintainer, or Andrew?

FWIW, Andrew took my patch in mm:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
[ CCing linux-next ML ]

Thanks for all your efforts to get this fb-issue nailed down for mainline!

Just as a note being a Linux-Next customer:

"fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
next-20130116!
Thanks for the link!

Normally Andrew sents out a mmotm release marking patches from his
tree destinated for Linux-Next with a "*".

To quote from the latest mmotm release-notes:

"This mmotm tree contains the following patches against 3.8-rc3:
(patches marked "*" will be included in linux-next)"

But anyway this stuff is Linux-3.8 material as well.

- Sedat -
thanks,

Takashi

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Sedat Dilek <hidden>
Date: 2013-01-16 09:59:51

On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek [off-list ref] wrote:
On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai [off-list ref] wrote:
quoted
At Wed, 16 Jan 2013 10:21:46 +0100,
Sedat Dilek wrote:
quoted
On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai [off-list ref] wrote:
quoted
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
[ CCing Rafael as he asked in another thread if I had sent a patch ]

I noticed also some these "strange" chars in the patch from Andrew and
a patch of mine was sent as
"fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
to the lists.

It is strange to me that Andrew or other maintainers himself did not
check with "checkpatch.pl".
This should be a common testcase!
Hey, noone is perfect :-).
( /me has also not checked with that script - I just saw it. )

Just as a note to the issue in general:
Andrew took over the patch from Alan which is very honest - he is not
the active TTY maintainer!
Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
If this is true, why the hell is Greg not CCed?
Let's do it :)

Greg, Jiri, this bug hits already quite a few people.

I can reproduce the bug easily on a machine with a radeon graphics.
It appears always at boot when lockdep is enabled.

quoted
Thanks for the real patch in the followup of this thread!
Who will take care of it :-)?
Either tty maintainer, or fb maintainer, or Andrew?

FWIW, Andrew took my patch in mm:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
[ CCing linux-next ML ]

Thanks for all your efforts to get this fb-issue nailed down for mainline!

Just as a note being a Linux-Next customer:

"fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
next-20130116!
Thanks for the link!

Normally Andrew sents out a mmotm release marking patches from his
tree destinated for Linux-Next with a "*".

To quote from the latest mmotm release-notes:

"This mmotm tree contains the following patches against 3.8-rc3:
(patches marked "*" will be included in linux-next)"

But anyway this stuff is Linux-3.8 material as well.
JYI: [1] now does NOT have anymore those "strange" chars, Thanks Takashi san.

I will test next-20130116 with both fb-fixes as -2 kernel.
( Running LTP-lite on my "naked" -1 kernel only with my kbuild/deb-pkg-fixes. )

Thanks to everyone involved.

- Sedat -

[1] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
- Sedat -
quoted
thanks,

Takashi

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2013-01-17 02:42:21

On Wed, Jan 16, 2013 at 10:35:12AM +0100, Takashi Iwai wrote:
At Wed, 16 Jan 2013 10:21:46 +0100,
Sedat Dilek wrote:
quoted
On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai [off-list ref] wrote:
quoted
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
quoted
Hi Jiri,

...known issue (see thread in [1]), please feel free to test patches
from Alan and Andrew (see [1], [2] and [3]) and report.

Regards,
- Sedat -

[1] http://marc.info/?t5309396400003&r=1&w=2
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
[4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.

A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?

(BTW, the patch [2] contains strange characters in the comments, and
 has a few coding issues easily detected by checkpatch.pl.)
[ CCing Rafael as he asked in another thread if I had sent a patch ]

I noticed also some these "strange" chars in the patch from Andrew and
a patch of mine was sent as
"fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
to the lists.

It is strange to me that Andrew or other maintainers himself did not
check with "checkpatch.pl".
This should be a common testcase!
Hey, noone is perfect :-).
( /me has also not checked with that script - I just saw it. )

Just as a note to the issue in general:
Andrew took over the patch from Alan which is very honest - he is not
the active TTY maintainer!
Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
If this is true, why the hell is Greg not CCed?
Let's do it :)

Greg, Jiri, this bug hits already quite a few people.

I can reproduce the bug easily on a machine with a radeon graphics.
It appears always at boot when lockdep is enabled.

quoted
Thanks for the real patch in the followup of this thread!
Who will take care of it :-)?
Either tty maintainer, or fb maintainer, or Andrew?

FWIW, Andrew took my patch in mm:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch

Ok, so, which one should I take for 3.8?  And ideally the fb maintainer
should do this, not I, right?

thanks,

greg k-h

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2013-01-17 03:49:49

On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman [off-list ref] wrote:
quoted
FWIW, Andrew took my patch in mm:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch

Ok, so, which one should I take for 3.8?  And ideally the fb maintainer
should do this, not I, right?
Please see http://www.spinics.net/lists/linux-fbdev/msg08954.html

Tomi might be able to review the above for us.  I think we need both. 
If nothing else happens I intend to send both Linuswards for 3.8 in a
week or two.

Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2013-01-17 04:15:32

On Wed, Jan 16, 2013 at 07:54:16PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman [off-list ref] wrote:
quoted
quoted
FWIW, Andrew took my patch in mm:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch

Ok, so, which one should I take for 3.8?  And ideally the fb maintainer
should do this, not I, right?
Please see http://www.spinics.net/lists/linux-fbdev/msg08954.html

Tomi might be able to review the above for us.  I think we need both. 
If nothing else happens I intend to send both Linuswards for 3.8 in a
week or two.
Ok, that sounds fine with me, thanks for doing that.

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help