From: Jeff Liu <jeff.liu@oracle.com>
To: Richard Yao <ryao@gentoo.org>
Cc: Mark Fasheh <mfasheh@suse.com>,
linux-kernel@vger.kernel.org, kernel@gentoo.org,
linux-fsdevel@vger.kernel.org,
Ocfs2-Devel <ocfs2-devel@oss.oracle.com>
Subject: [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
Date: Sun, 16 Jun 2013 15:00:24 +0800 [thread overview]
Message-ID: <51BD6288.5030901@oracle.com> (raw)
In-Reply-To: <51BD0AFF.8010504@gentoo.org>
On 06/16/2013 08:46 AM, Richard Yao wrote:
> 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.
Hmm?? Did you mean to say that an invalid whence(i.e, whence > SEEK_MAX)
can be passed into generic_file_llseek()?
If so, I don't think that is a problem because any invalid whence should
be rejected at the entrance of VFS lseek(2) with EINVAL.
Thanks,
-Jeff
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Liu <jeff.liu@oracle.com>
To: Richard Yao <ryao@gentoo.org>
Cc: Mark Fasheh <mfasheh@suse.com>,
linux-kernel@vger.kernel.org, kernel@gentoo.org,
linux-fsdevel@vger.kernel.org,
Ocfs2-Devel <ocfs2-devel@oss.oracle.com>
Subject: Re: [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
Date: Sun, 16 Jun 2013 15:00:24 +0800 [thread overview]
Message-ID: <51BD6288.5030901@oracle.com> (raw)
In-Reply-To: <51BD0AFF.8010504@gentoo.org>
On 06/16/2013 08:46 AM, Richard Yao wrote:
> 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.
Hmm?? Did you mean to say that an invalid whence(i.e, whence > SEEK_MAX)
can be passed into generic_file_llseek()?
If so, I don't think that is a problem because any invalid whence should
be rejected at the entrance of VFS lseek(2) with EINVAL.
Thanks,
-Jeff
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Liu <jeff.liu@oracle.com>
To: Richard Yao <ryao@gentoo.org>
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: Sun, 16 Jun 2013 15:00:24 +0800 [thread overview]
Message-ID: <51BD6288.5030901@oracle.com> (raw)
In-Reply-To: <51BD0AFF.8010504@gentoo.org>
On 06/16/2013 08:46 AM, Richard Yao wrote:
> 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.
Hmm?? Did you mean to say that an invalid whence(i.e, whence > SEEK_MAX)
can be passed into generic_file_llseek()?
If so, I don't think that is a problem because any invalid whence should
be rejected at the entrance of VFS lseek(2) with EINVAL.
Thanks,
-Jeff
next prev parent reply other threads:[~2013-06-16 7:00 UTC|newest]
Thread overview: 21+ 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 ` [Ocfs2-devel] " Jeff Liu
2013-06-15 5:09 ` Jeff Liu
2013-06-15 5:09 ` Jeff Liu
2013-06-15 6:22 ` [Ocfs2-devel] " shencanquan
2013-06-15 6:22 ` shencanquan
2013-06-16 0:44 ` Richard Yao
2013-06-16 0:45 ` Richard Yao
2013-06-16 1:57 ` shencanquan
2013-06-16 1:57 ` shencanquan
2013-06-16 7:16 ` Jeff Liu
2013-06-16 7:16 ` Jeff Liu
2013-06-16 0:46 ` Richard Yao
2013-06-16 0:47 ` [Ocfs2-devel] " Richard Yao
2013-06-16 7:00 ` Jeff Liu [this message]
2013-06-16 7:00 ` Jeff Liu
2013-06-16 7:00 ` Jeff Liu
2013-06-16 7:17 ` Richard Yao
2013-06-16 7:17 ` [Ocfs2-devel] " 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=51BD6288.5030901@oracle.com \
--to=jeff.liu@oracle.com \
--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 \
--cc=ryao@gentoo.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.