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 <[email protected]> > Cc: Daniel Vetter <[email protected]> > Cc: Claudio Suarez <[email protected]> > Cc: Tetsuo Handa <[email protected]> > Cc: Thomas Zimmermann <[email protected]> > Cc: Greg Kroah-Hartman <[email protected]> > Cc: Du Cheng <[email protected]> > Cc: Sam Ravnborg <[email protected]> > Cc: Matthew Wilcox <[email protected]> > Cc: William Kucharski <[email protected]> > Cc: Alex Deucher <[email protected]> > Cc: Zheyu Ma <[email protected]> > Cc: Zhen Lei <[email protected]> > Cc: Xiyu Yang <[email protected]>
Well, the patch does what the commit log says. Acked-by: Sam Ravnborg <[email protected]>
