[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Tomi Valkeinen]

On 08/12/15 10:19, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote:
>>
>> On 25/08/15 16:45, Daniel Vetter wrote:
>>> When the usual fbcon legacy options are enabled we have
>>> ->register_framebuffer
>>>   ->fb notifier chain calls into fbcon
>>>     ->fbcon sets up console on new fbi
>>>       ->fbi->set_par
>>>         ->drm_fb_helper_set_par exercises full kms api
>>>
>>> And because of locking inversion hilarity all of register_framebuffer
>>> is done with the console lock held. Which means that the first time on
>>> driver load we exercise _all_ the kms code (all probe paths and
>>> modeset paths for everything connected) is under the console lock.
>>> That means if anything goes belly-up in that big pile of code nothing
>>> ever reaches logfiles (and the machine is dead).
>>>
>>> Usual tactic to debug that is to temporarily remove those console_lock
>>> calls to be able to capture backtraces. I'm fed up writing this patch
>>> and recompiling kernels. Hence this patch here to add an unsafe,
>>> kernel-taining option to do this at runtime.
>>
>> I think this was never merged. This was part 4 of 4, were there
>> dependencies or...? Should I apply this for 4.5?
> 
> Patches 1-3 have all already landed in drm, and patch 4 is free standing.
> Would be great if you can pull it in.

Ok, I'll apply for 4.5.

>> But then... I think my issues with console lock have been later at
>> runtime, not at register. Maybe we need a module option to disable the
>> console lock altogether. I wonder how much havoc that might create, though.
> 
> Hm, where in fbdev do you hold the console_lock outside of
> registering/unregistering an fbdev (because of fbcon)? There's of course
> general trouble with console_lock deadlocks and fun like that, but ime
> that all got a lot more manageable since I added lockdep annotations to
> console_lock.

I don't know... I just have a vague recollection that I was having
trouble with the lock with... crashes during blanking, perhaps. I really
can't remember, so possibly things are better now, or I just remember wrong.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/a1acfb5b/attachment.sig>