All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/panfrost: Prevent division by 0
Date: Thu, 20 Aug 2026 14:11:54 +0000	[thread overview]
Message-ID: <20260820141155.478701F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820-b4-panfrost-fixes-v1-2-1b2c2376f4bc@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Rearranging the expression to `status->busy_time * 100` introduces an integer overflow on 32-bit architectures, resulting in drastically incorrect devfreq load percentages being logged.
--

--- Patch [2]: [PATCH 2/3] drm/panfrost: Prevent division by 0 ---
commit f1707dda0ddcd92307754978d37b7e0bf9939612
Author: Adrián Larumbe <adrian.larumbe@collabora.com>
drm/panfrost: Prevent division by 0

This commit addresses a potential division by zero when calculating device
frequency utilization for debug logging. It rearranges the calculation to
multiply busy time by 100 before dividing by the maximum of total time or 1.

Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/88

> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -78,7 +78,7 @@ static int panfrost_devfreq_get_dev_status(struct device *dev,
>  
>  	dev_dbg(pfdev->base.dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
>  		status->busy_time, status->total_time,
> -		status->busy_time / (status->total_time / 100),
> +		status->busy_time * 100 / MAX(status->total_time, 1),

[Severity: Medium]
Will this calculation overflow on 32-bit architectures?

In panfrost_devfreq_get_dev_status(), status->busy_time is an unsigned long,
which is 32 bits on ARM32 architectures where Panfrost is widely used.

Since devfreq times are calculated in nanoseconds, a standard 50ms polling
interval can yield a busy_time of around 50,000,000 ns. Multiplying
50,000,000 by 100 results in 5,000,000,000, which exceeds the maximum
32-bit unsigned long value of 4,294,967,295.

Could this cause drastically incorrect load percentages to be logged during
normal GPU workloads when devfreq debug logging is enabled?

>  		status->current_frequency / 1000 / 1000);
>  
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820-b4-panfrost-fixes-v1-0-1b2c2376f4bc@collabora.com?part=2

  reply	other threads:[~2026-08-20 14:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 14:04 [PATCH 0/3] Collection of small fixes for Panfrost Adrián Larumbe
2026-08-20 14:04 ` [PATCH 1/3] drm/panfrost: Check another bo field for cache option query Adrián Larumbe
2026-08-20 14:04 ` [PATCH 2/3] drm/panfrost: Prevent division by 0 Adrián Larumbe
2026-08-20 14:11   ` sashiko-bot [this message]
2026-08-20 14:04 ` [PATCH 3/3] drm/panfrost: Remove unnecessary header file include Adrián Larumbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260820141155.478701F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=adrian.larumbe@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.