linux-kernel - Re: [PATCH v4 01/11] ASoC: SOF: core: add 'no

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Sep 2023 09:51:41 +0300
From:   Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Cc:     alsa-devel@...a-project.org, Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>,
        Daniel Baluta <daniel.baluta@....com>,
        linux-kernel@...r.kernel.org, sound-open-firmware@...a-project.org
Subject: Re: [PATCH v4 01/11] ASoC: SOF: core: add 'no_wq' probe and remove
 callbacks

On 07/09/2023 20:29, Pierre-Louis Bossart wrote:
>> I think find all this very confusing, because there is no workqueue used
>> in the remove steps. The workqueue is only used ONCE during the probe.
> 
> Maybe we should just remove any references to workqueues, and have
> 
> probe_start (cannot run in a wq)
> probe (may run in a wq)
> remove (cannot run in a wq, needs to call cancel_work_sync() if the
> probe runs in a wq)
> remove_last (cannot run in a wq, releases all resources acquired in
> probe_start)
> 
> Or something similar that shows the symmetry between steps and when the
> wq is allowed.

What we have atm:
snd_sof_probe - might be called from wq
snd_sof_remove - might be called from wq (cleans up the snd_sof_probe
		 step)

We want a callbacks for hardware/device probing, right, split the
snd_sof_probe (and remove) to be able to support a sane level of
deferred probing support.

With that in mind:
snd_sof_device_probe - Not called from wq (to handle deferred probing)
snd_sof_probe - might be called from wq

snd_sof_remove - might be called from wq (cleans up the snd_sof_probe
		 step)
snd_sof_device_remove - Not called from wq (to up the
			snd_sof_device_probe step)

Naming option: s/device/hardware

However, I think the snd_sof_device_remove itself is redundant and we
might not need it at all as in case we have wq and there is a failure in
there we do want to release resources as much as possible. The module
will be kept loaded (no deferred handling in wq) and that might block
PM, other devices to behave correctly. Iow, if the wq has failure we
should do a cleanup to the best effort to reach a level like the driver
is not even loaded.

Doable? I thin it is.

-- 
Péter