| Message ID | 20191128011358.39234-1-cujomalainey@chromium.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 9c9b65203492927cc4ae419e9601e837ecbd889e |
| Headers | show |
| Series | ASoC: core: only flush inited work during free | expand |
On Thu, 28 Nov 2019 02:13:58 +0100, Curtis Malainey wrote: > > There are many paths to soc_free_pcm_runtime which can both have and > have not yet inited the workqueue yet. When we flush the queue when we > have not yet inited the queue we cause warnings to be printed. > > An example is soc_cleanup_card_resources which is called by > snd_soc_bind_card which has multiple failure points before and after > soc_link_init -> soc_new_pcm which is where the queue is inited. > > Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> This patch itself isn't wrong, but there is a generic problem in the current code in general. Many fields in snd_soc_pcm_runtime object, not only delayed_work, are initialized too late where soc_free_pcm_runtime() may be called beforehand. For example, rtd->component_list is initialized after the error path of rtd->codec_dais kmalloc, although soc_free_pcm_runtime() has a loop over the link. That said, at least the things like the linked list head and the work struct must be initialized right after the allocation before any use of the object. For this delayed_work, the situation is a bit complex, though. Usually the work is set up to point to a fixed function, but in the case of ASoC, it seems serving for different purposes depending on the component type. I guess the cleaner way would be a redirect call like: static void rtd_delayed_work(struct work_struct *work) { struct snd_soc_pcm_runtime *rtd = container_of(work, struct snd_soc_pcm_runtime, delayed_work.work); if (rtd->delayed_work_fn) rtd->delayed_work_fn(rtd); } static struct snd_soc_pcm_runtime *soc_new_pcm_runtime() { .... INIT_DELAYED_WORK(&rtd->delayed_work, rtd_delayed_work); .... } thanks, Takashi
On Thu, Nov 28, 2019 at 07:39:30AM +0100, Takashi Iwai wrote: > For this delayed_work, the situation is a bit complex, though. > Usually the work is set up to point to a fixed function, but in the > case of ASoC, it seems serving for different purposes depending on the > component type. I guess the cleaner way would be a redirect call > like: Yes, or just separate fields for each.
On Thu, Nov 28, 2019 at 5:49 AM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Nov 28, 2019 at 07:39:30AM +0100, Takashi Iwai wrote: > > > For this delayed_work, the situation is a bit complex, though. > > Usually the work is set up to point to a fixed function, but in the > > case of ASoC, it seems serving for different purposes depending on the > > component type. I guess the cleaner way would be a redirect call > > like: > > Yes, or just separate fields for each. Sounds good, I will refactor this change and send a new version next week as US is on holiday rest of this week.
On Thu, Nov 28, 2019 at 08:23:21AM -0800, Curtis Malainey wrote: > On Thu, Nov 28, 2019 at 5:49 AM Mark Brown <broonie@kernel.org> wrote: > > > For this delayed_work, the situation is a bit complex, though. > > > Usually the work is set up to point to a fixed function, but in the > > > case of ASoC, it seems serving for different purposes depending on the > > > component type. I guess the cleaner way would be a redirect call > > > like: > > Yes, or just separate fields for each. > Sounds good, I will refactor this change and send a new version next > week as US is on holiday rest of this week. I applied the change as-is already since like Takashi says it is an improvement in itself but obviously doing something more complete and thorough on top of it would be great if you have the time!
I sent a patch with the proxy function fix in it. I did not include a revert for this patch as I didn't see it on any of your branches. Let me know if I missed it and I can send you a revert as well. Curtis On Thu, Nov 28, 2019 at 9:28 AM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Nov 28, 2019 at 08:23:21AM -0800, Curtis Malainey wrote: > > On Thu, Nov 28, 2019 at 5:49 AM Mark Brown <broonie@kernel.org> wrote: > > > > > For this delayed_work, the situation is a bit complex, though. > > > > Usually the work is set up to point to a fixed function, but in the > > > > case of ASoC, it seems serving for different purposes depending on the > > > > component type. I guess the cleaner way would be a redirect call > > > > like: > > > > Yes, or just separate fields for each. > > > > Sounds good, I will refactor this change and send a new version next > > week as US is on holiday rest of this week. > > I applied the change as-is already since like Takashi says it is an > improvement in itself but obviously doing something more complete and > thorough on top of it would be great if you have the time!
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 062653ab03a37..3bf702b874a6d 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -419,7 +419,8 @@ static void soc_free_pcm_runtime(struct snd_soc_pcm_runtime *rtd) list_del(&rtd->list); - flush_delayed_work(&rtd->delayed_work); + if (delayed_work_pending(&rtd->delayed_work)) + flush_delayed_work(&rtd->delayed_work); snd_soc_pcm_component_free(rtd); /*
There are many paths to soc_free_pcm_runtime which can both have and have not yet inited the workqueue yet. When we flush the queue when we have not yet inited the queue we cause warnings to be printed. An example is soc_cleanup_card_resources which is called by snd_soc_bind_card which has multiple failure points before and after soc_link_init -> soc_new_pcm which is where the queue is inited. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> --- sound/soc/soc-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)