Matthew Wilcox (Oracle) wrote on Thu, Sep 17, 2020: > The 9p readpage implementation was already synchronous, so use > AOP_UPDATED_PAGE to avoid cycling the page lock. > > Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> Acked-by: Dominique Martinet <asmadeus@xxxxxxxxxxxxx> (I assume it'll be merged together with the rest) > > What I'm curious about is the page used to be both unlocked and put, but > > now isn't either and the return value hasn't changed for the caller to > > make a difference on write_begin / I don't see any code change in the > > vfs to handle that. > > What did I miss? > > The page cache is kind of subtle. The grab_cache_page_write_begin() > will return a Locked page with an increased refcount. If it's Uptodate, > that's exactly what we want, and we return it. If we have to read the > page, readpage used to unlock the page before returning, and rather than > re-lock it, we would drop the reference to the page and look it up again. > It's possible that after dropping the lock on that page that the page > was replaced in the page cache and so we'd get a different page. Thanks for the explanation, I didn't realize the page already is gotten/locked at the PageUptodate goto out. > Anyway, now (unless fscache is involved), v9fs_fid_readpage will return > the page without unlocking it. So we don't need to do the dance of > dropping the lock, putting the refcount and looking the page back up > again. We can just return the page. The VFS doesn't need a special > return code because nothing has changed from the VFS's point of view -- > it asked you to get a page and you got the page. Yes, looks good to me. Cheers, -- Dominique
