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
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
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
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
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
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
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
> > >
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/
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
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"
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)
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
> > >
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
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
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
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
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
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
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
>
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
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
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
22 matches
Mail list logo