On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > > On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote: > > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxx> > > --- > > 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. > What ends up happening is the submit has reference to submit-queue, which has reference to the ctx.. the submitqueue could be alive still pending in-flight submits (in a later patch), but dead from the PoV of userspace interface. We aren't relying (or at least aren't in the end, and I *think* I didn't miss anything in the middle) relying on ctx->submitqueues list to clean anything up in the end, just track what is still a valid submitqueue from userspace PoV BR, -R > > 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 > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel