From patchwork Thu Jul 18 23:06:09 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049637 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 828C514F6 for ; Thu, 18 Jul 2019 23:06:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6F57928894 for ; Thu, 18 Jul 2019 23:06:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 62653288BB; Thu, 18 Jul 2019 23:06:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C9ACA28894 for ; Thu, 18 Jul 2019 23:06:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391451AbfGRXGW (ORCPT ); Thu, 18 Jul 2019 19:06:22 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:41750 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXGW (ORCPT ); Thu, 18 Jul 2019 19:06:22 -0400 Received: by mail-pg1-f195.google.com with SMTP id x15so3211526pgg.8; Thu, 18 Jul 2019 16:06:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RrGwnDIom4ZFYE5fokLWAofw8P39aInJ+75MpS6dYUY=; b=P1sr1lvdOjP9q4y5nMv2L/n34MSNMq4WYk7sYEzrb/Wza65cZ99SdQEFOQ+xfky0uh 0rTxEMKWrUGQ/yxiJ9hDFwKP1mVxaUsuc3B6hjoUJV7u4w6MsWvSHZh3yCtkWNKr31E6 dhERoUFLh0AG2JiTlU2vq8EhTWe0G1sh2YhnbGZAdVyhnNgYUpBToPkxbAbEYeMO+M9t rMiMglsCECyt8nvwxZEhY5U0LBQeAqLom6LRImEh4RCAOnpxa2jZA/bayM+DACv1JSYe ZIZKMt0JC9Nh3bhpgRoQvUxLP+EFk2UNwb61clocXSeF+SPdEoV1GJr55NB57NMqKC6V jmmQ== X-Gm-Message-State: APjAAAX6RfAhIOuVLXurID4ZVVwEn6uxhQrQ7T3RLa9pevf0H8JIu8E3 d9SKovItDN9hkMhB1e/cA7k= X-Google-Smtp-Source: APXvYqwG9Ca4dM15fm3yeZQi2YPcXMRaY1uZ3V1bOUeUc6WvLHjWuQD1LJWrBRntYHJ3E06dNrpjeA== X-Received: by 2002:a63:494d:: with SMTP id y13mr51271481pgk.109.1563491181078; Thu, 18 Jul 2019 16:06:21 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id w2sm22802922pgc.32.2019.07.18.16.06.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:19 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 1F84340004; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Darrick J. Wong" , Dave Chinner , Christoph Hellwig , Dave Chinner , Luis Chamberlain Subject: [PATCH 1/9] xfs: fix pagecache truncation prior to reflink Date: Thu, 18 Jul 2019 23:06:09 +0000 Message-Id: <20190718230617.7439-2-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Darrick J. Wong" commit 4918ef4ea008cd2ff47eb852894e3f9b9047f4f3 upstream. Prior to remapping blocks, it is necessary to remove pages from the destination file's page cache. Unfortunately, the truncation is not aggressive enough -- if page size > block size, we'll end up zeroing subpage blocks instead of removing them. So, round the start offset down and the end offset up to page boundaries. We already wrote all the dirty data so the larger range shouldn't be a problem. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_reflink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 7088f44c0c59..38ea08a3dd1d 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -1369,8 +1369,9 @@ xfs_reflink_remap_prep( goto out_unlock; /* Zap any page cache for the destination file's range. */ - truncate_inode_pages_range(&inode_out->i_data, pos_out, - PAGE_ALIGN(pos_out + *len) - 1); + truncate_inode_pages_range(&inode_out->i_data, + round_down(pos_out, PAGE_SIZE), + round_up(pos_out + *len, PAGE_SIZE) - 1); /* If we're altering the file contents... */ if (!is_dedupe) { From patchwork Thu Jul 18 23:06:10 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049645 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4F37A14F6 for ; Thu, 18 Jul 2019 23:06:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3E82228894 for ; Thu, 18 Jul 2019 23:06:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 326EB288BB; Thu, 18 Jul 2019 23:06:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B684828894 for ; Thu, 18 Jul 2019 23:06:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391651AbfGRXG1 (ORCPT ); Thu, 18 Jul 2019 19:06:27 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:45893 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXG1 (ORCPT ); Thu, 18 Jul 2019 19:06:27 -0400 Received: by mail-pl1-f196.google.com with SMTP id y8so14621011plr.12; Thu, 18 Jul 2019 16:06:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jI9RSC+Ajgq24i5IppYuO6Qi2kQaROT+33IGQt5erpE=; b=J+yT08ZfXreqX9QGx2EWfiNYtF9m5Ty4hb/7tvPpR95BRRju6Q1DLbdlax4+sCqXbe 5/WaTXJJuIrT8pQik8lJTydyjcYPNa2sT/gbVudYAfzOpbRi6URdvFUzTtk6Kk0gSERH 7MNjr0uz+SKi3ilwwxKJqxCphjdO4C1Y7vdZBIQberojDLxlqEToUi2cjYqyw/6yL02L 0IeSiTsDRFt8Vr0+tCkfVIaav+JUX2ZvgQnRYNQ95PWXUwotrrVne7EY7PNOXWDDQOXj hCet+KMvUg7NoBkpIlcVndYakkG2NAGM8zvKUbX2/dAWBt4wL0hy+g6AJQoyPiGyXXJo p8kQ== X-Gm-Message-State: APjAAAX5ImXASEbBvNzLP7I0TvX9Ypv1oQ6FX/T2y3wJiP54bElNSRVn OgDsuu2piq5co26tiD8iOS0= X-Google-Smtp-Source: APXvYqw71sGo/ZCt33Ffm9D8/mmcZVl9xhDXLGCM5KhnphvKalhWRtwOMeaN/7286BF5PAT2fYKrxg== X-Received: by 2002:a17:902:ff05:: with SMTP id f5mr51364609plj.116.1563491185985; Thu, 18 Jul 2019 16:06:25 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id b24sm26453839pfd.98.2019.07.18.16.06.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:19 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 2981840619; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, Dave Chinner , Christoph Hellwig , "Darrick J . Wong" , Luis Chamberlain Subject: [PATCH 2/9] xfs: flush removing page cache in xfs_reflink_remap_prep Date: Thu, 18 Jul 2019 23:06:10 +0000 Message-Id: <20190718230617.7439-3-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Dave Chinner commit 2c307174ab77e34645e75e12827646e044d273c3 upstream. On a sub-page block size filesystem, fsx is failing with a data corruption after a series of operations involving copying a file with the destination offset beyond EOF of the destination of the file: 8093(157 mod 256): TRUNCATE DOWN from 0x7a120 to 0x50000 ******WWWW 8094(158 mod 256): INSERT 0x25000 thru 0x25fff (0x1000 bytes) 8095(159 mod 256): COPY 0x18000 thru 0x1afff (0x3000 bytes) to 0x2f400 8096(160 mod 256): WRITE 0x5da00 thru 0x651ff (0x7800 bytes) HOLE 8097(161 mod 256): COPY 0x2000 thru 0x5fff (0x4000 bytes) to 0x6fc00 The second copy here is beyond EOF, and it is to sub-page (4k) but block aligned (1k) offset. The clone runs the EOF zeroing, landing in a pre-existing post-eof delalloc extent. This zeroes the post-eof extents in the page cache just fine, dirtying the pages correctly. The problem is that xfs_reflink_remap_prep() now truncates the page cache over the range that it is copying it to, and rounds that down to cover the entire start page. This removes the dirty page over the delalloc extent from the page cache without having written it back. Hence later, when the page cache is flushed, the page at offset 0x6f000 has not been written back and hence exposes stale data, which fsx trips over less than 10 operations later. Fix this by changing xfs_reflink_remap_prep() to use xfs_flush_unmap_range(). Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_bmap_util.c | 2 +- fs/xfs/xfs_bmap_util.h | 2 ++ fs/xfs/xfs_reflink.c | 17 +++++++++++++---- 3 files changed, 16 insertions(+), 5 deletions(-) diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c index 211b06e4702e..41ad9eaab6ce 100644 --- a/fs/xfs/xfs_bmap_util.c +++ b/fs/xfs/xfs_bmap_util.c @@ -1080,7 +1080,7 @@ xfs_adjust_extent_unmap_boundaries( return 0; } -static int +int xfs_flush_unmap_range( struct xfs_inode *ip, xfs_off_t offset, diff --git a/fs/xfs/xfs_bmap_util.h b/fs/xfs/xfs_bmap_util.h index 87363d136bb6..9c73d012f56a 100644 --- a/fs/xfs/xfs_bmap_util.h +++ b/fs/xfs/xfs_bmap_util.h @@ -76,6 +76,8 @@ int xfs_swap_extents(struct xfs_inode *ip, struct xfs_inode *tip, xfs_daddr_t xfs_fsb_to_db(struct xfs_inode *ip, xfs_fsblock_t fsb); xfs_extnum_t xfs_bmap_count_leaves(struct xfs_ifork *ifp, xfs_filblks_t *count); +int xfs_flush_unmap_range(struct xfs_inode *ip, xfs_off_t offset, + xfs_off_t len); int xfs_bmap_count_blocks(struct xfs_trans *tp, struct xfs_inode *ip, int whichfork, xfs_extnum_t *nextents, xfs_filblks_t *count); diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 38ea08a3dd1d..f3c393f309e1 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -1368,10 +1368,19 @@ xfs_reflink_remap_prep( if (ret) goto out_unlock; - /* Zap any page cache for the destination file's range. */ - truncate_inode_pages_range(&inode_out->i_data, - round_down(pos_out, PAGE_SIZE), - round_up(pos_out + *len, PAGE_SIZE) - 1); + /* + * If pos_out > EOF, we may have dirtied blocks between EOF and + * pos_out. In that case, we need to extend the flush and unmap to cover + * from EOF to the end of the copy length. + */ + if (pos_out > XFS_ISIZE(dest)) { + loff_t flen = *len + (pos_out - XFS_ISIZE(dest)); + ret = xfs_flush_unmap_range(dest, XFS_ISIZE(dest), flen); + } else { + ret = xfs_flush_unmap_range(dest, pos_out, *len); + } + if (ret) + goto out_unlock; /* If we're altering the file contents... */ if (!is_dedupe) { From patchwork Thu Jul 18 23:06:11 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049639 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2B82717E0 for ; Thu, 18 Jul 2019 23:06:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1A21E28894 for ; Thu, 18 Jul 2019 23:06:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0E71B288BB; Thu, 18 Jul 2019 23:06:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A1DA228894 for ; Thu, 18 Jul 2019 23:06:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391534AbfGRXGX (ORCPT ); Thu, 18 Jul 2019 19:06:23 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:35141 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391508AbfGRXGX (ORCPT ); Thu, 18 Jul 2019 19:06:23 -0400 Received: by mail-pg1-f194.google.com with SMTP id s1so7247723pgr.2; Thu, 18 Jul 2019 16:06:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1uIbphx6NSKm0Sqq/tE2psnkMa07yggKxaPV7J4/nmM=; b=pZUYyVP18HN6Tp/0z3asMzgADr6p+YXin6cw6qW+CeL2PrIc0AZY4TgIGscdrbpBUD LR+uR/9EBpkUQp4spWy7keShFqz34aE7M21TYRG4ty+Y+4y837+79bDGHCftJv4yp4zU eXtYnL+pyLrk+NyBcrz23hEWbUU2r2YK1M1MEaQO8xNoWmHVRJRoMj/ZYAURnaplS00N PsL2PmiCzBuCzNvr+RdSer3vyuCldL+izxG4ASXs0OJjzA5ChVxLTj0pHR7UpTb+V15Z QFDcuEoxIvzzAsUP+2XrxGdYh4pYoEvM3EzzvTKd6fQoDHNLFthF2MikdNghX6VnwXwn 202g== X-Gm-Message-State: APjAAAU9PeF6Kp4kkGjeJyFIK65IHyfoGlYTuyszUD7PFgLmRWPoi0VO tPMkMraeMFMAum4mQg9nCrI= X-Google-Smtp-Source: APXvYqxYHxyAmehpEkgAAftAxk3dLBv09TcDURVA27vrDPIxOHqs0p6fFHw0etFZYwKw/njFe9NKWg== X-Received: by 2002:a17:90a:fa12:: with SMTP id cm18mr53756255pjb.137.1563491182300; Thu, 18 Jul 2019 16:06:22 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id n7sm34025966pff.59.2019.07.18.16.06.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:19 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 378A54075D; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Darrick J. Wong" , Christoph Hellwig , Luis Chamberlain Subject: [PATCH 3/9] xfs: don't overflow xattr listent buffer Date: Thu, 18 Jul 2019 23:06:11 +0000 Message-Id: <20190718230617.7439-4-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Darrick J. Wong" commit 3b50086f0c0d78c144d9483fa292c1509c931b70 upstream. For VFS listxattr calls, xfs_xattr_put_listent calls __xfs_xattr_put_listent twice if it sees an attribute "trusted.SGI_ACL_FILE": once for that name, and again for "system.posix_acl_access". Unfortunately, if we happen to run out of buffer space while emitting the first name, we set count to -1 (so that we can feed ERANGE to the caller). The second invocation doesn't check that the context parameters make sense and overwrites the byte before the buffer, triggering a KASAN report: ================================================================== BUG: KASAN: slab-out-of-bounds in strncpy+0xb3/0xd0 Write of size 1 at addr ffff88807fbd317f by task syz/1113 CPU: 3 PID: 1113 Comm: syz Not tainted 5.0.0-rc6-xfsx #rc6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: dump_stack+0xcc/0x180 print_address_description+0x6c/0x23c kasan_report.cold.3+0x1c/0x35 strncpy+0xb3/0xd0 __xfs_xattr_put_listent+0x1a9/0x2c0 [xfs] xfs_attr_list_int_ilocked+0x11af/0x1800 [xfs] xfs_attr_list_int+0x20c/0x2e0 [xfs] xfs_vn_listxattr+0x225/0x320 [xfs] listxattr+0x11f/0x1b0 path_listxattr+0xbd/0x130 do_syscall_64+0x139/0x560 While we're at it we add an assert to the other put_listent to avoid this sort of thing ever happening to the attrlist_by_handle code. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Suggested-by: Amir Goldstein Reviewed-by: Amir Goldstein Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_attr_list.c | 1 + fs/xfs/xfs_xattr.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c index a58034049995..3d213a7394c5 100644 --- a/fs/xfs/xfs_attr_list.c +++ b/fs/xfs/xfs_attr_list.c @@ -555,6 +555,7 @@ xfs_attr_put_listent( attrlist_ent_t *aep; int arraytop; + ASSERT(!context->seen_enough); ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c index 63ee1d5bf1d7..9a63016009a1 100644 --- a/fs/xfs/xfs_xattr.c +++ b/fs/xfs/xfs_xattr.c @@ -129,6 +129,9 @@ __xfs_xattr_put_listent( char *offset; int arraytop; + if (context->count < 0 || context->seen_enough) + return; + if (!context->alist) goto compute_size; From patchwork Thu Jul 18 23:06:12 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049641 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 82462112C for ; Thu, 18 Jul 2019 23:06:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7281F28894 for ; Thu, 18 Jul 2019 23:06:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 66C8C288BB; Thu, 18 Jul 2019 23:06:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 013C428894 for ; Thu, 18 Jul 2019 23:06:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391508AbfGRXGY (ORCPT ); Thu, 18 Jul 2019 19:06:24 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:42931 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXGY (ORCPT ); Thu, 18 Jul 2019 19:06:24 -0400 Received: by mail-pg1-f195.google.com with SMTP id t132so13544158pgb.9; Thu, 18 Jul 2019 16:06:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VJUF/5trFajgFahlUUYT8qz+0thXGl5ABcEKwOEmlRc=; b=kvVBltyLyvqA7pcScUp1FY7c8Ri4TL1PXebnPMYlgZMQft97ege4YSv7zHKBC/vMJE 1G2zZHL/jCuqphJi9/x5XdgO6Pgp+4dTDzSivzhq/xTZ9pFl81VBUzP5VDWCmrZn7kPU 2FW78dC8uCE86Con5wmIuHntC/461/boHoj6lBv82hkvt8EgwMUGNBzceOubDhggWo/Y riN7d0/u9LuPoKlYb20Oxp2Qwv6ZQK96BWtFZpQvY/3r3lLmw2SEm61PM2Jc4+GQAUNB 53dYS5M7qxi/VXcvSodHw6NTCmSkAJZbzpB1s9MEu0B/LXilUsyNWd1jg3wRQ/QZidMq VJGg== X-Gm-Message-State: APjAAAWql7v7ptLW17AlUAqU4whgRwStPMYEMqv3RTLN87gnneRMmSYO 8Adn+ggDUmgzKAnZ0xoLPhk= X-Google-Smtp-Source: APXvYqwCKFchc13XPEg14/byJx9C1ThXkfzQjYp5e0uxhbDu7fDW7JSaLYy1pMlhRaKSdG99ZVS2/A== X-Received: by 2002:a17:90a:cb18:: with SMTP id z24mr3762748pjt.108.1563491183476; Thu, 18 Jul 2019 16:06:23 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id t26sm22281932pgu.43.2019.07.18.16.06.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:19 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 44CF040906; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , Luis Chamberlain Subject: [PATCH 4/9] xfs: rename m_inotbt_nores to m_finobt_nores Date: Thu, 18 Jul 2019 23:06:12 +0000 Message-Id: <20190718230617.7439-5-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Darrick J. Wong" commit e1f6ca11381588e3ef138c10de60eeb34cb8466a upstream. Rename this flag variable to imply more strongly that it's related to the free inode btree (finobt) operation. No functional changes. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Suggested-by: Amir Goldstein Reviewed-by: Amir Goldstein Signed-off-by: Luis Chamberlain --- fs/xfs/libxfs/xfs_ag_resv.c | 2 +- fs/xfs/libxfs/xfs_ialloc_btree.c | 4 ++-- fs/xfs/xfs_inode.c | 2 +- fs/xfs/xfs_mount.h | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/xfs/libxfs/xfs_ag_resv.c b/fs/xfs/libxfs/xfs_ag_resv.c index e701ebc36c06..e2ba2a3b63b2 100644 --- a/fs/xfs/libxfs/xfs_ag_resv.c +++ b/fs/xfs/libxfs/xfs_ag_resv.c @@ -281,7 +281,7 @@ xfs_ag_resv_init( */ ask = used = 0; - mp->m_inotbt_nores = true; + mp->m_finobt_nores = true; error = xfs_refcountbt_calc_reserves(mp, tp, agno, &ask, &used); diff --git a/fs/xfs/libxfs/xfs_ialloc_btree.c b/fs/xfs/libxfs/xfs_ialloc_btree.c index 86c50208a143..adb2f6df5a11 100644 --- a/fs/xfs/libxfs/xfs_ialloc_btree.c +++ b/fs/xfs/libxfs/xfs_ialloc_btree.c @@ -124,7 +124,7 @@ xfs_finobt_alloc_block( union xfs_btree_ptr *new, int *stat) { - if (cur->bc_mp->m_inotbt_nores) + if (cur->bc_mp->m_finobt_nores) return xfs_inobt_alloc_block(cur, start, new, stat); return __xfs_inobt_alloc_block(cur, start, new, stat, XFS_AG_RESV_METADATA); @@ -157,7 +157,7 @@ xfs_finobt_free_block( struct xfs_btree_cur *cur, struct xfs_buf *bp) { - if (cur->bc_mp->m_inotbt_nores) + if (cur->bc_mp->m_finobt_nores) return xfs_inobt_free_block(cur, bp); return __xfs_inobt_free_block(cur, bp, XFS_AG_RESV_METADATA); } diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index 05db9540e459..ae07baa7bdbf 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -1754,7 +1754,7 @@ xfs_inactive_ifree( * now remains allocated and sits on the unlinked list until the fs is * repaired. */ - if (unlikely(mp->m_inotbt_nores)) { + if (unlikely(mp->m_finobt_nores)) { error = xfs_trans_alloc(mp, &M_RES(mp)->tr_ifree, XFS_IFREE_SPACE_RES(mp), 0, XFS_TRANS_RESERVE, &tp); diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 7964513c3128..7e0bf952e087 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -127,7 +127,7 @@ typedef struct xfs_mount { struct mutex m_growlock; /* growfs mutex */ int m_fixedfsid[2]; /* unchanged for life of FS */ uint64_t m_flags; /* global mount flags */ - bool m_inotbt_nores; /* no per-AG finobt resv. */ + bool m_finobt_nores; /* no per-AG finobt resv. */ int m_ialloc_inos; /* inodes in inode allocation */ int m_ialloc_blks; /* blocks in inode allocation */ int m_ialloc_min_blks;/* min blocks in sparse inode From patchwork Thu Jul 18 23:06:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049651 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C6A3714F6 for ; Thu, 18 Jul 2019 23:06:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B1C8428894 for ; Thu, 18 Jul 2019 23:06:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A2BC9288BB; Thu, 18 Jul 2019 23:06:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3291328894 for ; Thu, 18 Jul 2019 23:06:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391700AbfGRXGa (ORCPT ); Thu, 18 Jul 2019 19:06:30 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:37821 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXGa (ORCPT ); Thu, 18 Jul 2019 19:06:30 -0400 Received: by mail-pg1-f195.google.com with SMTP id i70so2810920pgd.4; Thu, 18 Jul 2019 16:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vmLjoAykF7SC/W4iSm7Wt7PkUxoMMGGLnWy2r5LRqEE=; b=YULNQLZyQA2C4oymezVOwMbfu8JcqUusiR93XA1nh2cUAl5MumaFhCNPGC253gzPsL jbEC5O4fkCQyfAlFlKvE40aAgtD09manJFPKjvTBJhxDKN6bsxeKByhZCDkLRf6wcx2h kEyCd6jE93T3sa4Nn31gJdMIJI561OS8wKY0hX6KQIQPS8UxV4gQCQ+37VQjgjFntzqI QRX1pmBxb9qC5sKjJlmwG6MrnS7JVCGJ5x0pd1hcwdQplpJ8eAW7KP+4Bfvgdw5uF8O/ no+9MEHNpr3uqzJPOrvhexrjlAC61F8u41OTWjG5SzLh9DYGwG5o3BMQxooYZWzJ0Gvl 6y3w== X-Gm-Message-State: APjAAAVDfwEL2RAIbkI+9ra9Fa9t8VaRYURlyWeieB6VR8M6hY6/Bss9 l13YYK7tG1U5HRRZz22inr8= X-Google-Smtp-Source: APXvYqxHvghnpumeN8uqUXgjgbta+fe/HsXKb0cb65cRzkBkkvsi5UeEkRyNBtbPPPnxEV+jri9hsw== X-Received: by 2002:a17:90a:cf8f:: with SMTP id i15mr4025698pju.110.1563491189702; Thu, 18 Jul 2019 16:06:29 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id h70sm22615444pgc.36.2019.07.18.16.06.21 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:26 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 5327E41399; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Darrick J. Wong" , Christoph Hellwig , Luis Chamberlain Subject: [PATCH 5/9] xfs: don't ever put nlink > 0 inodes on the unlinked list Date: Thu, 18 Jul 2019 23:06:13 +0000 Message-Id: <20190718230617.7439-6-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Darrick J. Wong" commit c4a6bf7f6cc7eb4cce120fb7eb1e1fb8b2d65e09 upstream. When XFS creates an O_TMPFILE file, the inode is created with nlink = 1, put on the unlinked list, and then the VFS sets nlink = 0 in d_tmpfile. If we crash before anything logs the inode (it's dirty incore but the vfs doesn't tell us it's dirty so we never log that change), the iunlink processing part of recovery will then explode with a pile of: XFS: Assertion failed: VFS_I(ip)->i_nlink == 0, file: fs/xfs/xfs_log_recover.c, line: 5072 Worse yet, since nlink is nonzero, the inodes also don't get cleaned up and they just leak until the next xfs_repair run. Therefore, change xfs_iunlink to require that inodes being put on the unlinked list have nlink == 0, change the tmpfile callers to instantiate nodes that way, and set the nlink to 1 just prior to calling d_tmpfile. Fix the comment for xfs_iunlink while we're at it. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Suggested-by: Amir Goldstein Reviewed-by: Amir Goldstein Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_inode.c | 16 ++++++---------- fs/xfs/xfs_iops.c | 13 +++++++++++-- 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index ae07baa7bdbf..5ed84d6c7059 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -1332,7 +1332,7 @@ xfs_create_tmpfile( if (error) goto out_trans_cancel; - error = xfs_dir_ialloc(&tp, dp, mode, 1, 0, prid, &ip); + error = xfs_dir_ialloc(&tp, dp, mode, 0, 0, prid, &ip); if (error) goto out_trans_cancel; @@ -1907,11 +1907,8 @@ xfs_inactive( } /* - * This is called when the inode's link count goes to 0 or we are creating a - * tmpfile via O_TMPFILE. In the case of a tmpfile, @ignore_linkcount will be - * set to true as the link count is dropped to zero by the VFS after we've - * created the file successfully, so we have to add it to the unlinked list - * while the link count is non-zero. + * This is called when the inode's link count has gone to 0 or we are creating + * a tmpfile via O_TMPFILE. The inode @ip must have nlink == 0. * * We place the on-disk inode on a list in the AGI. It will be pulled from this * list when the inode is freed. @@ -1931,6 +1928,7 @@ xfs_iunlink( int offset; int error; + ASSERT(VFS_I(ip)->i_nlink == 0); ASSERT(VFS_I(ip)->i_mode != 0); /* @@ -2837,11 +2835,9 @@ xfs_rename_alloc_whiteout( /* * Prepare the tmpfile inode as if it were created through the VFS. - * Otherwise, the link increment paths will complain about nlink 0->1. - * Drop the link count as done by d_tmpfile(), complete the inode setup - * and flag it as linkable. + * Complete the inode setup and flag it as linkable. nlink is already + * zero, so we can skip the drop_nlink. */ - drop_nlink(VFS_I(tmpfile)); xfs_setup_iops(tmpfile); xfs_finish_inode_setup(tmpfile); VFS_I(tmpfile)->i_state |= I_LINKABLE; diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index f48ffd7a8d3e..1efef69a7f1c 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -191,9 +191,18 @@ xfs_generic_create( xfs_setup_iops(ip); - if (tmpfile) + if (tmpfile) { + /* + * The VFS requires that any inode fed to d_tmpfile must have + * nlink == 1 so that it can decrement the nlink in d_tmpfile. + * However, we created the temp file with nlink == 0 because + * we're not allowed to put an inode with nlink > 0 on the + * unlinked list. Therefore we have to set nlink to 1 so that + * d_tmpfile can immediately set it back to zero. + */ + set_nlink(inode, 1); d_tmpfile(dentry, inode); - else + } else d_instantiate(dentry, inode); xfs_finish_inode_setup(ip); From patchwork Thu Jul 18 23:06:14 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049649 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9A369112C for ; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8A55D28894 for ; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7E94E288BB; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1FCC0288B2 for ; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391695AbfGRXG3 (ORCPT ); Thu, 18 Jul 2019 19:06:29 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:44852 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXG3 (ORCPT ); Thu, 18 Jul 2019 19:06:29 -0400 Received: by mail-pf1-f196.google.com with SMTP id t16so13266972pfe.11; Thu, 18 Jul 2019 16:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=XOpbXKQjFIWxL9L7MymjemNedb65xZQkcaFvd4hXAD4=; b=D5BkP9GJGEhWTkiLBcz4YRNjYeOoS8EHN4F78itoHEpMDui8SdPKBHucIPJMIJ7sgu P8uLHG23JSmSpT55yrML6/Caci7YGAciVMu35heZ1/TBQgBGHwcVSi60Mad+XpG8Af5t pb3M8JQ42X4v0WYCe7s50nVoVX/tKrCopfcv6TGMK9d3Z6NKdjRUvXn/YQZQCMnfNrNZ PQM1ruEJohrpaA3gi4loPRejw8KFfboJs3nyGH7M38jkt++SHRdnG/yeK5z0Qt10GMJV uObJluEsyurRrWULU8TfgEAsEcYqF3KtOJku3fCTLrN/LaiVxyqvMusyVXSvtYd51qDg Q+hg== X-Gm-Message-State: APjAAAW1OvEtL2595NCMX3Ae0PGozCiIyGHv9tDq71pQobGP2B0rCjIx eU5OYYpahx7b9o0ngL47OI8= X-Google-Smtp-Source: APXvYqxipZjOJXFzwMfSCc16MjWFaYbB3RSqAYWWKlqnFRWq6N+USOvW/7fiSSqm6lV0exRWJaD3Jg== X-Received: by 2002:a17:90a:7d09:: with SMTP id g9mr52753680pjl.38.1563491188441; Thu, 18 Jul 2019 16:06:28 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id v3sm26916513pfm.188.2019.07.18.16.06.21 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:26 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 6160D413C3; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , Luis Chamberlain Subject: [PATCH 6/9] xfs: reserve blocks for ifree transaction during log recovery Date: Thu, 18 Jul 2019 23:06:14 +0000 Message-Id: <20190718230617.7439-7-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Darrick J. Wong" commit 15a268d9f263ed3a0601a1296568241a5a3da7aa upstream. Log recovery frees all the inodes stored in the unlinked list, which can cause expansion of the free inode btree. The ifree code skips block reservations if it thinks there's a per-AG space reservation, but we don't set up the reservation until after log recovery, which means that a finobt expansion blows up in xfs_trans_mod_sb when we exceed the transaction's block reservation. To fix this, we set the "no finobt reservation" flag to true when we create the xfs_mount and only set it to false if we confirm that every AG had enough free space to put aside for the finobt. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Suggested-by: Amir Goldstein Reviewed-by: Amir Goldstein Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_fsops.c | 1 + fs/xfs/xfs_super.c | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index 7c00b8bedfe3..09fd602507ef 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -534,6 +534,7 @@ xfs_fs_reserve_ag_blocks( int error = 0; int err2; + mp->m_finobt_nores = false; for (agno = 0; agno < mp->m_sb.sb_agcount; agno++) { pag = xfs_perag_get(mp, agno); err2 = xfs_ag_resv_init(pag, NULL); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 207ee302b1bb..dce8114e3198 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1561,6 +1561,13 @@ xfs_mount_alloc( INIT_DELAYED_WORK(&mp->m_eofblocks_work, xfs_eofblocks_worker); INIT_DELAYED_WORK(&mp->m_cowblocks_work, xfs_cowblocks_worker); mp->m_kobj.kobject.kset = xfs_kset; + /* + * We don't create the finobt per-ag space reservation until after log + * recovery, so we must set this to true so that an ifree transaction + * started during log recovery will not depend on space reservations + * for finobt expansion. + */ + mp->m_finobt_nores = true; return mp; } From patchwork Thu Jul 18 23:06:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049647 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6B09C14F6 for ; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5A3C028894 for ; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4E486288C5; Thu, 18 Jul 2019 23:06:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3F45B28894 for ; Thu, 18 Jul 2019 23:06:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391675AbfGRXG2 (ORCPT ); Thu, 18 Jul 2019 19:06:28 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:41336 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXG2 (ORCPT ); Thu, 18 Jul 2019 19:06:28 -0400 Received: by mail-pf1-f194.google.com with SMTP id m30so13291093pff.8; Thu, 18 Jul 2019 16:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dbKBgzrzQrC5cGlbyCVNUXmHFj744pksl4qhcQY0yIo=; b=LVdxQBrWiUUKIkvtNCCDAwHEBm+L8Jehw6N+HQ71qToK0IFLNnm3rPo4mpPZ/FA7Ue P142/onXrnlEtaEntI2qNaCIpmOaviXShUR1NNP7nqchK9RPI3RSoB1AxDkkSejhQnC7 vVZkDxDf+2GrF88/7CJThzEKfYZGIA0HNw9oDRwxj4hWi9l76zzXHbnbTrN/1mi//no9 VmIvkuvqfuUc6TF/qyB5x/9uUt1rdAbgoi/qxVnbCBWkQAOE9WmaoOJ8LT3I+bzX8V// rsC8XO64oSkT4fWKZ5qh3dnOEOF6NJW6N9nagWm4Np1kB3+t7pf4DQF19CYfAayDku08 oa3w== X-Gm-Message-State: APjAAAWcDatpQjNHR+E+sMTvFXrlkeR98hLfuJuusxrMKf5HpOaPWm5B KuPJDrMcGgeKV3N4gz1B1Og= X-Google-Smtp-Source: APXvYqxdBXs8p5rBq6FmFrjUwDTLMIS99dIbZe96dqCIwIuJnBMkGcJnWTSNI1knQV1bD6q9Ocsu9g== X-Received: by 2002:a17:90a:f498:: with SMTP id bx24mr54672904pjb.91.1563491187667; Thu, 18 Jul 2019 16:06:27 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id i15sm31178948pfd.160.2019.07.18.16.06.22 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:26 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 68A37413E9; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Luis R. Rodriguez" , "Darrick J . Wong" Subject: [PATCH 7/9] xfs: fix reporting supported extra file attributes for statx() Date: Thu, 18 Jul 2019 23:06:15 +0000 Message-Id: <20190718230617.7439-8-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Luis R. Rodriguez" commit 1b9598c8fb9965fff901c4caa21fed9644c34df3 upstream. statx(2) notes that any attribute that is not indicated as supported by stx_attributes_mask has no usable value. Commit 5f955f26f3d42d ("xfs: report crtime and attribute flags to statx") added support for informing userspace of extra file attributes but forgot to list these flags as supported making reporting them rather useless for the pedantic userspace author. $ git describe --contains 5f955f26f3d42d04aba65590a32eb70eedb7f37d v4.11-rc6~5^2^2~2 Fixes: 5f955f26f3d42d ("xfs: report crtime and attribute flags to statx") Signed-off-by: Luis R. Rodriguez Reviewed-by: Darrick J. Wong [darrick: add a comment reminding people to keep attributes_mask up to date] Signed-off-by: Darrick J. Wong Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_iops.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index 1efef69a7f1c..74047bd0c1ae 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -531,6 +531,10 @@ xfs_vn_getattr( } } + /* + * Note: If you add another clause to set an attribute flag, please + * update attributes_mask below. + */ if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) stat->attributes |= STATX_ATTR_IMMUTABLE; if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) @@ -538,6 +542,10 @@ xfs_vn_getattr( if (ip->i_d.di_flags & XFS_DIFLAG_NODUMP) stat->attributes |= STATX_ATTR_NODUMP; + stat->attributes_mask |= (STATX_ATTR_IMMUTABLE | + STATX_ATTR_APPEND | + STATX_ATTR_NODUMP); + switch (inode->i_mode & S_IFMT) { case S_IFBLK: case S_IFCHR: From patchwork Thu Jul 18 23:06:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049655 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5B1BF112C for ; Thu, 18 Jul 2019 23:06:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4A79728894 for ; Thu, 18 Jul 2019 23:06:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3ECAE288BB; Thu, 18 Jul 2019 23:06:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C7E3928894 for ; Thu, 18 Jul 2019 23:06:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391712AbfGRXGd (ORCPT ); Thu, 18 Jul 2019 19:06:33 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:39194 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXGd (ORCPT ); Thu, 18 Jul 2019 19:06:33 -0400 Received: by mail-pl1-f194.google.com with SMTP id b7so14647218pls.6; Thu, 18 Jul 2019 16:06:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=yEc9XLZPW7y6dr82LLDI0BVN3EGK1CtlYHnQMwvR/xs=; b=j1gHkBMW2emt2yau+2Cd52gpku3AKyBJgVlbW+SfrWbiw2L7wQcsqMf3eTQbDwgG1b jioinZ1nNMhp6xEdLlp9HmONn/NLWAouVbX0RKYEUBHr0/ZySChg/Z1y+nkUFAAM/+Mr KMgoDtrYleEKKTdxV2REL9lEyp9ptZF0udbqfuMS8CG5wRMkPpYX9p6pNYQiwO1aJw0G 0CycLOMvA2m2qT8lQvGZtxGFUcLqct0rfoB3xeVaYENpugAv1ZBeDJp6w221D4fumJ/A 9e57vyrwMPkW/fgphUBl4DUplMnk5iBy1fNkQZ40s9KQxUs+m9IrX3R/KW56twViJklU Xg0g== X-Gm-Message-State: APjAAAUqBNT4FTo0uAeHw1zhklNGEyZpe4I527XdOdMMcZxvH/slZsTw s8qxavI7SW8eaEjR5Rcikxo= X-Google-Smtp-Source: APXvYqzj57MLo9ebDpmD8MlccPKNlbWl23I3IRQrLAZkxs9SchXEZ8xKnZlZK6Zy9R4XYjn1sknv6g== X-Received: by 2002:a17:902:be0a:: with SMTP id r10mr50064457pls.51.1563491192146; Thu, 18 Jul 2019 16:06:32 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id d14sm37989935pfo.154.2019.07.18.16.06.22 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:26 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 704E941405; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, Brian Foster , Allison Henderson , Dave Chinner , "Darrick J . Wong" , Luis Chamberlain Subject: [PATCH 8/9] xfs: serialize unaligned dio writes against all other dio writes Date: Thu, 18 Jul 2019 23:06:16 +0000 Message-Id: <20190718230617.7439-9-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Brian Foster commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a upstream. XFS applies more strict serialization constraints to unaligned direct writes to accommodate things like direct I/O layer zeroing, unwritten extent conversion, etc. Unaligned submissions acquire the exclusive iolock and wait for in-flight dio to complete to ensure multiple submissions do not race on the same block and cause data corruption. This generally works in the case of an aligned dio followed by an unaligned dio, but the serialization is lost if I/Os occur in the opposite order. If an unaligned write is submitted first and immediately followed by an overlapping, aligned write, the latter submits without the typical unaligned serialization barriers because there is no indication of an unaligned dio still in-flight. This can lead to unpredictable results. To provide proper unaligned dio serialization, require that such direct writes are always the only dio allowed in-flight at one time for a particular inode. We already acquire the exclusive iolock and drain pending dio before submitting the unaligned dio. Wait once more after the dio submission to hold the iolock across the I/O and prevent further submissions until the unaligned I/O completes. This is heavy handed, but consistent with the current pre-submission serialization for unaligned direct writes. Signed-off-by: Brian Foster Reviewed-by: Allison Henderson Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_file.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index 61a5ad2600e8..10f75965243c 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -529,18 +529,17 @@ xfs_file_dio_aio_write( count = iov_iter_count(from); /* - * If we are doing unaligned IO, wait for all other IO to drain, - * otherwise demote the lock if we had to take the exclusive lock - * for other reasons in xfs_file_aio_write_checks. + * If we are doing unaligned IO, we can't allow any other overlapping IO + * in-flight at the same time or we risk data corruption. Wait for all + * other IO to drain before we submit. If the IO is aligned, demote the + * iolock if we had to take the exclusive lock in + * xfs_file_aio_write_checks() for other reasons. */ if (unaligned_io) { - /* If we are going to wait for other DIO to finish, bail */ - if (iocb->ki_flags & IOCB_NOWAIT) { - if (atomic_read(&inode->i_dio_count)) - return -EAGAIN; - } else { - inode_dio_wait(inode); - } + /* unaligned dio always waits, bail */ + if (iocb->ki_flags & IOCB_NOWAIT) + return -EAGAIN; + inode_dio_wait(inode); } else if (iolock == XFS_IOLOCK_EXCL) { xfs_ilock_demote(ip, XFS_IOLOCK_EXCL); iolock = XFS_IOLOCK_SHARED; @@ -548,6 +547,14 @@ xfs_file_dio_aio_write( trace_xfs_file_direct_write(ip, count, iocb->ki_pos); ret = iomap_dio_rw(iocb, from, &xfs_iomap_ops, xfs_dio_write_end_io); + + /* + * If unaligned, this is the only IO in-flight. If it has not yet + * completed, wait on it before we release the iolock to prevent + * subsequent overlapping IO. + */ + if (ret == -EIOCBQUEUED && unaligned_io) + inode_dio_wait(inode); out: xfs_iunlock(ip, iolock); From patchwork Thu Jul 18 23:06:17 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11049653 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DE01D14F6 for ; Thu, 18 Jul 2019 23:06:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C9AF028894 for ; Thu, 18 Jul 2019 23:06:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BDFC9288BB; Thu, 18 Jul 2019 23:06:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 675C828894 for ; Thu, 18 Jul 2019 23:06:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391707AbfGRXGc (ORCPT ); Thu, 18 Jul 2019 19:06:32 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:45338 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728524AbfGRXGb (ORCPT ); Thu, 18 Jul 2019 19:06:31 -0400 Received: by mail-pg1-f195.google.com with SMTP id o13so13540880pgp.12; Thu, 18 Jul 2019 16:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=asc29S1aXqINt/LkQnormGy5CNyyKODqHRTWf7EXfUM=; b=jULWg4UBJdyE/6SoUXW3r7bIr6pogyKagkfrfGgyUl++ZGwGWFk9TdD/mh4YniaOBp /xSs3GgGqf/NBGZLhCJN7KXf/koQBbP+dDca1bxw7op/lo4uaY7aAbGRVeo5eVPDQZMp 1XDMBcWrHrczUobl3qPADF85UgtSodJNeRWX8yEyT0L9VFR1KT5nAHiIndJJbbg09AN+ 85ztsTLYXisx1Q4RdaGDjECprbmGtCBoknC4zrvUZIm1E81dxMAPteCYlfDBQ1cf0nme kg/e9M0XbIeSiMld6SINBnSRxEvfOmoFjtpRK/gwGmsTLzQnWFQWu8tpXm0mJOkRHnF1 vubQ== X-Gm-Message-State: APjAAAVBtO3HzGbwTRbnUuKXDRlQxumqUJuh78P0nt2hdyU1mSkXSh4J ktuqktstzNb9fqKN8Yq6iw8= X-Google-Smtp-Source: APXvYqxL+jUEhMBP1njatVJZMWX4Fy/hxMTF2axokayELle6LTw0e5ztOLtTNEzs+TprMI77+hJv2Q== X-Received: by 2002:a17:90a:17c4:: with SMTP id q62mr54823024pja.104.1563491190987; Thu, 18 Jul 2019 16:06:30 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id a25sm26509765pfn.1.2019.07.18.16.06.23 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Jul 2019 16:06:26 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 781B741464; Thu, 18 Jul 2019 23:06:19 +0000 (UTC) From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, zlang@redhat.com, "Darrick J. Wong" , Dave Chinner , Brian Foster , Dave Chinner , Christoph Hellwig , Luis Chamberlain Subject: [PATCH 9/9] xfs: abort unaligned nowait directio early Date: Thu, 18 Jul 2019 23:06:17 +0000 Message-Id: <20190718230617.7439-10-mcgrof@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190718230617.7439-1-mcgrof@kernel.org> References: <20190718230617.7439-1-mcgrof@kernel.org> MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Darrick J. Wong" commit 1fdeaea4d92c69fb9f871a787af6ad00f32eeea7 upstream. Dave Chinner noticed that xfs_file_dio_aio_write returns EAGAIN without dropping the IOLOCK when its deciding not to wait, which means that we leak the IOLOCK there. Since we now make unaligned directio always wait, we have the opportunity to bail out before trying to take the lock, which should reduce the overhead of this never-gonna-work case considerably while also solving the dropped lock problem. Reported-by: Dave Chinner Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Reviewed-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_file.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index 10f75965243c..259549698ba7 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -517,6 +517,9 @@ xfs_file_dio_aio_write( } if (iocb->ki_flags & IOCB_NOWAIT) { + /* unaligned dio always waits, bail */ + if (unaligned_io) + return -EAGAIN; if (!xfs_ilock_nowait(ip, iolock)) return -EAGAIN; } else { @@ -536,9 +539,6 @@ xfs_file_dio_aio_write( * xfs_file_aio_write_checks() for other reasons. */ if (unaligned_io) { - /* unaligned dio always waits, bail */ - if (iocb->ki_flags & IOCB_NOWAIT) - return -EAGAIN; inode_dio_wait(inode); } else if (iolock == XFS_IOLOCK_EXCL) { xfs_ilock_demote(ip, XFS_IOLOCK_EXCL);