From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
arnd@arndb.de, "Yu, Fenghua" <fenghua.yu@intel.com>,
gregkh@linuxfoundation.org, iommu@lists.linux-foundation.org,
zhangfei.gao@linaro.org, linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH 0/2] iommu: Remove iommu_sva_ops::mm_exit()
Date: Thu, 9 Apr 2020 09:21:34 -0700 [thread overview]
Message-ID: <20200409092134.0c427b95@jacob-builder> (raw)
In-Reply-To: <20200409142519.GH11886@ziepe.ca>
On Thu, 9 Apr 2020 11:25:19 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Thu, Apr 09, 2020 at 07:14:24AM -0700, Jacob Pan wrote:
> > > When the process is killed, mm release can happen before fds are
> > > released. If you look at do_exit() in kernel/exit.c:
> > >
> > > exit_mm()
> > > mmput()
> > > -> mmu release notifier
> > > ...
> > > exit_files()
> > > close_files()
> > > fput()
> > > exit_task_work()
> > > __fput()
> > > -> unbind()
> > >
> > So unbind is coming anyway, the difference in handling in mmu
> > release notifier is whether we silently drop DMA fault vs.
> > reporting fault?
>
> Userspace can significantly delay the final fput triggering the
> unbind, the above is only for the trivial case where the process
> owning the mm_struct is the only process holding the fd.
>
Are you talking about FDs owned buy children after fork() or FDs sent
over to another process. I think, in either case SVA is not supported.
> The destruction of a mm_struct should be treated the same as unmapping
> every vma in the process. The observable effect should be no different
> than munmap.
>
Good point. I agree, we should suppress the error in the window before
unbind.
> Jason
[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-04-09 16:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 14:04 [PATCH 0/2] iommu: Remove iommu_sva_ops::mm_exit() Jean-Philippe Brucker
2020-04-08 14:04 ` [PATCH 1/2] uacce: Remove mm_exit() op Jean-Philippe Brucker
2020-04-09 9:07 ` Zhangfei Gao
2020-04-09 9:44 ` Jean-Philippe Brucker
2020-04-08 14:04 ` [PATCH 2/2] iommu: Remove iommu_sva_ops::mm_exit() Jean-Philippe Brucker
2020-04-08 18:35 ` [PATCH 0/2] " Jacob Pan
2020-04-08 19:02 ` Jason Gunthorpe
2020-04-08 21:35 ` Jacob Pan
2020-04-08 22:32 ` Jason Gunthorpe
2020-04-08 23:48 ` Jacob Pan
2020-04-09 6:39 ` Jean-Philippe Brucker
2020-04-09 14:14 ` Jacob Pan
2020-04-09 14:25 ` Jason Gunthorpe
2020-04-09 16:21 ` Jacob Pan [this message]
2020-04-09 16:58 ` Jason Gunthorpe
2020-04-09 14:50 ` Jean-Philippe Brucker
2020-04-09 16:27 ` Jacob Pan
2020-04-10 15:52 ` Jacob Pan
2020-04-15 7:47 ` Jean-Philippe Brucker
2020-04-16 20:58 ` Jacob Pan
2020-04-20 8:02 ` Jean-Philippe Brucker
2020-04-09 12:08 ` Jason Gunthorpe
2020-04-09 16:31 ` Jacob Pan
2020-04-08 23:49 ` Fenghua Yu
2020-04-09 12:12 ` Jason Gunthorpe
2020-04-08 19:04 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200409092134.0c427b95@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=arnd@arndb.de \
--cc=fenghua.yu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=jgg@ziepe.ca \
--cc=linux-accelerators@lists.ozlabs.org \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.