* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
@ 2013-01-05 12:13 Sedat Dilek
2013-01-15 14:25 ` Takashi Iwai
0 siblings, 1 reply; 12+ messages in thread
From: Sedat Dilek @ 2013-01-05 12:13 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-fbdev, LKML, alan, Andrew Morton
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/?t\x135309396400003&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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-05 12:13 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem Sedat Dilek
@ 2013-01-15 14:25 ` Takashi Iwai
2013-01-15 14:47 ` Takashi Iwai
2013-01-16 9:21 ` Sedat Dilek
0 siblings, 2 replies; 12+ messages in thread
From: Takashi Iwai @ 2013-01-15 14:25 UTC (permalink / raw)
To: sedat.dilek; +Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton
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/?t\x135309396400003&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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-15 14:25 ` Takashi Iwai
@ 2013-01-15 14:47 ` Takashi Iwai
2013-01-15 16:46 ` Takashi Iwai
2013-01-16 9:21 ` Sedat Dilek
1 sibling, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2013-01-15 14:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan
At Tue, 15 Jan 2013 15:25:18 +0100,
Takashi Iwai wrote:
>
> 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/?t\x135309396400003&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 <tiwai@suse.de>
Subject: [PATCH] fb: Fix coding style and remove stray non-ascii chars
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-15 14:47 ` Takashi Iwai
@ 2013-01-15 16:46 ` Takashi Iwai
0 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2013-01-15 16:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan
At Tue, 15 Jan 2013 15:47:18 +0100,
Takashi Iwai wrote:
>
> At Tue, 15 Jan 2013 15:25:18 +0100,
> Takashi Iwai wrote:
> >
> > 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/?t\x135309396400003&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 <tiwai@suse.de>
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 <tiwai@suse.de>
---
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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-15 14:25 ` Takashi Iwai
2013-01-15 14:47 ` Takashi Iwai
@ 2013-01-16 9:21 ` Sedat Dilek
2013-01-16 9:35 ` Takashi Iwai
1 sibling, 1 reply; 12+ messages in thread
From: Sedat Dilek @ 2013-01-16 9:21 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki
On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
> 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/?t\x135309396400003&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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-16 9:21 ` Sedat Dilek
@ 2013-01-16 9:35 ` Takashi Iwai
2013-01-16 9:52 ` Sedat Dilek
2013-01-17 2:42 ` Greg Kroah-Hartman
0 siblings, 2 replies; 12+ messages in thread
From: Takashi Iwai @ 2013-01-16 9:35 UTC (permalink / raw)
To: sedat.dilek
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby
At Wed, 16 Jan 2013 10:21:46 +0100,
Sedat Dilek wrote:
>
> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > 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/?t\x135309396400003&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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-16 9:35 ` Takashi Iwai
@ 2013-01-16 9:52 ` Sedat Dilek
2013-01-16 9:59 ` Sedat Dilek
2013-01-17 2:42 ` Greg Kroah-Hartman
1 sibling, 1 reply; 12+ messages in thread
From: Sedat Dilek @ 2013-01-16 9:52 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby, linux-next
On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Wed, 16 Jan 2013 10:21:46 +0100,
> Sedat Dilek wrote:
>>
>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> > 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/?t\x135309396400003&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
>
[ 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-16 9:52 ` Sedat Dilek
@ 2013-01-16 9:59 ` Sedat Dilek
[not found] ` <CA+icZUVviNP_BHBNQXo35W1Ge121_89argJ2NN1+rLOWgoYBtQ@mail.gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Sedat Dilek @ 2013-01-16 9:59 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby, linux-next
On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@suse.de> wrote:
>> At Wed, 16 Jan 2013 10:21:46 +0100,
>> Sedat Dilek wrote:
>>>
>>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
>>> > 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/?t\x135309396400003&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
>>
>
> [ 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 -
>
>>
>> thanks,
>>
>> Takashi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
[not found] ` <CA+icZUVviNP_BHBNQXo35W1Ge121_89argJ2NN1+rLOWgoYBtQ@mail.gmail.com>
@ 2013-01-16 12:51 ` Sedat Dilek
0 siblings, 0 replies; 12+ messages in thread
From: Sedat Dilek @ 2013-01-16 12:51 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby, linux-next
[-- Attachment #1: Type: text/plain, Size: 5008 bytes --]
On Wed, Jan 16, 2013 at 12:07 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 10:59 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@suse.de> wrote:
>>>> At Wed, 16 Jan 2013 10:21:46 +0100,
>>>> Sedat Dilek wrote:
>>>>>
>>>>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
>>>>> > 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/?t=135309396400003&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
>>>>
>>>
>>> [ 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.
>>
>
> I have reverted the three fb-fixes from akpm-tree in next-20130116...
> ...and applied the two fb-fixes from mmotm-tree (see attached patches file).
>
> FYI: The 1st patch from mmotm-tree is a (proper) replacement for the 3
> patches in Linux-Next.
>
> Furthermore, I made some quick testing:
> Booting into the system is fine.
> Suspend + resume looks good (see dmesg.diff).
>
> See also attached files!
>
En plus, I have run successfully LTP-lite.
$ egrep -i 'error|fail'
runltplite-results_3.8.0-rc3-next20130116-2-iniza-generic.txt | egrep
-v -i 'expected' | wc -l
208
I do not want to flood the MLs, so people wanting full LTP-lite report
(~600KiB) can contact me.
- Sedat -
> - Sedat -
>
>> - 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 -
>>>
>>>>
>>>> thanks,
>>>>
>>>> Takashi
[-- Attachment #2: ltplite_expected-failures_3.8.0-rc3-next20130116-2-iniza-generic.txt --]
[-- Type: text/plain, Size: 15254 bytes --]
PASS: error count is 0
bind02 1 TPASS : correct error
chmod01 2 TPASS : chmod(2) error when accessing non-existent object through symbolic link is caught
chown04 1 TPASS : chown failed: TEST_ERRNO=EPERM(1): Operation not permitted
chown04 2 TPASS : chown failed: TEST_ERRNO=EACCES(13): Permission denied
chown04 3 TPASS : chown failed: TEST_ERRNO=EFAULT(14): Bad address
chown04 4 TPASS : chown failed: TEST_ERRNO=EFAULT(14): Bad address
chown04 5 TPASS : chown failed: TEST_ERRNO=ENAMETOOLONG(36): File name too long
chown04 6 TPASS : chown failed: TEST_ERRNO=ENOENT(2): No such file or directory
chown04 7 TPASS : chown failed: TEST_ERRNO=ENOTDIR(20): Not a directory
flock01 1 TPASS : flock() succeded with Shared Lock, returned error number=0
flock01 2 TPASS : flock() succeded with Unlock, returned error number=0
flock01 3 TPASS : flock() succeded with Exclusive Lock, returned error number=0
fork06 0 TINFO : failures 0
getpriority02 1 TPASS : getpriority(2) fails, Invalid 'which' value specified, errno:22
getpriority02 2 TPASS : getpriority(2) fails, Invalid 'who' value specified, errno:3
getpriority02 3 TPASS : getpriority(2) fails, Invalid 'who' value specified, errno:3
getpriority02 4 TPASS : getpriority(2) fails, Invalid 'who' value specified, errno:3
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty0
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty1
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty10
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty11
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty12
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty13
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty14
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty15
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty16
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty17
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty18
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty19
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty2
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty20
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty21
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty22
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty23
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty24
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty25
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty26
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty27
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty28
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty29
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty3
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty30
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty31
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty32
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty33
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty34
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty35
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty36
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty37
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty38
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty39
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty4
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty40
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty41
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty42
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty43
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty44
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty45
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty46
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty47
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty48
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty49
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty5
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty50
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty51
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty52
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty53
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty54
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty55
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty56
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty57
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty58
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty59
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty6
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty60
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty61
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty62
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty63
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty7
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty8
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty9
kill failed with EPERM
lchown02 1 TPASS : lchown(2) fails, Process is not owner/root, errno:1
lchown02 2 TPASS : lchown(2) fails, Search permission denied, errno:13
lchown02 3 TPASS : lchown(2) fails, Address beyond address space, errno:14
lchown02 4 TPASS : lchown(2) fails, Unaccessible address space, errno:14
lchown02 5 TPASS : lchown(2) fails, Pathname too long, errno:36
lchown02 6 TPASS : lchown(2) fails, Path contains regular file, errno:20
lchown02 7 TPASS : lchown(2) fails, Pathname is empty, errno:2
link04 1 TPASS : link(<non-existent file>, <nefile>) Failed, errno=2
link04 2 TPASS : link(<path is empty string>, <nefile>) Failed, errno=2
link04 3 TPASS : link(<path contains a non-existent file>, <nefile>) Failed, errno=2
link04 4 TPASS : link(<path contains a regular file>, <nefile>) Failed, errno=20
link04 5 TPASS : link(<pathname too long>, <nefile>) Failed, errno=36
link04 6 TPASS : link(<address beyond address space>, <nefile>) Failed, errno=14
link04 7 TPASS : link(<negative address>, <nefile>) Failed, errno=14
link04 8 TPASS : link(<regfile>, <empty string>) Failed, errno=2
link04 9 TPASS : link(<regfile>, <path contains a non-existent file>) Failed, errno=2
link04 10 TPASS : link(<regfile>, <path contains a regular file>) Failed, errno=2
link04 11 TPASS : link(<regfile>, <pathname too long>) Failed, errno=36
link04 12 TPASS : link(<regfile>, <address beyond address space>) Failed, errno=14
link04 13 TPASS : link(<regfile>, <negative address>) Failed, errno=14
link04 14 TPASS : link(<regfile>, <regfile2>) Failed, errno=17
llseek02 1 TPASS : llseek() fails, 'whence' argument is not valid, errno:22
llseek02 2 TPASS : llseek() fails, 'fd' is not an open file descriptor, errno:9
lseek02 1 TPASS : lseek(-1, 1, SEEK_SET) Failed, errno=9 : Bad file descriptor
lseek03 1 TPASS : lseek(tfile_5520, 1, 5) Failed, errno=22 : Invalid argument
lseek03 2 TPASS : lseek(tfile_5520, 1, -1) Failed, errno=22 : Invalid argument
lseek03 3 TPASS : lseek(tfile_5520, 1, 7) Failed, errno=22 : Invalid argument
lseek04 1 TPASS : lseek(fifofd, 1, SEEK_SET) Failed, errno=29 : Illegal seek
lseek05 1 TPASS : lseek(pipefd, 1, SEEK_SET) Failed, errno=29 : Illegal seek
lseek10 1 TPASS : lseek() fails, 'fd' associated with a pipe/fifo, errno:29
lseek10 2 TPASS : lseek() fails, 'whence' argument is not valid, errno:22
lseek10 3 TPASS : lseek() fails, 'fd' is not an open file descriptor, errno:9
lstat02 1 TPASS : lstat() fails, No Search permissions to process, errno:13
lstat02 2 TPASS : lstat() fails, Negative address, errno:14
lstat02 3 TPASS : lstat() fails, Address beyond address space, errno:14
lstat02 4 TPASS : lstat() fails, Pathname too long, errno:36
lstat02 5 TPASS : lstat() fails, Pathname is empty, errno:2
lstat02 6 TPASS : lstat() fails, Path contains regular file, errno:20
mknod06 1 TPASS : mknod() fails, Specified node already exists, errno:17
mknod06 2 TPASS : mknod() fails, Negative address, errno:14
mknod06 3 TPASS : mknod() fails, Address beyond address space, errno:14
mknod06 4 TPASS : mknod() fails, Non-existent file, errno:2
mknod06 5 TPASS : mknod() fails, Pathname is empty, errno:2
mknod06 6 TPASS : mknod() fails, Pathname too long, errno:36
mknod06 7 TPASS : mknod() fails, Path contains regular file, errno:20
mmap06 1 TPASS : mmap failed with EACCES
mmap07 1 TPASS : mmap failed with EACCES
mmap08 1 TPASS : mmap failed with EBADF
mremap02 1 TPASS : mremap() Failed, 'invalid argument specified' - errno 22
mremap03 1 TPASS : mremap() Fails, 'old region not mapped', errno 14
mremap04 1 TPASS : mremap() failed, 'MREMAP_MAYMOVE flag unset', errno 12
open01 3 TPASS : open(2) with (O_CREAT | O_EXCL) error is caught when creating object file through symbolic link file
open01 4 TPASS : open(2) error with O_RDWR is caught when processing symbolic link file which points at no object file
pipe06 1 TPASS : failed with EMFILE
pread02 1 TPASS : pread() fails, file descriptor is a PIPE or FIFO, errno:29
pread02 2 TPASS : pread() fails, specified offset is -ve or invalid, errno:22
readlink01 3 TPASS : Reading a symbolic link which exceeds maximum pathname error is caught
readlink01 4 TPASS : Reading a nonsymbolic link file error condition is caught. EINVAL is returned
rmdir05 1 TPASS : rmdir(".") failed to remove the current working directory. Returned 22 : Invalid argument
sched_getscheduler02 1 TPASS : call failed with ESRCH
setgroups03 1 TPASS : setgroups(65537) fails, Size is > sysconf(_SC_NGROUPS_MAX), errno=22
setgroups03 2 TPASS : setgroups(65536) fails, Permission denied, not super-user, errno=1
setregid02 0 TINFO : ERROR: After setregid(-1, root), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(-1, bin) real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(root,-1), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(bin, -1), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(root, bin) real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(bin, root), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(invalid group, -1), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(-1, invalid group), real gid = 65534; effective gid = 65534
shmctl02 6 TCONF : shmctl() did not fail for non-root user.This may be okay for your distribution.
shmctl02 7 TCONF : shmctl() did not fail for non-root user.This may be okay for your distribution.
sigaltstack02 1 TPASS : stgaltstack() fails, Invalid Flag value, errno:22
sigaltstack02 2 TPASS : stgaltstack() fails, alternate stack is < MINSIGSTKSZ, errno:12
sighold02 1 TPASS : Sighold called without error for 57 of 64 signals
stat03 1 TPASS : stat() fails, No Search permissions to process, errno:13
stat03 2 TPASS : stat() fails, Address beyond address space, errno:14
stat03 3 TPASS : stat() fails, Negative address, errno:14
stat03 4 TPASS : stat() fails, Pathname too long, errno:36
stat03 5 TPASS : stat() fails, Pathname is empty, errno:2
stat03 6 TPASS : stat() fails, Path contains regular file, errno:20
stat04 2 TPASS : Stat(2) error when accessing non-existent object through symbolic link is caught
stat06 1 TPASS : stat(<non-existent file>, &stbuf) Failed, errno=2
stat06 2 TPASS : stat(<path is empty string>, &stbuf) Failed, errno=2
stat06 3 TPASS : stat(<path contains a non-existent file>, &stbuf) Failed, errno=2
stat06 4 TPASS : stat(<path contains a regular file>, &stbuf) Failed, errno=20
stat06 5 TPASS : stat(<pathname too long>, &stbuf) Failed, errno=36
stat06 6 TPASS : stat(<address beyond address space>, &stbuf) Failed, errno=14
stat06 7 TPASS : stat(<negative address>, &stbuf) Failed, errno=14
symlink01 4 TPASS : Creating an existing symbolic link file error is caught
symlink01 5 TPASS : Creating a symbolic link which exceeds maximum pathname error is caught
symlink03 1 TPASS : symlink() Fails, No Search permissions to process, errno=13
symlink03 2 TPASS : symlink() Fails, Specified symlink already exists, errno=17
symlink03 3 TPASS : symlink() Fails, Address beyond address space, errno=14
symlink03 4 TPASS : symlink() Fails, Negative address, errno=14
symlink03 5 TPASS : symlink() Fails, Symlink path too long, errno=36
symlink03 6 TPASS : symlink() Fails, Symlink Pathname is empty, errno=2
symlink03 7 TPASS : symlink() Fails, Symlink Path contains regular file, errno=20
sysinfo02 1 TPASS : Test to check the error code 14 PASSED
truncate03 1 TPASS : truncate() fails, No Search permissions to process, errno=13
truncate03 2 TPASS : truncate() fails, Path contains regular file, errno=20
truncate03 3 TPASS : truncate() fails, Address beyond address space, errno=14
truncate03 4 TPASS : truncate() fails, Negative address, errno=14
truncate03 5 TPASS : truncate() fails, Pathname too long, errno=36
truncate03 6 TPASS : truncate() fails, Pathname is empty, errno=2
truncate04 1 TPASS : truncate() fails, File is a directory, errno=21
unlink07 1 TPASS : unlink(<non-existent file>) Failed, errno=2
unlink07 2 TPASS : unlink(<path is empty string>) Failed, errno=2
unlink07 3 TPASS : unlink(<path contains a non-existent file>) Failed, errno=2
unlink07 4 TPASS : unlink(<address beyond address space>) Failed, errno=14
unlink07 5 TPASS : unlink(<path contains a regular file>) Failed, errno=20
unlink07 6 TPASS : unlink(<address beyond address space>) Failed, errno=14
unlink07 7 TPASS : unlink(<pathname too long>) Failed, errno=36
unlink07 8 TPASS : unlink(<negative address>) Failed, errno=14
unlink08 3 TPASS : unlink(<directory>) Failed, errno=21
utime01 2 TPASS : utime(2) error when accessing non-existent object through symbolic link is caught
utime06 1 TPASS : utime() fails, Permission denied to modify file time, errno:13
utime06 2 TPASS : utime() fails, Specified file doesn't exist, errno:2
write03 0 TINFO : Enter Block 1: test to check if write corrupts the file when write fails
write03 1 TPASS : failure of write(2) didnot corrupt the file
mtest01 1 TFAIL : More memory than the maximum amount you specified is already being used
mtest01 1 TFAIL : More memory than the maximum amount you specified is already being used
gf17 1 TFAIL : Test failed
gf18 1 TFAIL : Test failed
INFO: ltp-pan reported some tests FAIL
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-16 9:35 ` Takashi Iwai
2013-01-16 9:52 ` Sedat Dilek
@ 2013-01-17 2:42 ` Greg Kroah-Hartman
2013-01-17 3:54 ` Andrew Morton
1 sibling, 1 reply; 12+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-17 2:42 UTC (permalink / raw)
To: Takashi Iwai
Cc: sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Jiri Slaby
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:
> >
> > On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > > 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/?t\x135309396400003&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
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-17 2:42 ` Greg Kroah-Hartman
@ 2013-01-17 3:54 ` Andrew Morton
2013-01-17 4:16 ` Greg Kroah-Hartman
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Morton @ 2013-01-17 3:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Takashi Iwai, sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan,
Rafael J. Wysocki, Jiri Slaby
On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
2013-01-17 3:54 ` Andrew Morton
@ 2013-01-17 4:16 ` Greg Kroah-Hartman
0 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-17 4:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Takashi Iwai, sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan,
Rafael J. Wysocki, Jiri Slaby
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 <gregkh@linuxfoundation.org> wrote:
>
> > > 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-01-17 4:16 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-05 12:13 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem Sedat Dilek
2013-01-15 14:25 ` Takashi Iwai
2013-01-15 14:47 ` Takashi Iwai
2013-01-15 16:46 ` Takashi Iwai
2013-01-16 9:21 ` Sedat Dilek
2013-01-16 9:35 ` Takashi Iwai
2013-01-16 9:52 ` Sedat Dilek
2013-01-16 9:59 ` Sedat Dilek
[not found] ` <CA+icZUVviNP_BHBNQXo35W1Ge121_89argJ2NN1+rLOWgoYBtQ@mail.gmail.com>
2013-01-16 12:51 ` Sedat Dilek
2013-01-17 2:42 ` Greg Kroah-Hartman
2013-01-17 3:54 ` Andrew Morton
2013-01-17 4:16 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).