[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <010001645d77ee2c-de7fedbd-f52d-4b74-9388-e6435973792b-000000@email.amazonses.com>
Date: Tue, 3 Jul 2018 00:08:18 +0000
From: Christopher Lameter <cl@...ux.com>
To: John Hubbard <jhubbard@...dia.com>
cc: Jan Kara <jack@...e.cz>, john.hubbard@...il.com,
Matthew Wilcox <willy@...radead.org>,
Michal Hocko <mhocko@...nel.org>,
Jason Gunthorpe <jgg@...pe.ca>,
Dan Williams <dan.j.williams@...el.com>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>,
linux-rdma <linux-rdma@...r.kernel.org>,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 5/6] mm: track gup pages with page->dma_pinned_*
fields
On Mon, 2 Jul 2018, John Hubbard wrote:
> >
> > These two are just wrong. You cannot make any page reference for
> > PageDmaPinned() account against a pin count. First, it is just conceptually
> > wrong as these references need not be long term pins, second, you can
> > easily race like:
> >
> > Pinner Random process
> > get_page(page)
> > pin_page_for_dma()
> > put_page(page)
> > -> oops, page gets unpinned too early
> >
>
> I'll drop this approach, without mentioning any of the locking that is hiding in
> there, since that was probably breaking other rules anyway. :) Thanks for your
> patience in reviewing this.
Mayb the following would work:
If you establish a reference to a page then increase the page count. If
the reference is a dma pin action also then increase the pinned count.
That way you know how many of the references to the page are dma
pins and you can correctly manage the state of the page if the dma pins go
away.
Powered by blists - more mailing lists