On Fri, Aug 16, 2019 at 11:50:09AM -0700, John Hubbard wrote:
On 8/16/19 11:33 AM, Ira Weiny wrote:
quoted
On Fri, Aug 16, 2019 at 05:41:08PM +0200, Jan Kara wrote:
quoted
On Thu 15-08-19 19:14:08, John Hubbard wrote:
quoted
On 8/15/19 10:41 AM, John Hubbard wrote:
quoted
On 8/15/19 10:32 AM, Ira Weiny wrote:
quoted
On Thu, Aug 15, 2019 at 03:35:10PM +0200, Jan Kara wrote:
quoted
On Thu 15-08-19 15:26:22, Jan Kara wrote:
quoted
On Wed 14-08-19 20:01:07, John Hubbard wrote:
quoted
On 8/14/19 5:02 PM, John Hubbard wrote:
...
OK, there was only process_vm_access.c, plus (sort of) Bharath's sgi-gru
patch, maybe eventually [1]. But looking at process_vm_access.c, I think
it is one of the patches that is no longer applicable, and I can just
drop it entirely...I'd welcome a second opinion on that...
I don't think you can drop the patch. process_vm_rw_pages() clearly touches
page contents and does not synchronize with page_mkclean(). So it is case
1) and needs FOLL_PIN semantics.
John could you send a formal patch using vaddr_pin* and I'll add it to the
tree?
Yes...hints about which struct file to use here are very welcome, btw. This part
of mm is fairly new to me.
I'm still working out the final semantics of vaddr_pin*. But right now you
don't need a vaddr_pin if you don't specify FOLL_LONGTERM.
Since case 1, this case, does not need FOLL_LONGTERM I think it is safe to
simply pass NULL here.
OTOH we could just track this against the mm_struct. But I don't think we need
to because this pin should be transient.
And this is why I keep leaning toward _not_ putting these flags in the
vaddr_pin*() calls. I know this is what I did but I think I'm wrong. It should
be the caller specifying what they want and the vaddr_pin*() calls check that
what they are asking for is correct.
Ira
thanks,
--
John Hubbard
NVIDIA