On Fri, Aug 22, 2025 at 12:25 PM Danilo Krummrich <[email protected]> wrote: > > On Fri Aug 22, 2025 at 11:28 AM CEST, Alice Ryhl wrote: > > diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h > > index > > 4a22b9d848f7b3d5710ca554f5b01556abf95985..598ba376b9430cdd4ab7bacdc15de031a887cf71 > > 100644 > > --- a/include/drm/drm_gpuvm.h > > +++ b/include/drm/drm_gpuvm.h > > @@ -196,10 +196,20 @@ enum drm_gpuvm_flags { > > */ > > DRM_GPUVM_RESV_PROTECTED = BIT(0), > > > > + /** > > + * @DRM_GPUVM_IMMEDIATE_MODE: use the locking scheme that makes it > > safe > > + * to modify the GPUVM during the fence signalling path > > I think this isn't entirely true yet or at least can be ambiguous for now, > because it doesn't prevent users from having DRM_GPUVM_RESV_PROTECTED set, > which > requires the DMA resv lock to destroy a struct drm_gpuvm_bo, which may happen > from drm_gpuva_unlink(). > > So, for now, until we have the deferred drop idea in place, it also > requires DRM_GPUVM_RESV_PROTECTED to not be set. > > (Eventually, we of course want both to be represented as a single flag, such > that it becomes an either or.)
I'm going to introduce "designed for" in the wording to address this. I don't think we need to say that you are required to only pick one of DRM_GPUVM_RESV_PROTECTED or this flag, since you can use both if you manually postpone vm_bo cleanup. Let's just not elaborate on that here. > I also wouldn't say "makes it safe to", but rather "makes it possible to > safely". We have no control over what the users do with the mutex. :) > > NIT: missing period I didn't put a period for consistency. Nothing else has a period in the summary sentence at the top of the doc-comment. Alice
