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

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

[Gabbay, Oded]

On Fri, 2014-06-27 at 22:00 -0400, Jérôme Glisse wrote:
> From: Jérôme Glisse <jglisse@redhat.com>
> 
> Several subsystem require a callback when a mm struct is being destroy
> so that they can cleanup there respective per mm struct. Instead of
> having each subsystem add its callback to mmput use a notifier chain
> to call each of the subsystem.
> 
> This will allow new subsystem to register callback even if they are
> module. There should be no contention on the rw semaphore protecting
> the call chain and the impact on the code path should be low and
> burried in the noise.
> 
> Note that this patch also move the call to cleanup functions after
> exit_mmap so that new call back can assume that mmu_notifier_release
> have already been call. This does not impact existing cleanup functions
> as they do not rely on anything that exit_mmap is freeing. Also moved
> khugepaged_exit to exit_mmap so that ordering is preserved for that
> function.
> 
> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
> ---
>  fs/aio.c                | 29 ++++++++++++++++++++++-------
>  include/linux/aio.h     |  2 --
>  include/linux/ksm.h     | 11 -----------
>  include/linux/sched.h   |  5 +++++
>  include/linux/uprobes.h |  1 -
>  kernel/events/uprobes.c | 19 ++++++++++++++++---
>  kernel/fork.c           | 22 ++++++++++++++++++----
>  mm/ksm.c                | 26 +++++++++++++++++++++-----
>  mm/mmap.c               |  3 +++
>  9 files changed, 85 insertions(+), 33 deletions(-)
> 
> diff --git a/fs/aio.c b/fs/aio.c
> index c1d8c48..1d06e92 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -40,6 +40,7 @@
>  #include <linux/ramfs.h>
>  #include <linux/percpu-refcount.h>
>  #include <linux/mount.h>
> +#include <linux/notifier.h>
>  
>  #include <asm/kmap_types.h>
>  #include <asm/uaccess.h>
> @@ -774,20 +775,22 @@ ssize_t wait_on_sync_kiocb(struct kiocb *req)
>  EXPORT_SYMBOL(wait_on_sync_kiocb);
>  
>  /*
> - * exit_aio: called when the last user of mm goes away.  At this point, there is
> + * aio_exit: called when the last user of mm goes away.  At this point, there is
>   * no way for any new requests to be submited or any of the io_* syscalls to be
>   * called on the context.
>   *
>   * There may be outstanding kiocbs, but free_ioctx() will explicitly wait on
>   * them.
>   */
> -void exit_aio(struct mm_struct *mm)
> +static int aio_exit(struct notifier_block *nb,
> +		    unsigned long action, void *data)
>  {
> +	struct mm_struct *mm = data;
>  	struct kioctx_table *table = rcu_dereference_raw(mm->ioctx_table);
>  	int i;
>  
>  	if (!table)
> -		return;
> +		return 0;
>  
>  	for (i = 0; i < table->nr; ++i) {
>  		struct kioctx *ctx = table->table[i];
> @@ -796,10 +799,10 @@ void exit_aio(struct mm_struct *mm)
>  			continue;
>  		/*
>  		 * We don't need to bother with munmap() here - exit_mmap(mm)
> -		 * is coming and it'll unmap everything. And we simply can't,
> -		 * this is not necessarily our ->mm.
> -		 * Since kill_ioctx() uses non-zero ->mmap_size as indicator
> -		 * that it needs to unmap the area, just set it to 0.
> +		 * have already been call and everything is unmap by now. But
> +		 * to be safe set ->mmap_size to 0 since aio_free_ring() uses
> +		 * non-zero ->mmap_size as indicator that it needs to unmap the
> +		 * area.
>  		 */
>  		ctx->mmap_size = 0;
>  		kill_ioctx(mm, ctx, NULL);
> @@ -807,6 +810,7 @@ void exit_aio(struct mm_struct *mm)
>  
>  	RCU_INIT_POINTER(mm->ioctx_table, NULL);
>  	kfree(table);
> +	return 0;
>  }
>  
>  static void put_reqs_available(struct kioctx *ctx, unsigned nr)
> @@ -1629,3 +1633,14 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
>  	}
>  	return ret;
>  }
> +
> +static struct notifier_block aio_mmput_nb = {
> +	.notifier_call		= aio_exit,
> +	.priority		= 1,
> +};
> +
> +static int __init aio_init(void)
> +{
> +	return mmput_register_notifier(&aio_mmput_nb);
> +}
> +subsys_initcall(aio_init);
> diff --git a/include/linux/aio.h b/include/linux/aio.h
> index d9c92da..6308fac 100644
> --- a/include/linux/aio.h
> +++ b/include/linux/aio.h
> @@ -73,7 +73,6 @@ static inline void init_sync_kiocb(struct kiocb *kiocb, struct file *filp)
>  extern ssize_t wait_on_sync_kiocb(struct kiocb *iocb);
>  extern void aio_complete(struct kiocb *iocb, long res, long res2);
>  struct mm_struct;
> -extern void exit_aio(struct mm_struct *mm);
>  extern long do_io_submit(aio_context_t ctx_id, long nr,
>  			 struct iocb __user *__user *iocbpp, bool compat);
>  void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn *cancel);
> @@ -81,7 +80,6 @@ void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn *cancel);
>  static inline ssize_t wait_on_sync_kiocb(struct kiocb *iocb) { return 0; }
>  static inline void aio_complete(struct kiocb *iocb, long res, long res2) { }
>  struct mm_struct;
> -static inline void exit_aio(struct mm_struct *mm) { }
>  static inline long do_io_submit(aio_context_t ctx_id, long nr,
>  				struct iocb __user * __user *iocbpp,
>  				bool compat) { return 0; }
> diff --git a/include/linux/ksm.h b/include/linux/ksm.h
> index 3be6bb1..84c184f 100644
> --- a/include/linux/ksm.h
> +++ b/include/linux/ksm.h
> @@ -20,7 +20,6 @@ struct mem_cgroup;
>  int ksm_madvise(struct vm_area_struct *vma, unsigned long start,
>  		unsigned long end, int advice, unsigned long *vm_flags);
>  int __ksm_enter(struct mm_struct *mm);
> -void __ksm_exit(struct mm_struct *mm);
>  
>  static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
>  {
> @@ -29,12 +28,6 @@ static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
>  	return 0;
>  }
>  
> -static inline void ksm_exit(struct mm_struct *mm)
> -{
> -	if (test_bit(MMF_VM_MERGEABLE, &mm->flags))
> -		__ksm_exit(mm);
> -}
> -
>  /*
>   * A KSM page is one of those write-protected "shared pages" or "merged pages"
>   * which KSM maps into multiple mms, wherever identical anonymous page content
> @@ -83,10 +76,6 @@ static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
>  	return 0;
>  }
>  
> -static inline void ksm_exit(struct mm_struct *mm)
> -{
> -}
> -
>  static inline int PageKsm(struct page *page)
>  {
>  	return 0;
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 322d4fc..428b3cf 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2384,6 +2384,11 @@ static inline void mmdrop(struct mm_struct * mm)
>  		__mmdrop(mm);
>  }
>  
> +/* mmput call list of notifier and subsystem/module can register
> + * new one through this call.
> + */
> +extern int mmput_register_notifier(struct notifier_block *nb);
> +extern int mmput_unregister_notifier(struct notifier_block *nb);
>  /* mmput gets rid of the mappings and all user-space */
>  extern void mmput(struct mm_struct *);
>  /* Grab a reference to a task's mm, if it is not already going away */
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index 4f844c6..44e7267 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -120,7 +120,6 @@ extern int uprobe_pre_sstep_notifier(struct pt_regs *regs);
>  extern void uprobe_notify_resume(struct pt_regs *regs);
>  extern bool uprobe_deny_signal(void);
>  extern bool arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
> -extern void uprobe_clear_state(struct mm_struct *mm);
>  extern int  arch_uprobe_analyze_insn(struct arch_uprobe *aup, struct mm_struct *mm, unsigned long addr);
>  extern int  arch_uprobe_pre_xol(struct arch_uprobe *aup, struct pt_regs *regs);
>  extern int  arch_uprobe_post_xol(struct arch_uprobe *aup, struct pt_regs *regs);
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 46b7c31..32b04dc 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -37,6 +37,7 @@
>  #include <linux/percpu-rwsem.h>
>  #include <linux/task_work.h>
>  #include <linux/shmem_fs.h>
> +#include <linux/notifier.h>
>  
>  #include <linux/uprobes.h>
>  
> @@ -1220,16 +1221,19 @@ static struct xol_area *get_xol_area(void)
>  /*
>   * uprobe_clear_state - Free the area allocated for slots.
>   */
> -void uprobe_clear_state(struct mm_struct *mm)
> +static int uprobe_clear_state(struct notifier_block *nb,
> +			      unsigned long action, void *data)
>  {
> +	struct mm_struct *mm = data;
>  	struct xol_area *area = mm->uprobes_state.xol_area;
>  
>  	if (!area)
> -		return;
> +		return 0;
>  
>  	put_page(area->page);
>  	kfree(area->bitmap);
>  	kfree(area);
> +	return 0;
>  }
>  
>  void uprobe_start_dup_mmap(void)
> @@ -1979,9 +1983,14 @@ static struct notifier_block uprobe_exception_nb = {
>  	.priority		= INT_MAX-1,	/* notified after kprobes, kgdb */
>  };
>  
> +static struct notifier_block uprobe_mmput_nb = {
> +	.notifier_call		= uprobe_clear_state,
> +	.priority		= 0,
> +};
> +
>  static int __init init_uprobes(void)
>  {
> -	int i;
> +	int i, err;
>  
>  	for (i = 0; i < UPROBES_HASH_SZ; i++)
>  		mutex_init(&uprobes_mmap_mutex[i]);
> @@ -1989,6 +1998,10 @@ static int __init init_uprobes(void)
>  	if (percpu_init_rwsem(&dup_mmap_sem))
>  		return -ENOMEM;
>  
> +	err = mmput_register_notifier(&uprobe_mmput_nb);
> +	if (err)
> +		return err;
> +
>  	return register_die_notifier(&uprobe_exception_nb);
>  }
>  __initcall(init_uprobes);
> diff --git a/kernel/fork.c b/kernel/fork.c
> index dd8864f..b448509 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -87,6 +87,8 @@
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/task.h>
>  
> +static BLOCKING_NOTIFIER_HEAD(mmput_notifier);
> +
>  /*
>   * Protected counters by write_lock_irq(&tasklist_lock)
>   */
> @@ -623,6 +625,21 @@ void __mmdrop(struct mm_struct *mm)
>  EXPORT_SYMBOL_GPL(__mmdrop);
>  
>  /*
> + * Register a notifier that will be call by mmput
> + */
> +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);
> +
> +/*
>   * Decrement the use count and release all resources for an mm.
>   */
>  void mmput(struct mm_struct *mm)
> @@ -630,11 +647,8 @@ void mmput(struct mm_struct *mm)
>  	might_sleep();
>  
>  	if (atomic_dec_and_test(&mm->mm_users)) {
> -		uprobe_clear_state(mm);
> -		exit_aio(mm);
> -		ksm_exit(mm);
> -		khugepaged_exit(mm); /* must run before exit_mmap */
>  		exit_mmap(mm);
> +		blocking_notifier_call_chain(&mmput_notifier, 0, mm);
>  		set_mm_exe_file(mm, NULL);
>  		if (!list_empty(&mm->mmlist)) {
>  			spin_lock(&mmlist_lock);
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 346ddc9..cb1e976 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -37,6 +37,7 @@
>  #include <linux/freezer.h>
>  #include <linux/oom.h>
>  #include <linux/numa.h>
> +#include <linux/notifier.h>
>  
>  #include <asm/tlbflush.h>
>  #include "internal.h"
> @@ -1586,7 +1587,7 @@ static struct rmap_item *scan_get_next_rmap_item(struct page **page)
>  		ksm_scan.mm_slot = slot;
>  		spin_unlock(&ksm_mmlist_lock);
>  		/*
> -		 * Although we tested list_empty() above, a racing __ksm_exit
> +		 * Although we tested list_empty() above, a racing ksm_exit
>  		 * of the last mm on the list may have removed it since then.
>  		 */
>  		if (slot == &ksm_mm_head)
> @@ -1658,9 +1659,9 @@ next_mm:
>  		/*
>  		 * We've completed a full scan of all vmas, holding mmap_sem
>  		 * throughout, and found no VM_MERGEABLE: so do the same as
> -		 * __ksm_exit does to remove this mm from all our lists now.
> -		 * This applies either when cleaning up after __ksm_exit
> -		 * (but beware: we can reach here even before __ksm_exit),
> +		 * ksm_exit does to remove this mm from all our lists now.
> +		 * This applies either when cleaning up after ksm_exit
> +		 * (but beware: we can reach here even before ksm_exit),
>  		 * or when all VM_MERGEABLE areas have been unmapped (and
>  		 * mmap_sem then protects against race with MADV_MERGEABLE).
>  		 */
> @@ -1821,11 +1822,16 @@ int __ksm_enter(struct mm_struct *mm)
>  	return 0;
>  }
>  
> -void __ksm_exit(struct mm_struct *mm)
> +static int ksm_exit(struct notifier_block *nb,
> +		    unsigned long action, void *data)
>  {
> +	struct mm_struct *mm = data;
>  	struct mm_slot *mm_slot;
>  	int easy_to_free = 0;
>  
> +	if (!test_bit(MMF_VM_MERGEABLE, &mm->flags))
> +		return 0;
> +
>  	/*
>  	 * This process is exiting: if it's straightforward (as is the
>  	 * case when ksmd was never running), free mm_slot immediately.
> @@ -1857,6 +1863,7 @@ void __ksm_exit(struct mm_struct *mm)
>  		down_write(&mm->mmap_sem);
>  		up_write(&mm->mmap_sem);
>  	}
> +	return 0;
>  }
>  
>  struct page *ksm_might_need_to_copy(struct page *page,
> @@ -2305,11 +2312,20 @@ static struct attribute_group ksm_attr_group = {
>  };
>  #endif /* CONFIG_SYSFS */
>  
> +static struct notifier_block ksm_mmput_nb = {
> +	.notifier_call		= ksm_exit,
> +	.priority		= 2,
> +};
> +
>  static int __init ksm_init(void)
>  {
>  	struct task_struct *ksm_thread;
>  	int err;
>  
> +	err = mmput_register_notifier(&ksm_mmput_nb);
> +	if (err)
> +		return err;
> +
>  	err = ksm_slab_init();
>  	if (err)
>  		goto out;
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 61aec93..b684a21 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2775,6 +2775,9 @@ void exit_mmap(struct mm_struct *mm)
>  	struct vm_area_struct *vma;
>  	unsigned long nr_accounted = 0;
>  
> +	/* Important to call this first. */
> +	khugepaged_exit(mm);
> +
>  	/* mm's last user has gone, and its about to be pulled down */
>  	mmu_notifier_release(mm);
>  

Hi Jerome, I reviewed the patch, integrated and tested it in AMD's HSA
driver (KFD). It works as expected and I didn't find any problems with
it.

I did face some problems regarding the amd IOMMU v2 driver, which
changed its behavior (see commit "iommu/amd: Implement
mmu_notifier_release call-back") to use mmu_notifier_release and did
some "bad things" inside that
notifier (primarily, but not only, deleting the object which held the
mmu_notifier object itself, which you mustn't do because of the
locking). 

I'm thinking of changing that driver's behavior to use this new
mechanism instead of using mmu_notifier_release. Does that seem
acceptable ? Another solution will be to add a new mmu_notifier call,
but we already ruled that out ;)

So,
Reviewed-by: Oded Gabbay <oded.gabbay@amd.com>

	Oded

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

[Jerome Glisse]

On Mon, Jun 30, 2014 at 02:41:24PM +0000, Gabbay, Oded wrote:
> On Fri, 2014-06-27 at 22:00 -0400, Jérôme Glisse wrote:
> > From: Jérôme Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > 
> > Several subsystem require a callback when a mm struct is being destroy
> > so that they can cleanup there respective per mm struct. Instead of
> > having each subsystem add its callback to mmput use a notifier chain
> > to call each of the subsystem.
> > 
> > This will allow new subsystem to register callback even if they are
> > module. There should be no contention on the rw semaphore protecting
> > the call chain and the impact on the code path should be low and
> > burried in the noise.
> > 
> > Note that this patch also move the call to cleanup functions after
> > exit_mmap so that new call back can assume that mmu_notifier_release
> > have already been call. This does not impact existing cleanup functions
> > as they do not rely on anything that exit_mmap is freeing. Also moved
> > khugepaged_exit to exit_mmap so that ordering is preserved for that
> > function.
> > 
> > Signed-off-by: Jérôme Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> >  fs/aio.c                | 29 ++++++++++++++++++++++-------
> >  include/linux/aio.h     |  2 --
> >  include/linux/ksm.h     | 11 -----------
> >  include/linux/sched.h   |  5 +++++
> >  include/linux/uprobes.h |  1 -
> >  kernel/events/uprobes.c | 19 ++++++++++++++++---
> >  kernel/fork.c           | 22 ++++++++++++++++++----
> >  mm/ksm.c                | 26 +++++++++++++++++++++-----
> >  mm/mmap.c               |  3 +++
> >  9 files changed, 85 insertions(+), 33 deletions(-)
> > 
> > diff --git a/fs/aio.c b/fs/aio.c
> > index c1d8c48..1d06e92 100644
> > --- a/fs/aio.c
> > +++ b/fs/aio.c
> > @@ -40,6 +40,7 @@
> >  #include <linux/ramfs.h>
> >  #include <linux/percpu-refcount.h>
> >  #include <linux/mount.h>
> > +#include <linux/notifier.h>
> >  
> >  #include <asm/kmap_types.h>
> >  #include <asm/uaccess.h>
> > @@ -774,20 +775,22 @@ ssize_t wait_on_sync_kiocb(struct kiocb *req)
> >  EXPORT_SYMBOL(wait_on_sync_kiocb);
> >  
> >  /*
> > - * exit_aio: called when the last user of mm goes away.  At this point, there is
> > + * aio_exit: called when the last user of mm goes away.  At this point, there is
> >   * no way for any new requests to be submited or any of the io_* syscalls to be
> >   * called on the context.
> >   *
> >   * There may be outstanding kiocbs, but free_ioctx() will explicitly wait on
> >   * them.
> >   */
> > -void exit_aio(struct mm_struct *mm)
> > +static int aio_exit(struct notifier_block *nb,
> > +		    unsigned long action, void *data)
> >  {
> > +	struct mm_struct *mm = data;
> >  	struct kioctx_table *table = rcu_dereference_raw(mm->ioctx_table);
> >  	int i;
> >  
> >  	if (!table)
> > -		return;
> > +		return 0;
> >  
> >  	for (i = 0; i < table->nr; ++i) {
> >  		struct kioctx *ctx = table->table[i];
> > @@ -796,10 +799,10 @@ void exit_aio(struct mm_struct *mm)
> >  			continue;
> >  		/*
> >  		 * We don't need to bother with munmap() here - exit_mmap(mm)
> > -		 * is coming and it'll unmap everything. And we simply can't,
> > -		 * this is not necessarily our ->mm.
> > -		 * Since kill_ioctx() uses non-zero ->mmap_size as indicator
> > -		 * that it needs to unmap the area, just set it to 0.
> > +		 * have already been call and everything is unmap by now. But
> > +		 * to be safe set ->mmap_size to 0 since aio_free_ring() uses
> > +		 * non-zero ->mmap_size as indicator that it needs to unmap the
> > +		 * area.
> >  		 */
> >  		ctx->mmap_size = 0;
> >  		kill_ioctx(mm, ctx, NULL);
> > @@ -807,6 +810,7 @@ void exit_aio(struct mm_struct *mm)
> >  
> >  	RCU_INIT_POINTER(mm->ioctx_table, NULL);
> >  	kfree(table);
> > +	return 0;
> >  }
> >  
> >  static void put_reqs_available(struct kioctx *ctx, unsigned nr)
> > @@ -1629,3 +1633,14 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
> >  	}
> >  	return ret;
> >  }
> > +
> > +static struct notifier_block aio_mmput_nb = {
> > +	.notifier_call		= aio_exit,
> > +	.priority		= 1,
> > +};
> > +
> > +static int __init aio_init(void)
> > +{
> > +	return mmput_register_notifier(&aio_mmput_nb);
> > +}
> > +subsys_initcall(aio_init);
> > diff --git a/include/linux/aio.h b/include/linux/aio.h
> > index d9c92da..6308fac 100644
> > --- a/include/linux/aio.h
> > +++ b/include/linux/aio.h
> > @@ -73,7 +73,6 @@ static inline void init_sync_kiocb(struct kiocb *kiocb, struct file *filp)
> >  extern ssize_t wait_on_sync_kiocb(struct kiocb *iocb);
> >  extern void aio_complete(struct kiocb *iocb, long res, long res2);
> >  struct mm_struct;
> > -extern void exit_aio(struct mm_struct *mm);
> >  extern long do_io_submit(aio_context_t ctx_id, long nr,
> >  			 struct iocb __user *__user *iocbpp, bool compat);
> >  void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn *cancel);
> > @@ -81,7 +80,6 @@ void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn *cancel);
> >  static inline ssize_t wait_on_sync_kiocb(struct kiocb *iocb) { return 0; }
> >  static inline void aio_complete(struct kiocb *iocb, long res, long res2) { }
> >  struct mm_struct;
> > -static inline void exit_aio(struct mm_struct *mm) { }
> >  static inline long do_io_submit(aio_context_t ctx_id, long nr,
> >  				struct iocb __user * __user *iocbpp,
> >  				bool compat) { return 0; }
> > diff --git a/include/linux/ksm.h b/include/linux/ksm.h
> > index 3be6bb1..84c184f 100644
> > --- a/include/linux/ksm.h
> > +++ b/include/linux/ksm.h
> > @@ -20,7 +20,6 @@ struct mem_cgroup;
> >  int ksm_madvise(struct vm_area_struct *vma, unsigned long start,
> >  		unsigned long end, int advice, unsigned long *vm_flags);
> >  int __ksm_enter(struct mm_struct *mm);
> > -void __ksm_exit(struct mm_struct *mm);
> >  
> >  static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
> >  {
> > @@ -29,12 +28,6 @@ static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
> >  	return 0;
> >  }
> >  
> > -static inline void ksm_exit(struct mm_struct *mm)
> > -{
> > -	if (test_bit(MMF_VM_MERGEABLE, &mm->flags))
> > -		__ksm_exit(mm);
> > -}
> > -
> >  /*
> >   * A KSM page is one of those write-protected "shared pages" or "merged pages"
> >   * which KSM maps into multiple mms, wherever identical anonymous page content
> > @@ -83,10 +76,6 @@ static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
> >  	return 0;
> >  }
> >  
> > -static inline void ksm_exit(struct mm_struct *mm)
> > -{
> > -}
> > -
> >  static inline int PageKsm(struct page *page)
> >  {
> >  	return 0;
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 322d4fc..428b3cf 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -2384,6 +2384,11 @@ static inline void mmdrop(struct mm_struct * mm)
> >  		__mmdrop(mm);
> >  }
> >  
> > +/* mmput call list of notifier and subsystem/module can register
> > + * new one through this call.
> > + */
> > +extern int mmput_register_notifier(struct notifier_block *nb);
> > +extern int mmput_unregister_notifier(struct notifier_block *nb);
> >  /* mmput gets rid of the mappings and all user-space */
> >  extern void mmput(struct mm_struct *);
> >  /* Grab a reference to a task's mm, if it is not already going away */
> > diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> > index 4f844c6..44e7267 100644
> > --- a/include/linux/uprobes.h
> > +++ b/include/linux/uprobes.h
> > @@ -120,7 +120,6 @@ extern int uprobe_pre_sstep_notifier(struct pt_regs *regs);
> >  extern void uprobe_notify_resume(struct pt_regs *regs);
> >  extern bool uprobe_deny_signal(void);
> >  extern bool arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
> > -extern void uprobe_clear_state(struct mm_struct *mm);
> >  extern int  arch_uprobe_analyze_insn(struct arch_uprobe *aup, struct mm_struct *mm, unsigned long addr);
> >  extern int  arch_uprobe_pre_xol(struct arch_uprobe *aup, struct pt_regs *regs);
> >  extern int  arch_uprobe_post_xol(struct arch_uprobe *aup, struct pt_regs *regs);
> > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > index 46b7c31..32b04dc 100644
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -37,6 +37,7 @@
> >  #include <linux/percpu-rwsem.h>
> >  #include <linux/task_work.h>
> >  #include <linux/shmem_fs.h>
> > +#include <linux/notifier.h>
> >  
> >  #include <linux/uprobes.h>
> >  
> > @@ -1220,16 +1221,19 @@ static struct xol_area *get_xol_area(void)
> >  /*
> >   * uprobe_clear_state - Free the area allocated for slots.
> >   */
> > -void uprobe_clear_state(struct mm_struct *mm)
> > +static int uprobe_clear_state(struct notifier_block *nb,
> > +			      unsigned long action, void *data)
> >  {
> > +	struct mm_struct *mm = data;
> >  	struct xol_area *area = mm->uprobes_state.xol_area;
> >  
> >  	if (!area)
> > -		return;
> > +		return 0;
> >  
> >  	put_page(area->page);
> >  	kfree(area->bitmap);
> >  	kfree(area);
> > +	return 0;
> >  }
> >  
> >  void uprobe_start_dup_mmap(void)
> > @@ -1979,9 +1983,14 @@ static struct notifier_block uprobe_exception_nb = {
> >  	.priority		= INT_MAX-1,	/* notified after kprobes, kgdb */
> >  };
> >  
> > +static struct notifier_block uprobe_mmput_nb = {
> > +	.notifier_call		= uprobe_clear_state,
> > +	.priority		= 0,
> > +};
> > +
> >  static int __init init_uprobes(void)
> >  {
> > -	int i;
> > +	int i, err;
> >  
> >  	for (i = 0; i < UPROBES_HASH_SZ; i++)
> >  		mutex_init(&uprobes_mmap_mutex[i]);
> > @@ -1989,6 +1998,10 @@ static int __init init_uprobes(void)
> >  	if (percpu_init_rwsem(&dup_mmap_sem))
> >  		return -ENOMEM;
> >  
> > +	err = mmput_register_notifier(&uprobe_mmput_nb);
> > +	if (err)
> > +		return err;
> > +
> >  	return register_die_notifier(&uprobe_exception_nb);
> >  }
> >  __initcall(init_uprobes);
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index dd8864f..b448509 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -87,6 +87,8 @@
> >  #define CREATE_TRACE_POINTS
> >  #include <trace/events/task.h>
> >  
> > +static BLOCKING_NOTIFIER_HEAD(mmput_notifier);
> > +
> >  /*
> >   * Protected counters by write_lock_irq(&tasklist_lock)
> >   */
> > @@ -623,6 +625,21 @@ void __mmdrop(struct mm_struct *mm)
> >  EXPORT_SYMBOL_GPL(__mmdrop);
> >  
> >  /*
> > + * Register a notifier that will be call by mmput
> > + */
> > +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);
> > +
> > +/*
> >   * Decrement the use count and release all resources for an mm.
> >   */
> >  void mmput(struct mm_struct *mm)
> > @@ -630,11 +647,8 @@ void mmput(struct mm_struct *mm)
> >  	might_sleep();
> >  
> >  	if (atomic_dec_and_test(&mm->mm_users)) {
> > -		uprobe_clear_state(mm);
> > -		exit_aio(mm);
> > -		ksm_exit(mm);
> > -		khugepaged_exit(mm); /* must run before exit_mmap */
> >  		exit_mmap(mm);
> > +		blocking_notifier_call_chain(&mmput_notifier, 0, mm);
> >  		set_mm_exe_file(mm, NULL);
> >  		if (!list_empty(&mm->mmlist)) {
> >  			spin_lock(&mmlist_lock);
> > diff --git a/mm/ksm.c b/mm/ksm.c
> > index 346ddc9..cb1e976 100644
> > --- a/mm/ksm.c
> > +++ b/mm/ksm.c
> > @@ -37,6 +37,7 @@
> >  #include <linux/freezer.h>
> >  #include <linux/oom.h>
> >  #include <linux/numa.h>
> > +#include <linux/notifier.h>
> >  
> >  #include <asm/tlbflush.h>
> >  #include "internal.h"
> > @@ -1586,7 +1587,7 @@ static struct rmap_item *scan_get_next_rmap_item(struct page **page)
> >  		ksm_scan.mm_slot = slot;
> >  		spin_unlock(&ksm_mmlist_lock);
> >  		/*
> > -		 * Although we tested list_empty() above, a racing __ksm_exit
> > +		 * Although we tested list_empty() above, a racing ksm_exit
> >  		 * of the last mm on the list may have removed it since then.
> >  		 */
> >  		if (slot == &ksm_mm_head)
> > @@ -1658,9 +1659,9 @@ next_mm:
> >  		/*
> >  		 * We've completed a full scan of all vmas, holding mmap_sem
> >  		 * throughout, and found no VM_MERGEABLE: so do the same as
> > -		 * __ksm_exit does to remove this mm from all our lists now.
> > -		 * This applies either when cleaning up after __ksm_exit
> > -		 * (but beware: we can reach here even before __ksm_exit),
> > +		 * ksm_exit does to remove this mm from all our lists now.
> > +		 * This applies either when cleaning up after ksm_exit
> > +		 * (but beware: we can reach here even before ksm_exit),
> >  		 * or when all VM_MERGEABLE areas have been unmapped (and
> >  		 * mmap_sem then protects against race with MADV_MERGEABLE).
> >  		 */
> > @@ -1821,11 +1822,16 @@ int __ksm_enter(struct mm_struct *mm)
> >  	return 0;
> >  }
> >  
> > -void __ksm_exit(struct mm_struct *mm)
> > +static int ksm_exit(struct notifier_block *nb,
> > +		    unsigned long action, void *data)
> >  {
> > +	struct mm_struct *mm = data;
> >  	struct mm_slot *mm_slot;
> >  	int easy_to_free = 0;
> >  
> > +	if (!test_bit(MMF_VM_MERGEABLE, &mm->flags))
> > +		return 0;
> > +
> >  	/*
> >  	 * This process is exiting: if it's straightforward (as is the
> >  	 * case when ksmd was never running), free mm_slot immediately.
> > @@ -1857,6 +1863,7 @@ void __ksm_exit(struct mm_struct *mm)
> >  		down_write(&mm->mmap_sem);
> >  		up_write(&mm->mmap_sem);
> >  	}
> > +	return 0;
> >  }
> >  
> >  struct page *ksm_might_need_to_copy(struct page *page,
> > @@ -2305,11 +2312,20 @@ static struct attribute_group ksm_attr_group = {
> >  };
> >  #endif /* CONFIG_SYSFS */
> >  
> > +static struct notifier_block ksm_mmput_nb = {
> > +	.notifier_call		= ksm_exit,
> > +	.priority		= 2,
> > +};
> > +
> >  static int __init ksm_init(void)
> >  {
> >  	struct task_struct *ksm_thread;
> >  	int err;
> >  
> > +	err = mmput_register_notifier(&ksm_mmput_nb);
> > +	if (err)
> > +		return err;
> > +
> >  	err = ksm_slab_init();
> >  	if (err)
> >  		goto out;
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 61aec93..b684a21 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2775,6 +2775,9 @@ void exit_mmap(struct mm_struct *mm)
> >  	struct vm_area_struct *vma;
> >  	unsigned long nr_accounted = 0;
> >  
> > +	/* Important to call this first. */
> > +	khugepaged_exit(mm);
> > +
> >  	/* mm's last user has gone, and its about to be pulled down */
> >  	mmu_notifier_release(mm);
> >  
> 
> Hi Jerome, I reviewed the patch, integrated and tested it in AMD's HSA
> driver (KFD). It works as expected and I didn't find any problems with
> it.
> 
> I did face some problems regarding the amd IOMMU v2 driver, which
> changed its behavior (see commit "iommu/amd: Implement
> mmu_notifier_release call-back") to use mmu_notifier_release and did
> some "bad things" inside that
> notifier (primarily, but not only, deleting the object which held the
> mmu_notifier object itself, which you mustn't do because of the
> locking). 
> 
> I'm thinking of changing that driver's behavior to use this new
> mechanism instead of using mmu_notifier_release. Does that seem
> acceptable ? Another solution will be to add a new mmu_notifier call,
> but we already ruled that out ;)
> 

This sounds acceptable. You can check how i did it in hmm :
http://cgit.freedesktop.org/~glisse/linux/log/?h=hmm

As it had similar issues.

Cheers,
Jérôme

> So,
> Reviewed-by: Oded Gabbay <oded.gabbay-5C7GfCeVMHo@public.gmane.org>
> 
> 	Oded

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

[Joerg Roedel]

On Mon, Jun 30, 2014 at 02:41:24PM +0000, Gabbay, Oded wrote:
> I did face some problems regarding the amd IOMMU v2 driver, which
> changed its behavior (see commit "iommu/amd: Implement
> mmu_notifier_release call-back") to use mmu_notifier_release and did
> some "bad things" inside that
> notifier (primarily, but not only, deleting the object which held the
> mmu_notifier object itself, which you mustn't do because of the
> locking). 
> 
> I'm thinking of changing that driver's behavior to use this new
> mechanism instead of using mmu_notifier_release. Does that seem
> acceptable ? Another solution will be to add a new mmu_notifier call,
> but we already ruled that out ;)

The mmu_notifier_release() function is exactly what this new notifier
aims to do. Unless there is a very compelling reason to duplicate this
functionality I stronly NACK this approach.


	Joerg

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

[Jerome Glisse]

On Mon, Jun 30, 2014 at 05:40:42PM +0200, Joerg Roedel wrote:
> On Mon, Jun 30, 2014 at 02:41:24PM +0000, Gabbay, Oded wrote:
> > I did face some problems regarding the amd IOMMU v2 driver, which
> > changed its behavior (see commit "iommu/amd: Implement
> > mmu_notifier_release call-back") to use mmu_notifier_release and did
> > some "bad things" inside that
> > notifier (primarily, but not only, deleting the object which held the
> > mmu_notifier object itself, which you mustn't do because of the
> > locking). 
> > 
> > I'm thinking of changing that driver's behavior to use this new
> > mechanism instead of using mmu_notifier_release. Does that seem
> > acceptable ? Another solution will be to add a new mmu_notifier call,
> > but we already ruled that out ;)
> 
> The mmu_notifier_release() function is exactly what this new notifier
> aims to do. Unless there is a very compelling reason to duplicate this
> functionality I stronly NACK this approach.
> 
>

No this patch does not duplicate it. Current user of mmu_notifier
rely on file close code path to call mmu_notifier_unregister. New
code like AMD IOMMUv2 or HMM can not rely on that. Thus they need
a way to call the mmu_notifer_unregister (which can not be done
from inside the the release call back).

If you look at current code the release callback is use to kill
secondary translation but not to free associated resources. All
the associated resources are free later on after the release
callback (well it depends if the file is close before the process
is kill).

So this patch aims to provide a callback to code outside of the
mmu_notifier realms, a place where it is safe to cleanup the
mmu_notifier and associated resources.

Cheers,
Jérôme Glisse

--
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>

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

[Joerg Roedel]

On Mon, Jun 30, 2014 at 12:06:05PM -0400, Jerome Glisse wrote:
> No this patch does not duplicate it. Current user of mmu_notifier
> rely on file close code path to call mmu_notifier_unregister. New
> code like AMD IOMMUv2 or HMM can not rely on that. Thus they need
> a way to call the mmu_notifer_unregister (which can not be done
> from inside the the release call back).

No, when the mm is destroyed the .release function is called from
exit_mmap() which calls mmu_notifier_release() right at the beginning.
In this case you don't need to call mmu_notifer_unregister yourself (you
can still call it, but it will be a nop).

> If you look at current code the release callback is use to kill
> secondary translation but not to free associated resources. All
> the associated resources are free later on after the release
> callback (well it depends if the file is close before the process
> is kill).

In exit_mmap the .release function is called when all mappings are still
present. Thats the perfect point in time to unbind all those resources
from your device so that it can not use it anymore when the mappings get
destroyed.

> So this patch aims to provide a callback to code outside of the
> mmu_notifier realms, a place where it is safe to cleanup the
> mmu_notifier and associated resources.

Still, this is a duplication of mmu_notifier release call-back, so still
NACK.


	Joerg

--
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>

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

[Jerome Glisse]

On Mon, Jun 30, 2014 at 08:16:23PM +0200, Joerg Roedel wrote:
> On Mon, Jun 30, 2014 at 12:06:05PM -0400, Jerome Glisse wrote:
> > No this patch does not duplicate it. Current user of mmu_notifier
> > rely on file close code path to call mmu_notifier_unregister. New
> > code like AMD IOMMUv2 or HMM can not rely on that. Thus they need
> > a way to call the mmu_notifer_unregister (which can not be done
> > from inside the the release call back).
> 
> No, when the mm is destroyed the .release function is called from
> exit_mmap() which calls mmu_notifier_release() right at the beginning.
> In this case you don't need to call mmu_notifer_unregister yourself (you
> can still call it, but it will be a nop).
> 

We do intend to tear down all secondary mapping inside the relase
callback but still we can not cleanup all the resources associated
with it.

> > If you look at current code the release callback is use to kill
> > secondary translation but not to free associated resources. All
> > the associated resources are free later on after the release
> > callback (well it depends if the file is close before the process
> > is kill).
> 
> In exit_mmap the .release function is called when all mappings are still
> present. Thats the perfect point in time to unbind all those resources
> from your device so that it can not use it anymore when the mappings get
> destroyed.
> 
> > So this patch aims to provide a callback to code outside of the
> > mmu_notifier realms, a place where it is safe to cleanup the
> > mmu_notifier and associated resources.
> 
> Still, this is a duplication of mmu_notifier release call-back, so still
> NACK.
> 

It is not, mmu_notifier_register take increase mm_count and only
mmu_notifier_unregister decrease the mm_count which is different
from the mm_users count (the latter being the one that trigger an
mmu notifier release).

As said from the release call back you can not call mmu_notifier_unregister
and thus you can not fully cleanup things. Only way to achieve so is
to do it ouside mmu_notifier callback. As pointed out current user do
not have this issue because they rely on file close callback to perform
the cleanup operation. New user will not necessarily have such things
to rely on. Hence factorizing various mm_struct destruction callback
with an callback chain.

If you know any other way to call mmu_notifier_unregister before the
end of mmput function than i am all ear. I am not adding this call
back just for the fun of it i spend serious time trying to find a
way to do thing without it. I might have miss a way so if i did please
show it to me.

Cheers,
Jérôme Glisse

--
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>

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

[Lewycky, Andrew]

> On Mon, Jun 30, 2014 at 08:16:23PM +0200, Joerg Roedel wrote:
> > On Mon, Jun 30, 2014 at 12:06:05PM -0400, Jerome Glisse wrote:
> > > No this patch does not duplicate it. Current user of mmu_notifier
> > > rely on file close code path to call mmu_notifier_unregister. New
> > > code like AMD IOMMUv2 or HMM can not rely on that. Thus they need a
> > > way to call the mmu_notifer_unregister (which can not be done from
> > > inside the the release call back).
> >
> > No, when the mm is destroyed the .release function is called from
> > exit_mmap() which calls mmu_notifier_release() right at the beginning.
> > In this case you don't need to call mmu_notifer_unregister yourself
> > (you can still call it, but it will be a nop).
> >
> 
> We do intend to tear down all secondary mapping inside the relase callback but
> still we can not cleanup all the resources associated with it.
> 
> > > If you look at current code the release callback is use to kill
> > > secondary translation but not to free associated resources. All the
> > > associated resources are free later on after the release callback
> > > (well it depends if the file is close before the process is kill).
> >
> > In exit_mmap the .release function is called when all mappings are
> > still present. Thats the perfect point in time to unbind all those
> > resources from your device so that it can not use it anymore when the
> > mappings get destroyed.
> >
> > > So this patch aims to provide a callback to code outside of the
> > > mmu_notifier realms, a place where it is safe to cleanup the
> > > mmu_notifier and associated resources.
> >
> > Still, this is a duplication of mmu_notifier release call-back, so
> > still NACK.
> >
> 
> It is not, mmu_notifier_register take increase mm_count and only
> mmu_notifier_unregister decrease the mm_count which is different from the
> mm_users count (the latter being the one that trigger an mmu notifier
> release).
> 
> As said from the release call back you can not call mmu_notifier_unregister
> and thus you can not fully cleanup things. Only way to achieve so is to do it
> ouside mmu_notifier callback. As pointed out current user do not have this
> issue because they rely on file close callback to perform the cleanup operation.
> New user will not necessarily have such things to rely on. Hence factorizing
> various mm_struct destruction callback with an callback chain.
> 
> If you know any other way to call mmu_notifier_unregister before the end of
> mmput function than i am all ear. I am not adding this call back just for the fun
> of it i spend serious time trying to find a way to do thing without it. I might have
> miss a way so if i did please show it to me.
> 

Joerg, please consider that the amd_iommu_v2 driver already breaks the rules for what can be done from the release callback. In particular, it frees the pasid_state structure containing the struct mmu_notifier. (mn_release, unbind_pasid, put_pasid_state_wait, free_pasid_state). Since this contains the next pointer for the mmu_notifier list, __mmu_notifier_release will crash. Modifying the MMU notifier list isn't allowed because the notifier code is holding an RCU read lock. In general the problem is that RCU read locks are very constraining and things that you'd like to do from release can't be done. It could be done from the mmput callback, or perhaps mmu_notifier_release could call release from call_srcu instead.

As an aside we found another small issue: amd_iommu_bind_pasid calls get_task_mm. This bumps the mm_struct use count and it will never be released. This would prevent the buggy code path described above from ever running in the first place.

Thanks.
Andrew

--
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>

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

[Joerg Roedel]

Hi Andrew,

On Mon, Jun 30, 2014 at 06:57:48PM +0000, Lewycky, Andrew wrote:
> As an aside we found another small issue: amd_iommu_bind_pasid calls
> get_task_mm. This bumps the mm_struct use count and it will never be
> released. This would prevent the buggy code path described above from
> ever running in the first place.

You are right, the current code is a bit problematic, but to fix this no
new notifier chain in mm-code is needed.

In fact, using get_task_mm() is a good way to keep a reference to the mm
as a user (an external device is in fact another user) and defer the
destruction of the mappings to the file-close path (where you can call
mmput to destroy it). So this is another way to solve the problem
without any new notifier.


	Joerg


--
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>

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

[Joerg Roedel]

On Mon, Jun 30, 2014 at 02:35:57PM -0400, Jerome Glisse wrote:
> We do intend to tear down all secondary mapping inside the relase
> callback but still we can not cleanup all the resources associated
> with it.
>

And why can't you cleanup the other resources in the file close path?
Tearing down the mappings is all you need to do in the release function
anyway.

> As said from the release call back you can not call
> mmu_notifier_unregister and thus you can not fully cleanup things.

You don't need to call mmu_notifier_unregister when the release function
is already running from exit_mmap because this is equivalent to calling
mmu_notifier_unregister.

> Only way to achieve so is to do it ouside mmu_notifier callback.

The resources that can't be handled there can be cleaned up in the
file-close path. No need for a new notifier in mm code.

In the end all you need to do in the release function is to tear down
the secondary mapping and make sure the device can no longer access the
address space when the release function returns. Everything else, like
freeing any resources can be done later when the file descriptors are
teared down.

> If you know any other way to call mmu_notifier_unregister before the
> end of mmput function than i am all ear. I am not adding this call
> back just for the fun of it i spend serious time trying to find a
> way to do thing without it. I might have miss a way so if i did please
> show it to me.

Why do you need to call mmu_notifier_unregister manually when it is done
implicitly in exit_mmap already? 


	Joerg

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

[Gabbay, Oded]

On Tue, 2014-07-01 at 11:15 +0200, Joerg Roedel wrote:
> On Mon, Jun 30, 2014 at 02:35:57PM -0400, Jerome Glisse wrote:
> > We do intend to tear down all secondary mapping inside the relase
> > callback but still we can not cleanup all the resources associated
> > with it.
> >
> 
> And why can't you cleanup the other resources in the file close path?
> Tearing down the mappings is all you need to do in the release function
> anyway.
> 
> > As said from the release call back you can not call
> > mmu_notifier_unregister and thus you can not fully cleanup things.
> 
> You don't need to call mmu_notifier_unregister when the release function
> is already running from exit_mmap because this is equivalent to calling
> mmu_notifier_unregister.
> 
> > Only way to achieve so is to do it ouside mmu_notifier callback.
> 
> The resources that can't be handled there can be cleaned up in the
> file-close path. No need for a new notifier in mm code.
> 
> In the end all you need to do in the release function is to tear down
> the secondary mapping and make sure the device can no longer access the
> address space when the release function returns. Everything else, like
> freeing any resources can be done later when the file descriptors are
> teared down.

I will answer from the KFD perpective, as I'm AMD's maintainer of this
driver.

Little background: AMD's HSA Linux kernel driver (called radeon_kfd or
KFD in short), has been developed for the past year by AMD, to support
running Linux compute applications on AMD's HSA-enabled APUs, i.e Kaveri
(A10-7850K/7700K). The driver will be up for kernel community review in
about 2-3 weeks so we could push it during the 3.17 merge window. Prior
discussions were made with gpu/drm subsystem maintainers about this
driver.

