On Tue, 27 Nov 2018, Mike Rapoport wrote: > > * @page: The page to wait for. > > * > > * The caller should hold a reference on @page. They expect the page to > > * become unlocked relatively soon, but do not wish to hold up migration > > * (for example) by holding the reference while waiting for the page to > > * come unlocked. After this function returns, the caller should not > > * dereference @page. > > */ > > How about: > > They expect the page to become unlocked relatively soon, but they can wait > for the page to come unlocked without holding the reference, to allow > other users of the @page (for example migration) to continue. All of this seems a bit strange and it seems unnecessary? Maybe we need a better explanation? A process has no refcount on a page struct and is waiting for it to become unlocked? Why? Should it not simply ignore that page and continue? It cannot possibly do anything with the page since it does not hold a refcount. In order to do anything with the page struct it would have to obtain a refcount and possibly lock the page. That would already wait for the page to become unlocked.