From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mundt <lethal@linux-sh.org>,
linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Francis Moreau <francis.moro@gmail.com>
Subject: Re: Possible deadlock when suspending framebuffer
Date: Tue, 14 Jun 2011 19:04:20 +0000 [thread overview]
Message-ID: <4DF7B0B4.4060002@gmx.de> (raw)
In-Reply-To: <BANLkTimny9nzr23TufH1kMcsk57M3NXuaA@mail.gmail.com>
Hi Linus,
On 06/14/2011 06:15 PM, Linus Torvalds wrote:
> Paul, fbdev people.. Comments? This was sent to me and lkml, the right
> people probably didn't see it.
Sounds very familiar. Indeed a quick glance at my archive revealed 2
approaches/patches dealing with similar issues
http://marc.info/?l=linux-fbdev&m\x129539210207429&w=2
http://marc.info/?l=linux-fbdev&m\x129700789632450&w=2
I did not have time to verify that those do actually get those things right
everywhere but the first one looks good and should also solve this issue I think.
Regards,
Florian Tobias Schandinat
>
> I doubt it's a big problem in practice, but..
>
> Linus
>
> On Tue, Jun 14, 2011 at 6:10 AM, Francis Moreau<francis.moro@gmail.com> wrote:
>> Hello,
>>
>> I noticed that a possible deadlock can happen when the current frame
>> buffering is being suspended and a new frambuffer device is being
>> registred at the same time.
>>
>> When suspending the current frambuffer by doing : echo 1
>>> /sys/class/graphics/fb0/state, the kernel actually takes the
>> following locks in that order: console_lock, lock_fb_info (see
>> store_fbstate()).
>>
>> However when a new framebuffer is coming in, the lock sequence is:
>> lock_fb_info (taken by do_remove_conflicting_framebuffer()),
>> console_lock() (taken by unbind_console).
>>
>> I don't know how this should be fixed though...
>>
>> Thanks
>> --
>> Francis
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mundt <lethal@linux-sh.org>,
linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Francis Moreau <francis.moro@gmail.com>
Subject: Re: Possible deadlock when suspending framebuffer
Date: Tue, 14 Jun 2011 19:04:20 +0000 [thread overview]
Message-ID: <4DF7B0B4.4060002@gmx.de> (raw)
In-Reply-To: <BANLkTimny9nzr23TufH1kMcsk57M3NXuaA@mail.gmail.com>
Hi Linus,
On 06/14/2011 06:15 PM, Linus Torvalds wrote:
> Paul, fbdev people.. Comments? This was sent to me and lkml, the right
> people probably didn't see it.
Sounds very familiar. Indeed a quick glance at my archive revealed 2
approaches/patches dealing with similar issues
http://marc.info/?l=linux-fbdev&m=129539210207429&w=2
http://marc.info/?l=linux-fbdev&m=129700789632450&w=2
I did not have time to verify that those do actually get those things right
everywhere but the first one looks good and should also solve this issue I think.
Regards,
Florian Tobias Schandinat
>
> I doubt it's a big problem in practice, but..
>
> Linus
>
> On Tue, Jun 14, 2011 at 6:10 AM, Francis Moreau<francis.moro@gmail.com> wrote:
>> Hello,
>>
>> I noticed that a possible deadlock can happen when the current frame
>> buffering is being suspended and a new frambuffer device is being
>> registred at the same time.
>>
>> When suspending the current frambuffer by doing : echo 1
>>> /sys/class/graphics/fb0/state, the kernel actually takes the
>> following locks in that order: console_lock, lock_fb_info (see
>> store_fbstate()).
>>
>> However when a new framebuffer is coming in, the lock sequence is:
>> lock_fb_info (taken by do_remove_conflicting_framebuffer()),
>> console_lock() (taken by unbind_console).
>>
>> I don't know how this should be fixed though...
>>
>> Thanks
>> --
>> Francis
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-06-14 19:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 13:10 Possible deadlock when suspending framebuffer Francis Moreau
2011-06-14 18:15 ` Linus Torvalds
2011-06-14 18:15 ` Linus Torvalds
2011-06-14 19:04 ` Florian Tobias Schandinat [this message]
2011-06-14 19:04 ` Florian Tobias Schandinat
2011-06-17 18:46 ` [PATCH] fb: avoid possible deadlock caused by fb_set_suspend Florian Tobias Schandinat
2011-06-17 19:02 ` Florian Tobias Schandinat
2011-06-18 8:43 ` Bruno Prémont
2011-06-18 8:43 ` Bruno Prémont
2011-06-18 9:19 ` Bruno Prémont
2011-06-18 9:19 ` Bruno Prémont
2011-09-01 15:42 ` Florian Tobias Schandinat
2011-09-01 15:42 ` Florian Tobias Schandinat
2011-09-01 16:28 ` Guennadi Liakhovetski
2011-09-01 16:28 ` Guennadi Liakhovetski
2011-09-02 16:06 ` Guennadi Liakhovetski
2011-09-02 16:06 ` Guennadi Liakhovetski
2011-09-02 16:46 ` Florian Tobias Schandinat
2011-09-02 16:46 ` Florian Tobias Schandinat
2011-09-02 17:24 ` [PATCH] fb: sh-mobile: Fix deadlock risk between lock_fb_info() and Bruno Prémont
2011-09-02 17:24 ` [PATCH] fb: sh-mobile: Fix deadlock risk between lock_fb_info() and console_lock() Bruno Prémont
2011-09-02 20:54 ` [PATCH] fb: sh-mobile: Fix deadlock risk between lock_fb_info() Florian Tobias Schandinat
2011-09-02 20:54 ` [PATCH] fb: sh-mobile: Fix deadlock risk between lock_fb_info() and console_lock() Florian Tobias Schandinat
2011-07-20 18:16 ` [PATCH] fb: avoid possible deadlock caused by fb_set_suspend Florian Tobias Schandinat
2011-07-20 18:16 ` Florian Tobias Schandinat
2011-07-28 22:10 ` Francis Moreau
2011-07-28 22:10 ` Francis Moreau
2011-06-15 1:09 ` re:Possible deadlock when suspending framebuffer Wanlong Gao
2011-06-15 1:09 ` Wanlong Gao
2011-06-15 5:58 ` Possible " Bruno Prémont
2011-06-15 5:58 ` Bruno Prémont
2011-06-15 6:22 ` Wanlong Gao
2011-06-15 6:22 ` Wanlong Gao
2011-06-15 7:04 ` Américo Wang
2011-06-15 7:04 ` Américo Wang
2011-06-15 7:12 ` Francis Moreau
2011-06-15 7:12 ` Francis Moreau
2011-06-15 10:20 ` Bruno Prémont
2011-06-15 10:20 ` Bruno Prémont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DF7B0B4.4060002@gmx.de \
--to=florianschandinat@gmx.de \
--cc=francis.moro@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.