From patchwork Wed Feb 19 13:11:02 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 3680911 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 EE10A9F35F for ; Wed, 19 Feb 2014 13:12:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 05106201CD for ; Wed, 19 Feb 2014 13:12:02 +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 005662016C for ; Wed, 19 Feb 2014 13:12:00 +0000 (UTC) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1JDBkxB031832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Feb 2014 13:11:46 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 s1JDBgA0009982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 13:11:44 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1WG6wA-0007Nr-10; Wed, 19 Feb 2014 05:11:42 -0800 Received: from acsinet21.oracle.com ([141.146.126.237]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1WG6vq-0007NO-CN for ocfs2-devel@oss.oracle.com; Wed, 19 Feb 2014 05:11:22 -0800 Received: from aserp1020.oracle.com (aserp1020.oracle.com [141.146.126.67]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1JDBLT6009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Feb 2014 13:11:21 GMT Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by aserp1020.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1JDBJZN000793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Feb 2014 13:11:20 GMT Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0416AAC95; Wed, 19 Feb 2014 13:11:19 +0000 (UTC) Received: by quack.suse.cz (Postfix, from userid 1000) id 9DBBE80D20; Wed, 19 Feb 2014 14:11:16 +0100 (CET) From: Jan Kara To: Joel Becker Date: Wed, 19 Feb 2014 14:11:02 +0100 Message-Id: <1392815462-9522-1-git-send-email-jack@suse.cz> X-Mailer: git-send-email 1.8.1.4 X-Flow-Control-Info: class=Pass-to-MM reputation=ipRisk-All ip=195.135.220.15 ct-class=T2 ct-vol1=0 ct-vol2=4 ct-vol3=3 ct-risk=53 ct-spam1=65 ct-spam2=44 ct-bulk=36 rcpts=1 size=1788 X-SPF-Info: NONE::cantor2.suse.de X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.1 cv=LvSrlBtc c=1 sm=1 tr=0 a=uEuDQZVrWKuLCe7byFjfVg==:117 a=uEuDQZVrWKuLCe7byFjfVg==:17 a=Rt7G4jiTwnYA:10 a=OfuDiCMNFBUA:10 a=PZA5uJTw0oG88kkFaTkA:9 a=0kPLrQdw3YYA:10 X-Sendmail-CT-Classification: not spam X-Sendmail-CT-RefID: str=0001.0A090203.5304AD79.0101:SCFSTAT18040053, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: Mark Fasheh , Jan Kara , ocfs2-devel@oss.oracle.com Subject: [Ocfs2-devel] [PATCH] ocfs2: Fix quota file corruption 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: , MIME-Version: 1.0 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=-4.8 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 Global quota files are accessed from different nodes and reading and writing of these files happens via block device page cache. Thus even though the access between nodes is properly serialized by quota file's inode lock we cannot rely on consistency of block device page cache between nodes. Indeed currently it is possible to corrupt quota files by creating and deleting quota structures from two nodes in parallel. Fix the problem by using OCFS2_BH_IGNORE_CACHE mount option when reading from quota file. CC: Goldwyn Rodrigues CC: Mark Fasheh Signed-off-by: Jan Kara --- fs/ocfs2/quota_global.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) This is a quick fix for quota file corruption I have found during my testing (to be used for 3.13 and -stable kernels). Longer term we likely want to do something more clever. Ideally we would invalidate relevant blocks from buffer cache when node releases quota file's inode lock (similarly as we do it for page cache). I wanted to do it similarly as for e.g. extent tree blocks but I failed to find how consistency of those between nodes is achieved. Can anyone point me in the right direction? Thanks in advance. diff --git a/fs/ocfs2/quota_global.c b/fs/ocfs2/quota_global.c index aaa50611ec66..f1f0cca15db6 100644 --- a/fs/ocfs2/quota_global.c +++ b/fs/ocfs2/quota_global.c @@ -151,7 +151,8 @@ int ocfs2_read_quota_phys_block(struct inode *inode, u64 p_block, int rc; *bhp = NULL; - rc = ocfs2_read_blocks(INODE_CACHE(inode), p_block, 1, bhp, 0, + rc = ocfs2_read_blocks(INODE_CACHE(inode), p_block, 1, bhp, + OCFS2_BH_IGNORE_CACHE, ocfs2_validate_quota_block); if (rc) mlog_errno(rc);