Skip to content

ASoC: SOF: fix race in FW boot timeout handling#896

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
plbossart merged 1 commit into from
May 3, 2019
Merged

ASoC: SOF: fix race in FW boot timeout handling #896

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions sound/soc/sof/loader.c
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -372,6 +372,8 @@ int snd_sof_run_firmware(struct snd_sof_dev *sdev)
msecs_to_jiffies(sdev->boot_timeout));
if (ret == 0) {
dev_err(sdev->dev, "error: firmware boot failure\n");
/* after this point FW_READY msg should be ignored */
sdev->boot_complete = true;

@plbossartplbossartMay 2, 2019

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Humm, not quite getting the idea.
the boot_complete is tested for in snd_sof_ipc_msgs_rx() which is called in the interrupt thead, so isn't there a risk here? so you could have a case where you timeout, and before setting boot_complete to true you deal with the interrupt.
I guess if @lyakh approves I am fine but I can't figure this one out by myself...

@kv2019ikv2019iMay 2, 2019

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plbossart wrote:

the boot_complete is tested for in snd_sof_ipc_msgs_rx() which is called in the interrupt thead, > so isn't there a risk here? so you could have a case where you timeout, and before setting
boot_complete to true you deal with the interrupt.

This is ok, if interrupt occurs here we are still all set up and FW_READY can be handled. We set up the debugfs nodes and what not but no kernel crashes.

The problem I hit if the interrupt happens after this point. E.g. even snd_sof_ipc_free() still doesn't actually disable the IPC, so there's quite a wide time window where resources have been freed while the IPC irq is still active and can potentially receive FW_READY.

@plbossartplbossartMay 2, 2019

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. If @lyakh agrees then we are good to go.

@plbossartplbossartMay 3, 2019

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will assume @lyakh is fine with the changes...

snd_sof_dsp_dbg_dump(sdev, SOF_DBG_REGS | SOF_DBG_MBOX |
SOF_DBG_TEXT | SOF_DBG_PCI);
return -EIO;
Expand Down