Thanks for the explanation. I agree that the analysis in the commit message is wrong: tbo is the first member of struct vmw_bo, so this does not create the NULL dereference described there. Please disregard this patch as a bug fix. Sorry for the noise.
Ruoyu Wang On Wed, Jul 8, 2026 at 11:35 AM Zack Rusin <[email protected]> wrote: > On Tue, Jul 7, 2026 at 11:05 AM Ruoyu Wang <[email protected]> wrote: > > > > Single-page MOBs and small OTable bases use depth-0 page-table entries > > and do not allocate a page-table BO. Their existing teardown paths were > > written to tolerate that by checking a local BO pointer before reserving > > or fencing it. > > > > Commit 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") > > changed pt_bo from a raw TTM buffer object pointer to a vmwgfx BO pointer > > and converted those local BO initializers to &pt_bo->tbo. That > > dereferences pt_bo before the existing NULL checks, so depth-0 MOBs can > > crash during OTable teardown or MOB unbind. > > That analysis is incorrect. Nothing here can crash. &pt_bo->tbo is not > a dereference. It's address-of-member. tbo is the first member of > struct vmw_bo (offset 0) so &((struct vmw_bo *)NULL)->tbo evaluates to > exactly NULL. The entire patch is basically a no-op. If you have some > decent static checker that's being tricked by this code and there's > value in unblocking it, please describe your static checker and feel > free to resubmit as a code cleanup, but the above analysis and fhe > fixes tag are incorrect. > > z >
