dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Zhen Lei <thunder.leizhen@huawei.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Xiyu Yang <xiyuyang19@fudan.edu.cn>,
	Du Cheng <ducheng2@gmail.com>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Zheyu Ma <zheyuma97@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	William Kucharski <william.kucharski@oracle.com>,
	Claudio Suarez <cssk@net-c.es>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alex Deucher <alexander.deucher@amd.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: [PATCH v3 12/17] fbcon: use lock_fb_info in fbcon_open/release
Date: Tue,  5 Apr 2022 23:03:30 +0200	[thread overview]
Message-ID: <20220405210335.3434130-13-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20220405210335.3434130-1-daniel.vetter@ffwll.ch>

Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.

Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.

Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info

Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.

Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
 drivers/video/fbdev/core/fbcon.c | 5 +++++
 drivers/video/fbdev/core/fbmem.c | 4 ----
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index f0213a0e3870..cc960bf49991 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -684,8 +684,10 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
 
 static void fbcon_release(struct fb_info *info)
 {
+	lock_fb_info(info);
 	if (info->fbops->fb_release)
 		info->fbops->fb_release(info, 0);
+	unlock_fb_info(info);
 
 	module_put(info->fbops->owner);
 }
@@ -697,11 +699,14 @@ static int fbcon_open(struct fb_info *info)
 	if (!try_module_get(info->fbops->owner))
 		return -ENODEV;
 
+	lock_fb_info(info);
 	if (info->fbops->fb_open &&
 	    info->fbops->fb_open(info, 0)) {
+		unlock_fb_info(info);
 		module_put(info->fbops->owner);
 		return -ENODEV;
 	}
+	unlock_fb_info(info);
 
 	ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
 	if (!ops) {
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 34d6bb1bf82e..0e68d9456bc2 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1670,9 +1670,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
 		console_lock();
 	else
 		atomic_inc(&ignore_console_lock_warning);
-	lock_fb_info(fb_info);
 	ret = fbcon_fb_registered(fb_info);
-	unlock_fb_info(fb_info);
 
 	if (!lockless_register_fb)
 		console_unlock();
@@ -1689,9 +1687,7 @@ static void unbind_console(struct fb_info *fb_info)
 		return;
 
 	console_lock();
-	lock_fb_info(fb_info);
 	fbcon_fb_unbind(fb_info);
-	unlock_fb_info(fb_info);
 	console_unlock();
 }
 
-- 
2.34.1


  parent reply	other threads:[~2022-04-05 21:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 21:03 [PATCH v3 00/17] fbcon cleanups Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 01/17] fbcon: delete a few unneeded forward decl Daniel Vetter
2022-04-05 23:36   ` Fabio Estevam
2022-04-05 21:03 ` [PATCH v3 02/17] fbcon: Move fbcon_bmove(_rec) functions Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 03/17] fbcon: Introduce wrapper for console->fb_info lookup Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 04/17] fbcon: delete delayed loading code Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 05/17] fbdev/sysfs: Fix locking Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 06/17] fbcon: Use delayed work for cursor Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 07/17] fbcon: Replace FBCON_FLAGS_INIT with a boolean Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 08/17] fb: Delete fb_info->queue Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 09/17] fbcon: Extract fbcon_open/release helpers Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 10/17] fbcon: Ditch error handling for con2fb_release_oldinfo Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 11/17] fbcon: move more common code into fb_open() Daniel Vetter
2022-04-05 21:03 ` Daniel Vetter [this message]
2022-04-05 21:03 ` [PATCH v3 13/17] fbcon: Consistently protect deferred_takeover with console_lock() Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 14/17] fbcon: Move console_lock for register/unlink/unregister Daniel Vetter
2022-04-11 22:27   ` Nathan Chancellor
2022-04-13  8:13     ` Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 15/17] fbcon: Move more code into fbcon_release Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 16/17] fbcon: untangle fbcon_exit Daniel Vetter
2022-04-05 21:03 ` [PATCH v3 17/17] fbcon: Maintain a private array of fb_info Daniel Vetter
2022-04-08  7:51 ` [PATCH v3 00/17] fbcon cleanups Daniel Vetter

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=20220405210335.3434130-13-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=alexander.deucher@amd.com \
    --cc=cssk@net-c.es \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ducheng2@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=sam@ravnborg.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=tzimmermann@suse.de \
    --cc=william.kucharski@oracle.com \
    --cc=willy@infradead.org \
    --cc=xiyuyang19@fudan.edu.cn \
    --cc=zheyuma97@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).