1 ext4: call ext4_error_inode() if jbd2_journal_dirty_metadata() fails
3 While it's true that errors can only happen if there is a bug in
4 jbd2_journal_dirty_metadata(), if a bug does happen, we need to halt
5 the kernel or remount the file system read-only in order to avoid
6 further data loss. The ext4_journal_abort_handle() function doesn't
7 do any of this, and while it's likely that this call (since it doesn't
8 adjust refcounts) will likely result in the file system eventually
9 deadlocking since the current transaction will never be able to close,
10 it's much cleaner to call let ext4's error handling system deal with
13 There's a separate bug here which is that if certain jbd2 errors
14 errors occur and file system is mounted errors=continue, the file
15 system will probably eventually end grind to a halt as described
16 above. But things have been this way in a long time, and usually when
17 we have these sorts of errors it's pretty much a disaster --- and
18 that's why the jbd2 layer aggressively retries memory allocations,
19 which is the most likely cause of these jbd2 errors.
21 Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
22 Cc: stable@vger.kernel.org
24 fs/ext4/ext4_jbd2.c | 9 +++++++++
25 1 file changed, 9 insertions(+)
27 diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
28 index 17ac112..3fe29de 100644
29 --- a/fs/ext4/ext4_jbd2.c
30 +++ b/fs/ext4/ext4_jbd2.c
31 @@ -259,6 +259,15 @@ int __ext4_handle_dirty_metadata(const char *where, unsigned int line,
32 if (WARN_ON_ONCE(err)) {
33 ext4_journal_abort_handle(where, line, __func__, bh,
35 + ext4_error_inode(inode, where, line,
37 + "journal_dirty_metadata failed: "
38 + "handle type %u started at line %u, "
39 + "credits %u/%u, errcode %d",
42 + handle->h_requested_credits,
43 + handle->h_buffer_credits, err);