All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Jerome Glisse <j.glisse@gmail.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"Tang, CQ" <cq.tang@intel.com>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"aarcange@redhat.com" <aarcange@redhat.com>,
	"jakumar@nvidia.com" <jakumar@nvidia.com>,
	"ldunning@nvidia.com" <ldunning@nvidia.com>,
	"mgorman@suse.de" <mgorman@suse.de>,
	"jweiner@redhat.com" <jweiner@redhat.com>,
	"sgutti@nvidia.com" <sgutti@nvidia.com>,
	"riel@redhat.com" <riel@redhat.com>,
	"Bridgman, John" <John.Bridgman@amd.com>,
	"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
	"mhairgrove@nvidia.com" <mhairgrove@nvidia.com>,
	"cabuschardt@nvidia.com" <cabuschardt@nvidia.com>,
	"dpoole@nvidia.com" <dpoole@nvidia.com>,
	"Cornwall, Jay" <Jay.Cornwall@amd.com>,
	"Lewycky, Andrew" <Andrew.Lewycky@amd.com>,
	"SCheung@nvidia.com" <SCheung@nvidia.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"arvindg@nvidia.com" <arvindg@nvidia.com>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.
Date: Fri, 20 Nov 2015 15:45:29 +0000	[thread overview]
Message-ID: <1448034329.89124.26.camel@infradead.org> (raw)
In-Reply-To: <1444590209.92154.116.camel@infradead.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: David Woodhouse <dwmw2@infradead.org>
To: Jerome Glisse <j.glisse@gmail.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"Tang, CQ" <cq.tang@intel.com>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"aarcange@redhat.com" <aarcange@redhat.com>,
	"jakumar@nvidia.com" <jakumar@nvidia.com>,
	"ldunning@nvidia.com" <ldunning@nvidia.com>,
	"mgorman@suse.de" <mgorman@suse.de>,
	"jweiner@redhat.com" <jweiner@redhat.com>,
	"sgutti@nvidia.com" <sgutti@nvidia.com>,
	"riel@redhat.com" <riel@redhat.com>,
	"Bridgman, John" <John.Bridgman@amd.com>,
	"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
	"mhairgrove@nvidia.com" <mhairgrove@nvidia.com>,
	"cabuschardt@nvidia.com" <cabuschardt@nvidia.com>,
	"dpoole@nvidia.com" <dpoole@nvidia.com>,
	"Cornwall, Jay" <Jay.Cornwall@amd.com>,
	"Lewycky, Andrew" <Andrew.Lewycky@amd.com>,
	"SCheung@nvidia.com" <SCheung@nvidia.com>,
	"iommu@lists.linux-foundation.org" <iommu@lis>