In the KFD, we need to maintain a notion of each compute process.
Therefore, we have an object called "kfd_process" that is created for
each process that uses the KFD. Naturally, we need to be able to track
the process's shutdown in order to perform cleanup of the resources it
uses (compute queues, virtual address space, gpu local memory
allocations, etc.).

To enable this tracking mechanism, we decided to associate the
kfd_process with mm_struct to ensure that a kfd_process object has
exactly the same lifespan as the process it represents. We preferred to
use the mm_struct and not a file description because using a file
descriptor to track “process” shutdown is wrong in two ways:

* Technical: file descriptors can be passed to unrelated processes using
AF_UNIX sockets. This means that a process can exit while the file stays
open. Even if we implement this “correctly” i.e. holding the address
space & page tables alive until the file is finally released, it’s
really dodgy.

* Philosophical: our ioctls are actually system calls in disguise. They
operate on the process, not on a device.

Moreover, because the GPU interacts with the process only through
virtual memory (and not e.g. file descriptors), and because virtual
address space is fundamental to an intuitive notion of what a process
is, the decision to associate the kfd_process with mm_struct seems like
a natural choice.

Then arrived the issue of how the KFD is notified about an mm_struct
destruction. Because the mmu_notifier release callback is called from an
RCU read lock, it can't destory the mmu_notifier object, which is the
kfd_process object itself. Therefore, I talked to Jerome and Andrew
Morton on a way to implement this and after the discussion (which was in
private emails), Jerome was kind enough to write a patch, which is the
patch we are now discussing.

