[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200924183953.GG9916@ziepe.ca>
Date: Thu, 24 Sep 2020 15:39:53 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Peter Xu <peterx@...hat.com>
Cc: John Hubbard <jhubbard@...dia.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.cz>, Michal Hocko <mhocko@...e.com>,
Kirill Tkhai <ktkhai@...tuozzo.com>,
Kirill Shutemov <kirill@...temov.name>,
Hugh Dickins <hughd@...gle.com>,
Christoph Hellwig <hch@....de>,
Andrea Arcangeli <aarcange@...hat.com>,
Oleg Nesterov <oleg@...hat.com>,
Leon Romanovsky <leonro@...dia.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned
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 triggered
> > >
> > > Currently when fork() we'll happily share a pinned read-only page with the
> > > child by copying the pte directly.
> >
> > Why? This series prevents that, the page will be maybe_dma_pinned, so
> > fork() will copy it.
>
> 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
DMA pinned logic even if the pte is already write protected.
Jason
Powered by blists - more mailing lists