[PATCH 0/2] llseek fixes

From: Richard Yao
Date: Fri Jun 14 2013 - 15:24:34 EST


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/