From patchwork Thu Nov 24 16:59:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13055193 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B260C4332F for ; Thu, 24 Nov 2022 16:59:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229502AbiKXQ71 (ORCPT ); Thu, 24 Nov 2022 11:59:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbiKXQ70 (ORCPT ); Thu, 24 Nov 2022 11:59:26 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AA06B70C9 for ; Thu, 24 Nov 2022 08:59:25 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 34B4762080 for ; Thu, 24 Nov 2022 16:59:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 914D5C433D6; Thu, 24 Nov 2022 16:59:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669309164; bh=P5lsVs2mbizYgQ41CiRtXuYMZIKsCctgdgZe1qA/7LQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=f4UCMMWkXd2nI8+YJ3/wtvjQbJbUSIgs5dHnHT1CR1uf44r+PmsXjgrZULQWoc5g8 IrfewAvkzhX5Vnc1SUqNVeOYhsC31ZtuNkU9w8tBBEKpoARMk+WdFaM0ZUOW0zT3l0 7iIUABH0XeoFF/9pJ1oZvxui20wxA01OEztNMM4bSceX6a/7aMBXqtbG5BmXoy7vcx HD1DVYSh7fRrjhir56XptPJMSeWhrrO2p9zsLfBUSMRgt74WNPeTA6o1RqBaNGSJUM XgIwzav0sIhoGarD2cjTdgb/084Es6DwcgIPRSbIVZy8HNXg2lJ3c7+c+aFW6p/m2B W9TtAl/HOpk7g== Subject: [PATCH 1/3] xfs: invalidate block device page cache during unmount From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org Date: Thu, 24 Nov 2022 08:59:24 -0800 Message-ID: <166930916399.2061853.16165124824627761814.stgit@magnolia> In-Reply-To: <166930915825.2061853.2470510849612284907.stgit@magnolia> References: <166930915825.2061853.2470510849612284907.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong Every now and then I see fstests failures on aarch64 (64k pages) that trigger on the following sequence: mkfs.xfs $dev mount $dev $mnt touch $mnt/a umount $mnt xfs_db -c 'path /a' -c 'print' $dev 99% of the time this succeeds, but every now and then xfs_db cannot find /a and fails. This turns out to be a race involving udev/blkid, the page cache for the block device, and the xfs_db process. udev is triggered whenever anyone closes a block device or unmounts it. The default udev rules invoke blkid to read the fs super and create symlinks to the bdev under /dev/disk. For this, it uses buffered reads through the page cache. xfs_db also uses buffered reads to examine metadata. There is no coordination between xfs_db and udev, which means that they can run concurrently. Note there is no coordination between the kernel and blkid either. On a system with 64k pages, the page cache can cache the superblock and the root inode (and hence the root dir) with the same 64k page. If udev spawns blkid after the mkfs and the system is busy enough that it is still running when xfs_db starts up, they'll both read from the same page in the pagecache. The unmount writes updated inode metadata to disk directly. The XFS buffer cache does not use the bdev pagecache, nor does it invalidate the pagecache on umount. If the above scenario occurs, the pagecache no longer reflects what's on disk, xfs_db reads the stale metadata, and fails to find /a. Most of the time this succeeds because closing a bdev invalidates the page cache, but when processes race, everyone loses. Fix the problem by invalidating the bdev pagecache after flushing the bdev, so that xfs_db will see up to date metadata. Signed-off-by: Darrick J. Wong Reviewed-by: Gao Xiang Reviewed-by: Dave Chinner --- fs/xfs/xfs_buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index dde346450952..54c774af6e1c 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -1945,6 +1945,7 @@ xfs_free_buftarg( list_lru_destroy(&btp->bt_lru); blkdev_issue_flush(btp->bt_bdev); + invalidate_bdev(btp->bt_bdev); fs_put_dax(btp->bt_daxdev, btp->bt_mount); kmem_free(btp); From patchwork Thu Nov 24 16:59:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13055194 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AF81C433FE for ; Thu, 24 Nov 2022 16:59:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229582AbiKXQ7c (ORCPT ); Thu, 24 Nov 2022 11:59:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbiKXQ7b (ORCPT ); Thu, 24 Nov 2022 11:59:31 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34DBE7C036 for ; Thu, 24 Nov 2022 08:59:31 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B5FB1621AA for ; Thu, 24 Nov 2022 16:59:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E50BC433C1; Thu, 24 Nov 2022 16:59:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669309170; bh=EAyYS4iwINg9EfiQ4+s56XcTxK7HXRkbS2b/udMknR0=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=MOf63xjRkCWzKNSAo9+h4dt48C01c8HingzPqjAgzDSYswCuU06Kvvl6RMrFV9DRH /0KYfEzIuu03AWJd9iTx0Hj+5ms115hKilfc1Gn9c6X892inAIi64RhrZRZjavnNxE stvJmWoMGQT/w7oFhEA/+6xYeI63k7HpNeasSbajWU1k4LLoAslAyih0NFN40dkIEV n7+wNJeBJFgYBEEz3rMzYj6ETO5Mbk6b4YbK9ZxTqB5PD7YsHdfcz8A2aU9MsCC1FV kgH5Bdf+cttTs0HGa83Bevf5C4mySyUjTQrsciOqat+PvbAJNkFFbu7G/mDbrtZBTP k+I49R1h0FCCQ== Subject: [PATCH 2/3] xfs: use memcpy, not strncpy, to format the attr prefix during listxattr From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org Date: Thu, 24 Nov 2022 08:59:29 -0800 Message-ID: <166930916972.2061853.5449429916617568478.stgit@magnolia> In-Reply-To: <166930915825.2061853.2470510849612284907.stgit@magnolia> References: <166930915825.2061853.2470510849612284907.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong When -Wstringop-truncation is enabled, the compiler complains about truncation of the null byte at the end of the xattr name prefix. This is intentional, since we're concatenating the two strings together and do _not_ want a null byte in the middle of the name. We've already ensured that the name buffer is long enough to handle prefix and name, and the prefix_len is supposed to be the length of the prefix string without the null byte, so use memcpy here instead. Signed-off-by: Darrick J. Wong Reviewed-by: Gao Xiang Reviewed-by: Dave Chinner --- fs/xfs/xfs_xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c index c325a28b89a8..10aa1fd39d2b 100644 --- a/fs/xfs/xfs_xattr.c +++ b/fs/xfs/xfs_xattr.c @@ -210,7 +210,7 @@ __xfs_xattr_put_listent( return; } offset = context->buffer + context->count; - strncpy(offset, prefix, prefix_len); + memcpy(offset, prefix, prefix_len); offset += prefix_len; strncpy(offset, (char *)name, namelen); /* real name */ offset += namelen; From patchwork Thu Nov 24 16:59:35 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13055195 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32472C433FE for ; Thu, 24 Nov 2022 16:59:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229481AbiKXQ7j (ORCPT ); Thu, 24 Nov 2022 11:59:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbiKXQ7j (ORCPT ); Thu, 24 Nov 2022 11:59:39 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5538CB54CF for ; Thu, 24 Nov 2022 08:59:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1150FB82899 for ; Thu, 24 Nov 2022 16:59:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA9EAC433C1; Thu, 24 Nov 2022 16:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669309175; bh=B+rifbk15R8VDExDcIh4ROAoGhjJRQcwXJct6Y6SuXY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=dT3hftHtsbHL3hvDCdp3pk43STiaW0lNtPidrwnwCpbxtzHdgAUXuGyuxHFnbJhZJ Z9UFKyGDu6ccu1l5+AYqZz1st/kMk8Y5TbNyr5q9woDCQuBZUOA2sB2pKzCzGOHySb IZTtNMjeOMX0/cvmFNTK5G/fNzNYXtgg1lX3zsmzJKlGI/9FtD4AdO+jeHfBzPKRjx Sz43SR8qHI1xU+sSsOgs9xsF3EImDDZxFSbQwI/yv7hO0stpAykTyTV2rbhcoKyolD hktG1dFPm0dWqTe+/eLwkS2a3cASTm8UlCRZZznjVCMhmQ0jeYgfj11lZ9/3h4lyi9 qgxOGSfE1F/6w== Subject: [PATCH 3/3] xfs: shut up -Wuninitialized in xfsaild_push From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org Date: Thu, 24 Nov 2022 08:59:35 -0800 Message-ID: <166930917525.2061853.17523624187254825450.stgit@magnolia> In-Reply-To: <166930915825.2061853.2470510849612284907.stgit@magnolia> References: <166930915825.2061853.2470510849612284907.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong -Wuninitialized complains about @target in xfsaild_push being uninitialized in the case where the waitqueue is active but there is no last item in the AIL to wait for. I /think/ it should never be the case that the subsequent xfs_trans_ail_cursor_first returns a log item and hence we'll never end up at XFS_LSN_CMP, but let's make this explicit. Signed-off-by: Darrick J. Wong Reviewed-by: Gao Xiang Reviewed-by: Dave Chinner --- fs/xfs/xfs_trans_ail.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c index f51df7d94ef7..7d4109af193e 100644 --- a/fs/xfs/xfs_trans_ail.c +++ b/fs/xfs/xfs_trans_ail.c @@ -422,7 +422,7 @@ xfsaild_push( struct xfs_ail_cursor cur; struct xfs_log_item *lip; xfs_lsn_t lsn; - xfs_lsn_t target; + xfs_lsn_t target = NULLCOMMITLSN; long tout; int stuck = 0; int flushing = 0; @@ -472,6 +472,8 @@ xfsaild_push( XFS_STATS_INC(mp, xs_push_ail); + ASSERT(target != NULLCOMMITLSN); + lsn = lip->li_lsn; while ((XFS_LSN_CMP(lip->li_lsn, target) <= 0)) { int lock_result; From patchwork Sun Nov 27 18:36:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13056835 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4012C43217 for ; Sun, 27 Nov 2022 18:36:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229589AbiK0Sge (ORCPT ); Sun, 27 Nov 2022 13:36:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229500AbiK0Sgd (ORCPT ); Sun, 27 Nov 2022 13:36:33 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 559FDE69 for ; Sun, 27 Nov 2022 10:36:32 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0A07AB80B2F for ; Sun, 27 Nov 2022 18:36:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9B71C433C1; Sun, 27 Nov 2022 18:36:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669574189; bh=rDbh2u2nUggyGJK47vCsS92qdiIodm2yiz+73wnjqwU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hWCojgDK3859Tj0RNvBdUnubdB9jYjzi+GttNo7NABIdAByuAMhkoPQZlIHQectF4 vvNApPq3yqpXYLF1VjfGY4vePUW7crr/UbFQ18whcLE6SMezFt8jU1jRTSd64AlsUY m55Xy3/LE3LjOmojexHjWqC8kNZrvjbB4ptnHlQTYjN5EWpZOhSbgw+94mjXve304P xzeH53URbEakmMB3k2hCsgzA+zD4INE+I6cA+umjQ5euXcASfgh84R9awhm5UTuUts qdOl3pxnscFdHYcmjR2xQsLjJl2Z9Ou8/0Ju6kjzQUZH+smqR/uERYjkZsXGkch5oF 1B3TVDYUhrRQA== Date: Sun, 27 Nov 2022 10:36:29 -0800 From: "Darrick J. Wong" To: linux-xfs@vger.kernel.org Cc: Dave Chinner Subject: [PATCH 4/3] xfs: attach dquots to inode before reading data/cow fork mappings Message-ID: References: <166930915825.2061853.2470510849612284907.stgit@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <166930915825.2061853.2470510849612284907.stgit@magnolia> Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong I've been running near-continuous integration testing of online fsck, and I've noticed that once a day, one of the ARM VMs will fail the test with out of order records in the data fork. xfs/804 races fsstress with online scrub (aka scan but do not change anything), so I think this might be a bug in the core xfs code. This also only seems to trigger if one runs the test for more than ~6 minutes via TIME_FACTOR=13 or something. https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/tree/tests/xfs/804?h=djwong-wtf I added a debugging patch to the kernel to check the data fork extents after taking the ILOCK, before dropping ILOCK, and before and after each bmapping operation. So far I've narrowed it down to the delalloc code inserting a record in the wrong place in the iext tree: xfs_bmap_add_extent_hole_delay, near line 2691: case 0: /* * New allocation is not contiguous with another * delayed allocation. * Insert a new entry. */ oldlen = newlen = 0; xfs_iunlock_check_datafork(ip); <-- ok here xfs_iext_insert(ip, icur, new, state); xfs_iunlock_check_datafork(ip); <-- bad here break; } I recorded the state of the data fork mappings and iext cursor state when a corrupt data fork is detected immediately after the xfs_bmap_add_extent_hole_delay call in xfs_bmapi_reserve_delalloc: ino 0x140bb3 func xfs_bmapi_reserve_delalloc line 4164 data fork: ino 0x140bb3 nr 0x0 nr_real 0x0 offset 0xb9 blockcount 0x1f startblock 0x935de2 state 1 ino 0x140bb3 nr 0x1 nr_real 0x1 offset 0xe6 blockcount 0xa startblock 0xffffffffe0007 state 0 ino 0x140bb3 nr 0x2 nr_real 0x1 offset 0xd8 blockcount 0xe startblock 0x935e01 state 0 Here we see that a delalloc extent was inserted into the wrong position in the iext leaf, same as all the other times. The extra trace data I collected are as follows: ino 0x140bb3 fork 0 oldoff 0xe6 oldlen 0x4 oldprealloc 0x6 isize 0xe6000 ino 0x140bb3 oldgotoff 0xea oldgotstart 0xfffffffffffffffe oldgotcount 0x0 oldgotstate 0 ino 0x140bb3 crapgotoff 0x0 crapgotstart 0x0 crapgotcount 0x0 crapgotstate 0 ino 0x140bb3 freshgotoff 0xd8 freshgotstart 0x935e01 freshgotcount 0xe freshgotstate 0 ino 0x140bb3 nowgotoff 0xe6 nowgotstart 0xffffffffe0007 nowgotcount 0xa nowgotstate 0 ino 0x140bb3 oldicurpos 1 oldleafnr 2 oldleaf 0xfffffc00f0609a00 ino 0x140bb3 crapicurpos 2 crapleafnr 2 crapleaf 0xfffffc00f0609a00 ino 0x140bb3 freshicurpos 1 freshleafnr 2 freshleaf 0xfffffc00f0609a00 ino 0x140bb3 newicurpos 1 newleafnr 3 newleaf 0xfffffc00f0609a00 The first line shows that xfs_bmapi_reserve_delalloc was called with whichfork=XFS_DATA_FORK, off=0xe6, len=0x4, prealloc=6. The second line ("oldgot") shows the contents of @got at the beginning of the call, which are the results of the first iext lookup in xfs_buffered_write_iomap_begin. Line 3 ("crapgot") is the result of duplicating the cursor at the start of the body of xfs_bmapi_reserve_delalloc and performing a fresh lookup at @off. Line 4 ("freshgot") is the result of a new xfs_iext_get_extent right before the call to xfs_bmap_add_extent_hole_delay. Totally garbage. Line 5 ("nowgot") is contents of @got after the xfs_bmap_add_extent_hole_delay call. Line 6 is the contents of @icur at the beginning fo the call. Lines 7-9 are the contents of the iext cursors at the point where the block mappings were sampled. I think @oldgot is a HOLESTARTBLOCK extent because the first lookup didn't find anything, so we filled in imap with "fake hole until the end". At the time of the first lookup, I suspect that there's only one 32-block unwritten extent in the mapping (hence oldicurpos==1) but by the time we get to recording crapgot, crapicurpos==2. Dave then added: Ok, that's much simpler to reason about, and implies the smoke is coming from xfs_buffered_write_iomap_begin() or xfs_bmapi_reserve_delalloc(). I suspect the former - it does a lot of stuff with the ILOCK_EXCL held..... .... including calling xfs_qm_dqattach_locked(). xfs_buffered_write_iomap_begin ILOCK_EXCL look up icur xfs_qm_dqattach_locked xfs_qm_dqattach_one xfs_qm_dqget_inode dquot cache miss xfs_iunlock(ip, XFS_ILOCK_EXCL); error = xfs_qm_dqread(mp, id, type, can_alloc, &dqp); xfs_ilock(ip, XFS_ILOCK_EXCL); .... xfs_bmapi_reserve_delalloc(icur) Yup, that's what is letting the magic smoke out - xfs_qm_dqattach_locked() can cycle the ILOCK. If that happens, we can pass a stale icur to xfs_bmapi_reserve_delalloc() and it all goes downhill from there. So. Fix this by moving the dqattach_locked call up, and add a comment about how we must attach the dquots *before* sampling the data/cow fork contents. Fixes: a526c85c2236 ("xfs: move xfs_file_iomap_begin_delay around") # goes further back than this Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner --- fs/xfs/xfs_iomap.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 1bdd7afc1010..d903f0586490 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -984,6 +984,14 @@ xfs_buffered_write_iomap_begin( if (error) goto out_unlock; + /* + * Attach dquots before we access the data/cow fork mappings, because + * this function can cycle the ILOCK. + */ + error = xfs_qm_dqattach_locked(ip, false); + if (error) + goto out_unlock; + /* * Search the data fork first to look up our source mapping. We * always need the data fork map, as we have to return it to the @@ -1071,10 +1079,6 @@ xfs_buffered_write_iomap_begin( allocfork = XFS_COW_FORK; } - error = xfs_qm_dqattach_locked(ip, false); - if (error) - goto out_unlock; - if (eof && offset + count > XFS_ISIZE(ip)) { /* * Determine the initial size of the preallocation.