From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Eryu Guan <eguan@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/4] ext4: Fix deadlock during page writeback
Date: Thu, 30 Jun 2016 11:05:48 -0400 [thread overview]
Message-ID: <20160630150548.GC2028@thunk.org> (raw)
In-Reply-To: <1466073736-30447-2-git-send-email-jack@suse.cz>
On Thu, Jun 16, 2016 at 12:42:13PM +0200, Jan Kara wrote:
> Commit 06bd3c36a733 (ext4: fix data exposure after a crash) uncovered a
> deadlock in ext4_writepages() which was previously much harder to hit.
> After this commit xfstest generic/130 reproduces the deadlock on small
> filesystems.
>
> The problem happens when ext4_do_update_inode() sets LARGE_FILE feature
> and marks current inode handle as synchronous. That subsequently results
> in ext4_journal_stop() called from ext4_writepages() to block waiting for
> transaction commit while still holding page locks, reference to io_end,
> and some prepared bio in mpd structure each of which can possibly block
> transaction commit from completing and thus results in deadlock.
Would it be safe to submit the bio *after* calling
ext4_journal_stop()? It looks like that would be safe, and I'd prefer
to minimize the time that a handle is open since that can really
impact performance when trying to close all existing handles when we
are starting commit processing. It looks to me like this would be
safe in terms of avoiding deadlocks, yes?
- Ted
next prev parent reply other threads:[~2016-06-30 15:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 10:42 [PATCH 0/4] ext4: Fix deadlock during page writeback Jan Kara
2016-06-16 10:42 ` [PATCH 1/4] " Jan Kara
2016-06-30 15:05 ` Theodore Ts'o [this message]
2016-07-01 9:09 ` Jan Kara
2016-07-01 16:53 ` Theodore Ts'o
2016-07-01 17:40 ` Jan Kara
2016-07-01 21:26 ` Theodore Ts'o
2016-07-04 14:00 ` Jan Kara
2016-07-04 15:20 ` Theodore Ts'o
2016-07-04 15:47 ` Jan Kara
2016-07-05 2:43 ` Theodore Ts'o
2016-07-06 7:04 ` Jan Kara
2016-07-04 14:14 ` Theodore Ts'o
2016-07-04 15:51 ` Jan Kara
2016-07-05 3:38 ` Theodore Ts'o
2016-07-06 7:51 ` Jan Kara
2016-07-06 12:35 ` Theodore Ts'o
2016-07-06 12:52 ` Jan Kara
2016-07-06 14:27 ` Theodore Ts'o
2016-07-06 14:41 ` Jan Kara
2016-06-16 10:42 ` [PATCH 2/4] jbd2: Move lockdep instrumentation for jbd2 handles Jan Kara
2016-06-30 15:34 ` Theodore Ts'o
2016-06-16 10:42 ` [PATCH 3/4] jbd2: Move lockdep tracking to journal_s Jan Kara
2016-06-16 11:42 ` kbuild test robot
2016-06-30 15:40 ` Theodore Ts'o
2016-06-16 10:42 ` [PATCH 4/4] jbd2: Track more dependencies on transaction commit Jan Kara
2016-06-30 15:45 ` Theodore Ts'o
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=20160630150548.GC2028@thunk.org \
--to=tytso@mit.edu \
--cc=eguan@redhat.com \
--cc=jack@suse.cz \
--cc=linux-ext4@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).