[PATCH 0/2] Fix silent write loss in iomap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While working on the THP patchset, I decided to inject errors, and
unfortunately I found a hole in our handling of errors with non-THPs.
You can probably reproduce these errors by inserting your own error
injection for readahead pages; mine is a little too tied to the THP
patchset to post.

The basic outline of the problem is:

 - read(ahead) hits an error, page is marked Error, !Uptodate
 - write_begin succeeds at reading in page, but it is not marked
   Uptodate due to PageError being set
 - write path copies data to page, write() call returns success
 - subsequent read() sees a page which is !Uptodate, clears Error,
   calls ->readpage, re-reads data from storage, overwrites data
   from write() with old data.

The solution presented here is to behave compatibly with mm/filemap.c.
I don't _like_ how we handle PageError for read errors.  See that other
mail to linux-fsdevel for details, but this solution fixes an error that
can be hit by people with flaky storage.

I've done this as two patches because there are actually two independent
problems here.  The bug is not fixed without applying both patches, so
I'm happy to combine them into a single patch if that makes life easier.

The problem was introduced with commit 9dc55f1389f9, which made setting
PageUptodate conditional on PageError().

Matthew Wilcox (Oracle) (2):
  iomap: Clear page error before beginning a write
  iomap: Mark read blocks uptodate in write_begin

 fs/iomap/buffered-io.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

-- 
2.28.0




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux