From patchwork Thu Jun 27 03:28:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shen Canquan X-Patchwork-Id: 2789501 Return-Path: X-Original-To: patchwork-ocfs2-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4731AC0AB1 for ; Thu, 27 Jun 2013 03:30:44 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 399AE201F0 for ; Thu, 27 Jun 2013 03:30:43 +0000 (UTC) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4BB26201EE for ; Thu, 27 Jun 2013 03:30:42 +0000 (UTC) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5R3NlDD022258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 03:23:48 GMT Received: from oss.oracle.com (oss-external.oracle.com [137.254.96.51]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5R3U4JS025554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 03:30:04 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1Us2uK-0005U5-19; Wed, 26 Jun 2013 20:30:04 -0700 Received: from ucsinet22.oracle.com ([156.151.31.94]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1Us2u2-0005TI-4H for ocfs2-devel@oss.oracle.com; Wed, 26 Jun 2013 20:29:46 -0700 Received: from userp1020.oracle.com (userp1020.oracle.com [156.151.31.79]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5R3Tjva017214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Jun 2013 03:29:45 GMT Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by userp1020.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5R3T91a019851 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 27 Jun 2013 03:29:11 GMT Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id BEL14811; Thu, 27 Jun 2013 11:29:20 +0800 (CST) Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by szxeml206-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 27 Jun 2013 11:28:36 +0800 Received: from [127.0.0.1] (10.135.66.129) by szxeml457-hub.china.huawei.com (10.82.67.200) with Microsoft SMTP Server id 14.1.323.7; Thu, 27 Jun 2013 11:28:50 +0800 Message-ID: <51CBB16F.6080906@huawei.com> Date: Thu, 27 Jun 2013 11:28:47 +0800 From: Jensen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Andrew Morton , Mark Fasheh X-Originating-IP: [10.135.66.129] X-CFilter-Loop: Reflected X-Flow-Control-Info: class=Pass-to-MM reputation=ipRisk-All ip=119.145.14.64 ct-class=R4 ct-vol1=-91 ct-vol2=6 ct-vol3=5 ct-risk=38 ct-spam1=58 ct-spam2=1 ct-bulk=87 rcpts=1 size=1614 X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.1 cv=Vv8aXYGn c=1 sm=1 tr=0 a=6YMIiCGU//PUEf62qScyBg==:117 a=6YMIiCGU//PUEf62qScyBg==:17 a=ammSLeDMHFAA:10 a=ruNcIze9tfQA:10 a=CreWmo11hPwA:10 a=O9dq5j03pVQA:10 a=8nJEP1OIZ-IA:10 a=i0EeH86SAAAA:8 a=VK--xsosqxkA:10 a=nNeHDO7Bd91snwK_J ToA:9 a=wPNLvfGTeEIA:10 a=hPjdaMEvmhQA:10 X-Sendmail-CT-Classification: not spam X-Sendmail-CT-RefID: str=0001.0A090205.51CBB1A9.001F:SCFSTAT1612107, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: "ocfs2-devel@oss.oracle.com" Subject: [Ocfs2-devel] [PATCH V3] ocfs2: llseek requires to ocfs2 inode lock for the file in SEEK_END X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP llseek requires ocfs2 inode lock for updating the file size in SEEK_END. because the file size maybe update on another node. if it not . after call llseek in SEEK_END. the position is old. this bug can be reproduce the following scenario: at first ,we dd a test fileA,the file size is 10k. on NodeA: --------- 1) open the test fileA, lseek the end of file. and print the position. 2) close the test fileA on NodeB: 1) open the test fileA, append the 5k data to test FileA. 2) lseek the end of file. and print the position. 3) close file. at first we run the test program1 on NodeA , the result is 10k. and then run the test program2 on NodeB, the result is 15k. at last, we run the test program1 on NodeA again, the result is 10k. after apply this patch. the three step result is 15k. Signed-off-by: Jensen --- fs/ocfs2/file.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index ff54014..6ef4f2e 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -2626,7 +2626,16 @@ static loff_t ocfs2_file_llseek(struct file *file, loff_t offset, int whence) case SEEK_SET: break; case SEEK_END: - offset += inode->i_size; + /* SEEK_END requires the OCFS2 inode lock for the file + * because it references the file's size. + */ + ret = ocfs2_inode_lock(inode, NULL, 0); + if (ret < 0) { + mlog_errno(ret); + goto out; + } + offset += i_size_read(inode); + ocfs2_inode_unlock(inode, 0); break; case SEEK_CUR: if (offset == 0) {