You are more than welcomed to take a look at the entire driver, at
http://cgit.freedesktop.org/~gabbayo/linux/?h=kfd-0.6.x      although
the driver will undergo some changes before sending the pull request to
Dave Airle.

I believe that converting amd_iommu_v2 driver to use this patch as well,
will benefit all parties. AFAIK, KFD is the _only_ client of the
amd_iommu_v2 driver, so it is imperative that we will work together on
this.

	Oded
> > If you know any other way to call mmu_notifier_unregister before the
> > end of mmput function than i am all ear. I am not adding this call
> > back just for the fun of it i spend serious time trying to find a
> > way to do thing without it. I might have miss a way so if i did please
> > show it to me.
> 
> Why do you need to call mmu_notifier_unregister manually when it is done
> implicitly in exit_mmap already? 
> 
> 
> 	Joerg
> 
> 

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

[Joerg Roedel]

On Tue, Jul 01, 2014 at 09:29:49AM +0000, Gabbay, Oded wrote:
> In the KFD, we need to maintain a notion of each compute process.
> Therefore, we have an object called "kfd_process" that is created for
> each process that uses the KFD. Naturally, we need to be able to track
> the process's shutdown in order to perform cleanup of the resources it
> uses (compute queues, virtual address space, gpu local memory
> allocations, etc.).

