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@xxxxxxxxx> > Cc: Daniel Vetter <daniel@xxxxxxxx> > Cc: Claudio Suarez <cssk@xxxxxxxx> > Cc: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > Cc: Thomas Zimmermann <tzimmermann@xxxxxxx> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Cc: Du Cheng <ducheng2@xxxxxxxxx> > Cc: Sam Ravnborg <sam@xxxxxxxxxxxx> > Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx> > Cc: William Kucharski <william.kucharski@xxxxxxxxxx> > Cc: Alex Deucher <alexander.deucher@xxxxxxx> > Cc: Zheyu Ma <zheyuma97@xxxxxxxxx> > Cc: Zhen Lei <thunder.leizhen@xxxxxxxxxx> > Cc: Xiyu Yang <xiyuyang19@xxxxxxxxxxxx> Well, the patch does what the commit log says. Acked-by: Sam Ravnborg <sam@xxxxxxxxxxxx>
