diff options
author | Jeff Layton <jlayton@redhat.com> | 2017-07-06 13:02:21 +0200 |
---|---|---|
committer | Jeff Layton <jlayton@redhat.com> | 2017-07-06 13:02:21 +0200 |
commit | 87354e5de04fe727227ff619af164202adcfa4d4 (patch) | |
tree | 1cde8e4890ca73ce6513c19c48c151e20b867433 /net/bridge | |
parent | fs: check for writeback errors after syncing out buffers in generic_file_fsync (diff) | |
download | linux-87354e5de04fe727227ff619af164202adcfa4d4.tar.xz linux-87354e5de04fe727227ff619af164202adcfa4d4.zip |
buffer: set errors in mapping at the time that the error occurs
I noticed on xfs that I could still sometimes get back an error on fsync
on a fd that was opened after the error condition had been cleared.
The problem is that the buffer code sets the write_io_error flag and
then later checks that flag to set the error in the mapping. That flag
perisists for quite a while however. If the file is later opened with
O_TRUNC, the buffers will then be invalidated and the mapping's error
set such that a subsequent fsync will return error. I think this is
incorrect, as there was no writeback between the open and fsync.
Add a new mark_buffer_write_io_error operation that sets the flag and
the error in the mapping at the same time. Replace all calls to
set_buffer_write_io_error with mark_buffer_write_io_error, and remove
the places that check this flag in order to set the error in the
mapping.
This sets the error in the mapping earlier, at the time that it's first
detected.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Diffstat (limited to 'net/bridge')
0 files changed, 0 insertions, 0 deletions