On Mon, Sep 28, 2020 at 12:50:03PM -0700, Linus Torvalds wrote:
> On Mon, Sep 28, 2020 at 12:36 PM Linus Torvalds
> wrote:
> >
> > So I'll do the pte wrprotect/restore removal. Anybody willing to do
> > and test the sequence count approach?
>
> So the wrprotect removal is trivial, with most of it
On Mon, Sep 28, 2020 at 07:51:07PM -0300, Jason Gunthorpe wrote:
> > So I'll attach my suggested patch, but I won't actually commit it. I'd
> > really like to have this tested, possibly _together_ with the sequence
> > count addition..
>
> Ok, we will do this once the holidays are over. If Peter d
On 9/28/20 4:57 PM, Jason Gunthorpe wrote:
On Mon, Sep 28, 2020 at 12:29:55PM -0700, Linus Torvalds wrote:
...
I think this is really hard to use and ugly. My thinking has been to
just stick:
if (flags & FOLL_LONGTERM)
flags |= FOLL_FORCE | FOLL_WRITE
In pin_user_pages(). It would
On Mon, Sep 28, 2020 at 12:29:55PM -0700, Linus Torvalds wrote:
> So a read pin action would basically never work for the fast-path for
> a few cases, notably a shared read-only mapping - because we could
> never mark it in the page tables as "fast pin accessible"
Agree, I was assuming we'd loose
On Mon, Sep 28, 2020 at 12:50:03PM -0700, Linus Torvalds wrote:
> But the more I look at this code, the more I go "ok, I want somebody
> to actually test this with the rdma case".
I suspect it will be OK as our immediate test suite that touches this
will be using malloc memory.
It seems some mma
On Mon, Sep 28, 2020 at 12:36 PM Linus Torvalds
wrote:
>
> So I'll do the pte wrprotect/restore removal. Anybody willing to do
> and test the sequence count approach?
So the wrprotect removal is trivial, with most of it being about the comments.
However, when I look at this, I am - once again -
On Mon, Sep 28, 2020 at 11:39 AM Jason Gunthorpe wrote:
>
> All of gup_fast and copy_mm could be wrappered in a seq count so that
> gup_fast always goes to the slow path if fork is concurrent.
>
> That doesn't sound too expensive and avoids all the problems you
> pointed with the WP scheme.
Ok, I
On Mon, Sep 28, 2020 at 11:39 AM Jason Gunthorpe wrote:
>
> I prefer the version where read pin and write pin are symmetric. The
> PTE in the MM should not change once pinned.
The thing is, I don't really see how to do that.
Right now the write pin fastpath part depends on the PTE being
writable
On Mon, Sep 28, 2020 at 10:54:28AM -0700, Linus Torvalds wrote:
> On Mon, Sep 28, 2020 at 10:23 AM Peter Xu wrote:
> >
> > Yes... Actually I am also thinking about the complete solution to cover
> > read-only fast-gups too, but now I start to doubt this, at least for the
> > fork()
> > path. E.
On Mon, Sep 28, 2020 at 10:23 AM Peter Xu wrote:
>
> Yes... Actually I am also thinking about the complete solution to cover
> read-only fast-gups too, but now I start to doubt this, at least for the
> fork()
> path. E.g. if we'd finally like to use pte_protnone() to replace the current
> pte_w
On Mon, Sep 28, 2020 at 09:17:09AM -0700, Linus Torvalds wrote:
> On Mon, Sep 28, 2020 at 5:49 AM Jason Gunthorpe wrote:
> >
> > Not seeing an obvious option besides adding a smp_mb() before
> > page_maybe_dma_pinned() as Peter once suggested.
>
> That is going to be prohibitively expensive - nee
On Sun, Sep 27, 2020 at 11:16:34AM -0700, Linus Torvalds wrote:
> - split up the "copy page" into its own function kind of like I had
> done for my minimal patch
I didn't do that majorly because of the wrprotect() (of the fast-gup race) that
can potentially be kept if it's a normal cow. Maybe we
On Mon, Sep 28, 2020 at 5:49 AM Jason Gunthorpe wrote:
>
> Not seeing an obvious option besides adding a smp_mb() before
> page_maybe_dma_pinned() as Peter once suggested.
That is going to be prohibitively expensive - needing it for each pte
whether it's pinned or not.
I really think the better
On Sun, Sep 27, 2020 at 11:45:30AM -0700, Linus Torvalds wrote:
> On Sun, Sep 27, 2020 at 11:16 AM Linus Torvalds
> wrote:
> >
> > Btw, I'm not convinced about the whole "turn the pte read-only and
> > then back". If the fork races with another thread doing a pinning
> > fast-GUP on another CPU, t
On Sun, Sep 27, 2020 at 11:16 AM Linus Torvalds
wrote:
>
> Btw, I'm not convinced about the whole "turn the pte read-only and
> then back". If the fork races with another thread doing a pinning
> fast-GUP on another CPU, there are memory ordering issues etc too.
> That's not necessarily visible on
On Sat, Sep 26, 2020 at 11:24 PM Leon Romanovsky wrote:
>
> We won't be able to test the series till Tuesday due to religious holidays.
That's fine. I've merged the series up, and it will be in rc7 later
today, and with an rc8 next week we'll have two weeks to find any
issues.
I did edit Peter's
On Sat, Sep 26, 2020 at 03:28:32PM -0700, Linus Torvalds wrote:
> On Fri, Sep 25, 2020 at 6:15 PM Linus Torvalds
> wrote:
> >
> > I think that over the weekend I'll do Peter's version but with the
> > "page_mapcount() == 1" check, because I'm starting to like that
> > better than the mm->has_pinn
On Fri, Sep 25, 2020 at 6:15 PM Linus Torvalds
wrote:
>
> I think that over the weekend I'll do Peter's version but with the
> "page_mapcount() == 1" check, because I'm starting to like that
> better than the mm->has_pinned.
Actually, rafter the first read-through, I feel like I'll just apply
th
On Fri, Sep 25, 2020 at 5:41 PM Jason Gunthorpe wrote:
>
> I don't completely grok the consequences of the anon_vma check. We
> can exclude file backed mappings as they are broken for pinning
> anyhow, so what is left that could be MAP_PRIVATE of a non-anon_vma?
It really shouldn't ever happen.
On Fri, Sep 25, 2020 at 02:06:59PM -0700, Linus Torvalds wrote:
> On Fri, Sep 25, 2020 at 12:56 PM Linus Torvalds
> wrote:
> >
> > And honestly, since this is all getting fairly late in the rc, and it
> > took longer than I thought, I think we should do the GFP_ATOMIC
> > approach for now - not gr
On Fri, Sep 25, 2020 at 2:13 PM Peter Xu wrote:
>
> On Fri, Sep 25, 2020 at 12:56:05PM -0700, Linus Torvalds wrote:
> > So I think we can simply add a
> >
> > if (page_mapcount(page) != 1)
> > return false;
> >
> > to page_maybe_dma_pinned(), and that very naturally protect
On Fri, Sep 25, 2020 at 12:56:05PM -0700, Linus Torvalds wrote:
> So I think we can simply add a
>
> if (page_mapcount(page) != 1)
> return false;
>
> to page_maybe_dma_pinned(), and that very naturally protects against
> the "is the page count perhaps elevated due to a lo
On Fri, Sep 25, 2020 at 12:56 PM Linus Torvalds
wrote:
>
> And honestly, since this is all getting fairly late in the rc, and it
> took longer than I thought, I think we should do the GFP_ATOMIC
> approach for now - not great, but since it only triggers for this case
> that really should never hap
On Thu, Sep 24, 2020 at 2:30 PM Peter Xu wrote:
>
> > >
> > > With the extra mprotect(!WRITE), I think we'll see a !pte_write() entry.
> > > Then
> > > it'll not go into maybe_dma_pinned() at all since cow==false.
> >
> > Hum that seems like a problem in this patch, we still need to do the
> > D
On Thu, Sep 24, 2020 at 03:39:53PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 24, 2020 at 02:34:18PM -0400, Peter Xu wrote:
>
> > > >// RDONLY gup
> > > >pin_user_pages(buf, !WRITE);
> > > >// pte of buf duplicated on both sides
> > > >fork();
> > > >mprote
On Thu, Sep 24, 2020 at 02:34:18PM -0400, Peter Xu wrote:
> > >// RDONLY gup
> > >pin_user_pages(buf, !WRITE);
> > >// pte of buf duplicated on both sides
> > >fork();
> > >mprotect(buf, WRITE);
> > >*buf = 1;
> > >// buf page replaced as cow
On Thu, Sep 24, 2020 at 03:15:01PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 24, 2020 at 01:55:31PM -0400, Peter Xu wrote:
> > On Thu, Sep 24, 2020 at 01:51:52PM -0300, Jason Gunthorpe wrote:
> > > > Regarding the solution here, I think we can also cover read-only
> > > > fast-gup too
> > > > in
On Thu, Sep 24, 2020 at 01:55:31PM -0400, Peter Xu wrote:
> On Thu, Sep 24, 2020 at 01:51:52PM -0300, Jason Gunthorpe wrote:
> > > Regarding the solution here, I think we can also cover read-only fast-gup
> > > too
> > > in the future - IIUC what we need to do is to make it pte_protnone()
> > > i
On Thu, Sep 24, 2020 at 01:51:52PM -0300, Jason Gunthorpe wrote:
> > Regarding the solution here, I think we can also cover read-only fast-gup
> > too
> > in the future - IIUC what we need to do is to make it pte_protnone()
> > instead of
> > pte_wrprotect(), then in the fault handler we should i
On Thu, Sep 24, 2020 at 10:35:17AM -0400, Peter Xu wrote:
> If so, I'd hope you won't disagree that I still move the get_page() out of the
> "if (wp)". Not only it's a shared operation no matter whether "if (wp)" or
> not, but I'm afraid it would confuse future readers on a special ordering on
>
On Thu 24-09-20 11:02:37, Jason Gunthorpe wrote:
> On Thu, Sep 24, 2020 at 09:44:09AM +0200, Jan Kara wrote:
> > > After the page is pinned it is prevented from being freed and
> > > recycled. After GUP has the pin it must check that the PTE still
> > > points at the same page, otherwise it might h
On Wed, Sep 23, 2020 at 02:07:59PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 22, 2020 at 08:27:35PM -0400, Peter Xu wrote:
> > On Tue, Sep 22, 2020 at 04:11:16PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> > > > diff --git a/mm/memory.c b/mm/mem
On Thu, Sep 24, 2020 at 09:44:09AM +0200, Jan Kara wrote:
> > After the page is pinned it is prevented from being freed and
> > recycled. After GUP has the pin it must check that the PTE still
> > points at the same page, otherwise it might have pinned a page that is
> > alreay free'd - and that wo
On Wed 23-09-20 14:12:07, Jason Gunthorpe wrote:
> On Wed, Sep 23, 2020 at 04:20:03PM +0200, Jan Kara wrote:
>
> > I'd hate to take spinlock in the GUP-fast path. Also I don't think this is
> > quite correct because GUP-fast-only can be called from interrupt context
> > and page table locks are no
On Wed, Sep 23, 2020 at 04:20:03PM +0200, Jan Kara wrote:
> I'd hate to take spinlock in the GUP-fast path. Also I don't think this is
> quite correct because GUP-fast-only can be called from interrupt context
> and page table locks are not interrupt safe.
Yes, IIRC, that is a key element of GUP
On Tue, Sep 22, 2020 at 08:27:35PM -0400, Peter Xu wrote:
> On Tue, Sep 22, 2020 at 04:11:16PM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 8f3521be80ca..6591f3f33299 100644
> > > +++ b/mm/memory
On Wed 23-09-20 09:10:43, Peter Xu wrote:
> On Tue, Sep 22, 2020 at 08:27:35PM -0400, Peter Xu wrote:
> > On Tue, Sep 22, 2020 at 04:11:16PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> > > > diff --git a/mm/memory.c b/mm/memory.c
> > > > index 8f3
On Tue, Sep 22, 2020 at 08:27:35PM -0400, Peter Xu wrote:
> On Tue, Sep 22, 2020 at 04:11:16PM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 8f3521be80ca..6591f3f33299 100644
> > > +++ b/mm/memory
On Tue, Sep 22, 2020 at 04:11:16PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 8f3521be80ca..6591f3f33299 100644
> > +++ b/mm/memory.c
> > @@ -888,8 +888,8 @@ copy_one_pte(struct mm_struct *dst_mm, st
On Tue, Sep 22, 2020 at 01:54:15PM -0400, Peter Xu wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index 8f3521be80ca..6591f3f33299 100644
> +++ b/mm/memory.c
> @@ -888,8 +888,8 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
> *src_mm,
> * Because we'll need to relea
On 9/22/20 8:17 AM, Peter Xu wrote:
On Mon, Sep 21, 2020 at 04:53:38PM -0700, John Hubbard wrote:
On 9/21/20 2:17 PM, Peter Xu wrote:
...
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 496c3ff97cce..6f291f8b74c6 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/
On Tue, Sep 22, 2020 at 11:02:03AM -0700, John Hubbard wrote:
> On 9/22/20 8:17 AM, Peter Xu wrote:
> > On Mon, Sep 21, 2020 at 04:53:38PM -0700, John Hubbard wrote:
> > > On 9/21/20 2:17 PM, Peter Xu wrote:
> > > > (Commit message collected from Jason Gunthorpe)
> > > >
> > > > Reduce the chance
On 9/22/20 8:17 AM, Peter Xu wrote:
On Mon, Sep 21, 2020 at 04:53:38PM -0700, John Hubbard wrote:
On 9/21/20 2:17 PM, Peter Xu wrote:
(Commit message collected from Jason Gunthorpe)
Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
Not yet, it doesn't. :) More:
t
On Tue, Sep 22, 2020 at 01:10:46PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 22, 2020 at 11:17:36AM -0400, Peter Xu wrote:
>
> > > But it's admittedly a cosmetic point, combined with my perennial fear that
> > > I'm missing something when I look at a READ_ONCE()/WRITE_ONCE() pair. :)
> >
> > Ye
On Tue, Sep 22, 2020 at 8:56 AM Jason Gunthorpe wrote:
>
> I thought MAP_PRIVATE without PROT_WRITE was nonsensical,
MAP_PRIVATE without PROT_WRITE is very common.
It's what happens for every executable mapping, for example.
And no, it's not the same as MAP_SHARED, for a couple of simple
reason
On Tue, Sep 22, 2020 at 11:17:36AM -0400, Peter Xu wrote:
> > But it's admittedly a cosmetic point, combined with my perennial fear that
> > I'm missing something when I look at a READ_ONCE()/WRITE_ONCE() pair. :)
>
> Yeah but I hope I'm using it right.. :) I used READ_ONCE/WRITE_ONCE explicitly
On Tue, Sep 22, 2020 at 10:28:02AM -0400, Peter Xu wrote:
> On Tue, Sep 22, 2020 at 08:54:36AM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 22, 2020 at 12:47:11AM +0200, Jann Horn wrote:
> > > On Tue, Sep 22, 2020 at 12:30 AM Peter Xu wrote:
> > > > On Mon, Sep 21, 2020 at 11:43:38PM +0200, Jann
On Mon, Sep 21, 2020 at 04:53:38PM -0700, John Hubbard wrote:
> On 9/21/20 2:17 PM, Peter Xu wrote:
> > (Commit message collected from Jason Gunthorpe)
> >
> > Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
>
> Not yet, it doesn't. :) More:
>
> > track if the mm_str
On Tue, Sep 22, 2020 at 08:54:36AM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 22, 2020 at 12:47:11AM +0200, Jann Horn wrote:
> > On Tue, Sep 22, 2020 at 12:30 AM Peter Xu wrote:
> > > On Mon, Sep 21, 2020 at 11:43:38PM +0200, Jann Horn wrote:
> > > > On Mon, Sep 21, 2020 at 11:17 PM Peter Xu wro
On Tue, Sep 22, 2020 at 12:47:11AM +0200, Jann Horn wrote:
> On Tue, Sep 22, 2020 at 12:30 AM Peter Xu wrote:
> > On Mon, Sep 21, 2020 at 11:43:38PM +0200, Jann Horn wrote:
> > > On Mon, Sep 21, 2020 at 11:17 PM Peter Xu wrote:
> > > > (Commit message collected from Jason Gunthorpe)
> > > >
> > >
On 9/21/20 4:53 PM, John Hubbard wrote:
On 9/21/20 2:17 PM, Peter Xu wrote:
(Commit message collected from Jason Gunthorpe)
Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
Not yet, it doesn't. :) More:
track if the mm_struct has ever been used with pin_user_page
On 9/21/20 2:17 PM, Peter Xu wrote:
(Commit message collected from Jason Gunthorpe)
Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
Not yet, it doesn't. :) More:
track if the mm_struct has ever been used with pin_user_pages(). mm_structs
that have never been pass
On Tue, Sep 22, 2020 at 12:30 AM Peter Xu wrote:
> On Mon, Sep 21, 2020 at 11:43:38PM +0200, Jann Horn wrote:
> > On Mon, Sep 21, 2020 at 11:17 PM Peter Xu wrote:
> > > (Commit message collected from Jason Gunthorpe)
> > >
> > > Reduce the chance of false positive from page_maybe_dma_pinned() by
On Mon, Sep 21, 2020 at 11:43:38PM +0200, Jann Horn wrote:
> On Mon, Sep 21, 2020 at 11:17 PM Peter Xu wrote:
> >
> > (Commit message collected from Jason Gunthorpe)
> >
> > Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
> > track if the mm_struct has ever been used wi
On Mon, Sep 21, 2020 at 11:17 PM Peter Xu wrote:
>
> (Commit message collected from Jason Gunthorpe)
>
> Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
> track if the mm_struct has ever been used with pin_user_pages(). mm_structs
> that have never been passed to pin_us
(Commit message collected from Jason Gunthorpe)
Reduce the chance of false positive from page_maybe_dma_pinned() by keeping
track if the mm_struct has ever been used with pin_user_pages(). mm_structs
that have never been passed to pin_user_pages() cannot have a positive
page_maybe_dma_pinned() by
56 matches
Mail list logo
