[PATCH] reiserfs: reiserfs_file_write will lose error code when a 0-length write occurs w/ O_SYNC

[PATCH] reiserfs: reiserfs_file_write will lose error code when a 0-length write occurs w/ O_SYNC

[Jeff Mahoney]

 When an error occurs in reiserfs_file_write before any data is written, and
 O_SYNC is set, the return code of generic_osync_write will overwrite the
 error code, losing it.

 This patch ensures that generic_osync_inode() doesn't run under an error
 condition, losing the error. This duplicates the logic from
 generic_file_buffered_write().

Signed-off-by: Jeff Mahoney <jeffm@suse.com>

diff -ruNpX dontdiff linux-2.6.15/fs/reiserfs/file.c linux-2.6.15.reiserfs/fs/reiserfs/file.c
--- linux-2.6.15/fs/reiserfs/file.c	2006-03-02 12:10:04.000000000 -0500
+++ linux-2.6.15.reiserfs/fs/reiserfs/file.c	2006-03-02 16:08:49.000000000 -0500
@@ -1563,10 +1563,10 @@ static ssize_t reiserfs_file_write(struc
 		}
 	}
 
-	if ((file->f_flags & O_SYNC) || IS_SYNC(inode))
-		res =
-		    generic_osync_inode(inode, file->f_mapping,
-					OSYNC_METADATA | OSYNC_DATA);
+	if (likely(res >= 0) &&
+	    (unlikely((file->f_flags & O_SYNC) || IS_SYNC(inode))))
+		res = generic_osync_inode(inode, file->f_mapping,
+		                          OSYNC_METADATA | OSYNC_DATA);
 
 	mutex_unlock(&inode->i_mutex);
 	reiserfs_async_progress_wait(inode->i_sb);
-- 
Jeff Mahoney
SuSE Labs

Re: [PATCH] reiserfs: reiserfs_file_write will lose error code when a 0-length write occurs w/ O_SYNC

[Andrew Morton]

Boy, lots of reiserfs things happening lately.

We presently have:

reiserfs-do-not-check-if-unsigned-0.patch	[ merged today ]
reiserfs-fix-transaction-overflowing.patch
reiserfs-handle-trans_id-overflow.patch
reiserfs-reiserfs_file_write-will-lose-error-code-when-a-0-length-write-occurs-w-o_sync.patch
reiserfs-cleanups.patch
reiserfs-use-balance_dirty_pages_ratelimited_nr-in-reiserfs_file_write.patch
reiserfs-fix-unaligned-bitmap-usage.patch

The question is, which of these are sufficiently serious-and-safe for
2.6.16?

I haven't seen any resierfs bug reports for quite some time (except for the
usual dribble of it-goes-oops-in-prints.c-when-something-went-wrong
reports).

So I'm inclined to hold off on all the above?

Re: [PATCH] reiserfs: reiserfs_file_write will lose error code when a 0-length write occurs w/ O_SYNC

[Linus Torvalds]

On Thu, 2 Mar 2006, Andrew Morton wrote:
>
> reiserfs-fix-unaligned-bitmap-usage.patch

I applied this one already, it seemed obvious.

(And then I've applied the ones you forwarded to me, of course).

		Linus

Re: [PATCH] reiserfs: reiserfs_file_write will lose error code when a 0-length write occurs w/ O_SYNC

[Hans Reiser]

Andrew Morton wrote:

>Boy, lots of reiserfs things happening lately.
>
>We presently have:
>
>reiserfs-do-not-check-if-unsigned-0.patch	[ merged today ]
>reiserfs-fix-transaction-overflowing.patch
>reiserfs-handle-trans_id-overflow.patch
>reiserfs-reiserfs_file_write-will-lose-error-code-when-a-0-length-write-occurs-w-o_sync.patch
>reiserfs-cleanups.patch
>reiserfs-use-balance_dirty_pages_ratelimited_nr-in-reiserfs_file_write.patch
>reiserfs-fix-unaligned-bitmap-usage.patch
>
>The question is, which of these are sufficiently serious-and-safe for
>2.6.16?
>
>I haven't seen any resierfs bug reports for quite some time (except for the
>usual dribble of it-goes-oops-in-prints.c-when-something-went-wrong
>reports).
>
>So I'm inclined to hold off on all the above?
>
>
>  
>
I suggest that they sit in -mm or an rc for ~2 weeks before they go in. 
If 2.6.16 is coming out before then, then let it ship without them.  All
of these things are pretty obscure/rare, so not unsettling the code
matters more than getting them in.

Re: [PATCH] reiserfs: reiserfs_file_write will lose error code when a 0-length write occurs w/ O_SYNC

[Clemens Eisserer]

> I suggest that they sit in -mm or an rc for ~2 weeks before they go in.
> If 2.6.16 is coming out before then, then let it ship without them.  All
> of these things are pretty obscure/rare, so not unsettling the code
> matters more than getting them in.

I know this sounds quite a bit stupid but does that mean Reiser4 will
be included into the mainline kernel? Would be great :-)

lg Clemens