Segfault on nonexistent journal device

Segfault on nonexistent journal device

[Adam Nielsen]

Hi all,

Further to my previous message, I've found that if you try to mount a reiserfs device and tell it to use a nonexistent log device, you get a segfault and a kernel NULL pointer dereference - in case this hasn't already been fixed in a newer release, this is what I did:

$ mount -t reiserfs /dev/cdrom /mnt/cdrom -o ro,nolog,jdev=t
Segmentation fault

kernel: ReiserFS: hdc: warning: journal_init_dev: Cannot open 't': -2
kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
kernel:  printing eip:
kernel: c018b5b2
kernel: *pde = 00000000
kernel: Oops: 0000 [#1]
...
kernel: Call Trace:
kernel:  [<c01b27b0>] journal_init_dev+0x140/0x1b0
kernel:  [<c01af2ba>] allocate_bitmap_node+0x3a/0xa0
kernel:  [<c01af3ce>] allocate_bitmap_nodes+0x1e/0x50
...

It seems that after this I can no longer mount any reiserfs volumes - time for a restart I think.

Cheers,
Adam.

Re: Segfault on nonexistent journal device

[Edward Shishkin]

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

Adam Nielsen wrote:

>Hi all,
>
>Further to my previous message, I've found that if you try to mount a reiserfs device and tell it to use a nonexistent log device, you get a segfault and a kernel NULL pointer dereference - in case this hasn't already been fixed in a newer release, this is what I did:
>
>$ mount -t reiserfs /dev/cdrom /mnt/cdrom -o ro,nolog,jdev=t
>Segmentation fault
>
>kernel: ReiserFS: hdc: warning: journal_init_dev: Cannot open 't': -2
>kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
>kernel:  printing eip:
>kernel: c018b5b2
>kernel: *pde = 00000000
>kernel: Oops: 0000 [#1]
>...
>kernel: Call Trace:
>kernel:  [<c01b27b0>] journal_init_dev+0x140/0x1b0
>kernel:  [<c01af2ba>] allocate_bitmap_node+0x3a/0xa0
>kernel:  [<c01af3ce>] allocate_bitmap_nodes+0x1e/0x50
>...
>
>It seems that after this I can no longer mount any reiserfs volumes - time for a restart I think.
>
>Cheers,
>Adam.
>
>
>  
>
The fix against 2.6.11 is attached
Edward.

[-- Attachment #2: journal_init_dev_fix.patch --]
[-- Type: text/x-patch, Size: 453 bytes --]

diff -urN linux-2.6.11.orig/fs/reiserfs/journal.c linux-2.6.11/fs/reiserfs/journal.c
--- linux-2.6.11.orig/fs/reiserfs/journal.c	2005-04-18 13:55:44.000000000 +0400
+++ linux-2.6.11/fs/reiserfs/journal.c	2005-04-18 14:52:25.471889996 +0400
@@ -2323,6 +2323,7 @@
 	}
 	if( result != 0 ) {
 		release_journal_dev( super, journal );
+		return result;
 	}
 	reiserfs_info(super, "journal_init_dev: journal device: %s\n",
 		bdevname(journal->j_dev_bd, b));

searching on groups of files in reiser4

[Nicolas Smallwood]

Hello,

My question concerns searching through a group of files on reiser4.
Assume that we are dealing with a directory full of files (say a few 
million or so).

If I am currently viewing a given file, and wish to iterate to the next 
file in the directory,
is there a method to do so without opening the base directory and moving 
from one
directory entry to the next until you find it?

In short, are there any constructs to perform a binary search on these 
directories instead of a slow
O(n) search using seekdir or whatever method?

Or is some type of plugin our best route?


Thank You,

Nicolas Smallwood
Maya Design

Re: searching on groups of files in reiser4

[Hans Reiser]

Nicolas Smallwood wrote:

> Hello,
>
> My question concerns searching through a group of files on reiser4.
> Assume that we are dealing with a directory full of files (say a few 
> million or so).
>
> If I am currently viewing a given file, and wish to iterate to the 
> next file in the directory,
> is there a method to do so without opening the base directory and 
> moving from one
> directory entry to the next until you find it?
>
> In short, are there any constructs to perform a binary search on these 
> directories instead of a slow
> O(n) search using seekdir or whatever method?
>
> Or is some type of plugin our best route?

We can write some sort of plugin for you, and it will be the best 
solution.  I assume that readdir() does not do what you need because the 
order you need to iterate in is not that of readdir()?  (Your exact 
phrasing would seem to indicate that your needs are met by iterating 
through the directory using readdir() ).

>
>
> Thank You,
>
> Nicolas Smallwood
> Maya Design
>
>
>

Re: searching on groups of files in reiser4

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:
> Nicolas Smallwood wrote:
> 
>> Hello,
>>
>> My question concerns searching through a group of files on reiser4.
>> Assume that we are dealing with a directory full of files (say a few
>> million or so).
>>
>> If I am currently viewing a given file, and wish to iterate to the
>> next file in the directory,
>> is there a method to do so without opening the base directory and
>> moving from one
>> directory entry to the next until you find it?
>>
>> In short, are there any constructs to perform a binary search on these
>> directories instead of a slow
>> O(n) search using seekdir or whatever method?
>>
>> Or is some type of plugin our best route?
> 
> 
> We can write some sort of plugin for you, and it will be the best
> solution.  I assume that readdir() does not do what you need because the
> order you need to iterate in is not that of readdir()?  (Your exact
> phrasing would seem to indicate that your needs are met by iterating
> through the directory using readdir() ).

I'm guessing it's got nothing to do with the order of readdir, simply
that to grep through all files in the directory, readdir is the fastest
option.

I think what he's saying is that he wants a way to do

grep foo *

in a directory of 500 files, 1K each, only he wants it to approach the
speed of

grep foo bar

where "bar" is a 500K file.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQnAKy3gHNmZLgCUhAQIWXQ//d+lBV1UrVqlrg4B3Bv5lRTiRZ0ZJFm+R
eRVTPP+30W9wtwZpLXVYSpnfAwYEYWGD2mUiZ1Qrq9OG5E1QcULp8pFfCL7uPNlX
64+RlajsppjJB7XSc0j+xF8qIBCZIgtk+4BTvRug6d2/bhf45iwenmEyWJwSBS78
dMqCNtuAkfFKb6jujGjZOYRkGtSRtZB3LEqFkBQlyR4rHkFxdsNC9JbqnoxZxPqr
p+BBUo5rtuqxUpmeMhcHI2l0NmxTNrpOvMHBelv83ZIN1PkYMMrKl3jfKVbkE/+a
IPBXtgNTf1yWx9q/PiIRncGQHVbwIrouI5YKQZUMjQtGtpermjuy6E3XluqSg9Sn
nqEHln5m6czZefR3vz2UdgxLFBykJYfmvbkOwzjWK7joUDnMpw8ltNkEYH6CY8wE
uDmWbcEneP/N8BFzC9SpH/KPD1OyM0qWY+ydy4U0r/rRZ/gRtvknJUrRRn74BgrZ
X0G8g9eJaStvTNPZUdD44d2Iu+Sv82pv2nA+kg0LR43UHMY6dKq9IfyvdfofYy+f
541q70mUrBdncR3nXdg3+QJbgzlBfk1uCe8EWyU2M7/wSKNmsuuPHj7lNDR1OuqL
SU0qtaKEU1cXA4BEj0IM2l55NnHwsc3t9XSM4eUDRiU3Hl5QmkBrJm3IiUGYo3O5
89BSikQG/K4=
=3jFe
-----END PGP SIGNATURE-----