| Message ID | cover.1578907890.git.riteshh@linux.ibm.com |
|---|---|
| Headers | show |
| Series | ext4: Fix stale data read exposure problem with DIO read/page_mkwrite | expand |
> Currently there is a small race window as pointed out by Jan [2] where, when > ext4 tries to allocate a written block for mapped files and if DIO read is in > progress, then this may result into stale data read exposure problem. Do we have a test case for the problem?
On 1/14/20 10:09 PM, Christoph Hellwig wrote: >> Currently there is a small race window as pointed out by Jan [2] where, when >> ext4 tries to allocate a written block for mapped files and if DIO read is in >> progress, then this may result into stale data read exposure problem. > > Do we have a test case for the problem? I am not very sure if we have it in xfstests, (since I guess, DIO read during mmap writes is not well supported anyways). But sure I was anyway thinking of writing one for my unit testing. Till now I was mainly following that theoretically it is possible, although it may be hard to catch it practically. > Please add at very least the fsdevel and xfs lists to iomap patches. Yes, sorry about that. Will cc' in next time. -ritesh
Hello All, Sorry for the delay on this patchset. I guess it's because there were lot of other context switches while working at it. Please note that this is a RFC patch and also a WIP (due to a open problem listed below). There is also another thread going on where making dioread_nolock as default mount opt [1] is being discussed. That approach should also solve the given race at hand. But since nothing is finalized yet, so I wanted to get this patch out for early review/discussion. About patch =========== Currently there is a small race window as pointed out by Jan [2] where, when ext4 tries to allocate a written block for mapped files and if DIO read is in progress, then this may result into stale data read exposure problem. This patch tries to fix the mentioned issue by: 1. For non-delalloc path, page_mkwrite will use unwritten blocks by default for extent based files. 2. For delalloc path, we check if DIO is in progress during writeback. If yes, then we use unwritten blocks method to avoid this race. Patch-1: This moves the inode_dio_begin() call before calling for filemap_write_and_wait_range. Patch-2: This implementes the points (1) & (2) mentioned above. Testing: ======== xfstests "-g auto" ran fine except one warn_on issue. Below tests are giving kernel WARN_ON from "ext4_journalled_invalidatepage()", with 1024 blocksize, 4K pagesize & with "nodelalloc,data=journal" mount opt. - generic/013, generic/269, generic/270 In case if someone has any pointers around this, I could dig more deeper into this. References ========== [1] https://www.spinics.net/lists/linux-ext4/msg69224.html [2] https://lore.kernel.org/linux-ext4/20190926134726.GA28555@quack2.suse.cz/ Ritesh Harjani (2): iomap: direct-io: Move inode_dio_begin before filemap_write_and_wait_range ext4: Fix stale data read issue with DIO read & ext4_page_mkwrite path fs/ext4/inode.c | 45 +++++++++++++++++++++++++++++++------------- fs/iomap/direct-io.c | 17 +++++++++++++---- 2 files changed, 45 insertions(+), 17 deletions(-)