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