All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [bug report] drm/ttm, drm_xe, Implement ttm_lru_walk_for_evict() using the guarded LRU iteration
Date: Mon, 21 Jul 2025 16:10:15 +0200	[thread overview]
Message-ID: <70af5644eaf561617aaf6ade2d83fe1f1afa7ffa.camel@linux.intel.com> (raw)
In-Reply-To: <1dcd1afb-1e5d-4624-ae3f-9f96ceab6134@sabinyo.mountain>

Hi!

On Tue, 2025-07-01 at 12:49 -0500, Dan Carpenter wrote:
> Hello Thomas Hellström,
> 
> Commit bb8aa27eff6f ("drm/ttm, drm_xe, Implement
> ttm_lru_walk_for_evict() using the guarded LRU iteration") from Jun
> 23, 2025 (linux-next), leads to the following Smatch static checker
> warning:
> 
> 	drivers/gpu/drm/ttm/ttm_bo_util.c:899
> ttm_lru_walk_for_evict()
> 	warn: 'bo' isn't an ERR_PTR
> 
> drivers/gpu/drm/ttm/ttm_bo_util.c
>    883  s64 ttm_lru_walk_for_evict(struct ttm_lru_walk *walk, struct
> ttm_device *bdev,
>    884                             struct ttm_resource_manager *man,
> s64 target)
>    885  {
>    886          struct ttm_bo_lru_cursor cursor;
>    887          struct ttm_buffer_object *bo;
>    888          s64 progress = 0;
>    889          s64 lret;
>    890  
>    891          ttm_bo_lru_for_each_reserved_guarded(&cursor, man,
> &walk->arg, bo) {
>    892                  lret = walk->ops->process_bo(walk, bo);
>    893                  if (lret == -EBUSY || lret == -EALREADY)
>    894                          lret = 0;
>    895                  progress = (lret < 0) ? lret : progress +
> lret;
>    896                  if (progress < 0 || progress >= target)
>    897                          break;
>    898          }
>    899          if (IS_ERR(bo))
>    900                  return PTR_ERR(bo);
> 
> The ttm_bo_lru_for_each_reserved_guarded() macro checks for
> IS_ERR_OR_NULL()
> but it can only be NULL.

That's not correct.

>   These things are a bit frustrating to me because
> when a function returns both error pointers and NULL then ideally
> there is a
> reason for that and it should be documented.  "This function returns
> error
> pointers if there is an error (kmalloc failed etc) or NULL if the
> object is
> not found".

The error pointer is documented under the
ttm_bo_lru_for_each_reserved_guarded() macro. But it is true that I've
forgotten to update the doc for ttm_bo_lru_cursor_first() and
ttm_bo_lru_cursor_next() to reflect that they may return an error
pointer or NULL. I will put together a patch for that.

> 
> https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
> 
>    901  
>    902          return progress;
> 
> It's strange to me that we returns progress values which are greater
> than the
> target value.

This is also documented in the ttm_lru_walk_for_evict() kerneldoc. In
short a typical intended use-case is that we're requested to evict
@target pages, but since we evict a buffer object at a time (multiple
pages) the total may exceed @progress.

In any case it looks like the ttm_lru_walk_for_evict() function may go
away with upcoming patches from Christian.

Thanks,
Thomas
 

> 
>    903  }
> 
> regards,
> dan carpenter


  reply	other threads:[~2025-07-21 14:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 17:49 [bug report] drm/ttm, drm_xe, Implement ttm_lru_walk_for_evict() using the guarded LRU iteration Dan Carpenter
2025-07-21 14:10 ` Thomas Hellström [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-06-29  3:51 Dan Carpenter
2025-07-21 14:35 ` Thomas Hellström

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=70af5644eaf561617aaf6ade2d83fe1f1afa7ffa.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=dan.carpenter@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    /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.