From: <gregkh@linuxfoundation.org>
To: bo.li.liu@oracle.com, alexander.levin@verizon.com,
anand.jain@oracle.com, dsterba@suse.com,
gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "Btrfs: adjust outstanding_extents counter properly when dio write is split" has been added to the 4.4-stable tree
Date: Fri, 04 Aug 2017 15:26:10 -0700 [thread overview]
Message-ID: <1501885570131143@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
Btrfs: adjust outstanding_extents counter properly when dio write is split
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
btrfs-adjust-outstanding_extents-counter-properly-when-dio-write-is-split.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Fri Aug 4 15:15:51 PDT 2017
From: Liu Bo <bo.li.liu@oracle.com>
Date: Thu, 22 Dec 2016 17:13:54 -0800
Subject: Btrfs: adjust outstanding_extents counter properly when dio write is split
From: Liu Bo <bo.li.liu@oracle.com>
[ Upstream commit c2931667c83ded6504b3857e99cc45b21fa496fb ]
Currently how btrfs dio deals with split dio write is not good
enough if dio write is split into several segments due to the
lack of contiguous space, a large dio write like 'dd bs=1G count=1'
can end up with incorrect outstanding_extents counter and endio
would complain loudly with an assertion.
This fixes the problem by compensating the outstanding_extents
counter in inode if a large dio write gets split.
Reported-by: Anand Jain <anand.jain@oracle.com>
Tested-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/inode.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7521,11 +7521,18 @@ static void adjust_dio_outstanding_exten
* within our reservation, otherwise we need to adjust our inode
* counter appropriately.
*/
- if (dio_data->outstanding_extents) {
+ if (dio_data->outstanding_extents >= num_extents) {
dio_data->outstanding_extents -= num_extents;
} else {
+ /*
+ * If dio write length has been split due to no large enough
+ * contiguous space, we need to compensate our inode counter
+ * appropriately.
+ */
+ u64 num_needed = num_extents - dio_data->outstanding_extents;
+
spin_lock(&BTRFS_I(inode)->lock);
- BTRFS_I(inode)->outstanding_extents += num_extents;
+ BTRFS_I(inode)->outstanding_extents += num_needed;
spin_unlock(&BTRFS_I(inode)->lock);
}
}
Patches currently in stable-queue which might be from bo.li.liu@oracle.com are
queue-4.4/btrfs-adjust-outstanding_extents-counter-properly-when-dio-write-is-split.patch
queue-4.4/btrfs-use-down_read_nested-to-make-lockdep-silent.patch
reply other threads:[~2017-08-04 22:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1501885570131143@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexander.levin@verizon.com \
--cc=anand.jain@oracle.com \
--cc=bo.li.liu@oracle.com \
--cc=dsterba@suse.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.