From patchwork Mon Jun 17 14:48:54 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shen Canquan X-Patchwork-Id: 2733651 Return-Path: X-Original-To: patchwork-ocfs2-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C027D9F39E for ; Mon, 17 Jun 2013 14:50:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2B129202AF for ; Mon, 17 Jun 2013 14:50:30 +0000 (UTC) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B8509202AC for ; Mon, 17 Jun 2013 14:50:28 +0000 (UTC) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5HEnr1p025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 14:49:53 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 r5HEnqGF025989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 14:49:52 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1Uoaki-0001i0-Co; Mon, 17 Jun 2013 07:49:52 -0700 Received: from ucsinet21.oracle.com ([156.151.31.93]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1Uoakb-0001hc-Bn for ocfs2-devel@oss.oracle.com; Mon, 17 Jun 2013 07:49:45 -0700 Received: from aserp1030.oracle.com (aserp1030.oracle.com [141.146.126.68]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5HEni37002835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Jun 2013 14:49:44 GMT Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by aserp1030.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5HEnfK3023007 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=FAIL) for ; Mon, 17 Jun 2013 14:49:43 GMT Received: from 172.24.2.119 (EHLO szxeml209-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id BDW37531; Mon, 17 Jun 2013 22:49:08 +0800 (CST) Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 22:49:07 +0800 Received: from [127.0.0.1] (10.135.66.129) by SZXEML458-HUB.china.huawei.com (10.82.67.201) with Microsoft SMTP Server id 14.1.323.7; Mon, 17 Jun 2013 22:49:02 +0800 Message-ID: <51BF21D6.9080008@huawei.com> Date: Mon, 17 Jun 2013 22:48:54 +0800 From: shencanquan 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=86 rcpts=1 size=1042 X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.1 cv=P+ID2Ewu c=1 sm=1 tr=0 a=6YMIiCGU//PUEf62qScyBg==:117 a=6YMIiCGU//PUEf62qScyBg==:17 a=ammSLeDMHFAA:10 a=ruNcIze9tfQA:10 a=yDbO3D1ezu4A:10 a=O9dq5j03pVQA:10 a=8nJEP1OIZ-IA:10 a=i0EeH86SAAAA:8 a=Jnuh05oZTIUA:10 a=u1O40XC-KYCc0oEFR 4EA:9 a=wPNLvfGTeEIA:10 a=hPjdaMEvmhQA:10 X-Sendmail-CT-Classification: not spam X-Sendmail-CT-RefID: str=0001.0A090205.51BF2208.002E:SCFSTAT1612107, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: linux-fsdevel@vger.kernel.org, "ocfs2-devel@oss.oracle.com" Subject: [Ocfs2-devel] [PATCH] ocfs2: llseek need to inode cluster lock and unlock for update the inode size 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.3 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 We found that llseek has a bug when in SEEK_END. it need to add the inode lock and unlock. This bug can be reproduce the following scenario: On one nodeA, open the file and then write some data to file and close the file . On another nodeB , open the file and llseek the end of file . the position of file is old. Signed-off-by: jensen --- file.c | 7 +++++++ 1 file changed, 7 insertions(+) case SEEK_CUR: diff --git a/file.c b/file.c index ff54014..4ee7c80 100644 --- a/file.c +++ b/file.c @@ -2626,6 +2626,13 @@ static loff_t ocfs2_file_llseek(struct file *file, loff_t offset, int whence) case SEEK_SET: break; case SEEK_END: + /*need to inode lock and unlock for update the inode size.*/ + ret = ocfs2_inode_lock(inode, NULL, 0); + if (ret < 0) { + mlog_errno(ret); + goto out; + } + ocfs2_inode_unlock(inode, 0); offset += inode->i_size; break;