[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4984946B.5000205@gmail.com>
Date: Sat, 31 Jan 2009 19:11:55 +0100
From: Andrea Righi <righi.andrea@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Andrey Borzenkov <arvidjaar@...l.ru>,
Linux Frame Buffer Device Development
<linux-fbdev-devel@...ts.sourceforge.net>,
"Antonino A. Daplas" <adaplas@...il.com>,
linux-pm@...ts.linux-foundation.org,
Linux Kernel Development <linux-kernel@...r.kernel.org>
Subject: Re: [Linux-fbdev-devel] [2.6.29-rc2] fb_mmap: circular locking dependency
on hibernation
On 2009-01-31 18:44, Geert Uytterhoeven wrote:
> On Sat, 31 Jan 2009, Andrea Righi wrote:
>> On 2009-01-30 05:15, Andrey Borzenkov wrote:
>>> On 29 of January 2009 12:10:11 Geert Uytterhoeven wrote:
>>>> On Tue, 27 Jan 2009, Andrey Borzenkov wrote:
>> fbcon: avoid circular locking dependency between fb_info->lock and mm->mmap_sem
>>
>> In fbcon notifier the handler for FB_EVENT_SET_CONSOLE_MAP doesn't need
>> to hold fb_info->lock.
>>
>> Simply unlock it before calling set_con2fb_map(), that could try to
>> acquire mm->mmap_sem to avoid a circular locking dependency with
>> fb_mmap() (that acquires mm->mmap_sem -> fb_info-lock).
>
> However, set_con2fb_map() accesses the array of fb_info pointers
> registered_fb[], which seems to be a bit unsafe now the BKL is no longer held.
mmmh.. not sure about that, registered_fb[] was never accessed with
fb_info->lock held, see register/unregister_framebuffer().
But maybe this is another issue, and anyway, the array and also
num_registered_fb don't seem to be protected at all...
-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists