reiser4 OOPSes and panics when out of memory

reiser4 OOPSes and panics when out of memory

[maciejej]

Has my previous post
(http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
overlooked, or have I not provided enough information? Do I need to
reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?

The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
physical memory.

Re: reiser4 OOPSes and panics when out of memory

[Vladimir V. Saveliev]

Hello

On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> Has my previous post
> (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> overlooked, or have I not provided enough information? Do I need to
> reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> 

your test crashes reiser4 on my test box. I hope to get a patch ready
later today. Not sure that I got the same problem as you, though. We
will see. 

> The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> physical memory.
> 
> 

Re: reiser4 OOPSes and panics when out of memory

[Vladimir V. Saveliev]

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

Hello

On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> Hello
> 
> On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> > Has my previous post
> > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > overlooked, or have I not provided enough information? Do I need to
> > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > 
> 

please try the attached patch.

> your test crashes reiser4 on my test box. I hope to get a patch ready
> later today. Not sure that I got the same problem as you, though. We
> will see. 
> 
> > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > physical memory.
> > 
> > 
> 
> 

[-- Attachment #2: Type: text/x-patch, Size: 1962 bytes --]


diff -puN fs/reiser4/plugin/file_ops_readdir.c~reiser4-fix-readdir fs/reiser4/plugin/file_ops_readdir.c
--- linux-2.6.17-mm6/fs/reiser4/plugin/file_ops_readdir.c~reiser4-fix-readdir	2006-07-17 18:43:50.000000000 +0400
+++ linux-2.6.17-mm6-vs/fs/reiser4/plugin/file_ops_readdir.c	2006-07-17 19:02:38.000000000 +0400
@@ -349,6 +349,7 @@ feed_entry(struct file *f,
 	 */
 	assert("nikita-3436", lock_stack_isclean(get_current_lock_stack()));
 
+	txn_restart_current();
 	result = filldir(dirent, name, (int)strlen(name),
 			 /* offset of this entry */
 			 f->f_pos,
diff -puN fs/reiser4/plugin/file/file.c~reiser4-fix-readdir fs/reiser4/plugin/file/file.c
--- linux-2.6.17-mm6/fs/reiser4/plugin/file/file.c~reiser4-fix-readdir	2006-07-17 20:39:11.000000000 +0400
+++ linux-2.6.17-mm6-vs/fs/reiser4/plugin/file/file.c	2006-07-17 21:35:31.000000000 +0400
@@ -781,9 +781,12 @@ int find_or_create_extent(struct page *p
 
 	lock_page(page);
 	node = jnode_of_page(page);
-	unlock_page(page);
-	if (IS_ERR(node))
+	if (IS_ERR(node)) {
+		unlock_page(page);
 		return PTR_ERR(node);
+	}
+	JF_SET(node, JNODE_WRITE_PREPARED);
+	unlock_page(page);
 
 	if (node->blocknr == 0) {
 		plugged_hole = 0;
@@ -791,6 +794,7 @@ int find_or_create_extent(struct page *p
 				       (loff_t)page->index << PAGE_CACHE_SHIFT,
 				       &plugged_hole);
 		if (result) {
+			JF_CLR(node, JNODE_WRITE_PREPARED);
 			jput(node);
 			warning("", "update_extent failed: %d", result);
 			return result;
@@ -806,6 +810,7 @@ int find_or_create_extent(struct page *p
 	}
 
 	BUG_ON(node->atom == NULL);
+	JF_CLR(node, JNODE_WRITE_PREPARED);
 	jput(node);
 
 	if (get_current_context()->entd) {
@@ -1729,7 +1734,9 @@ ssize_t read_unix_file(struct file *file
 			return RETERR(-EFAULT);
 		}
 
-		read = read_file(hint, file, buf, left, off);
+		read = read_file(hint, file, buf,
+				 left > PAGE_CACHE_SIZE ? PAGE_CACHE_SIZE : left,
+				 off);
 
  		drop_nonexclusive_access(uf_info);
 

_

Re: reiser4 OOPSes and panics when out of memory

[Jake Maciejewski]

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

Thanks for the patch, but I can still reproduce the problem. I've been
running the attached program to try to speed up the testing process a
bit. Interrupting and restarting the compilation loop also seems to
help.

If I had hours to wait, it would probably crash eventually without
additional encouragement, but I'm doing everything as an unprivileged
user, so I don't think my tests are unreasonable.

Anyway, I'm still getting a panic with debug enabled:

reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:

Without debug enabled I've seen:

http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz

but usually I get:

http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz

with no corruption (although I've been rebooting before complete
failure).

On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
> Hello
> 
> On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> > Hello
> > 
> > On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> > > Has my previous post
> > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > > overlooked, or have I not provided enough information? Do I need to
> > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > > 
> > 
> 
> please try the attached patch.
> 
> > your test crashes reiser4 on my test box. I hope to get a patch ready
> > later today. Not sure that I got the same problem as you, though. We
> > will see. 
> > 
> > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > > physical memory.
> > > 
> > > 
> > 
> > 
-- 
Jake Maciejewski <maciejej@msoe.edu>

[-- Attachment #2: waste_memory.c --]
[-- Type: text/x-csrc, Size: 792 bytes --]

#include <sys/sysinfo.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>

#define MB 1048576
#define DEFAULT_SAVE 0
#define DELAY 10

int main(int argc, char *argv[]) {

struct sysinfo info;
size_t waste, save;
void *ptr;

sysinfo(&info);

if(argc>1)
	save = atoi(argv[1])*MB;
else
	save = DEFAULT_SAVE*MB;

if( save >= info.freeram ) {
	fprintf(stderr, "error: only %iMB free\n", (int)info.freeram/MB);
	return ENOMEM;
	}

while(1) {
	sysinfo(&info);
	waste = (info.freeram-save)>0 ? info.freeram-save : 0;

	ptr = malloc(waste);
	if( ptr == 0 ) {
		perror("malloc() failed\n");
		return ENOMEM;
		}

	printf("reserving %iMB, wasting %iMB\n", (int)save/MB, (int)waste/MB);
	memset(ptr, 0, waste);

	sleep(DELAY);
	free(ptr);
	}

return 0;
}

Re: reiser4 OOPSes and panics when out of memory

[Vladimir V. Saveliev]

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

Hello

On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote:
> Thanks for the patch, but I can still reproduce the problem. I've been
> running the attached program to try to speed up the testing process a
> bit. Interrupting and restarting the compilation loop also seems to
> help.
> 

ok

> If I had hours to wait, it would probably crash eventually without
> additional encouragement, but I'm doing everything as an unprivileged
> user, so I don't think my tests are unreasonable.
> 
> Anyway, I'm still getting a panic with debug enabled:
> 
> reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> 

The attached patch should fix the above.

> Without debug enabled I've seen:
> 
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz
> 
> but usually I get:
> 
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz
> 
> with no corruption (although I've been rebooting before complete
> failure).
> 
> On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
> > Hello
> > 
> > On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> > > Hello
> > > 
> > > On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> > > > Has my previous post
> > > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > > > overlooked, or have I not provided enough information? Do I need to
> > > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > > > 
> > > 
> > 
> > please try the attached patch.
> > 
> > > your test crashes reiser4 on my test box. I hope to get a patch ready
> > > later today. Not sure that I got the same problem as you, though. We
> > > will see. 
> > > 
> > > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > > > physical memory.
> > > > 
> > > > 
> > > 
> > > 

[-- Attachment #2: Type: text/x-patch, Size: 1058 bytes --]

readdir has to txn_restart, therefore, grab space for stat data update has to be forced

---
commit f1cea9c0a8db0977077d54562677514d6d736690
tree 95479706299276d7c23efd337216501b0dfd69c2
parent bbf99f71c140d7758a6223a557fa4a4d2b5c384e
author Vladimir V. Saveliev <vs@tribesman.namesys.com> Tue, 18 Jul 2006 18:13:05 +0400
committer Vladimir V. Saveliev <vs@tribesman.namesys.com> Tue, 18 Jul 2006 18:13:05 +0400

 plugin/file_ops_readdir.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/plugin/file_ops_readdir.c b/plugin/file_ops_readdir.c
index 04ada21..dfdb68d 100644
--- a/plugin/file_ops_readdir.c
+++ b/plugin/file_ops_readdir.c
@@ -629,7 +629,7 @@ int readdir_common(struct file *f /* dir
 	detach_fsdata(f);
 
 	/* try to update directory's atime */
-	if (reiser4_grab_space(inode_file_plugin(inode)->estimate.update(inode),
+	if (reiser4_grab_space_force(inode_file_plugin(inode)->estimate.update(inode),
 			       BA_CAN_COMMIT) != 0)
 		warning("", "failed to update atime on readdir: %llu",
 			get_inode_oid(inode));

Re: reiser4 OOPSes and panics when out of memory

[Jake Maciejewski]

Thanks. Now with debug enabled I've gotten:

http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/panic1.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check_after_--fix.txt.gz

and

http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2.txt.gz
followed by
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2b.txt.gz

and without debug:

http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages3.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check_after_--fix.txt.gz

On Tue, 2006-07-18 at 18:18 +0400, Vladimir V. Saveliev wrote:
> Hello
> 
> On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote:
> > Thanks for the patch, but I can still reproduce the problem. I've been
> > running the attached program to try to speed up the testing process a
> > bit. Interrupting and restarting the compilation loop also seems to
> > help.
> > 
> 
> ok
> 
> > If I had hours to wait, it would probably crash eventually without
> > additional encouragement, but I'm doing everything as an unprivileged
> > user, so I don't think my tests are unreasonable.
> > 
> > Anyway, I'm still getting a panic with debug enabled:
> > 
> > reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> > Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> > 
> 
> The attached patch should fix the above.
> 
> > Without debug enabled I've seen:
> > 
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz
> > 
> > but usually I get:
> > 
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz
> > 
> > with no corruption (although I've been rebooting before complete
> > failure).
> > 
> > On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
> > > Hello
> > > 
> > > On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> > > > Hello
> > > > 
> > > > On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> > > > > Has my previous post
> > > > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > > > > overlooked, or have I not provided enough information? Do I need to
> > > > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > > > > 
> > > > 
> > > 
> > > please try the attached patch.
> > > 
> > > > your test crashes reiser4 on my test box. I hope to get a patch ready
> > > > later today. Not sure that I got the same problem as you, though. We
> > > > will see. 
> > > > 
> > > > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > > > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > > > > physical memory.
> > > > > 
> > > > > 
> > > > 
> > > > 
-- 
Jake Maciejewski <maciejej@msoe.edu>

Re: reiser4 OOPSes and panics when out of memory

[Vladimir V. Saveliev]

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

Hello

On Wed, 2006-07-19 at 07:28 -0600, Jake Maciejewski wrote:
> Thanks. Now with debug enabled I've gotten:
> 
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/panic1.txt.gz

the attached patch fixes a problem nikita-2967 reports about. Would you
please check whther it helps.

> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--fix.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check_after_--fix.txt.gz
> 
> and
> 
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2.txt.gz
> followed by
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2b.txt.gz
> 
> and without debug:
> 
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages3.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--fix.txt.gz
> http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check_after_--fix.txt.gz
> 
> On Tue, 2006-07-18 at 18:18 +0400, Vladimir V. Saveliev wrote:
> > Hello
> > 
> > On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote:
> > > Thanks for the patch, but I can still reproduce the problem. I've been
> > > running the attached program to try to speed up the testing process a
> > > bit. Interrupting and restarting the compilation loop also seems to
> > > help.
> > > 
> > 
> > ok
> > 
> > > If I had hours to wait, it would probably crash eventually without
> > > additional encouragement, but I'm doing everything as an unprivileged
> > > user, so I don't think my tests are unreasonable.
> > > 
> > > Anyway, I'm still getting a panic with debug enabled:
> > > 
> > > reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> > > Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> > > 
> > 
> > The attached patch should fix the above.
> > 
> > > Without debug enabled I've seen:
> > > 
> > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
> > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
> > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
> > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz
> > > 
> > > but usually I get:
> > > 
> > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz
> > > 
> > > with no corruption (although I've been rebooting before complete
> > > failure).
> > > 
> > > On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
> > > > Hello
> > > > 
> > > > On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> > > > > Hello
> > > > > 
> > > > > On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> > > > > > Has my previous post
> > > > > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > > > > > overlooked, or have I not provided enough information? Do I need to
> > > > > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > > > > > 
> > > > > 
> > > > 
> > > > please try the attached patch.
> > > > 
> > > > > your test crashes reiser4 on my test box. I hope to get a patch ready
> > > > > later today. Not sure that I got the same problem as you, though. We
> > > > > will see. 
> > > > > 
> > > > > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > > > > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > > > > > physical memory.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 

[-- Attachment #2: Type: text/x-patch, Size: 825 bytes --]


diff -puN fs/reiser4/plugin/file/file.c~reiser4-add-missing-unlock fs/reiser4/plugin/file/file.c
--- linux-2.6.17-mm6/fs/reiser4/plugin/file/file.c~reiser4-add-missing-unlock	2006-07-19 18:12:14.000000000 +0400
+++ linux-2.6.17-mm6-vs/fs/reiser4/plugin/file/file.c	2006-07-19 18:13:50.000000000 +0400
@@ -1636,14 +1636,18 @@ static size_t read_file(hint_t * hint, s
 			/* error happened */
 			break;
 
-		if (coord->between != AT_UNIT)
+		if (coord->between != AT_UNIT) {
 			/* there were no items corresponding to given offset */
+			done_lh(hint->ext_coord.lh);
 			break;
+		}
 
 		loaded = coord->node;
 		result = zload(loaded);
-		if (unlikely(result))
+		if (unlikely(result)) {
+			done_lh(hint->ext_coord.lh);
 			break;
+		}
 
 		if (hint->ext_coord.valid == 0)
 			validate_extended_coord(&hint->ext_coord,

_

Re: reiser4 OOPSes and panics when out of memory

[Jake Maciejewski]

I haven't hit nikita-2967 again, but I got several other interesting
results.

The first panic didn't cause corruption:
        reiser4 panicked cowardly: reiser4[pdflush(16048)]: scan_by_coord (fs/reiser4/flush.c:3431)[nikita-3435]:
        Kernel panic - not syncing: reiser4[pdflush(16048)]: scan_by_coord (fs/reiser4/flush.c:3431)[nikita-3435]:
        
The second affected my root partition, not the one I was stress testing:
        reiser4 panicked cowardly: reiser4[ent:hda3!(841)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]:
        Kernel panic - not syncing: reiser4[end:hda3!(841)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]:
        
I booted from a live CD to document the corruption (which seemed to have been completely fixed).
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck2_--check_hda3.txt.gz
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck2_--fix_hda3.txt.gz
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck2_--check_after_--fix_hda3.txt.gz
        
When I rebooted, I got another panic when my system tried to mount / read-write:
        reiser4 pnicked cowardly: reiser4[mount(3614)]: check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]:
        Kernel panic - not syncing: reiser4[mount(3614)]: check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]:
        
On the second reboot, it worked again.

The third panic was one I've seen before
(http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2):
        reiser4 panicked cowardly: reiser4[rm(25870)]: sibling_list_remove (fs/reiser4/tree_walk.c:813)[zam-32245]:
        Kernel panic - not syncing: reiser4[rm(25870)]: sibling_list_remove (fs/reiser4/tree_walk.c:813)[zam-32245]:
        
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck3_--check.txt.gz
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck3_--fix.txt.gz
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck3_--check_after_--fix.txt.gz
        
The fourth was another repeat:
        reiser4 panicked cowardly: reiser4[pdflush(198)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]:
        Kernel panic - not syncing: reiser4[pdflush(198)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]:
        
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck4_--check.txt.gz
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck4_--fix.txt.gz
        http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck4_--check_after_fix.txt.gz
        
Where the fsck logs from tests 3 and 4 say entries were removed, they
mean it. Those files were GONE. I would expect this to happen to
temporary files being written during the panic, but header files should
only have been open for reading if at all. I have metadata dumps from
before and after one of the fsck --fix runs. Should I make them
available?
        
On Wed, 2006-07-19 at 18:07 +0400, Vladimir V. Saveliev wrote:
> Hello
> 
> On Wed, 2006-07-19 at 07:28 -0600, Jake Maciejewski wrote:
> > Thanks. Now with debug enabled I've gotten:
> > 
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/panic1.txt.gz
> 
> the attached patch fixes a problem nikita-2967 reports about. Would you
> please check whther it helps.
> 
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--fix.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check_after_--fix.txt.gz
> > 
> > and
> > 
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2.txt.gz
> > followed by
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2b.txt.gz
> > 
> > and without debug:
> > 
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages3.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--fix.txt.gz
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check_after_--fix.txt.gz
> > 
> > On Tue, 2006-07-18 at 18:18 +0400, Vladimir V. Saveliev wrote:
> > > Hello
> > > 
> > > On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote:
> > > > Thanks for the patch, but I can still reproduce the problem. I've been
> > > > running the attached program to try to speed up the testing process a
> > > > bit. Interrupting and restarting the compilation loop also seems to
> > > > help.
> > > > 
> > > 
> > > ok
> > > 
> > > > If I had hours to wait, it would probably crash eventually without
> > > > additional encouragement, but I'm doing everything as an unprivileged
> > > > user, so I don't think my tests are unreasonable.
> > > > 
> > > > Anyway, I'm still getting a panic with debug enabled:
> > > > 
> > > > reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> > > > Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]:
> > > > 
> > > 
> > > The attached patch should fix the above.
> > > 
> > > > Without debug enabled I've seen:
> > > > 
> > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
> > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
> > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
> > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz
> > > > 
> > > > but usually I get:
> > > > 
> > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz
> > > > 
> > > > with no corruption (although I've been rebooting before complete
> > > > failure).
> > > > 
> > > > On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
> > > > > Hello
> > > > > 
> > > > > On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> > > > > > Hello
> > > > > > 
> > > > > > On Sun, 2006-07-16 at 12:44 -0500, maciejej@msoe.edu wrote:
> > > > > > > Has my previous post
> > > > > > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > > > > > > overlooked, or have I not provided enough information? Do I need to
> > > > > > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > please try the attached patch.
> > > > > 
> > > > > > your test crashes reiser4 on my test box. I hope to get a patch ready
> > > > > > later today. Not sure that I got the same problem as you, though. We
> > > > > > will see. 
> > > > > > 
> > > > > > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > > > > > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > > > > > > physical memory.
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > 
-- 
Jake Maciejewski <maciejej@msoe.edu>