• Grant Likely's avatar
    drivercore: deferral race condition fix · f1c8467e
    Grant Likely authored
    commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream.
    When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
    when all modules loaded but some driver still stuck in the deferred list
    and there is a need for external event to kick the deferred queue to probe
    these drivers.
    The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
    audio support built as modules and using nfsroot for root filesystem.
    The following log fragment shows such sequence when all audio modules
    were loaded but the sound card is not present since the machine driver has
    failed to probe due to missing dependency during it's probe.
    The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
    machine driver:
    [   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
    [   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
    [   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
    [   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
    [   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
    [   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
    [   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
    [   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
    [   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
    [   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
    [   13.346755] davinci_mcasp_driver_init: LEAVE
    [   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
    [   13.592527] platform sound.3: really_probe: probe_count = 0
    In the log the machine driver enters it's probe at 12.719969 (this point it
    has been removed from the deferred lists). McASP driver already executing
    it's probing (since 12.615118).
    The machine driver tries to construct the sound card (12.950839) but did
    not found one of the components so it fails. After this McASP driver
    registers all the ASoC components (the machine driver still in it's probe
    function after it failed to construct the card) and the deferred work is
    prepared at 13.099026 (note that this time the machine driver is not in the
    lists so it is not going to be handled when the work is executing).
    Lastly the machine driver exit from it's probe and the core places it to
    the deferred list but there will be no other driver going to load and the
    deferred queue is not going to be kicked again - till we have external event
    like connecting USB stick, etc.
    The proposed solution is to try the deferred queue once more when the last
    driver is asking for deferring and we had drivers loaded while this last
    driver was probing.
    This way we can avoid drivers stuck in the deferred queue.
    Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
    Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
    Tested-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
    Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
dd.c 16.7 KB