[Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect

[Hans de Goede]

Hi Hans,

Fedora has a (opt-in) system to automatically collect backtraces from software
crashing on users systems.

This includes collecting kernel backtraces (including once triggered by
WARN macros) while looking a the top 10 of the most reported backtrace during the
last 2 weeks report from ABRT: https://retrace.fedoraproject.org/faf/problems/

I noticed the following backtrace:
https://retrace.fedoraproject.org/faf/problems/8150/
which has been reported 170000 times by Fedora users who have opted-in during the
last 14 days.

The issue here is that cec_register_adapter ends up calling request_module()
from an async context, triggering this warn in kernel/kmod.c __request_module():

        /*
         * We don't allow synchronous module loading from async.  Module
         * init may invoke async_synchronize_full() which will end up
         * waiting for this task which already is waiting for the module
         * loading to complete, leading to a deadlock.
         */
        WARN_ON_ONCE(wait && current_is_async());

The call-path leading to this goes like this:

 ? kvasprintf+0x6d/0xa0
 ? kobject_set_name_vargs+0x6f/0x90
 rc_map_get+0x30/0x60
 rc_register_device+0x108/0x510
 cec_register_adapter+0x5c/0x280 [cec]
 drm_dp_cec_set_edid+0x11e/0x178 [drm_kms_helper]
 intel_dp_set_edid+0x8d/0xc0 [i915]
 intel_dp_detect+0x188/0x5c0 [i915]
 drm_helper_probe_single_connector_modes+0xc2/0x6d0 [drm_kms_helper]
 ? krealloc+0x7b/0xb0
 drm_client_modeset_probe+0x25b/0x1320 [drm]
 ? kfree+0x1ea/0x200
 ? sched_clock+0x5/0x10
 ? sched_clock_cpu+0xc/0xa0
 __drm_fb_helper_initial_config_and_unlock+0x37/0x470 [drm_kms_helper]
 ? _cond_resched+0x16/0x40
 intel_fbdev_initial_config+0x14/0x30 [i915]
 async_run_entry_fn+0x39/0x160

So 2 questions:

1. Can we get this fixed please ?
   Related to this, what happens if we make this an async modprobe
   (when running from async context) is that a problem, or is it fine
   if the rc_map module gets loaded later ?

2. If the answer to 1. is "tricky", "maybe" or some such then can we
look into a workaround here ? E.g. do we know in advance which module
is going to be requested (1), or does that depend on the EDID data ?

Regards,

Hans


1) And can we thus do tricks with a softdep on it ?