From: "Christian König" <christian.koenig@amd.com>
To: "Lazar, Lijo" <lijo.lazar@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 08:35:35 +0200 [thread overview]
Message-ID: <43403acf-d6f6-ed4e-2954-f9cdc7ea88b0@amd.com> (raw)
In-Reply-To: <84a62bf8-65e3-0b3b-91ef-bef5f4060601@amd.com>
Am 06.10.21 um 08:32 schrieb Lazar, Lijo:
>
>
> 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.
Well that would then rather be drm_is_debugfs_enabled(), because that we
separate debugfs handling into a drm core and individual drivers is drm
specific.
Christian.
>
> 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)) {
>>>>>>
>>>>
>>
next prev parent reply other threads:[~2021-10-06 6:35 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
2021-10-06 6:19 ` Christian König
2021-10-06 6:32 ` Lazar, Lijo
2021-10-06 6:35 ` Christian König [this message]
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=43403acf-d6f6-ed4e-2954-f9cdc7ea88b0@amd.com \
--to=christian.koenig@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=lijo.lazar@amd.com \
--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