Messages in this thread | | | Date | Fri, 4 Feb 2022 20:39:00 +0100 | From | Sam Ravnborg <> | Subject | Re: [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release |
| |
On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote: > 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. > > 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>
Well, the patch does what the commit log says. Acked-by: Sam Ravnborg <sam@ravnborg.org>
| |