If it is only that, you can also use the task_exit notifier already in
the kernel.

> To enable this tracking mechanism, we decided to associate the
> kfd_process with mm_struct to ensure that a kfd_process object has
> exactly the same lifespan as the process it represents. We preferred to
> use the mm_struct and not a file description because using a file
> descriptor to track “process” shutdown is wrong in two ways:
> 
> * Technical: file descriptors can be passed to unrelated processes using
> AF_UNIX sockets. This means that a process can exit while the file stays
> open. Even if we implement this “correctly” i.e. holding the address
> space & page tables alive until the file is finally released, it’s
> really dodgy.

No, its not in this case. The file descriptor is used to connect a
process address space with a device context. Thus without the mappings
the file-descriptor is useless and the mappings should stay in-tact
until the fd is closed.

It would be a very bad semantic for userspace if a fd that is passed on
fails on the other side because the sending process died.


	Joerg


_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

[Jerome Glisse]

On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> On Tue, Jul 01, 2014 at 09:29:49AM +0000, Gabbay, Oded wrote:
> > In the KFD, we need to maintain a notion of each compute process.
> > Therefore, we have an object called "kfd_process" that is created for
> > each process that uses the KFD. Naturally, we need to be able to track
> > the process's shutdown in order to perform cleanup of the resources it
> > uses (compute queues, virtual address space, gpu local memory
> > allocations, etc.).
> 
> If it is only that, you can also use the task_exit notifier already in
> the kernel.

