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
next prev parent 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.