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
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,
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)
>
On Tue, Jul 08, 2014 at 10:00:59AM +0200, j...@8bytes.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,
On Sun, Jul 06, 2014 at 07:25:18PM +, 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
On Mon, 2014-07-07 at 12:11 +0200, j...@8bytes.org wrote:
On Sun, Jul 06, 2014 at 07:25:18PM +, 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
On Mon, 2014-07-07 at 12:11 +0200, j...@8bytes.org wrote:
On Sun, Jul 06, 2014 at 07:25:18PM +, 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
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
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
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
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
Hi Andrew,
On Mon, Jun 30, 2014 at 06:57:48PM +, 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
On Tue, Jul 01, 2014 at 09:29:49AM +, 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
On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
On Tue, Jul 01, 2014 at 09:29:49AM +, 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.
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
On Mon, Jun 30, 2014 at 02:41:24PM +, 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
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
17 matches
Mail list logo