No task_exit will happen per thread not once per mm.

> 
> > To enable this tracking mechanism, we decided to associate the
> > kfd_process with mm_struct to ensure that a kfd_process object has
> > exactly the same lifespan as the process it represents. We preferred to
> > use the mm_struct and not a file description because using a file
> > descriptor to track “process” shutdown is wrong in two ways:
> > 
> > * Technical: file descriptors can be passed to unrelated processes using
> > AF_UNIX sockets. This means that a process can exit while the file stays
> > open. Even if we implement this “correctly” i.e. holding the address
> > space & page tables alive until the file is finally released, it’s
> > really dodgy.
> 
> No, its not in this case. The file descriptor is used to connect a
> process address space with a device context. Thus without the mappings
> the file-descriptor is useless and the mappings should stay in-tact
> until the fd is closed.
> 
> It would be a very bad semantic for userspace if a fd that is passed on
> fails on the other side because the sending process died.
> 

Consider use case where there is no file associated with the mmu_notifier
ie there is no device file descriptor that could hold and take care of
mmu_notifier destruction and cleanup. We need this call chain for this
case.

Anyother idea than task_exit ?

Cheers,
Jérôme

--
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>

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

[Joerg Roedel]

On Tue, Jul 01, 2014 at 03:33:44PM -0400, Jerome Glisse wrote:
> On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> > No, its not in this case. The file descriptor is used to connect a
> > process address space with a device context. Thus without the mappings
> > the file-descriptor is useless and the mappings should stay in-tact
> > until the fd is closed.
> > 
> > It would be a very bad semantic for userspace if a fd that is passed on
> > fails on the other side because the sending process died.
> 
> Consider use case where there is no file associated with the mmu_notifier
> ie there is no device file descriptor that could hold and take care of
> mmu_notifier destruction and cleanup. We need this call chain for this
> case.

