From: Richard Yao <ryao@gentoo.org>
To: Jeff Liu <jeff.liu@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@gentoo.org, Ocfs2-Devel <ocfs2-devel@oss.oracle.com>,
Joel Becker <jlbec@evilplan.org>, Mark Fasheh <mfasheh@suse.com>
Subject: Re: [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
Date: Sat, 15 Jun 2013 20:46:55 -0400 [thread overview]
Message-ID: <51BD0AFF.8010504@gentoo.org> (raw)
In-Reply-To: <51BBF6FE.6080502@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]
On 06/15/2013 01:09 AM, Jeff Liu wrote:
> [Add ocfs2-devel to CC-list]
>
> Hello Richard,
>
> Thanks for your patch.
>
> On 06/15/2013 03:23 AM, Richard Yao wrote:
>
>> There are multiple issues with the custom llseek implemented in ocfs2 for
>> implementing SEEK_HOLE/SEEK_DATA.
>>
>> 1. It takes the inode->i_mutex lock before calling generic_file_llseek(), which
>> is unnecessary.
>
> Agree, but please see my comments below.
>
>>
>> 2. It fails to take the filp->f_lock spinlock before modifying filp->f_pos and
>> filp->f_version, which differs from generic_file_llseek().
>>
>> 3. It does a offset > inode->i_sb->s_maxbytes check that permits seeking up to
>> the maximum file size possible on the ocfs2 filesystem, even when it is past
>> the end of the file. Seeking beyond that (if possible), would return EINVAL
>> instead of ENXIO.
>>
>> 4. The switch statement tries to cover all whence values when in reality it
>> should only care about SEEK_HOLE/SEEK_DATA. Any other cases should be passsed
>> to generic_file_llseek().
>
> I have another patch set for refactoring ocfs2_file_llseek() but not yet found time
> to run a comprehensive tests. It can solve the existing issues but also improved the
> SEEK_DATA/SEEK_HOLE for unwritten extents, i.e. OCFS2_EXT_UNWRITTEN.
>
> With this change, SEEK_DATA/SEEK_HOLE will go into separate function with a little code
> duplication instead of the current mix-ups in ocfs2_seek_data_hole_offset(), i.e,
>
> loff_t ocfs2_file_llseek()
> {
> switch (origin) {
> case SEEK_END:
> case SEEK_CUR:
> case SEEK_SET:
> return generic_file_llseek(file, offset, origin);
> case SEEK_DATA:
> return ocfs2_seek_data(file, offset);
> case SEEK_HOLE:
> return ocfs2_seek_hole(file, offset);
> default:
> return -EINVAL;
> }
> }
>
> I personally like keeping SEEK_DATA/SEEK_HOLE in switch...case style rather
> than dealing with them in a condition check block.
I would prefer to see the code structured like this:
loff_t ocfs2_file_llseek()
{
switch (origin) {
case SEEK_DATA:
return ocfs2_seek_data(file, offset);
case SEEK_HOLE:
return ocfs2_seek_hole(file, offset);
default:
return generic_file_llseek(file, offset, origin);
}
}
Unfortunately, I just noticed that this code has a problem. In specific,
generic_file_llseek() calls generic_file_llseek_size(), which has a
switch statement for whence that fails to distinguish between SEEK_SET
and invalid whence values. Invalid whence values are mapped to SEEK_SET
instead of returning EINVAL, which is wrong. That issue affects all
filesystems that do not specify a custom llseek() function and it would
affect ocfs2 if my version of the function is used.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2013-06-16 0:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 19:23 [PATCH 0/2] llseek fixes Richard Yao
2013-06-14 19:23 ` [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup Richard Yao
2013-06-15 5:09 ` Jeff Liu
2013-06-15 6:22 ` [Ocfs2-devel] " shencanquan
2013-06-16 0:44 ` Richard Yao
2013-06-16 1:57 ` shencanquan
2013-06-16 0:46 ` Richard Yao [this message]
2013-06-16 7:00 ` Jeff Liu
2013-06-16 7:17 ` Richard Yao
2013-06-14 19:23 ` [PATCH 2/2] btrfs: Cleanup llseek() Richard Yao
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=51BD0AFF.8010504@gentoo.org \
--to=ryao@gentoo.org \
--cc=jeff.liu@oracle.com \
--cc=jlbec@evilplan.org \
--cc=kernel@gentoo.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox