[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <561b39e0-4501-a6c3-5aa8-13a68d1c9484@intel.com>
Date: Thu, 30 Apr 2020 15:20:07 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Christian Borntraeger <borntraeger@...ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
viro@...iv.linux.org.uk
Cc: david@...hat.com, akpm@...ux-foundation.org, aarcange@...hat.com,
linux-mm@...ck.org, frankja@...ux.ibm.com, sfr@...b.auug.org.au,
jhubbard@...dia.com, linux-kernel@...r.kernel.org,
linux-s390@...r.kernel.org, jack@...e.cz, kirill@...temov.name,
peterz@...radead.org, sean.j.christopherson@...el.com,
Ulrich.Weigand@...ibm.com
Subject: Re: [PATCH v2 1/1] fs/splice: add missing callback for inaccessible
pages
One other thing... The gup code will not take references on ref-frozen
pages:
> static inline __must_check bool try_get_page(struct page *page)
> {
> page = compound_head(page);
> if (WARN_ON_ONCE(page_ref_count(page) <= 0))
> return false;
> page_ref_inc(page);
> return true;
> }
*But*, notice that the path that skips taking a ref is also a
WARN_ON_ONCE(). Basically, if you get to try_get_page() on a ref-frozen
page, it's considered buggy. This makes sense because you fundamentally
can't freeze refs on a page that might have more refs taken on it.
I think all the other users do this by ensuring that any PTE that could
be gup'd is set non-present before the refs are frozen and remote TLBs
are flushed which also ensures no GUPs are running. I don't know if the
s390 code has some other way of preventing GUPs, but leaving Present=1
PTEs while you freeze refs would be quite troublesome on x86.
Powered by blists - more mailing lists