Prevent direct I/O from mapping extents beyond eof

With the help from some tracing I found that we try to map extents beyond eof when doing a direct I/O read. It appears that the way to inform the generic direct I/O path (ie do_direct_IO()) that we have breached eof is to return an unmapped buffer from xfs_get_blocks_direct(). This will cause do_direct_IO() to jump to the hole handling code where is will check for eof and then abort.

This problem was found because a direct I/O read was trying to map beyond eof and was encountering delayed allocations. The delayed allocations beyond eof are speculative allocations and they didn't get converted when the direct I/O flushed the file because there was only enough space in the current AG to convert and write out the dirty pages within eof. Note that xfs_iomap_write_allocate() wont necessarily convert all the delayed allocation passed to it - it will return after allocating the first extent - so if the delayed allocation extends beyond eof then it will stay that way.

This change will detect a direct I/O read beyond eof:

Quoted 16 lines · Lachlan McIlroy

With the help from some tracing I found that we try to map extents beyond eof when doing a direct I/O read. It appears that the way to inform the generic direct I/O path (ie do_direct_IO()) that we have breached eof is to return an unmapped buffer from xfs_get_blocks_direct(). This will cause do_direct_IO() to jump to the hole handling code where is will check for eof and then abort.

This problem was found because a direct I/O read was trying to map beyond eof and was encountering delayed allocations. The delayed allocations beyond eof are speculative allocations and they didn't get converted when the direct I/O flushed the file because there was only enough space in the current AG to convert and write out the dirty pages within eof. Note that xfs_iomap_write_allocate() wont necessarily convert all the delayed allocation passed to it - it will return after allocating the first extent - so if the delayed allocation extends beyond eof then it will stay that way.

Quoted 1 line

This change will detect a direct I/O read beyond eof:

The change looks good to me, but I really think the direct I/O could should never send down requests like this down to the filesystems. akpm and -fsdevel Cc'ed.

Oh gee, I forget, and so many people have done drivebys on that code...

We _could_ add additional i_size checking into direct-io.c but bear in mind that it would be best-effort unreliable stuff. The code will still be tripped up by concurrent extends and concurrent truncates.

So we'll still end up calling the fs for blocks outside i_size, only less commonly. I think.