* [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
@ 2021-10-05 13:11 Nirmoy Das
2021-10-05 13:22 ` Christian König
0 siblings, 1 reply; 12+ messages in thread
From: Nirmoy Das @ 2021-10-05 13:11 UTC (permalink / raw)
To: amd-gfx; +Cc: Christian.Koenig, shashank.sharma, 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.
+ */
+ 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)) {
--
2.32.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
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
0 siblings, 1 reply; 12+ messages in thread
From: Christian König @ 2021-10-05 13:22 UTC (permalink / raw)
To: Nirmoy Das, amd-gfx; +Cc: shashank.sharma
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.
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)) {
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
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
0 siblings, 2 replies; 12+ messages in thread
From: Das, Nirmoy @ 2021-10-05 13:49 UTC (permalink / raw)
To: Christian König, amd-gfx; +Cc: shashank.sharma
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.
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)) {
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-05 13:49 ` Das, Nirmoy
@ 2021-10-05 13:56 ` Lazar, Lijo
2021-10-05 16:45 ` Christian König
1 sibling, 0 replies; 12+ messages in thread
From: Lazar, Lijo @ 2021-10-05 13:56 UTC (permalink / raw)
To: Das, Nirmoy, Christian König, amd-gfx; +Cc: shashank.sharma
On 10/5/2021 7:19 PM, Das, Nirmoy wrote:
>
> 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.
>
>
drm does a blind assignment.
minor->debugfs_root = debugfs_create_dir(name, root);
As per the latest documentation, the API doesn't return NULL
If an error occurs, ERR_PTR(-ERROR) will be returned.
In short, root won't be NULL once the debugfs API is called.
Thanks,
Lijo
> 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)) {
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
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
1 sibling, 1 reply; 12+ messages in thread
From: Christian König @ 2021-10-05 16:45 UTC (permalink / raw)
To: Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter; +Cc: shashank.sharma
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.
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)) {
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-05 16:45 ` Christian König
@ 2021-10-06 4:51 ` Lazar, Lijo
2021-10-06 6:19 ` Christian König
0 siblings, 1 reply; 12+ messages in thread
From: Lazar, Lijo @ 2021-10-06 4:51 UTC (permalink / raw)
To: Christian König, Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
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)) {
>>>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-06 4:51 ` Lazar, Lijo
@ 2021-10-06 6:19 ` Christian König
2021-10-06 6:32 ` Lazar, Lijo
0 siblings, 1 reply; 12+ messages in thread
From: Christian König @ 2021-10-06 6:19 UTC (permalink / raw)
To: Lazar, Lijo, Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
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.
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)) {
>>>>
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-06 6:19 ` Christian König
@ 2021-10-06 6:32 ` Lazar, Lijo
2021-10-06 6:35 ` Christian König
0 siblings, 1 reply; 12+ messages in thread
From: Lazar, Lijo @ 2021-10-06 6:32 UTC (permalink / raw)
To: Christian König, Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
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)) {
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-06 6:32 ` Lazar, Lijo
@ 2021-10-06 6:35 ` Christian König
2021-10-06 6:55 ` Lazar, Lijo
0 siblings, 1 reply; 12+ messages in thread
From: Christian König @ 2021-10-06 6:35 UTC (permalink / raw)
To: Lazar, Lijo, Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
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)) {
>>>>>>
>>>>
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-06 6:35 ` Christian König
@ 2021-10-06 6:55 ` Lazar, Lijo
2021-10-06 6:59 ` Christian König
0 siblings, 1 reply; 12+ messages in thread
From: Lazar, Lijo @ 2021-10-06 6:55 UTC (permalink / raw)
To: Christian König, Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
On 10/6/2021 12:05 PM, Christian König wrote:
> 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.
>
Had one more look and looks like this will do the job. In other cases,
API usage is allowed.
if (!debugfs_initialized())
return;
Thanks,
Lijo
> 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)) {
>>>>>>>
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-06 6:55 ` Lazar, Lijo
@ 2021-10-06 6:59 ` Christian König
2021-10-06 8:52 ` Das, Nirmoy
0 siblings, 1 reply; 12+ messages in thread
From: Christian König @ 2021-10-06 6:59 UTC (permalink / raw)
To: Lazar, Lijo, Das, Nirmoy, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
Am 06.10.21 um 08:55 schrieb Lazar, Lijo:
>
>
> On 10/6/2021 12:05 PM, Christian König wrote:
>> 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.
>>
>
> Had one more look and looks like this will do the job. In other cases,
> API usage is allowed.
>
> if (!debugfs_initialized())
> return;
Yeah, that might work as well.
Potentially a good idea to add that to both the core drm function and
the amdgpu function. and not attempt to create debugfs files in the
first place.
Christian.
>
> Thanks,
> Lijo
>
>> 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)) {
>>>>>>>>
>>>>>>
>>>>
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] drm/amdgpu: ignore -EPERM error from debugfs
2021-10-06 6:59 ` Christian König
@ 2021-10-06 8:52 ` Das, Nirmoy
0 siblings, 0 replies; 12+ messages in thread
From: Das, Nirmoy @ 2021-10-06 8:52 UTC (permalink / raw)
To: Christian König, Lazar, Lijo, amd-gfx, dri-devel, Daniel Vetter
Cc: shashank.sharma
On 10/6/2021 8:59 AM, Christian König wrote:
> Am 06.10.21 um 08:55 schrieb Lazar, Lijo:
>>
>>
>> On 10/6/2021 12:05 PM, Christian König wrote:
>>> 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.
>>>
>>
>> Had one more look and looks like this will do the job. In other
>> cases, API usage is allowed.
>>
>> if (!debugfs_initialized())
>> return;
>
> Yeah, that might work as well.
>
> Potentially a good idea to add that to both the core drm function and
> the amdgpu function. and not attempt to create debugfs files in the
> first place.
Sounds good, I will send patches to add this check.
Thanks,
Nirmoy
>
> Christian.
>
>>
>> Thanks,
>> Lijo
>>
>>> 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)) {
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-10-06 8:52 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.