Example of such a use-case where no fd will be associated?

Anyway, even without an fd, there will always be something that sets the
mm->device binding up (calling mmu_notifier_register) and tears it down
in the end (calling mmu_notifier_unregister). And this will be the
places where any resources left from the .release call-back can be
cleaned up.


	Joerg

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

[Jerome Glisse]

On Tue, Jul 01, 2014 at 11:06:20PM +0200, Joerg Roedel wrote:
> On Tue, Jul 01, 2014 at 03:33:44PM -0400, Jerome Glisse wrote:
> > On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> > > No, its not in this case. The file descriptor is used to connect a
> > > process address space with a device context. Thus without the mappings
> > > the file-descriptor is useless and the mappings should stay in-tact
> > > until the fd is closed.
> > > 
> > > It would be a very bad semantic for userspace if a fd that is passed on
> > > fails on the other side because the sending process died.
> > 
> > Consider use case where there is no file associated with the mmu_notifier
> > ie there is no device file descriptor that could hold and take care of
> > mmu_notifier destruction and cleanup. We need this call chain for this
> > case.
> 
> Example of such a use-case where no fd will be associated?
> 
> Anyway, even without an fd, there will always be something that sets the
> mm->device binding up (calling mmu_notifier_register) and tears it down
> in the end (calling mmu_notifier_unregister). And this will be the
> places where any resources left from the .release call-back can be
> cleaned up.
> 

That's the whole point we can not do what we want without the callback ie
the place where we do the cleanup is the mm callback we need. If you do not
like the call chain than we will just add ourself as another caller in the
exact same spot where the notifier chain is which Andrew disliked because
there are already enough submodule that are interested in being inform of
mm destruction.

Cheers,
Jérôme

--
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>

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

[Jerome Glisse]

On Tue, Jul 01, 2014 at 05:32:09PM -0400, Jerome Glisse wrote:
> On Tue, Jul 01, 2014 at 11:06:20PM +0200, Joerg Roedel wrote:
> > On Tue, Jul 01, 2014 at 03:33:44PM -0400, Jerome Glisse wrote:
> > > On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> > > > No, its not in this case. The file descriptor is used to connect a
> > > > process address space with a device context. Thus without the mappings
> > > > the file-descriptor is useless and the mappings should stay in-tact
> > > > until the fd is closed.
> > > > 
> > > > It would be a very bad semantic for userspace if a fd that is passed on
> > > > fails on the other side because the sending process died.
> > > 
> > > Consider use case where there is no file associated with the mmu_notifier
> > > ie there is no device file descriptor that could hold and take care of
> > > mmu_notifier destruction and cleanup. We need this call chain for this
> > > case.
> > 
> > Example of such a use-case where no fd will be associated?
> > 
> > Anyway, even without an fd, there will always be something that sets the
> > mm->device binding up (calling mmu_notifier_register) and tears it down
> > in the end (calling mmu_notifier_unregister). And this will be the
> > places where any resources left from the .release call-back can be
> > cleaned up.
> > 
> 
> That's the whole point we can not do what we want without the callback ie
> the place where we do the cleanup is the mm callback we need. If you do not
> like the call chain than we will just add ourself as another caller in the
> exact same spot where the notifier chain is which Andrew disliked because
> there are already enough submodule that are interested in being inform of
> mm destruction.
> 
> Cheers,
> Jérôme

Joerg do you still object to this patch ? Knowing that we need to bind the
lifetime of our object with the mm_struct. While the release callback of
mmu_notifier allow us to stop any further processing in timely manner with
mm destruction, we can not however free some of the associated resources
namely the structure containing the mmu_notifier struct. We could schedule
a delayed job to do it sometimes after we get the release callback but that
would be hackish.

Again the natural place to call this is from mmput and the fact that many
other subsystem already call in from there to cleanup there own per mm data
structure is a testimony that this is a valid use case and valid design.

This patch realy just try to allow new user to easily interface themself
at proper place in mm lifetime. It is just as the task exit notifier chain
but i deals with the mm_struct.

You pointed out that the cleanup should be done from the device driver file
close call. But as i stressed some of the new user will not necessarily have
a device file open hence no way for them to free the associated structure
except with hackish delayed job.

So i do not see any reasons to block this patch.

Cheers,
Jérôme

--
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>

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

[Joerg Roedel]

Hi Jerome,

On Thu, Jul 03, 2014 at 02:30:26PM -0400, Jerome Glisse wrote:
> Joerg do you still object to this patch ?

Yes.

> Again the natural place to call this is from mmput and the fact that many
> other subsystem already call in from there to cleanup there own per mm data
> structure is a testimony that this is a valid use case and valid design.

Device drivers are something different than subsystems. I think the
point that the mmu_notifier struct can not be freed in the .release
call-back is a weak reason for introducing a new notifier. In the end
every user of mmu_notifiers has to call mmu_notifier_register somewhere
(file-open/ioctl path or somewhere else where the mm<->device binding is
 set up) and can call mmu_notifier_unregister in a similar path which
destroys the binding.

> You pointed out that the cleanup should be done from the device driver file
> close call. But as i stressed some of the new user will not necessarily have
> a device file open hence no way for them to free the associated structure
> except with hackish delayed job.

Please tell me more about these 'new users', how does mm<->device binding
is set up there if no fd is used?


	Joerg

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

[Jerome Glisse]

On Fri, Jul 04, 2014 at 01:15:41AM +0200, Joerg Roedel wrote:
> Hi Jerome,
> 
> On Thu, Jul 03, 2014 at 02:30:26PM -0400, Jerome Glisse wrote:
> > Joerg do you still object to this patch ?
> 
> Yes.
> 
> > Again the natural place to call this is from mmput and the fact that many
> > other subsystem already call in from there to cleanup there own per mm data
> > structure is a testimony that this is a valid use case and valid design.
> 
> Device drivers are something different than subsystems. I think the
> point that the mmu_notifier struct can not be freed in the .release
> call-back is a weak reason for introducing a new notifier. In the end
> every user of mmu_notifiers has to call mmu_notifier_register somewhere
> (file-open/ioctl path or somewhere else where the mm<->device binding is
>  set up) and can call mmu_notifier_unregister in a similar path which
> destroys the binding.
> 
> > You pointed out that the cleanup should be done from the device driver file
> > close call. But as i stressed some of the new user will not necessarily have
> > a device file open hence no way for them to free the associated structure
> > except with hackish delayed job.
> 
> Please tell me more about these 'new users', how does mm<->device binding
> is set up there if no fd is used?

