On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
From: Rob Clark robdclark@chromium.org
Currently it doesn't matter, since we free the ctx immediately. But when we start refcnt'ing the ctx, we don't want old dangling list entries to hang around.
Signed-off-by: Rob Clark robdclark@chromium.org
drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c b/drivers/gpu/drm/msm/msm_submitqueue.c index a1d94be7883a..90c9d84e6155 100644 --- a/drivers/gpu/drm/msm/msm_submitqueue.c +++ b/drivers/gpu/drm/msm/msm_submitqueue.c @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx) * No lock needed in close and there won't * be any more user ioctls coming our way */
- list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node)
- list_for_each_entry_safe(entry, tmp, &ctx->submitqueues, node) {
list_del(&entry->node);
If you refcount ctx, what does that do for the entries in the submit queue?
"entry" here is kref'ed, but you're popping it off the list regardless of the put ends up freeing the object or not - which afaict would mean leaking the object.
On the other hand, with the current implementation an object with higher refcount with adjacent objects of single refcount would end up with dangling pointers after the put. So in itself this change seems like a net gain, but I'm wondering about the plan described in the commit message.
Regards, Bjorn
msm_submitqueue_put(entry);
- }
}
int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private *ctx,
2.26.2