summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_log.c
diff options
context:
space:
mode:
authorLachlan McIlroy <lachlan@sgi.com>2008-09-17 08:50:14 +0200
committerLachlan McIlroy <lachlan@redback.melbourne.sgi.com>2008-09-17 08:50:14 +0200
commit364f358a734ddcd827c662ccbfa58ee3ac510762 (patch)
tree2af362aa418b145e0626066ed2c8b3b0918630eb /fs/xfs/xfs_log.c
parent[XFS] Fix regression introduced by remount fixup (diff)
downloadlinux-364f358a734ddcd827c662ccbfa58ee3ac510762.tar.xz
linux-364f358a734ddcd827c662ccbfa58ee3ac510762.zip
[XFS] 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. SGI-PV: 983683 SGI-Modid: xfs-linux-melb:xfs-kern:31929a Signed-off-by: Lachlan McIlroy <lachlan@sgi.com> Signed-off-by: Christoph Hellwig <hch@infradead.org>
Diffstat (limited to 'fs/xfs/xfs_log.c')
0 files changed, 0 insertions, 0 deletions