From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: readahead: fix do_readahead for no readpage(s)
Date: Tue, 28 Jan 2014 23:01:26 +0200 [thread overview]
Message-ID: <20140128210126.GA27556@node.dhcp.inet.fi> (raw)
In-Reply-To: <20140128120301.581c90caeb1c49e346b6aa66@linux-foundation.org>
On Tue, Jan 28, 2014 at 12:03:01PM -0800, Andrew Morton wrote:
> On Tue, 28 Jan 2014 11:14:19 +0000 Mark Rutland <mark.rutland@arm.com> wrote:
>
> > Commit 63d0f0a3c7e1 (mm/readahead.c:do_readhead(): don't check for
> > ->readpage) unintentionally made do_readahead return 0 for all valid
> > files regardless of whether readahead was supported, rather than the
> > expected -EINVAL. This gets forwarded on to userspace, and results in
> > sys_readahead appearing to succeed in cases that don't make sense (e.g.
> > when called on pipes or sockets). This issue is detected by the LTP
> > readahead01 testcase.
>
> How can this be?
>
> : static ssize_t
> : do_readahead(struct address_space *mapping, struct file *filp,
> : pgoff_t index, unsigned long nr)
> : {
> : if (!mapping || !mapping->a_ops)
> : return -EINVAL;
> :
> : return force_page_cache_readahead(mapping, filp, index, nr);
It's not what we have in Linus' tree. force_page_cache_readahead() return
code is unused:
force_page_cache_readahead(mapping, filp, index, nr);
return 0;
> : }
>
> and
>
> : int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
> : pgoff_t offset, unsigned long nr_to_read)
> : {
> : if (unlikely(!mapping->a_ops->readpage && !mapping->a_ops->readpages))
> : return -EINVAL;
>
> Clearly, do_readahead() will return -EINVAL if neither ->readpage or
> ->readpages are implemented.
>
> I can see that the behaviour would change if the address_space
> implements only one of ->readpage and ->readpages, but that doesn't
> appear to match your description and the new behaviour is correct - we
> can now perform readahead for address_spaces which implement
> ->readpages and not ->readpage (which would be odd and might not work
> for other reasons..).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Kirill A. Shutemov
next prev parent reply other threads:[~2014-01-28 21:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 11:14 [PATCH] mm: readahead: fix do_readahead for no readpage(s) Mark Rutland
2014-01-28 11:53 ` Kirill A. Shutemov
2014-01-28 20:03 ` Andrew Morton
2014-01-28 21:01 ` Kirill A. Shutemov [this message]
2014-01-28 21:09 ` Andrew Morton
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=20140128210126.GA27556@node.dhcp.inet.fi \
--to=kirill@shutemov.name \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.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.