All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-cifs@vger.kernel.org,
	Richard Weinberger <richard@nod.at>,
	ecryptfs@vger.kernel.org, linux-um@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-mtd@lists.infradead.org,
	v9fs-developer@lists.sourceforge.net, ceph-devel@vger.kernel.org,
	linux-afs@lists.infradead.org
Subject: Re: [V9fs-developer] [PATCH 02/13] 9p: Tell the VFS that readpage was synchronous
Date: Fri, 18 Sep 2020 14:30:25 +0200	[thread overview]
Message-ID: <20200918123025.GA735@nautica> (raw)
In-Reply-To: <20200918111916.GA32101@casper.infradead.org> <20200917151050.5363-3-willy@infradead.org>

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@infradead.org>

Acked-by: Dominique Martinet <asmadeus@codewreck.org>

(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

WARNING: multiple messages have this Message-ID (diff)
From: Dominique Martinet <asmadeus@codewreck.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-cifs@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	ecryptfs@vger.kernel.org, linux-um@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net, ceph-devel@vger.kernel.org,
	linux-afs@lists.infradead.org
Subject: Re: [V9fs-developer] [PATCH 02/13] 9p: Tell the VFS that readpage was synchronous
Date: Fri, 18 Sep 2020 14:30:25 +0200	[thread overview]
Message-ID: <20200918123025.GA735@nautica> (raw)
In-Reply-To: <20200918111916.GA32101@casper.infradead.org> <20200917151050.5363-3-willy@infradead.org>

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@infradead.org>

Acked-by: Dominique Martinet <asmadeus@codewreck.org>

(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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Dominique Martinet <asmadeus@codewreck.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-cifs@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	ecryptfs@vger.kernel.org, linux-um@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net, ceph-devel@vger.kernel.org,
	linux-afs@lists.infradead.org
Subject: Re: [V9fs-developer] [PATCH 02/13] 9p: Tell the VFS that readpage was synchronous
Date: Fri, 18 Sep 2020 14:30:25 +0200	[thread overview]
Message-ID: <20200918123025.GA735@nautica> (raw)
In-Reply-To: <20200918111916.GA32101@casper.infradead.org> <20200917151050.5363-3-willy@infradead.org>

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@infradead.org>

Acked-by: Dominique Martinet <asmadeus@codewreck.org>

(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

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  parent reply	other threads:[~2020-09-18 12:30 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 15:10 [PATCH 00/13] Allow readpage to return a locked page Matthew Wilcox (Oracle)
2020-09-17 15:10 ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 01/13] mm: Add AOP_UPDATED_PAGE return value Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 22:03   ` Matthew Wilcox
2020-09-17 22:03     ` Matthew Wilcox
2020-09-17 22:03     ` Matthew Wilcox
2020-09-17 15:10 ` [PATCH 02/13] 9p: Tell the VFS that readpage was synchronous Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-18  5:59   ` [V9fs-developer] " Dominique Martinet
2020-09-18  5:59     ` Dominique Martinet
2020-09-18  5:59     ` Dominique Martinet
2020-09-18 11:19     ` Matthew Wilcox
2020-09-18 11:19       ` Matthew Wilcox
2020-09-18 11:19       ` Matthew Wilcox
2020-09-18 12:30   ` Dominique Martinet [this message]
2020-09-18 12:30     ` Dominique Martinet
2020-09-18 12:30     ` Dominique Martinet
2020-09-17 15:10 ` [PATCH 03/13] afs: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 04/13] ceph: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 16:49   ` Jeff Layton
2020-09-17 16:49     ` Jeff Layton
2020-09-17 16:49     ` Jeff Layton
2020-09-17 16:49     ` Jeff Layton
2020-09-17 15:10 ` [PATCH 05/13] cifs: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 06/13] cramfs: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 07/13] ecryptfs: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 08/13] fuse: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 09/13] hostfs: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 10/13] jffs2: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10 ` [PATCH 11/13] ubifs: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 20:46   ` Richard Weinberger
2020-09-17 20:46     ` Richard Weinberger
2020-09-17 20:46     ` Richard Weinberger
2020-09-17 20:46     ` Richard Weinberger
2020-09-17 20:46     ` Richard Weinberger
2020-09-17 15:10 ` [PATCH 12/13] udf: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-24  9:00   ` Jan Kara
2020-09-24  9:00     ` Jan Kara
2020-09-24  9:00     ` Jan Kara
2020-09-17 15:10 ` [PATCH 13/13] vboxsf: " Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 15:10   ` Matthew Wilcox (Oracle)
2020-09-17 22:56 ` [PATCH 14/13] iomap: Inline iomap_iop_set_range_uptodate into its one caller Matthew Wilcox (Oracle)
2020-09-17 22:56   ` [PATCH 15/13] iomap: Inline iomap_read_finish " Matthew Wilcox (Oracle)
2020-09-19  6:31     ` Christoph Hellwig
2020-09-17 22:56   ` [PATCH 16/13] iomap: Make readpage synchronous Matthew Wilcox (Oracle)
2020-09-19  6:39     ` Christoph Hellwig
2020-09-19  6:43       ` Christoph Hellwig
2020-09-19 17:03         ` Matthew Wilcox
2020-09-19 17:10       ` Matthew Wilcox
2020-09-19  6:31   ` [PATCH 14/13] iomap: Inline iomap_iop_set_range_uptodate into its one caller Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200918123025.GA735@nautica \
    --to=asmadeus@codewreck.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.