From patchwork Sat Apr 26 00:35:31 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 4067081 Return-Path: X-Original-To: patchwork-linux-btrfs@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 9A45CBFF02 for ; Fri, 25 Apr 2014 23:35:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A216120381 for ; Fri, 25 Apr 2014 23:35:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D739E2037F for ; Fri, 25 Apr 2014 23:35:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752006AbaDYXfo (ORCPT ); Fri, 25 Apr 2014 19:35:44 -0400 Received: from mail-we0-f170.google.com ([74.125.82.170]:50255 "EHLO mail-we0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751321AbaDYXfm (ORCPT ); Fri, 25 Apr 2014 19:35:42 -0400 Received: by mail-we0-f170.google.com with SMTP id w61so4284504wes.29 for ; Fri, 25 Apr 2014 16:35:41 -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=VdhR9PewM4VpclOj7TK8DI31PrO4/jdpQyRGBE5oAbc=; b=ogXftLPlQY01GIQf0dSBuI0ffIGkz1gwFoCyRaBcdj+kphiL3sAaRPhtdAE72+W3p+ sH7pQeC6U1MG/3xC9jLmXw98yjx70Mkx2WHzPtkYlM6L+nYh24+A2DdgteZh58o4K0ch WeDkZU6aUd05Pj18c7b/4m5fnemxW5/UkV7xMEt5uLDj+4fzrjctGkZA+h9v76zYondG mWPwhNle2tgBEH71BGt+1zINGjGkv5P3qaxRcBaVmtHgkUWnnjCBSE1ifxAwrBWU1OIL YSkFsQx0PGy8/qY+r/P+KlfySiy46BQiqeRiMizhrQYA/ZsUDkxpt/rsY/AomHhrud4I EyEA== X-Received: by 10.194.60.146 with SMTP id h18mr8876888wjr.26.1398468941707; Fri, 25 Apr 2014 16:35:41 -0700 (PDT) Received: from debian-vm3.lan (bl10-196-46.dsl.telepac.pt. [85.243.196.46]) by mx.google.com with ESMTPSA id j3sm13334913wjw.38.2014.04.25.16.35.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Apr 2014 16:35:40 -0700 (PDT) From: Filipe David Borba Manana To: linux-btrfs@vger.kernel.org Cc: clm@fb.com, Filipe David Borba Manana Subject: [PATCH] Btrfs: read inode size after acquiring the mutex when punching a hole Date: Sat, 26 Apr 2014 01:35:31 +0100 Message-Id: <1398472531-27343-1-git-send-email-fdmanana@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham 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 In a previous change, commit 12870f1c9b2de7d475d22e73fd7db1b418599725, I accidentally moved the roundup of inode->i_size to outside of the critical section delimited by the inode mutex, which is not atomic and not correct since the size can be changed by other task before we acquire the mutex. Therefore fix it. Signed-off-by: Filipe David Borba Manana --- fs/btrfs/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 23f6a9d..efaad37 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2192,13 +2192,14 @@ static int btrfs_punch_hole(struct inode *inode, loff_t offset, loff_t len) bool same_page = ((offset >> PAGE_CACHE_SHIFT) == ((offset + len - 1) >> PAGE_CACHE_SHIFT)); bool no_holes = btrfs_fs_incompat(root->fs_info, NO_HOLES); - u64 ino_size = round_up(inode->i_size, PAGE_CACHE_SIZE); + u64 ino_size; ret = btrfs_wait_ordered_range(inode, offset, len); if (ret) return ret; mutex_lock(&inode->i_mutex); + ino_size = round_up(inode->i_size, PAGE_CACHE_SIZE); /* * We needn't truncate any page which is beyond the end of the file * because we are sure there is no data there.