Skip to content

sink: guard against zero frame size in free-frames#10937

Open
lgirdwood wants to merge 1 commit into
thesofproject:mainfrom
lgirdwood:fix-sink-api
Open

sink: guard against zero frame size in free-frames#10937
lgirdwood wants to merge 1 commit into
thesofproject:mainfrom
lgirdwood:fix-sink-api

Conversation

@lgirdwood

Copy link
Copy Markdown
Member

sink_get_free_frames() divides the free byte count by the frame size, which
is channels * sample_size and can be zero when the channel count is zero
(host-influenced). Return 0 instead of dividing by zero.

Free-frames divided the free size by the frame size, which is channels
times sample size and can be zero when the channel count is zero. Return
zero instead of dividing by zero.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Copilot AI review requested due to automatic review settings June 17, 2026 13:30

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Prevents a divide-by-zero in sink_get_free_frames() when the computed frame size is zero (e.g., host provides channels == 0) by returning 0 frames instead.

Changes:

  • Compute frame_bytes once in sink_get_free_frames().
  • Add an early return when frame_bytes is zero to avoid division by zero.
  • Update comments to document why the guard exists (host-influenced inputs).

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

@tmleman tmleman left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Shouldn't we reject the case where the number of channels is equal to 0?

@lgirdwood

Copy link
Copy Markdown
Member Author

Shouldn't we reject the case where the number of channels is equal to 0?

We should indeed, which makes me think we need some agentic rules that help define what valid/invalid configurations would look like for audio at a high level. i.e. to be consumed by the code generating agent and by the code reviewing agent.

@kv2019i kv2019i left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Not sure about fixing this here

/* frame_bytes is channels * sample_size and both are host-influenced;
* guard against a zero divisor (e.g. channels == 0)
*/
if (!frame_bytes)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is a hot-path call. Should such checks be made at prepare() stage and not on the hot path?

/* frame_bytes is channels * sample_size and both are host-influenced;
* guard against a zero divisor (e.g. channels == 0)
*/
if (!frame_bytes)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

We should reject a frame size of 0 bytes before we get to this call, is there a check higher in the stack that validates this ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants