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.vet...@intel.com> > Cc: Daniel Vetter <dan...@ffwll.ch> > Cc: Claudio Suarez <c...@net-c.es> > Cc: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > Cc: Thomas Zimmermann <tzimmerm...@suse.de> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: Du Cheng <duche...@gmail.com> > Cc: Sam Ravnborg <s...@ravnborg.org> > Cc: Matthew Wilcox <wi...@infradead.org> > Cc: William Kucharski <william.kuchar...@oracle.com> > Cc: Alex Deucher <alexander.deuc...@amd.com> > Cc: Zheyu Ma <zheyum...@gmail.com> > Cc: Zhen Lei <thunder.leiz...@huawei.com> > Cc: Xiyu Yang <xiyuyan...@fudan.edu.cn>
Well, the patch does what the commit log says. Acked-by: Sam Ravnborg <s...@ravnborg.org>
