From: Eric Biggers <ebiggers@kernel.org>
To: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH] fs-verity: implement readahead for FS_IOC_ENABLE_VERITY
Date: Wed, 4 Dec 2019 10:10:56 -0800 [thread overview]
Message-ID: <20191204181056.GA4576@sol.localdomain> (raw)
In-Reply-To: <96a288281d9d84f11dcc06e62a1ff20e2bb2f776.camel@dubeyko.com>
On Wed, Dec 04, 2019 at 10:53:50AM +0300, Vyacheslav Dubeyko wrote:
> > diff --git a/fs/verity/enable.c b/fs/verity/enable.c
> > index eabc6ac19906..f7eaffa60196 100644
> > --- a/fs/verity/enable.c
> > +++ b/fs/verity/enable.c
> > @@ -13,14 +13,44 @@
> > #include <linux/sched/signal.h>
> > #include <linux/uaccess.h>
> >
> > -static int build_merkle_tree_level(struct inode *inode, unsigned int
> > level,
> > +/*
> > + * Read a file data page for Merkle tree construction. Do
> > aggressive readahead,
> > + * since we're sequentially reading the entire file.
> > + */
> > +static struct page *read_file_data_page(struct inode *inode,
> > + struct file_ra_state *ra,
> > + struct file *filp,
> > + pgoff_t index,
> > + pgoff_t num_pages_in_file)
> > +{
> > + struct page *page;
> > +
> > + page = find_get_page(inode->i_mapping, index);
> > + if (!page || !PageUptodate(page)) {
> > + if (page)
> > + put_page(page);
>
>
> It looks like that there is not necessary check here. If we have NULL
> pointer on page then we will not enter inside. But if we have valid
> pointer on page then we have double check inside. Am I correct?
>
I'm not sure what you mean. This code does the page_cache_sync_readahead() and
read_mapping_page() if either the page is not in the pagecache at all *or* is
not up to date. I know this is slightly different logic than
generic_file_buffered_read() uses, and is suboptimal since the use of
read_mapping_page() causes a redundant pagecache lookup. But we don't need to
squeeze out every possible bit of performance here.
Hmm, maybe it should only call page_cache_sync_readahead() when page == NULL
though. I'll check the readahead code again.
>
> > + page_cache_sync_readahead(inode->i_mapping, ra, filp,
> > + index, num_pages_in_file -
> > index);
> > + page = read_mapping_page(inode->i_mapping, index,
> > NULL);
> > + if (IS_ERR(page))
> > + return page;
>
> Could we recieve the NULL pointer here? Is callee ready to process theNULL return value?
>
No, read_mapping_page() returns either a valid page or an ERR_PTR().
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-ext4@vger.kernel.org, Victor Hsieh <victorhsieh@google.com>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] fs-verity: implement readahead for FS_IOC_ENABLE_VERITY
Date: Wed, 4 Dec 2019 10:10:56 -0800 [thread overview]
Message-ID: <20191204181056.GA4576@sol.localdomain> (raw)
In-Reply-To: <96a288281d9d84f11dcc06e62a1ff20e2bb2f776.camel@dubeyko.com>
On Wed, Dec 04, 2019 at 10:53:50AM +0300, Vyacheslav Dubeyko wrote:
> > diff --git a/fs/verity/enable.c b/fs/verity/enable.c
> > index eabc6ac19906..f7eaffa60196 100644
> > --- a/fs/verity/enable.c
> > +++ b/fs/verity/enable.c
> > @@ -13,14 +13,44 @@
> > #include <linux/sched/signal.h>
> > #include <linux/uaccess.h>
> >
> > -static int build_merkle_tree_level(struct inode *inode, unsigned int
> > level,
> > +/*
> > + * Read a file data page for Merkle tree construction. Do
> > aggressive readahead,
> > + * since we're sequentially reading the entire file.
> > + */
> > +static struct page *read_file_data_page(struct inode *inode,
> > + struct file_ra_state *ra,
> > + struct file *filp,
> > + pgoff_t index,
> > + pgoff_t num_pages_in_file)
> > +{
> > + struct page *page;
> > +
> > + page = find_get_page(inode->i_mapping, index);
> > + if (!page || !PageUptodate(page)) {
> > + if (page)
> > + put_page(page);
>
>
> It looks like that there is not necessary check here. If we have NULL
> pointer on page then we will not enter inside. But if we have valid
> pointer on page then we have double check inside. Am I correct?
>
I'm not sure what you mean. This code does the page_cache_sync_readahead() and
read_mapping_page() if either the page is not in the pagecache at all *or* is
not up to date. I know this is slightly different logic than
generic_file_buffered_read() uses, and is suboptimal since the use of
read_mapping_page() causes a redundant pagecache lookup. But we don't need to
squeeze out every possible bit of performance here.
Hmm, maybe it should only call page_cache_sync_readahead() when page == NULL
though. I'll check the readahead code again.
>
> > + page_cache_sync_readahead(inode->i_mapping, ra, filp,
> > + index, num_pages_in_file -
> > index);
> > + page = read_mapping_page(inode->i_mapping, index,
> > NULL);
> > + if (IS_ERR(page))
> > + return page;
>
> Could we recieve the NULL pointer here? Is callee ready to process theNULL return value?
>
No, read_mapping_page() returns either a valid page or an ERR_PTR().
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-12-04 18:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 19:30 [PATCH] fs-verity: implement readahead for FS_IOC_ENABLE_VERITY Eric Biggers
2019-12-03 19:30 ` [f2fs-dev] " Eric Biggers
2019-12-04 7:53 ` Vyacheslav Dubeyko
2019-12-04 7:53 ` [f2fs-dev] " Vyacheslav Dubeyko
2019-12-04 18:10 ` Eric Biggers [this message]
2019-12-04 18:10 ` Eric Biggers
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=20191204181056.GA4576@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=victorhsieh@google.com \
/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.