dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Lazar, Lijo" <lijo.lazar@amd.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Das, Nirmoy" <nirmoy.das@amd.com>,
	amd-gfx@lists.freedesktop.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Daniel Vetter" <daniel@ffwll.ch>
Cc: shashank.sharma@amd.com
Subject: Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
Date: Wed, 6 Oct 2021 10:21:12 +0530	[thread overview]
Message-ID: <af8ba141-1581-4b96-4ef4-bc82111e213d@amd.com> (raw)
In-Reply-To: <45342056-8e15-bdb0-0237-d11476bcc8fa@amd.com>



On 10/5/2021 10:15 PM, Christian König wrote:
> Am 05.10.21 um 15:49 schrieb Das, Nirmoy:
>>
>> On 10/5/2021 3:22 PM, Christian König wrote:
>>>
>>>
>>> Am 05.10.21 um 15:11 schrieb Nirmoy Das:
>>>> Debugfs core APIs will throw -EPERM when user disables debugfs
>>>> using CONFIG_DEBUG_FS_ALLOW_NONE or with kernel param. We shouldn't
>>>> see that as an error. Also validate drm root dentry before creating
>>>> amdgpu debugfs files.
>>>>
>>>> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
>>>> ---
>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 ++++++++++
>>>>   1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> index 6611b3c7c149..d786072e918b 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> @@ -1617,6 +1617,16 @@ int amdgpu_debugfs_init(struct amdgpu_device 
>>>> *adev)
>>>>       struct dentry *ent;
>>>>       int r, i;
>>>>   +    if (IS_ERR(root)) {
>>>> +        /* When debugfs is disabled we get -EPERM which is not an
>>>> +         * error as this is user controllable.
>>>> +         */
>>>
>>> Well setting primary->debugfs_root to an error code is probably not a 
>>> good idea to begin with.
>>>
>>> When debugfs is disabled that should most likely be NULL.
>>
>>
>> If we set primary->debugfs_root to  NULL then we need to add bunch of 
>> NULL checks everywhere before creating any debugfs files
>>
>> because debugfs_create_{file|dir}() with NULL root is still valid.  I 
>> am assuming a hypothetical case when debugfs_root dir creation fails 
>> even with debugfs enabled
>>
>> but further calls are successful.  This wont be a problem if we 
>> propagate the error code.
> 
> Yeah, but an error code in members is ugly like hell and potentially 
> causes crashes instead.
> 
> I strongly suggest to fix this so that root is NULL when debugfs isn't 
> available and we add proper checks for that instead.

This shouldn't be done. A NULL is a valid parent for debugfs API. An 
invalid parent is always checked like this
	      if (IS_ERR(parent))
                 return parent;

Instead of adding redundant work like NULL checks, let the API do its 
work and don't break the API contract. For ex: usage of sample client, 
you may look at the drm usage; it does the same.

Thanks,
Lijo

> 
> Regards,
> Christian.
> 
>>
>>
>> Regards,
>>
>> Nirmoy
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>> +        if (PTR_ERR(root) == -EPERM)
>>>> +            return 0;
>>>> +
>>>> +        return PTR_ERR(ent);
>>>> +    }
>>>> +
>>>>       ent = debugfs_create_file("amdgpu_preempt_ib", 0600, root, adev,
>>>>                     &fops_ib_preempt);
>>>>       if (IS_ERR(ent)) {
>>>
> 

  reply	other threads:[~2021-10-06  4:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20211005131115.25595-1-nirmoy.das@amd.com>
     [not found] ` <ab673b77-e8b7-94a4-76f6-588ad9e472f7@amd.com>
     [not found]   ` <182c1454-102e-cf2f-80eb-09baa57f8e82@amd.com>
2021-10-05 16:45     ` [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs Christian König
2021-10-06  4:51       ` Lazar, Lijo [this message]
2021-10-06  6:19         ` Christian König
2021-10-06  6:32           ` Lazar, Lijo
2021-10-06  6:35             ` Christian König
2021-10-06  6:55               ` Lazar, Lijo
2021-10-06  6:59                 ` Christian König
2021-10-06  8:52                   ` Das, Nirmoy

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=af8ba141-1581-4b96-4ef4-bc82111e213d@amd.com \
    --to=lijo.lazar@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=nirmoy.das@amd.com \
    --cc=shashank.sharma@amd.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox