Hi Takashi,
Sorry for interrupt you again after such a long time. I just notice there was an old patch posted[1] from you that made pcm pointer() and trigger() callbacks could being able to be executed under non-atomic context, by using mutex instead of spin_lock_irq().
I find several similar deadlocks like this one on other places(inside pointer() and trigger() callbacks and being interrupted by hardirq), I am confusing whether they could be real deadlocks, as if these callbacks are executed under non-atomic context then they could be real problem.
Thanks much if you are available to reply,
Chengfeng
[1] https://patchwork.kernel.org/project/alsa-devel/patch/[email protected]/
On Sun, 17 Sep 2023 19:26:13 +0200,
YE Chengfeng wrote:
>
> Hi Takashi,
>
> Sorry for interrupt you again after such a long time. I just notice there was an old patch posted[1] from you that made pcm pointer() and trigger() callbacks could being able to be executed under non-atomic context, by using mutex instead of spin_lock_irq().
>
> I find several similar deadlocks like this one on other places(inside pointer() and trigger() callbacks and being interrupted by hardirq), I am confusing whether they could be real deadlocks, as if these callbacks are executed under non-atomic context then they could be real problem.
It can't be a problem. The new code path with mutex() is enabled only
when the PCM nonatomic flag is explicitly defined by the driver.
And the dummy driver doesn't, i.e. it still uses the traditional
atomic PCM ops, hence spin_lock() without the irq-save can be used
fine in the atomic ops like pointer or trigger.
Takashi
>
> Thanks much if you are available to reply,
> Chengfeng
>
> [1]?https://patchwork.kernel.org/project/alsa-devel/patch/[email protected]/