[PATCH] drm/sched: Fix passing zero to 'PTR_ERR' warning

Dan Carpenter dan.carpenter at oracle.com
Tue Oct 29 18:03:57 UTC 2019

On Tue, Oct 29, 2019 at 11:04:44AM -0400, Andrey Grodzovsky wrote:
> Fix a static code checker warning.
> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky at amd.com>
> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index f39b97e..898b0c9 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -497,7 +497,7 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched)
> 		fence = sched->ops->run_job(s_job);
>  		if (IS_ERR_OR_NULL(fence)) {
>  			s_job->s_fence->parent = NULL;
> -			dma_fence_set_error(&s_fence->finished, PTR_ERR(fence));
> +			dma_fence_set_error(&s_fence->finished, PTR_ERR_OR_ZERO(fence));

I feel like I should explain better.  It's generally bad to mix NULL and
error pointers.  The situation where you would do it is when NULL is a
special case of success.  A typical situation is you request a feature,
like maybe logging for example:

	p = get_logger();

If there isn't enough memory then get_logger() returns ERR_PTR(-ENOMEM);
but if the user has disabled logging then we can't return a valid
pointer but it's also not an error so we return NULL.  It's a special
case of success.

In this situation sched->ops->run_job(s_job); appears to only ever
return NULL and it's not a special case of success, it's a regular old
error.  I guess we are transitioning from returning NULL to returning
error pointers?

So we should just do something like:

	fence = sched->ops->run_job(s_job);

	/* FIXME: Oct 2019: Remove this code when fence can't be NULL. */
	if (!fence)
		fence = ERR_PTR(-EINVAL);

	if (IS_ERR(fence)) {

dan carpenter

More information about the dri-devel mailing list