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

[Hans Verkuil]

Hi Hans,

On 17/02/2021 13:24, Hans de Goede wrote:
> <resend with the linux-media list added to the Cc>
> 
> 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

It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.

I've added Sean Young to the CC list.

Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is set?

I think this issue is very specific to CEC. I would not expect to see this
with any other rc keymap.

Regards,

	Hans

>  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 ?
>