On Mon, Sep 22, 2025 at 10:42:52AM -0700, Rob Clark wrote:
> On Mon, Sep 22, 2025 at 9:46 AM Stephan Gerhold
> wrote:
> >
> > On Mon, Sep 22, 2025 at 09:41:07AM -0700, Rob Clark wrote:
> > > On Mon, Sep 22, 2025 at 9:33 AM Stephan Gerhold
> > > wrote:
> > > > On Wed, Jul 23, 2025 at 12:08:49PM -0
On Mon, Sep 22, 2025 at 09:41:07AM -0700, Rob Clark wrote:
> On Mon, Sep 22, 2025 at 9:33 AM Stephan Gerhold
> wrote:
> > On Wed, Jul 23, 2025 at 12:08:49PM -0700, Rob Clark wrote:
> > > If we hit an error path in GEM obj creation before msm_gem_new_handle()
> > > updates obj->resv to point to the
On Mon, Sep 22, 2025 at 9:33 AM Stephan Gerhold
wrote:
>
> Hi Rob,
>
> On Wed, Jul 23, 2025 at 12:08:49PM -0700, Rob Clark wrote:
> > If we hit an error path in GEM obj creation before msm_gem_new_handle()
> > updates obj->resv to point to the gpuvm resv object, then obj->resv
> > still points to
Hi Rob,
On Wed, Jul 23, 2025 at 12:08:49PM -0700, Rob Clark wrote:
> If we hit an error path in GEM obj creation before msm_gem_new_handle()
> updates obj->resv to point to the gpuvm resv object, then obj->resv
> still points to &obj->_resv. In this case we don't want to decrement
> the refcount
If we hit an error path in GEM obj creation before msm_gem_new_handle()
updates obj->resv to point to the gpuvm resv object, then obj->resv
still points to &obj->_resv. In this case we don't want to decrement
the refcount of the object being freed (since the refcnt is already
zero). This fixes th
