[Fwd: 2.4 journal overflow fix, please forward]

[Fwd: 2.4 journal overflow fix, please forward]

[Hans Reiser]

[-- Attachment #1: Type: text/plain, Size: 25 bytes --]

Please apply.

-- 
Hans


[-- Attachment #2: 2.4 journal overflow fix, please forward --]
[-- Type: message/rfc822, Size: 2815 bytes --]

From: Oleg Drokin <green@namesys.com>
To: reiser@namesys.com
Subject: 2.4 journal overflow fix, please forward
Date: Tue, 4 Mar 2003 16:52:24 +0300
Message-ID: <20030304165224.B8434@namesys.com>

Hello!

    This changeset fixes possible journal overflow (and assertion) while deleting
    large highly fragmented files on large enough fs (each file block should
    be in different bitmap). While this condition is hard to trigger, it is still
    possible and Philippe Gramoulle managed to reproduce it for us.

    Please pull from bk://namesys.com/bk/reiser3-linux-2.4-journal-overflow-fix

    Tested by me and Elena, reviewed by Chris Mason.

Diffstat:
 stree.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+)

Plain text path:

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1009  -> 1.1010 
#	 fs/reiserfs/stree.c	1.20    -> 1.21   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/03/04	green@angband.namesys.com	1.1010
# reiserfs: Fix possible transaction overflow when deleting highly fragmented large files.
# 
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
--- a/fs/reiserfs/stree.c	Tue Mar  4 16:48:52 2003
+++ b/fs/reiserfs/stree.c	Tue Mar  4 16:48:52 2003
@@ -1125,6 +1125,21 @@
 		journal_mark_dirty (th, p_s_sb, p_s_bh);
 		inode->i_blocks -= p_s_sb->s_blocksize / 512;
 		reiserfs_free_block(th, tmp);
+		/* In case of big fragmentation it is possible that each block
+		   freed will cause dirtying of one more bitmap and then we will
+		   quickly overflow our transaction space. This is a
+		   counter-measure against that scenario */
+		if (journal_transaction_should_end(th, th->t_blocks_allocated)) {
+		    int orig_len_alloc = th->t_blocks_allocated ;
+		    pathrelse(p_s_path) ;
+
+		    journal_end(th, p_s_sb, orig_len_alloc) ;
+		    journal_begin(th, p_s_sb, orig_len_alloc) ;
+		    reiserfs_update_inode_transaction(inode) ;
+		    need_research = 1;
+		    break;
+		}
+
 		if ( item_moved (&s_ih, p_s_path) )  {
 			need_research = 1;
 			break ;