From patchwork Mon Jun 2 11:39:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zheng Liu X-Patchwork-Id: 354837 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1A4DD140091 for ; Mon, 2 Jun 2014 21:32:18 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754059AbaFBLcR (ORCPT ); Mon, 2 Jun 2014 07:32:17 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:63907 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752784AbaFBLcQ (ORCPT ); Mon, 2 Jun 2014 07:32:16 -0400 Received: by mail-pa0-f46.google.com with SMTP id hz1so1814848pad.19 for ; Mon, 02 Jun 2014 04:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=hVhDHEhSLPw0qtsoNgprlcAjqvawS7nkTlwo4DLyZYU=; b=Zg0tLD7bdbteP5G+8gNSXAFqUGkaON9C48v+B8rrjHUOOQehNPuoRe+9xoDbhYBg9W knFNMWwuoSxMIEM9nlYLxTck6jelqXiDKGxToM8cAikLE+jSb84opGg3URb3yhQwrv7k SeDhPlvUmaC94VrxOzNQTMp8QvWr04gjpsP1gS68DFsI1invGIAazOdGluXYDsdh3rmE 4HpfpMMiMJkUG6fxdFK8Q5QTyt24bkgZAcfdBo/EXI97oFf4GKKNtFAALwhI0f6vADOX xExOtue8Cs7b8TJelDyXaM90QXmevRSGQ7EO4t5vudXD071W+dLLUhjYKKpJ/s6BoPz7 7GYQ== X-Received: by 10.69.31.65 with SMTP id kk1mr37431620pbd.126.1401708735871; Mon, 02 Jun 2014 04:32:15 -0700 (PDT) Received: from alpha.hz.ali.com ([182.92.253.16]) by mx.google.com with ESMTPSA id wk4sm5805503pab.5.2014.06.02.04.32.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Jun 2014 04:32:15 -0700 (PDT) From: Zheng Liu X-Google-Original-From: Zheng Liu To: linux-ext4@vger.kernel.org Cc: Ian Nartowicz , Tao Ma , "Darrick J. Wong" , Andreas Dilger , "Theodore Ts'o" , Zheng Liu Subject: [PATCH] ext4: handle symlink properly with inline_data Date: Mon, 2 Jun 2014 19:39:28 +0800 Message-Id: <1401709168-27403-1-git-send-email-wenqing.lz@taobao.com> X-Mailer: git-send-email 1.7.9.7 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Zheng Liu 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" Reported-by: Ian Nartowicz Cc: Ian Nartowicz Cc: Tao Ma Cc: "Darrick J. Wong" Cc: Andreas Dilger Cc: "Theodore Ts'o" Signed-off-by: Zheng Liu --- fs/ext4/inode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 55f999a..bc5e4c1 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -148,6 +148,9 @@ static int ext4_inode_is_fast_symlink(struct inode *inode) int ea_blocks = EXT4_I(inode)->i_file_acl ? EXT4_CLUSTER_SIZE(inode->i_sb) >> 9 : 0; + if (ext4_has_inline_data(inode)) + return 0; + return (S_ISLNK(inode->i_mode) && inode->i_blocks - ea_blocks == 0); }