It could be setup on behalf of another process through others means like
local socket. Thought main use case i am thinking about is you open device
fd you setup your gpu queue and then you close the fd but you keep using
the gpu and the gpu keep accessing the address space.

Further done the lane we might even see gpu code as directly executable
thought that seems yet unreleasistic at this time.

Anyway whole point is that no matter how you turn the matter anything that
mirror a process address is linked to the lifetime of the mm_struct so in
order to have some logic there it is far best to have destruction match
the destruction of mm. This also make things like fork lot cleaner, as on
work the device file descriptor is duplicated inside the child process
but nothing setup child process to keep using the gpu. Thus you might
end up with way delayed file closure compare to parent process mm
destruction.

Cheers,
Jérôme


--
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>

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

[Gabbay, Oded]

On Fri, 2014-07-04 at 01:15 +0200, Joerg Roedel wrote:
> Hi Jerome,
> 
> On Thu, Jul 03, 2014 at 02:30:26PM -0400, Jerome Glisse wrote:
> > Joerg do you still object to this patch ?
> 
> Yes.
> 
> > Again the natural place to call this is from mmput and the fact that many
> > other subsystem already call in from there to cleanup there own per mm data
> > structure is a testimony that this is a valid use case and valid design.
> 
> Device drivers are something different than subsystems. 
I think that hsa (kfd) and hmm _are_ subsystems, if not in definition
than in practice. Our model is not a classic device-driver model in the
sense that our ioctl's are more like syscalls than traditional
device-driver ioctls. e.g our kfd_open() doesn't open a kfd device or
even a gpu device, it *binds* a *process* to a device. So basically, our
ioctls are not related to a specific H/W instance (specific GPU in case
of kfd) but more related to a specific process.

Once we can agree on that, than I think we can agree that kfd and hmm
can and should be bounded to mm struct and not file descriptors.

	Oded

> I think the
> point that the mmu_notifier struct can not be freed in the .release
> call-back is a weak reason for introducing a new notifier. In the end
> every user of mmu_notifiers has to call mmu_notifier_register somewhere
> (file-open/ioctl path or somewhere else where the mm<->device binding is
>  set up) and can call mmu_notifier_unregister in a similar path which
> destroys the binding.
> 
> > You pointed out that the cleanup should be done from the device driver file
> > close call. But as i stressed some of the new user will not necessarily have
> > a device file open hence no way for them to free the associated structure
> > except with hackish delayed job.
> 
> Please tell me more about these 'new users', how does mm<->device binding
> is set up there if no fd is used?
> 
> 
> 	Joerg
> 
> 

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

[joro]

On Sun, Jul 06, 2014 at 07:25:18PM +0000, Gabbay, Oded wrote:
> Once we can agree on that, than I think we can agree that kfd and hmm
> can and should be bounded to mm struct and not file descriptors.

The file descriptor concept is the way it works in the rest of the
kernel. It works for numerous drivers and subsystems (KVM, VFIO, UIO,
...), when you close a file descriptor handed out from any of those
drivers (already in the kernel) all related resources will be freed. I
don't see a reason why HSA drivers should break these expectations and
be different.


	Joerg


--
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>

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

[Oded Gabbay]

On Mon, 2014-07-07 at 12:11 +0200, joro@8bytes.org wrote:
> On Sun, Jul 06, 2014 at 07:25:18PM +0000, Gabbay, Oded wrote:
> > Once we can agree on that, than I think we can agree that kfd and hmm
> > can and should be bounded to mm struct and not file descriptors.
> 
> The file descriptor concept is the way it works in the rest of the
> kernel. It works for numerous drivers and subsystems (KVM, VFIO, UIO,
> ...), when you close a file descriptor handed out from any of those
> drivers (already in the kernel) all related resources will be freed. I
> don't see a reason why HSA drivers should break these expectations and
> be different.
> 
> 
> 	Joerg
> 
> 
As Jerome pointed out, there are a couple of subsystems/drivers who
don't rely on file descriptors but on the tear-down of mm struct, e.g.
aio, ksm, uprobes, khugepaged

So, based on this fact, I don't think that the argument of "The file
descriptor concept is the way it works in the rest of the kernel" and
only HSA/HMM now wants to change the rules, is a valid argument.

Jerome and I are saying that HMM and HSA, respectively, are additional
use cases of binding to mm struct. If you don't agree with that, than I
would like to hear why, but you can't say that no one else in the kernel
needs notification of mm struct tear-down.

As for the reasons why HSA drivers should follow aio,ksm,etc. and not
other drivers, I will repeat that our ioctls operate on a process
context and not on a device context. Moreover, the calling process
actually is sometimes not aware on which device it runs! 

A prime example of why HSA is not a regular device-driver, and operates
in context of a process and not a specific device is the fact that in
the near future (3-4 months), kfd_open() will actually bind a process
address space to a *set* of devices, each of which could have its *own*
device driver (eg radeon for the CI device, other amd drivers for future
devices). I Assume HMM can be considered in the same way. 

	Oded



--
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>

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

[Oded Gabbay]

On Mon, 2014-07-07 at 12:11 +0200, joro@8bytes.org wrote:
> On Sun, Jul 06, 2014 at 07:25:18PM +0000, Gabbay, Oded wrote:
> > Once we can agree on that, than I think we can agree that kfd and hmm
> > can and should be bounded to mm struct and not file descriptors.
> 
> The file descriptor concept is the way it works in the rest of the
> kernel. It works for numerous drivers and subsystems (KVM, VFIO, UIO,
> ...), when you close a file descriptor handed out from any of those
> drivers (already in the kernel) all related resources will be freed. I
> don't see a reason why HSA drivers should break these expectations and
> be different.
> 
> 
> 	Joerg
> 
> 
As Jerome pointed out, there are a couple of subsystems/drivers who
don't rely on file descriptors but on the tear-down of mm struct, e.g.
aio, ksm, uprobes, khugepaged

So, based on this fact, I don't think that the argument of "The file
descriptor concept is the way it works in the rest of the kernel" and
only HSA/HMM now wants to change the rules, is a valid argument.

Jerome and I are saying that HMM and HSA, respectively, are additional
use cases of binding to mm struct. If you don't agree with that, than I
would like to hear why, but you can't say that no one else in the kernel
needs notification of mm struct tear-down.

As for the reasons why HSA drivers should follow aio,ksm,etc. and not
other drivers, I will repeat that our ioctls operate on a process
context and not on a device context. Moreover, the calling process
actually is sometimes not aware on which device it runs! 

A prime example of why HSA is not a regular device-driver, and operates
in context of a process and not a specific device is the fact that in
the near future (3-4 months), kfd_open() will actually bind a process
address space to a *set* of devices, each of which could have its *own*
device driver (eg radeon for the CI device, other amd drivers for future
devices). I Assume HMM can be considered in the same way. 

	Oded




--
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>

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

[joro-zLv9SwRftAIdnm+yROfE0A]

On Mon, Jul 07, 2014 at 01:43:03PM +0300, Oded Gabbay wrote:
> As Jerome pointed out, there are a couple of subsystems/drivers who
> don't rely on file descriptors but on the tear-down of mm struct, e.g.
> aio, ksm, uprobes, khugepaged

What you name here is completly different from what HSA offers. AIO,
KSM, uProbes and THP are not drivers or subsystems of their own but
extend existing subsystems. KSM and THP also work in the background and
do not need a fd to setup things (in some cases only new flags to
existing system calls).

What HSA does is offering a new service to userspace applications.  This
either requires new system calls or, as currently implemented, a device
file which can be opened to use the services.  In this regard it is much
more similar to VFIO or KVM, which also offers a new service and which
use file descriptors as their interface to userspace and tear everything
down when the fd is closed.

> Jerome and I are saying that HMM and HSA, respectively, are additional
> use cases of binding to mm struct. If you don't agree with that, than I
> would like to hear why, but you can't say that no one else in the kernel
> needs notification of mm struct tear-down.

In the first place HSA is a service that allows applications to send
compute jobs to peripheral devices (usually GPUs) and read back the
results. That the peripheral device can access the process address space
is a feature of that service that is handled in the driver.

> As for the reasons why HSA drivers should follow aio,ksm,etc. and not
> other drivers, I will repeat that our ioctls operate on a process
> context and not on a device context. Moreover, the calling process
> actually is sometimes not aware on which device it runs!

KFD can very well hide the fact that there are multiple devices as the
IOMMU drivers usually also hide the details about how many IOMMUs are in
the system.


	Joerg

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

[Jerome Glisse]

On Tue, Jul 08, 2014 at 10:00:59AM +0200, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org wrote:
> On Mon, Jul 07, 2014 at 01:43:03PM +0300, Oded Gabbay wrote:
> > As Jerome pointed out, there are a couple of subsystems/drivers who
> > don't rely on file descriptors but on the tear-down of mm struct, e.g.
> > aio, ksm, uprobes, khugepaged
> 
> What you name here is completly different from what HSA offers. AIO,
> KSM, uProbes and THP are not drivers or subsystems of their own but
> extend existing subsystems. KSM and THP also work in the background and
> do not need a fd to setup things (in some cases only new flags to
> existing system calls).
> 
> What HSA does is offering a new service to userspace applications.  This
> either requires new system calls or, as currently implemented, a device
> file which can be opened to use the services.  In this regard it is much
> more similar to VFIO or KVM, which also offers a new service and which
> use file descriptors as their interface to userspace and tear everything
> down when the fd is closed.

Thing is we are closer to AIO than to KVM. Unlike kvm, hmm stores a pointer
to its structure inside mm_struct and those we already add ourself to the
mm_init function ie we do have the same lifespan as the mm_struct not the
same lifespan as a file.