Subject: Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.
Date: Fri, 20 Nov 2015 15:45:29 +0000	[thread overview]
Message-ID: <1448034329.89124.26.camel@infradead.org> (raw)
In-Reply-To: <1444590209.92154.116.camel@infradead.org>

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

  parent reply	other threads:[~2015-11-20 15:45 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-28  2:00 mm preparatory patches for HMM and IOMMUv2 Jérôme Glisse
2014-06-28  2:00 ` Jérôme Glisse
2014-06-28  2:00 ` [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:49   ` John Hubbard
2014-06-30  3:49     ` John Hubbard
2014-06-30 15:07     ` Jerome Glisse
2014-06-30 15:07       ` Jerome Glisse
2014-06-30 14:41   ` Gabbay, Oded
2014-06-30 14:41     ` Gabbay, Oded
2014-06-30 15:06     ` Jerome Glisse
2014-06-30 15:06       ` Jerome Glisse
     [not found]     ` <019CCE693E457142B37B791721487FD91806B836-0nO7ALo/ziwxlywnonMhLEEOCMrvLtNR@public.gmane.org>
2014-06-30 15:40       ` Joerg Roedel
2014-06-30 16:06         ` Jerome Glisse
2014-06-30 16:06           ` Jerome Glisse
2014-06-30 18:16           ` Joerg Roedel
2014-06-30 18:16             ` Joerg Roedel
2014-06-30 18:35             ` Jerome Glisse
2014-06-30 18:35               ` Jerome Glisse
2014-06-30 18:57               ` Lewycky, Andrew
2014-06-30 18:57                 ` Lewycky, Andrew
2014-07-01  9:41                 ` Joerg Roedel
2014-07-01  9:41                   ` Joerg Roedel
     [not found]               ` <20140630183556.GB3280-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-01  9:15                 ` Joerg Roedel
2014-07-01  9:29                   ` Gabbay, Oded
2014-07-01  9:29                     ` Gabbay, Oded
     [not found]                     ` <019CCE693E457142B37B791721487FD91806DD8B-0nO7ALo/ziwxlywnonMhLEEOCMrvLtNR@public.gmane.org>
2014-07-01 11:00                       ` Joerg Roedel
2014-07-01 19:33                         ` Jerome Glisse
2014-07-01 19:33                           ` Jerome Glisse
     [not found]                           ` <20140701193343.GB3322-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-01 21:06                             ` Joerg Roedel
2014-07-01 21:32                               ` Jerome Glisse
2014-07-01 21:32                                 ` Jerome Glisse
2014-07-03 18:30                                 ` Jerome Glisse
2014-07-03 18:30                                   ` Jerome Glisse
     [not found]                                   ` <20140703183024.GA3306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-03 23:15                                     ` Joerg Roedel
2014-07-04  0:03                                       ` Jerome Glisse
2014-07-04  0:03                                         ` Jerome Glisse
2014-07-06 19:25                                       ` Gabbay, Oded
2014-07-06 19:25                                         ` Gabbay, Oded
2014-07-07 10:11                                         ` joro
2014-07-07 10:11                                           ` joro
2014-07-07 10:36                                           ` Oded Gabbay
2014-07-07 10:36                                             ` Oded Gabbay
2014-07-07 10:43                                           ` Oded Gabbay
2014-07-07 10:43                                             ` Oded Gabbay
     [not found]                                             ` <1404729783.31606.1.camel-OrheeFI7RUaGvNAqNQFwiPZ4XP/Yx64J@public.gmane.org>
2014-07-08  8:00                                               ` joro-zLv9SwRftAIdnm+yROfE0A
2014-07-08 17:03                                                 ` Jerome Glisse
2014-07-08 17:03                                                   ` Jerome Glisse
2015-10-11 19:03                                                   ` David Woodhouse
2015-10-11 19:03                                                     ` David Woodhouse
2015-10-12 17:41                                                     ` Jerome Glisse
2015-10-12 17:41                                                       ` Jerome Glisse
2015-10-12 17:41                                                       ` Jerome Glisse
2015-11-20 15:45                                                     ` David Woodhouse [this message]
2015-11-20 15:45                                                       ` David Woodhouse
2014-06-30 15:37   ` Joerg Roedel
2014-06-28  2:00 ` [PATCH 2/6] mm: differentiate unmap for vmscan from other unmap Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:58   ` John Hubbard
2014-06-30  3:58     ` John Hubbard
2014-06-30 15:58     ` Jerome Glisse
2014-06-30 15:58       ` Jerome Glisse
2014-06-28  2:00 ` [PATCH 3/6] mmu_notifier: add event information to address invalidation v2 Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  5:22   ` John Hubbard
2014-06-30  5:22     ` John Hubbard
2014-06-30 15:57     ` Jerome Glisse
2014-06-30 15:57       ` Jerome Glisse
2014-07-01  1:57   ` Linus Torvalds
2014-06-28  2:00 ` [PATCH 4/6] mmu_notifier: pass through vma to invalidate_range and invalidate_page Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:29   ` John Hubbard
2014-06-30  3:29     ` John Hubbard
2014-06-30 16:00     ` Jerome Glisse
2014-06-30 16:00       ` Jerome Glisse
2014-07-01  2:04   ` Linus Torvalds

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=1448034329.89124.26.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=Alexander.Deucher@amd.com \
    --cc=Andrew.Lewycky@amd.com \
    --cc=Jay.Cornwall@amd.com \
    --cc=John.Bridgman@amd.com \
    --cc=SCheung@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arvindg@nvidia.com \
    --cc=cabuschardt@nvidia.com \
    --cc=cq.tang@intel.com \
    --cc=dpoole@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=j.glisse@gmail.com \
    --cc=jakumar@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=jweiner@redhat.com \
    --cc=ldunning@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhairgrove@nvidia.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=sgutti@nvidia.com \
    --cc=torvalds@linux-foundation.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.