Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-12 Thread Daniel Vetter
On Mon, Oct 12, 2020 at 12:47 PM Marek Szyprowski wrote: > > Hi Jason, > > On 09.10.2020 14:48, Jason Gunthorpe wrote: > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > >> I'm not a mm/ expert, but, from what I understood from Daniel's patch > >> description is that

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-12 Thread Marek Szyprowski
Hi Jason, On 09.10.2020 14:48, Jason Gunthorpe wrote: > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > >> I'm not a mm/ expert, but, from what I understood from Daniel's patch >> description is that this is unsafe *only if* __GFP_MOVABLE is used. > No, it is

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-11 Thread Mauro Carvalho Chehab
Em Sun, 11 Oct 2020 08:27:41 +0200 Mauro Carvalho Chehab escreveu: > Em Sat, 10 Oct 2020 23:50:27 +0200 > Daniel Vetter escreveu: > > > On Sat, Oct 10, 2020 at 11:36 PM Laurent Pinchart > > wrote: > > > > > > > > We probably still have a few legacy drivers using videobuf (non-2), > > > > but

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-11 Thread Mauro Carvalho Chehab
Em Sat, 10 Oct 2020 23:50:27 +0200 Daniel Vetter escreveu: > On Sat, Oct 10, 2020 at 11:36 PM Laurent Pinchart > wrote: > > > > > We probably still have a few legacy drivers using videobuf (non-2), > > > but IMHO those should be safe to put behind some disabled-by-default > > > Kconfig symbol

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Daniel Vetter
On Sat, Oct 10, 2020 at 11:36 PM Laurent Pinchart wrote: > > Hi Tomasz, > > On Sat, Oct 10, 2020 at 07:22:48PM +0200, Tomasz Figa wrote: > > On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote: > > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > > On Fri, Oct 09, 2020 at 02:37:23PM

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Laurent Pinchart
Hi Tomasz, On Sat, Oct 10, 2020 at 07:22:48PM +0200, Tomasz Figa wrote: > On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > > > I'm not a mm/

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Laurent Pinchart
Hi Daniel, On Fri, Oct 09, 2020 at 07:52:05PM +0200, Daniel Vetter wrote: > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > I'm not a mm/ expert, but, from what I understood from Daniel's patch > > >

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Tomasz Figa
Hi Mauro, On Fri, Oct 9, 2020 at 2:37 PM Mauro Carvalho Chehab wrote: > > Em Fri, 9 Oct 2020 09:21:11 -0300 > Jason Gunthorpe escreveu: > > > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote: > > > Hi, > > > > > > Em Fri, 9 Oct 2020 09:59:26 +0200 > > > Daniel Vetter

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Tomasz Figa
Hi Daniel, On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > I'm not a mm/ expert, but, from what I understood from Daniel's patch > > >

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Daniel Vetter
On Sat, Oct 10, 2020 at 1:39 PM Mauro Carvalho Chehab wrote: > > Em Sat, 10 Oct 2020 12:53:49 +0200 > Daniel Vetter escreveu: > > > Hi Mauro, > > > > You might want to read the patches more carefully, because what you're > > demanding is what my patches do. Short summary: > > > > - if

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Mauro Carvalho Chehab
Em Sat, 10 Oct 2020 12:53:49 +0200 Daniel Vetter escreveu: > Hi Mauro, > > You might want to read the patches more carefully, because what you're > demanding is what my patches do. Short summary: > > - if STRICT_FOLLOW_PFN is set: > a) normal memory is handled as-is (i.e. your example works)

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Daniel Vetter
Hi Mauro, You might want to read the patches more carefully, because what you're demanding is what my patches do. Short summary: - if STRICT_FOLLOW_PFN is set: a) normal memory is handled as-is (i.e. your example works) through the addition of FOLL_LONGTERM. This is the "pin the pages correctly"

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Jason Gunthorpe
On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > I'm not a mm/ expert, but, from what I understood from Daniel's patch > description is that this is unsafe *only if* __GFP_MOVABLE is used. No, it is unconditionally unsafe. The CMA movable mappings are specific VMAs that

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Jason Gunthorpe
On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote: > Hi, > > Em Fri, 9 Oct 2020 09:59:26 +0200 > Daniel Vetter escreveu: > > > Way back it was a reasonable assumptions that iomem mappings never > > change the pfn range they point at. But this has changed: > > > > - gpu

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Jason Gunthorpe
On Fri, Oct 09, 2020 at 07:52:05PM +0200, Daniel Vetter wrote: > > > If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE > > > flag that it would be denying the core mm code to set __GFP_MOVABLE. > > > > We can't tell from the VMA these kinds of details.. > > > > It has to go the

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Mauro Carvalho Chehab
Em Fri, 9 Oct 2020 19:52:05 +0200 Daniel Vetter escreveu: > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > I'm not a mm/ expert, but, from what I understood from Daniel's patch > > > description is

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-09 Thread Daniel Vetter
On Fri, Oct 9, 2020 at 8:01 PM Jason Gunthorpe wrote: > > On Fri, Oct 09, 2020 at 07:52:05PM +0200, Daniel Vetter wrote: > > > > > If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE > > > > flag that it would be denying the core mm code to set __GFP_MOVABLE. > > > > > > We can't

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-09 Thread Daniel Vetter
On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > I'm not a mm/ expert, but, from what I understood from Daniel's patch > > description is that this is unsafe *only if* __GFP_MOVABLE is used. > > No, it is

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-09 Thread Mauro Carvalho Chehab
Em Fri, 9 Oct 2020 14:37:23 +0200 Mauro Carvalho Chehab escreveu: > Em Fri, 9 Oct 2020 09:21:11 -0300 > Jason Gunthorpe escreveu: > > > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote: > > > Hi, > > > > > > Em Fri, 9 Oct 2020 09:59:26 +0200 > > > Daniel Vetter

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-09 Thread Mauro Carvalho Chehab
Em Fri, 9 Oct 2020 09:21:11 -0300 Jason Gunthorpe escreveu: > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote: > > Hi, > > > > Em Fri, 9 Oct 2020 09:59:26 +0200 > > Daniel Vetter escreveu: > > > > > Way back it was a reasonable assumptions that iomem mappings never >

Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-09 Thread Mauro Carvalho Chehab
Hi, Em Fri, 9 Oct 2020 09:59:26 +0200 Daniel Vetter escreveu: > Way back it was a reasonable assumptions that iomem mappings never > change the pfn range they point at. But this has changed: > > - gpu drivers dynamically manage their memory nowadays, invalidating > ptes with

[PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-09 Thread Daniel Vetter
Way back it was a reasonable assumptions that iomem mappings never change the pfn range they point at. But this has changed: - gpu drivers dynamically manage their memory nowadays, invalidating ptes with unmap_mapping_range when buffers get moved - contiguous dma allocations have moved from