From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Francis Moreau <francis.moro@gmail.com>
Cc: Wanlong Gao <wanlong.gao@gmail.com>,
Paul Mundt <lethal@linux-sh.org>,
linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Possible deadlock when suspending framebuffer
Date: Wed, 15 Jun 2011 10:20:46 +0000 [thread overview]
Message-ID: <20110615122046.70e1ee17@pluto.restena.lu> (raw)
In-Reply-To: <BANLkTinE+EZ9nr1qGKC0VY0bVHuF8U-R0w@mail.gmail.com>
On Wed, 15 Jun 2011 09:12:46 Francis Moreau wrote:
> On Wed, Jun 15, 2011 at 7:58 AM, Bruno Prémont wrote:
> Well, sorry for the dumb question but the fb/fbcon code is pretty hard
> to follow for me.
Certainly not just for you
> Why does store_fbstate() and any fb driver's suspsend methods acquire
> the console lock at all ?
From my understanding, fbcon currently has very loose binding with
framebuffers in general instead of just with those few framebuffers
it is effectively mapped to (and active on!).
James Simmons started a complete rework of fbcon/tty code which is
expected to get things more fine-grained, until then console semaphore
(console_lock) remains a kind of big kernel lock in the
console/framebuffer area.
As such any state change of framebuffer may influence/race against
fbcon.
e.g. for the suspend state you want to avoid fbcon to fiddle with
your framebuffer while it is suspending (and have fbcon know about the
suspended state). This way fbcon can unsuspend framebuffer if needed
but also stop accessing it when it should not.
Bruno
prev parent reply other threads:[~2011-06-15 10:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BANLkTiko+2AM8dq8jP5xjbTcCM63hBAK=A@mail.gmail.com>
2011-06-14 18:15 ` Possible deadlock when suspending framebuffer Linus Torvalds
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-18 8:43 ` Bruno Prémont
2011-06-18 9:19 ` Bruno Prémont
2011-09-01 15:42 ` Florian Tobias Schandinat
2011-09-01 16:28 ` Guennadi Liakhovetski
2011-09-02 16:06 ` Guennadi Liakhovetski
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 20:54 ` [PATCH] fb: sh-mobile: Fix deadlock risk between lock_fb_info() Florian Tobias Schandinat
2011-07-20 18:16 ` [PATCH] fb: avoid possible deadlock caused by fb_set_suspend Florian Tobias Schandinat
2011-07-28 22:10 ` Francis Moreau
2011-06-15 1:09 ` re:Possible deadlock when suspending framebuffer Wanlong Gao
2011-06-15 5:58 ` Possible " Bruno Prémont
2011-06-15 6:22 ` Wanlong Gao
2011-06-15 7:04 ` Américo Wang
2011-06-15 7:12 ` Francis Moreau
2011-06-15 10:20 ` Bruno Prémont [this message]
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=20110615122046.70e1ee17@pluto.restena.lu \
--to=bonbons@linux-vserver.org \
--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 \
--cc=wanlong.gao@gmail.com \
/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 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).