Re: [RFC] write(2) semantics wrt return values and current position

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Apr 09, 2015 at 12:23:33PM +0100, Al Viro wrote:
> On Thu, Apr 09, 2015 at 12:48:44PM +0800, Junxiao Bi wrote:
> 
> > Looks like if generic_file_direct_write() return -EIOCBQUEUED and
> > IS_SYNC(inode) is true, the sync range is also wrong.
> 
> *blink*
> 
> But in that case it shouldn't do any syncing at all...  Oh, right.
> Unlike generic_file_write_iter(), if goes into the sync pathway
> in that case (which was another long-standing bug there)...
> 
> Fixed and force-pushed.

	BTW, what about the locks needed to stabilize the file size?
generic_write_checks() in there looks like it's called too late - we
can't tell a damn thing about alignment until we do it, so at the very
least we might need to recheck that.

	Can we move it _before_ ocfs2_prepare_inode_for_write()?
Having it done twice in case we end up on "can't really do O_DIRECT, unlock
and redo everything without asking for direct IO" path is not a problem -
we just need to save the original count and restore it before that
goto relock in there.

	Do we hold enough locks to make sure that file size won't change
under us?