The following patch to the generic direct IO code fixes a problem we've
come across that affects the way XFS interacts with it.  Between 2.6.5 and
2.6.6 several changes to direct IO were made, in particular the
fallback-to-buffered path was introduced in that timeframe.

Those changes split the locking done within direct-io.c into two cases -
generic filesystems and blkdev/XFS.  There is no locking done for the
second case, and we also never set the create parameter to the get_blocks
call (via direct_io_worker ->do_direct_IO->get_more_blocks) for that case. 
This meant that XFS was accidentally no longer being told when a direct IO
write was being performed, which in turn meant that XFS would (often -
depending on the inode's size and bmap) tell get_more_blocks that it was
mapping to a hole.  It also means that currently all direct writes into XFS
are falling back to buffered writes.  Further, skipping the i_alloc_sem
locking entirely is not correct for us, we are relying on that aspect of
the generic locking.

The fallback behaviour from direct to buffered is "silent", so we didn't
actually pick up on these problems until just recently, unfortunately.

The approach I've taken here is to split the blkdev/XFS case into two, and
corrected the new third case behaviour for the functionality XFS provides. 
The generic behavior used by other filesystems remains unchanged, as does
direct IO to the block device, and XFS now becomes fully functional.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>