[Intel-gfx] [PATCH 04/33] vt: More locking checks

I honestly have no idea what the subtle differences between con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But it looks like both vc->vc_display_fg and con_driver_map are protected by the console_lock, so probably better if we hold that when checking this. To do that I had to d

Re: [Intel-gfx] [PATCH 04/33] vt: More locking checks

On Mon, May 27, 2019 at 09:08:58AM +0200, Daniel Vetter wrote: > On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote: > > I honestly have no idea what the subtle differences between > > con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But > > it looks like both vc->vc_di

Re: [Intel-gfx] [PATCH 04/33] vt: More locking checks

On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote: > I honestly have no idea what the subtle differences between > con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But > it looks like both vc->vc_display_fg and con_driver_map are protected > by the console_lock, so pro

[Intel-gfx] [PATCH 04/33] vt: More locking checks

I honestly have no idea what the subtle differences between con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But it looks like both vc->vc_display_fg and con_driver_map are protected by the console_lock, so probably better if we hold that when checking this. To do that I had to d

[Intel-gfx] [PATCH 04/33] vt: More locking checks

I honestly have no idea what the subtle differences between con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But it looks like both vc->vc_display_fg and con_driver_map are protected by the console_lock, so probably better if we hold that when checking this. To do that I had to d