diff options
author | Theodore Ts'o <tytso@mit.edu> | 2015-10-15 10:29:05 -0400 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2015-10-15 10:29:05 -0400 |
commit | b90197b655185a11640cce3a0a0bc5d8291b8ad2 (patch) | |
tree | 2fb6e2b7583eec3169d86d643f45b29d2704261b /include/linux/jbd2.h | |
parent | 36086d43f6575c081067de9855786a2fc91df77b (diff) | |
download | linux-b90197b655185a11640cce3a0a0bc5d8291b8ad2.tar.gz linux-b90197b655185a11640cce3a0a0bc5d8291b8ad2.tar.bz2 linux-b90197b655185a11640cce3a0a0bc5d8291b8ad2.zip |
ext4: use private version of page_zero_new_buffers() for data=journal mode
If there is a error while copying data from userspace into the page
cache during a write(2) system call, in data=journal mode, in
ext4_journalled_write_end() were using page_zero_new_buffers() from
fs/buffer.c. Unfortunately, this sets the buffer dirty flag, which is
no good if journalling is enabled. This is a long-standing bug that
goes back for years and years in ext3, but a combination of (a)
data=journal not being very common, (b) in many case it only results
in a warning message. and (c) only very rarely causes the kernel hang,
means that we only really noticed this as a problem when commit
998ef75ddb caused this failure to happen frequently enough to cause
generic/208 to fail when run in data=journal mode.
The fix is to have our own version of this function that doesn't call
mark_dirty_buffer(), since we will end up calling
ext4_handle_dirty_metadata() on the buffer head(s) in questions very
shortly afterwards in ext4_journalled_write_end().
Thanks to Dave Hansen and Linus Torvalds for helping to identify the
root cause of the problem.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.com>
Diffstat (limited to 'include/linux/jbd2.h')
0 files changed, 0 insertions, 0 deletions