From: Richard Yao <ryao@gentoo.org>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel@gentoo.org
Subject: [PATCH 0/2] llseek fixes
Date: Fri, 14 Jun 2013 15:23:32 -0400 [thread overview]
Message-ID: <1371237814-59365-1-git-send-email-ryao@gentoo.org> (raw)
btrfs_file_llseek() and ocfs2_file_llseek() are extremely similar and
consequently, contain many of the same flaws. Li Dongyang filed a pull request
with ZFSOnLinux for SEEK_HOLE/SEEK_DATA support that included a custom llseek
function that appears to have been modelled after the one in ocfs2. The
similarity was strong enough that it suffered from many of the same flaws,
which I caught during review. I addressed the issues with his patch with one
that I wrote. Since a small percentage of Gentoo Linux users are affected by
these flaws, I decided to adapt that code that to btrfs and ocfs2.
The specific issues are:
1. Taking the inode->i_mutex lock before calling generic_file_llseek(), which
is unnecessary.
2. Failing to take the filp->f_lock spinlock before modifying filp->f_pos and
filp->f_version, which differs from generic_file_llseek().
3. Having an offset > inode->i_sb->s_maxbytes check that is dead code in btrfs
and active code in ocfs2. In ocfs2, this permits seeking up to the maximum file
size possible, even when it is past the end of the file. Seeking beyond that
(if possible), would return EINVAL instead of ENXIO.
4. Trying to cover all whence values when in reality such functions should only
care about SEEK_HOLE/SEEK_DATA. Any other cases should be passsed to
generic_file_llseek().
Richard Yao (2):
ocfs2: Fix llseek() semantics and do some cleanup
btrfs: Cleanup llseek()
fs/btrfs/file.c | 49 ++++++++++++++++++-------------------------
fs/ocfs2/file.c | 65 ++++++++++++++++++++++-----------------------------------
2 files changed, 45 insertions(+), 69 deletions(-)
--
1.8.1.5
next reply other threads:[~2013-06-14 19:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 19:23 Richard Yao [this message]
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
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=1371237814-59365-1-git-send-email-ryao@gentoo.org \
--to=ryao@gentoo.org \
--cc=kernel@gentoo.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®