| Message ID | 20200726091052.30576-1-willy@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iomap: Ensure iop->uptodate matches PageUptodate | expand |
On Sun, Jul 26, 2020 at 10:10:52AM +0100, Matthew Wilcox (Oracle) wrote: > If the filesystem has block size < page size and we end up calling > iomap_page_create() in iomap_page_mkwrite_actor(), the uptodate bits > would be zero, which causes us to skip writeback of blocks which are > !uptodate in iomap_writepage_map(). This can lead to user data loss. > > Found using generic/127 with the THP patches. I don't think this can be > reproduced on mainline using that test (the THP code causes iomap_pages > to be discarded more frequently), but inspection shows it can happen > with an appropriate series of operations. Looks good, Reviewed-by: Christoph Hellwig <hch@lst.de>
On Sun, Jul 26, 2020 at 10:10:52AM +0100, Matthew Wilcox (Oracle) wrote: > If the filesystem has block size < page size and we end up calling > iomap_page_create() in iomap_page_mkwrite_actor(), the uptodate bits > would be zero, which causes us to skip writeback of blocks which are > !uptodate in iomap_writepage_map(). This can lead to user data loss. I'm still unclear on what condition gets us to iomap_page_mkwrite_actor() without already having initialised the page correctly. i.e. via a read() or write() call, or the read fault prior to ->page_mkwrite() which would have marked the page uptodate - that operation should have called iomap_page_create() and iomap_set_range_uptodate() on the page.... i.e. you've described the symptom, but not the cause of the issue you are addressing. > Found using generic/127 with the THP patches. I don't think this can be > reproduced on mainline using that test (the THP code causes iomap_pages > to be discarded more frequently), but inspection shows it can happen > with an appropriate series of operations. That sequence of operations would be? > Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > --- > fs/iomap/buffered-io.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index a2b3b5455219..f0c5027bf33f 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -53,7 +53,10 @@ iomap_page_create(struct inode *inode, struct page *page) > atomic_set(&iop->read_count, 0); > atomic_set(&iop->write_count, 0); > spin_lock_init(&iop->uptodate_lock); > - bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > + if (PageUptodate(page)) > + bitmap_fill(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > + else > + bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); I suspect this bitmap_fill call belongs in the iomap_page_mkwrite() code as is the only code that can call iomap_page_create() with an uptodate page. Then iomap_page_create() could just use kzalloc() and drop the atomic_set() and bitmap_zero() calls altogether, Cheers, Dave.
On Mon, Jul 27, 2020 at 09:06:57AM +1000, Dave Chinner wrote: > On Sun, Jul 26, 2020 at 10:10:52AM +0100, Matthew Wilcox (Oracle) wrote: > > If the filesystem has block size < page size and we end up calling > > iomap_page_create() in iomap_page_mkwrite_actor(), the uptodate bits > > would be zero, which causes us to skip writeback of blocks which are > > !uptodate in iomap_writepage_map(). This can lead to user data loss. > > I'm still unclear on what condition gets us to > iomap_page_mkwrite_actor() without already having initialised the > page correctly. i.e. via a read() or write() call, or the read fault > prior to ->page_mkwrite() which would have marked the page uptodate > - that operation should have called iomap_page_create() and > iomap_set_range_uptodate() on the page.... > > i.e. you've described the symptom, but not the cause of the issue > you are addressing. I don't know exactly what condition gets us there either. It must be possible, or there wouldn't be a call to iomap_page_create() but rather one to to_iomap_page() like the one in iomap_finish_page_writeback(). > > Found using generic/127 with the THP patches. I don't think this can be > > reproduced on mainline using that test (the THP code causes iomap_pages > > to be discarded more frequently), but inspection shows it can happen > > with an appropriate series of operations. > > That sequence of operations would be? > > > Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > > --- > > fs/iomap/buffered-io.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > > index a2b3b5455219..f0c5027bf33f 100644 > > --- a/fs/iomap/buffered-io.c > > +++ b/fs/iomap/buffered-io.c > > @@ -53,7 +53,10 @@ iomap_page_create(struct inode *inode, struct page *page) > > atomic_set(&iop->read_count, 0); > > atomic_set(&iop->write_count, 0); > > spin_lock_init(&iop->uptodate_lock); > > - bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > > + if (PageUptodate(page)) > > + bitmap_fill(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > > + else > > + bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > > I suspect this bitmap_fill call belongs in the iomap_page_mkwrite() > code as is the only code that can call iomap_page_create() with an > uptodate page. Then iomap_page_create() could just use kzalloc() and > drop the atomic_set() and bitmap_zero() calls altogether, Way ahead of you http://git.infradead.org/users/willy/pagecache.git/commitdiff/5a1de6fc4f815797caa4a2f37c208c67afd7c20b
On Mon, Jul 27, 2020 at 12:20:22AM +0100, Matthew Wilcox wrote: > On Mon, Jul 27, 2020 at 09:06:57AM +1000, Dave Chinner wrote: > > On Sun, Jul 26, 2020 at 10:10:52AM +0100, Matthew Wilcox (Oracle) wrote: > > > If the filesystem has block size < page size and we end up calling > > > iomap_page_create() in iomap_page_mkwrite_actor(), the uptodate bits > > > would be zero, which causes us to skip writeback of blocks which are > > > !uptodate in iomap_writepage_map(). This can lead to user data loss. > > > > I'm still unclear on what condition gets us to > > iomap_page_mkwrite_actor() without already having initialised the > > page correctly. i.e. via a read() or write() call, or the read fault > > prior to ->page_mkwrite() which would have marked the page uptodate > > - that operation should have called iomap_page_create() and > > iomap_set_range_uptodate() on the page.... > > > > i.e. you've described the symptom, but not the cause of the issue > > you are addressing. > > I don't know exactly what condition gets us there either. It must be > possible, or there wouldn't be a call to iomap_page_create() but rather > one to to_iomap_page() like the one in iomap_finish_page_writeback(). Yes, I understand the code accepts it can happen; what I dislike is code that asserts subtle behaviour can happen, then doesn't describe that exactly why/how that condition can occur. And then, because we don't know exactly how something happens, we add work arounds to hide issues we can't reason through fully. That's .... suboptimal. Christoph might know off the top of his head how we get into this state. Once we work it out, then we need to add comments... > > > reproduced on mainline using that test (the THP code causes iomap_pages > > > to be discarded more frequently), but inspection shows it can happen > > > with an appropriate series of operations. > > > > That sequence of operations would be? > > > > > Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") > > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > > > --- > > > fs/iomap/buffered-io.c | 7 ++++++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > > > index a2b3b5455219..f0c5027bf33f 100644 > > > --- a/fs/iomap/buffered-io.c > > > +++ b/fs/iomap/buffered-io.c > > > @@ -53,7 +53,10 @@ iomap_page_create(struct inode *inode, struct page *page) > > > atomic_set(&iop->read_count, 0); > > > atomic_set(&iop->write_count, 0); > > > spin_lock_init(&iop->uptodate_lock); > > > - bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > > > + if (PageUptodate(page)) > > > + bitmap_fill(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > > > + else > > > + bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); > > > > I suspect this bitmap_fill call belongs in the iomap_page_mkwrite() > > code as is the only code that can call iomap_page_create() with an > > uptodate page. Then iomap_page_create() could just use kzalloc() and > > drop the atomic_set() and bitmap_zero() calls altogether, > > Way ahead of you > http://git.infradead.org/users/willy/pagecache.git/commitdiff/5a1de6fc4f815797caa4a2f37c208c67afd7c20b *nod* I would suggest breaking that out as a separate cleanup patch and not hide is in a patch that contains both THP modifications and bug fixes. It stands alone as a valid cleanup. Cheers, Dave.
On Mon, Jul 27, 2020 at 09:53:35AM +1000, Dave Chinner wrote: > Yes, I understand the code accepts it can happen; what I dislike is > code that asserts subtle behaviour can happen, then doesn't describe > that exactly why/how that condition can occur. And then, because we > don't know exactly how something happens, we add work arounds to > hide issues we can't reason through fully. That's .... suboptimal. > > Christoph might know off the top of his head how we get into this > state. Once we work it out, then we need to add comments... Unfortunately I don't know offhand. I'll need to spend some more quality time with this code first. > > Way ahead of you > > http://git.infradead.org/users/willy/pagecache.git/commitdiff/5a1de6fc4f815797caa4a2f37c208c67afd7c20b > > *nod* > > I would suggest breaking that out as a separate cleanup patch and > not hide is in a patch that contains both THP modifications and bug > fixes. It stands alone as a valid cleanup. I'm pretty sure I already suggested that when it first showed up. That being said I have another somewhat related thing in this area that I really want to get done before THP support, and maybe I can offload it to willy: Currently we always allocate the iomap_page structure for blocksize < PAGE_SIZE. While this was easy to implement and a major improvement over the buffer heads it actually is quite silly, as we only actually need it if we either have sub-page uptodate state, or have extents boundaries in the page. So what I'd like to do is to only actually allocate it in that case. By doing the allocation lazy it should also help to never allocate one that is marked all uptodate from the start.
On Tue, Jul 28, 2020 at 10:23:01AM +0100, Christoph Hellwig wrote: > On Mon, Jul 27, 2020 at 09:53:35AM +1000, Dave Chinner wrote: > > Yes, I understand the code accepts it can happen; what I dislike is > > code that asserts subtle behaviour can happen, then doesn't describe > > that exactly why/how that condition can occur. And then, because we > > don't know exactly how something happens, we add work arounds to > > hide issues we can't reason through fully. That's .... suboptimal. > > > > Christoph might know off the top of his head how we get into this > > state. Once we work it out, then we need to add comments... > > Unfortunately I don't know offhand. I'll need to spend some more > quality time with this code first. The code reads like you had several ideas for how the uptodate array works, changing your mind as you went along, and it didn't quite get to a coherent state before it was merged. For example, there are parts of the code which think that a clear bit in the uptodate array means there's a hole in the file, eg fs/iomap/seek.c:page_seek_hole_data() calls iomap_is_partially_uptodate() but we set the uptodate bits when zeroing the parts of the page which are covered by holes in iomap_readpage_actor() > > > Way ahead of you > > > http://git.infradead.org/users/willy/pagecache.git/commitdiff/5a1de6fc4f815797caa4a2f37c208c67afd7c20b > > > > *nod* > > > > I would suggest breaking that out as a separate cleanup patch and > > not hide is in a patch that contains both THP modifications and bug > > fixes. It stands alone as a valid cleanup. > > I'm pretty sure I already suggested that when it first showed up. > > That being said I have another somewhat related thing in this area > that I really want to get done before THP support, and maybe I can > offload it to willy: > > Currently we always allocate the iomap_page structure for blocksize > < PAGE_SIZE. While this was easy to implement and a major improvement > over the buffer heads it actually is quite silly, as we only actually > need it if we either have sub-page uptodate state, or have extents > boundaries in the page. So what I'd like to do is to only actually > allocate it in that case. By doing the allocation lazy it should also > help to never allocate one that is marked all uptodate from the start. Hah, I want to do that too, and I was afraid I was going to have to argue with you about it! My thinking was to skip the allocation if the page lies entirely within an iomap extent. That will let us skip the allocation even for THPs unless the file is fragmented. I don't think it needs to get done before THP support, they're pretty orthogonal.
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index a2b3b5455219..f0c5027bf33f 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -53,7 +53,10 @@ iomap_page_create(struct inode *inode, struct page *page) atomic_set(&iop->read_count, 0); atomic_set(&iop->write_count, 0); spin_lock_init(&iop->uptodate_lock); - bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); + if (PageUptodate(page)) + bitmap_fill(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); + else + bitmap_zero(iop->uptodate, PAGE_SIZE / SECTOR_SIZE); /* * migrate_page_move_mapping() assumes that pages with private data have @@ -72,6 +75,8 @@ iomap_page_release(struct page *page) return; WARN_ON_ONCE(atomic_read(&iop->read_count)); WARN_ON_ONCE(atomic_read(&iop->write_count)); + WARN_ON_ONCE(bitmap_full(iop->uptodate, PAGE_SIZE / SECTOR_SIZE) != + PageUptodate(page)); kfree(iop); }
If the filesystem has block size < page size and we end up calling iomap_page_create() in iomap_page_mkwrite_actor(), the uptodate bits would be zero, which causes us to skip writeback of blocks which are !uptodate in iomap_writepage_map(). This can lead to user data loss. Found using generic/127 with the THP patches. I don't think this can be reproduced on mainline using that test (the THP code causes iomap_pages to be discarded more frequently), but inspection shows it can happen with an appropriate series of operations. Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> --- fs/iomap/buffered-io.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)