Now regarding the device side, if we were to cleanup inside the file release
callback than we would be broken in front of fork. Imagine the following :
  - process A open device file and mirror its address space (hmm or kfd)
    through a device file.
  - process A forks itself (child is B) while having the device file open.
  - process A quits

Now the file release will not be call until child B exit which might infinite.
Thus we would be leaking memory. As we already pointed out we can not free the
resources from the mmu_notifier >release callback.

One hacky way to do it would be to schedule some delayed job from >release
callback but then again we would have no way to properly synchronize ourself
with other mm destruction code ie the delayed job could run concurently with
other mm destruction code and interfer badly.

So as i am desperatly trying to show you, there is no other clean way to free
resources associated with hmm and same apply to kfd. Only way is by adding a
callback inside mmput.


Another thing you must understand, the kfd or hmm can be share among different
devices each of them having their own device file. So one and one hmm per mm
struct but several device using that hmm structure. Obviously the lifetime of
this hmm structure has first tie to mm struct, all ties to device file are
secondary and i can foresee situation where their would be absolutely no device
file open but still an hmm for mm struct (think another process is using the
process address through a device driver because it provide some api for that).


I genuinely fails to see how to do it properly using file device as i said
the file lifespan is not tie to an mm struct while the struct we want to
cleanup are tie to the mm struct.

Again hmm or kfd is like aio. Not like kvm.

Cheers,
Jérôme

> 
> > Jerome and I are saying that HMM and HSA, respectively, are additional
> > use cases of binding to mm struct. If you don't agree with that, than I
> > would like to hear why, but you can't say that no one else in the kernel
> > needs notification of mm struct tear-down.
> 
> In the first place HSA is a service that allows applications to send
> compute jobs to peripheral devices (usually GPUs) and read back the
> results. That the peripheral device can access the process address space
> is a feature of that service that is handled in the driver.
> 
> > As for the reasons why HSA drivers should follow aio,ksm,etc. and not
> > other drivers, I will repeat that our ioctls operate on a process
> > context and not on a device context. Moreover, the calling process
> > actually is sometimes not aware on which device it runs!
> 
> KFD can very well hide the fact that there are multiple devices as the
> IOMMU drivers usually also hide the details about how many IOMMUs are in
> the system.
> 
> 
> 	Joerg
> 
> 

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]

On Tue, 2014-07-08 at 13:03 -0400, Jerome Glisse wrote:
> 
> Now regarding the device side, if we were to cleanup inside the file release
> callback than we would be broken in front of fork. Imagine the following :
>   - process A open device file and mirror its address space (hmm or kfd)
>     through a device file.
>   - process A forks itself (child is B) while having the device file open.
>   - process A quits
> 
> Now the file release will not be call until child B exit which might infinite.
> Thus we would be leaking memory. As we already pointed out we can not free the
> resources from the mmu_notifier >release callback.

So if your library just registers a pthread_atfork() handler to close
the file descriptor in the child, that problem goes away? Like any
other "if we continue to hold file descriptors open when we should
close them, resources don't get freed" problem?

Perhaps we could even handled that automatically in the kernel, with
something like an O_CLOFORK flag on the file descriptor. Although
that's a little horrid.

You've argued that the amdkfd code is special and not just a device
driver. I'm not going to contradict you there, but now we *are* going
to see device drivers doing this kind of thing. And we definitely
*don't* want to be calling back into device driver code from the
mmu_notifier's .release() function.

I think amdkfd absolutely is *not* a useful precedent for normal device
drivers, and we *don't* want to follow this model in the general case.

As we try to put together a generic API for device access to processes'
address space, I definitely think we want to stick with the model that
we take a reference on the mm, and we *keep* it until the device driver
unbinds from the mm (because its file descriptor is closed, or
whatever).

Perhaps you can keep a back door into the AMD IOMMU code to continue to
do what you're doing, or perhaps the explicit management of off-cpu
tasks that is being posited will give you a sane cleanup path that
*doesn't* involve the IOMMU's mmu_notifier calling back to you. But
either way, I *really* don't want this to be the way it works for
device drivers.


> One hacky way to do it would be to schedule some delayed job from 
> >release callback but then again we would have no way to properly 
> synchronize ourself with other mm destruction code ie the delayed job 
> could run concurently with other mm destruction code and interfer
> badly.

With the RCU-based free of the struct containing the notifier, your
'schedule some delayed job' is basically what we have now, isn't it?

I note that you also have your *own* notifier which does other things,
and has to cope with being called before or after the IOMMU's notifier.

Seriously, we don't want device drivers having to do this. We really
need to keep it simple.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Jerome Glisse]

Note that i am no longer actively pushing this patch serie but i believe the
solution it provides to be needed in one form or another. So I still think
discussion on this to be useful so see below for my answer.

On Sun, Oct 11, 2015 at 08:03:29PM +0100, David Woodhouse wrote:
> On Tue, 2014-07-08 at 13:03 -0400, Jerome Glisse wrote:
> > 
> > Now regarding the device side, if we were to cleanup inside the file release
> > callback than we would be broken in front of fork. Imagine the following :
> >   - process A open device file and mirror its address space (hmm or kfd)
> >     through a device file.
> >   - process A forks itself (child is B) while having the device file open.
> >   - process A quits
> > 
> > Now the file release will not be call until child B exit which might infinite.
> > Thus we would be leaking memory. As we already pointed out we can not free the
> > resources from the mmu_notifier >release callback.
> 
> So if your library just registers a pthread_atfork() handler to close
> the file descriptor in the child, that problem goes away? Like any
> other "if we continue to hold file descriptors open when we should
> close them, resources don't get freed" problem?


I was just pointing out existing device driver usage pattern where user
space open device file and do ioctl on it without necessarily caring
about the mm struct.

New usecase where device actually run thread against a specific process
mm is different and require proper synchronization as file lifetime is
different from process lifetime in many case when fork is involve.

> 
> Perhaps we could even handled that automatically in the kernel, with
> something like an O_CLOFORK flag on the file descriptor. Although
> that's a little horrid.
> 
> You've argued that the amdkfd code is special and not just a device
> driver. I'm not going to contradict you there, but now we *are* going
> to see device drivers doing this kind of thing. And we definitely
> *don't* want to be calling back into device driver code from the
> mmu_notifier's .release() function.

Well that's the current solution, call back into device driver from the
mmu_notifer release() call back. Since changes to mmu_notifier this is
a workable solution (thanks to mmu_notifier_unregister_no_release()).

> 
> I think amdkfd absolutely is *not* a useful precedent for normal device
> drivers, and we *don't* want to follow this model in the general case.
> 
> As we try to put together a generic API for device access to processes'
> address space, I definitely think we want to stick with the model that
> we take a reference on the mm, and we *keep* it until the device driver
> unbinds from the mm (because its file descriptor is closed, or
> whatever).

Well i think when a process is kill (for whatever reasons) we do want to
also kill all device threads at the same time. For instance we do not want
to have zombie GPU threads that can keep running indefinitly. This is why
use mmu_notifier.release() callback is kind of right place as it will be
call once all threads using a given mm are killed.

The exit_mm() or do_exit() are also places from where we could a callback
to let device know that it must kill all thread related to a given mm.

>
> Perhaps you can keep a back door into the AMD IOMMU code to continue to
> do what you're doing, or perhaps the explicit management of off-cpu
> tasks that is being posited will give you a sane cleanup path that
> *doesn't* involve the IOMMU's mmu_notifier calling back to you. But
> either way, I *really* don't want this to be the way it works for
> device drivers.

So at kernel summit we are supposedly gonna have a discussion about device
thread and scheduling and i think device thread lifetime belongs to that
discussion too. My opinion is that device threads must be kill when a
process quits.


> > One hacky way to do it would be to schedule some delayed job from 
> > >release callback but then again we would have no way to properly 
> > synchronize ourself with other mm destruction code ie the delayed job 
> > could run concurently with other mm destruction code and interfer
> > badly.
> 
> With the RCU-based free of the struct containing the notifier, your
> 'schedule some delayed job' is basically what we have now, isn't it?
> 
> I note that you also have your *own* notifier which does other things,
> and has to cope with being called before or after the IOMMU's notifier.
> 
> Seriously, we don't want device drivers having to do this. We really
> need to keep it simple.

So right now in HMM what happens is that device driver get a callback as
a result of mmu_notifier.release() and can call the unregister functions
and device driver must then schedule through whatever means a call to the
unregister function (can be a workqueue or other a kernel thread).

Basicly i am hidding the issue inside the device driver until we can agree
on a common proper way to do this.

Cheers,
Jérôme

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

On Sun, 2015-10-11 at 20:03 +0100, David Woodhouse wrote:
> As we try to put together a generic API for device access to processes'
> address space, I definitely think we want to stick with the model that
> we take a reference on the mm, and we *keep* it until the device driver
> unbinds from the mm (because its file descriptor is closed, or
> whatever).

I've found another problem with this.

In use some cases, we mmap() the device file descriptor which is
responsible for the PASID binding. And in that case we end up with a
recursive refcount.

When the process exits, its file descriptors are closed... but the
underlying struct file remains open because it's still referenced from
the mmap'd VMA.

That VMA remains alive because it's still part of the MM.

And the MM remains alive because the PASID binding still holds a
refcount for it because device's struct file didn't get closed yet...
because it's still mmap'd... because the MM is still alive...

So I suspect that even for the relatively simple case where the
lifetime of the PASID can be bound to a file descriptor (unlike with
amdkfd), we probably still want to explicitly manage its lifetime as an
'off-cpu task' and explicitly kill it when the process dies.

I'm still not keen on doing that implicitly through the mm_release. I
think that way lies a lot of subtle bugs.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]