All of 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 12:02:24 +0530	[thread overview]
Message-ID: <84a62bf8-65e3-0b3b-91ef-bef5f4060601@amd.com> (raw)
In-Reply-To: <36880798-83c8-5566-dfe8-a18b9c4783f6@amd.com>



On 10/6/2021 11:49 AM, Christian König wrote:
> Am 06.10.21 um 06:51 schrieb Lazar, Lijo:
>>
>>
>> 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.
> 
> Yeah, but that is horrible API design and should be avoided.
> 
> ERR_PTR(), PTR_ERR(), IS_ERR() and similar are supposed to be used as 
> alternative to signaling errors as return values from functions and 
> should *never* ever be used to signal errors in pointer members.
> 

One escape route may be - add another export from debugfs like 
debugfs_is_valid_node() which adheres to the current logic in debugfs 
API and use that in client code. Whenever debugfs changes to a different 
logic from IS_ERR, let that be changed.

Thanks,
Lijo

> Regards,
> Christian.
> 
>>
>> 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  6:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 13:11 [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs Nirmoy Das
2021-10-05 13:22 ` Christian König
2021-10-05 13:49   ` Das, Nirmoy
2021-10-05 13:56     ` Lazar, Lijo
2021-10-05 16:45     ` Christian König
2021-10-06  4:51       ` Lazar, Lijo
2021-10-06  6:19         ` Christian König
2021-10-06  6:32           ` Lazar, Lijo [this message]
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=84a62bf8-65e3-0b3b-91ef-bef5f4060601@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 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.