summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorZheng Liu <wenqing.lz@taobao.com>2014-06-02 18:48:22 +0400
committerTheodore Ts'o <tytso@mit.edu>2014-06-02 18:48:22 +0400
commitbd9db175dde14b606265e0d37e8319d96fe1a58f (patch)
tree967cb128c52d2aeb5d98d5cd69eb4ec629fb657a /mm
parentb5b60778558cafad17bbcbf63e0310bd3c68eb17 (diff)
downloadlinux-bd9db175dde14b606265e0d37e8319d96fe1a58f.tar.xz
ext4: handle symlink properly with inline_data
This commit tries to fix a bug that we can't read symlink properly with inline data feature when the length of symlink is greater than 60 bytes but less than extra space. The key issue is in ext4_inode_is_fast_symlink() that it doesn't check whether or not an inode has inline data. When the user creates a new symlink, an inode will be allocated with MAY_INLINE_DATA flag. Then symlink will be stored in ->i_block and extended attribute space. In the mean time, this inode is with inline data flag. After remounting it, ext4_inode_is_fast_symlink() function thinks that this inode is a fast symlink so that the data in ->i_block is copied to the user, and the data in extra space is trimmed. In fact this inode should be as a normal symlink. The following script can hit this bug. #!/bin/bash cd ${MNT} filename=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 rm -rf test mkdir test cd test echo "hello" >$filename ln -s $filename symlinkfile cd sudo umount /mnt/sda1 sudo mount -t ext4 /dev/sda1 /mnt/sda1 readlink /mnt/sda1/test/symlinkfile After applying this patch, it will break the assumption in e2fsck because the original implementation doesn't want to support symlink with inline data. Reported-by: "Darrick J. Wong" <darrick.wong@oracle.com> Reported-by: Ian Nartowicz <claws@nartowicz.co.uk> Cc: Ian Nartowicz <claws@nartowicz.co.uk> Cc: Tao Ma <tm@tao.ma> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Andreas Dilger <adilger.kernel@dilger.ca> Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions