From patchwork Thu Dec 1 10:18:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eryu Guan X-Patchwork-Id: 9486573 X-Mozilla-Keys: nonjunk Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sandeen.net X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-HP: BAYES_00=-1.9,HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5,RP_MATCHES_RCVD=-0.1 X-Original-To: sandeen@sandeen.net Delivered-To: sandeen@sandeen.net Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by sandeen.net (Postfix) with ESMTP id D9A7451E33A for ; Thu, 1 Dec 2016 04:19:57 -0600 (CST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751423AbcLAKUs (ORCPT ); Thu, 1 Dec 2016 05:20:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51932 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751566AbcLAKUs (ORCPT ); Thu, 1 Dec 2016 05:20:48 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EA9096A6D0 for ; Thu, 1 Dec 2016 10:20:38 +0000 (UTC) Received: from localhost (dhcp-13-209.nay.redhat.com [10.66.13.209]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB1AKb03001430; Thu, 1 Dec 2016 05:20:38 -0500 From: Eryu Guan To: linux-xfs@vger.kernel.org Cc: Eryu Guan Subject: [PATCH] xfs: use xfs_vn_setattr_size to check on new size Date: Thu, 1 Dec 2016 18:18:00 +0800 Message-Id: <20161201101800.11419-1-eguan@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 01 Dec 2016 10:20:38 +0000 (UTC) Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org Commit 6552321831dc ("xfs: remove i_iolock and use i_rwsem in the VFS inode instead") introduced a regression that truncate(2) doesn't check on new size, so it succeeds even if the new size exceeds the current resource limit. Because xfs_setattr_size() was used instead of xfs_vn_setattr_size(), and the latter calls xfs_vn_change_ok() first to do sanity check on permission and new size. This is found by truncate03 test from ltp, and the following is a simplified reproducer: #!/bin/bash dev=/dev/sda5 mnt=/mnt/xfs mkfs -t xfs -f $dev mount $dev $mnt # set max file size to 16k ulimit -f 16 truncate -s $((16 * 1024 + 1)) /mnt/xfs/testfile [ $? -eq 0 ] && echo "FAIL: truncate exceeded max file size" ulimit -f unlimited umount $mnt Signed-off-by: Eryu Guan --- fs/xfs/xfs_iops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index c962999..b930be0 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -988,7 +988,7 @@ xfs_vn_setattr( return error; xfs_ilock(ip, XFS_MMAPLOCK_EXCL); - error = xfs_setattr_size(ip, iattr); + error = xfs_vn_setattr_size(dentry, iattr); xfs_iunlock(ip, XFS_MMAPLOCK_EXCL); } else { error = xfs_vn_setattr_nonsize(dentry, iattr);