Re: [PATCH 1/8] mmput: use notifier chain to call subsystem exit handler.

[Jerome Glisse <j.glisse@gmail.com>]

On Wed, Jul 09, 2014 at 06:21:24PM +0200, Joerg Roedel wrote:
> On Tue, Jul 08, 2014 at 05:59:58PM -0400, j.glisse@gmail.com wrote:
> > +int mmput_register_notifier(struct notifier_block *nb)
> > +{
> > +	return blocking_notifier_chain_register(&mmput_notifier, nb);
> > +}
> > +EXPORT_SYMBOL_GPL(mmput_register_notifier);
> > +
> > +int mmput_unregister_notifier(struct notifier_block *nb)
> > +{
> > +	return blocking_notifier_chain_unregister(&mmput_notifier, nb);
> > +}
> > +EXPORT_SYMBOL_GPL(mmput_unregister_notifier);
> 
> I am still not convinced that this is required. For core code that needs
> to hook into mmput (like aio or uprobes) it really improves code
> readability if their teardown functions are called explicitly in mmput.
> 
> And drivers that deal with the mm can use the already existing
> mmu_notifers. That works at least for the AMD-IOMMUv2 and KFD drivers.
> 
> Maybe HMM is different here, but then you should explain why and how it
> is different and why you can't add an explicit teardown function for
> HMM.

My first patchset added a call to hmm in mmput but Andrew asked me to
instead add a notifier chain as he foresee more user for that. Hence
why i did this patch.

On why hmm need to cleanup here it is simple :
  - hmm is tie to mm_struct (add a pointer to mm_struct)
  - hmm pointer of mm_struct is clear on fork
  - hmm object lifespan should be the same as mm_struct
  - device file descriptor can outlive the mm_struct into which they
    were open and thus an hmm structure that was allocated on behalf
    of a device driver would stay allocated for as long as children
    that have no use for it leaves (ie until they close the device
    file).

So again, hmm is tie to mm_struct life span. We want to free hmm and
its resources when mm is destroyed. We can not do that in file >release
callback because it might happen long after the mm struct is free.

We can not do that from mmu_notifier release callback because this
would lead to use after free.

We could add a delayed job from mmu_notifier callback but this would
be hacky as we would have no way to synchronize ourself with the mm
destruction without complex rules and crazy code.

So again i do not see any alternative to hmm interfacing them and i
genuinely belive iommuv2 is in the same situation as us thus justifying
even more the notifier chain idea.

Cheers,
Jerome

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>