All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rob Clark" <robin.clark@oss.qualcomm.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/msm/debugfs: Use cleanup.h for gpu state dump
Date: Sun, 01 Nov 2026 17:56:12 +0000	[thread overview]
Message-ID: <sashiko-outbox-192546@kernel.org> (raw)
In-Reply-To: <20261101174631.23637-4-robin.clark@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] drm/msm/debugfs: cleanup.h scope.lock access and shadowing in msm_gpu_open()
--

commit 320eeedaaf2618e89f113d51dc4647a97f5a4d17
Author: Rob Clark <robin.clark@oss.qualcomm.com>

drm/msm/debugfs: Use cleanup.h for gpu state dump

This commit converts msm_gpu_open() in drivers/gpu/drm/msm/msm_debugfs.c
to use cleanup.h helpers (__free, scoped_guard, and scoped_cond_guard)
instead of goto-based error handling.

> diff --git a/drivers/gpu/drm/msm/msm_debugfs.c b/drivers/gpu/drm/msm/msm_debugfs.c
> index d05307bfa1235..e1b872576c7b1 100644
> --- a/drivers/gpu/drm/msm/msm_debugfs.c
> +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> @@ -70,43 +70,36 @@ static int msm_gpu_open(struct inode *inode, struct file *file)
>  	struct drm_device *dev = inode->i_private;
>  	struct msm_drm_private *priv = dev->dev_private;
>  	struct msm_gpu *gpu = priv->gpu;
> -	struct msm_gpu_show_priv *show_priv;
>  	int ret;
>  
>  	if (!gpu || !gpu->funcs->gpu_state_get)
>  		return -ENODEV;
>  
> -	show_priv = kmalloc_obj(*show_priv);
> +	struct msm_gpu_show_priv *show_priv __free(kfree)
> +		= kmalloc_obj(*show_priv);
>  	if (!show_priv)
>  		return -ENOMEM;
>  
> -	ret = mutex_lock_interruptible(&gpu->lock);
> -	if (ret)
> -		goto free_priv;
> -
> -	pm_runtime_get_sync(&gpu->pdev->dev);
> -	msm_gpu_hw_init(gpu);
> -	show_priv->state = gpu->funcs->gpu_state_get(gpu);
> -	pm_runtime_put_sync(&gpu->pdev->dev);
> -
> -	mutex_unlock(&gpu->lock);
> +	scoped_guard (pm_runtime_active, &gpu->pdev->dev) {
> +		scoped_cond_guard (mutex_intr, return PTR_ERR(scope.lock), &gpu->lock) {
> +			msm_gpu_hw_init(gpu);
> +			show_priv->state = gpu->funcs->gpu_state_get(gpu);
> +		}
> +	}

[Severity: Low]
In msm_gpu_open(), both __scoped_guard() and __scoped_cond_guard() in
include/linux/cleanup.h expand to for-loops that declare a local variable
named scope:

    #define __scoped_guard(_name, _label, args...) \
        for (CLASS(_name, scope)(args); ...

    #define __scoped_cond_guard(_name, _fail, _label, args...) \
        for (CLASS(_name, scope)(args); true; ({ goto _label; })) \
            if (!__guard_ptr(_name)(&scope)) { ...

Nesting scoped_cond_guard() inside scoped_guard() causes the inner scope
declaration to shadow the outer one, which triggers a -Wshadow warning when
building with W=2.

In addition, passing return PTR_ERR(scope.lock) as the failure statement
reaches into the internal macro variable scope and the internal .lock field
where DEFINE_LOCK_GUARD_1_COND_4() stores ERR_PTR(_RET) on lock acquisition
failure.

Could this return -EINTR directly (or use ACQUIRE()/ACQUIRE_ERR()) instead
of referencing scope.lock, and avoid nesting the two scoped guard macros?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261101174631.23637-1-robin.clark@oss.qualcomm.com?part=3

  reply	other threads:[~2026-11-01 17:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01 17:46 [PATCH 0/4] drm/msm: Decouple IFPC disable and sysprof Rob Clark
2026-11-01 17:46 ` [PATCH 1/4] drm/msm: Rework IFPC disable Rob Clark
2026-11-01 17:58   ` sashiko-bot
2026-11-01 17:46 ` [PATCH 2/4] drm/msm: Add cleanup help for disabling IFPC Rob Clark
2026-11-01 18:06   ` sashiko-bot
2026-11-01 17:46 ` [PATCH 3/4] drm/msm/debugfs: Use cleanup.h for gpu state dump Rob Clark
2026-11-01 17:56   ` sashiko-bot [this message]
2026-11-01 17:46 ` [PATCH 4/4] drm/msm: Inhibit IFPC for state snapshot Rob Clark
2026-11-01 18:09   ` sashiko-bot
2026-11-02  9:44 ` [PATCH 0/4] drm/msm: Decouple IFPC disable and sysprof Konrad Dybcio

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=sashiko-outbox-192546@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robin.clark@oss.qualcomm.com \
    --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.