Hi,

On Thursday, June 22, 2017 03:48:34 PM Daniel Vetter wrote:

On Thu, Jun 22, 2017 at 3:42 PM, Daniel Vetter [off-list ref] wrote:

quoted

Tears pretty much guaranteed, and after a few hacks from Alan&me I
concluded that the only way to fix this is to at least partially
rewrite fbdev (a dead subsystem, so no one's volunteering), with the
risk that you get to revert it all because someone is indeed relying
on that super-flexible module loading order sequence. The simplest fix
would probably be to make the entire fbdev->fbcon setup depency a
hard-coded function call, or maybe at most a one-shot symbol_get
attempt.

I did once hash out a plan how to fix this with the least amount of pain:

1. Merge a patch to build the fbcon support into the overall fb.ko
module, so that the dynamic loading nonsense is essentially disabled,
and fbcon becomes a Kconfig/compile-time only option, no longer a
runtime-selectable thing.

2. Wait 1 year and pray that no one reports a regression. If you're
unlucky, try to fence them of with a runtime option to disable fbcon.

3. Rip out the notifier nonsense and replace it by direct function
calls. You can only do that once 1. won't be reverted anymore.

4. Push the console_lock donw the callchains until it's again at the
right spots, auditing all the other stuff meanwhile to make sure the
locking is still correct.

5. Apply your patch to make console_lock sane.

Adding fbdev maintainers and lists just.

Your plan sounds good to me.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics