Bug in ReiserFS

Bug in ReiserFS

[Aleksander Adamowski]

Hi,
I think I got bitten by a bug in reiserfs.

Kernels tested:
2.4.7 with patch-int
2.4.9 with patch-int (you can get its config from here: 
http://office.altkom.com.pl/olo/domowa/249i)
plain 2.4.9
My distro: Mandrake 7.1

I can reproduce it on my machine using gftp 2.0.8. I suspect that when 
it tries to write to files (or create ones) in the ~/.gftp/cache, it 
triggers that bug. It clearly fails when trying to update its remote 
directory cache, which is stored there.
I suspect that, because every time I connect to ftp.mozilla.org with 
gftp I see the same outdated directory listing.
However, I were able to copy the ~/.gftp with cp -R in whole, so that's 
probably not a problem with reading but writing.
When I had tried to refresh the remote dir, gftp-gtk segfaulted (it 
probably tried to update the cache), kernel error occured and files on 
the whole /home filesystem were inaccessible. I could list dirs in 
/home, but any process that tried to open a file instantly freezed (even 
if run by root).

The segfault message:

/usr/bin/gftp: line 9:  1349 Segmentation fault      /usr/bin/gftp-gtk $@


When I tried to do an emergency sync using the Alt-SysRq-S combo, I got 
the following message:

Syncing device 03:06 ... OK
Syncing device 03:08 ...


ll /dev/hda8 shows this:

brw-rw----    1 root     disk       3,   8 May  5  1998 /dev/hda8


mount shows this for dev/hda8:

/dev/hda8 on /home type reiserfs (rw)


Here are two snippets from /var/log messages - what the kernel said when 
the error occured (including some lines of context):

Sep  1 10:00:20 karpaty PAM_pwdb[734]: (login) session closed for user olo
Sep  1 10:00:34 karpaty kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 00000008
Sep  1 10:00:34 karpaty kernel:  printing eip:
Sep  1 10:00:34 karpaty kernel: c01721ce
Sep  1 10:00:34 karpaty kernel: *pde = 00000000
Sep  1 10:00:34 karpaty kernel: Oops: 0000
Sep  1 10:00:34 karpaty kernel: CPU:    0
Sep  1 10:00:34 karpaty kernel: EIP: 
0010:[leaf_copy_boundary_item+786/1796]
Sep  1 10:00:34 karpaty kernel: EFLAGS: 00010246
Sep  1 10:00:34 karpaty kernel: eax: 00001000   ebx: 00000015   ecx: 
c14ad600   edx: 00000000
Sep  1 10:00:34 karpaty kernel: esi: 00003a70   edi: c149c018   ebp: 
c15d31f8   esp: c30cd7f8
Sep  1 10:00:34 karpaty kernel: ds: 0018   es: 0018   ss: 0018
Sep  1 10:00:34 karpaty kernel: Process gftp-gtk (pid: 990, 
stackpage=c30cd000)
Sep  1 10:00:34 karpaty kernel: Stack: c149c018 00001000 00000010 
00000015 ffffffff c14ad600 c30cdf18 c1195200
Sep  1 10:00:34 karpaty kernel:        c2aad140 c016c05a c30be07c 
00000015 c145ba20 c0172da9 c30cd8a4 c14ad600
Sep  1 10:00:34 karpaty kernel:        00000001 ffffffff c30cd8a4 
c30cd894 ffffffff 00000010 c0172ff0 c30cd8a4
Sep  1 10:00:34 karpaty kernel: Call Trace: [get_num_ver+330/864] 
[leaf_copy_items+153/244] [leaf_move_items+68/132] 
[leaf_shift_right+27/68] [balance_leaf+3666/9696]
Sep  1 10:00:34 karpaty kernel:    [schedule+614/916] 
[__wait_on_buffer+128/140] [bread+89/120] [clear_all_dirty_bits+17/24] 
[do_balance+142/256] [leaf_delete_items+91/344]
Sep  1 10:00:34 karpaty kernel:    [reiserfs_insert_item+158/240] 
[indirect2direct+474/572] [maybe_indirect_to_direct+497/508] 
[reiserfs_cut_from_item+208/1104] [reiserfs_do_truncate+780/1052] 
[reiserfs_truncate_file+170/372]
Sep  1 10:00:34 karpaty kernel:    [reiserfs_file_release+828/864] 
[fput+56/192] [filp_close+92/100] [sys_close+67/84] [system_call+51/64]
Sep  1 10:00:34 karpaty kernel:
Sep  1 10:00:34 karpaty kernel: Code: 8b 42 08 ff d0 83 c4 08 85 c0 75 
07 31 c0 e9 d4 03 00 00 66
Sep  1 10:00:46 karpaty chronyd[416]: Selected source 149.156.2.100
Sep  1 10:01:00 karpaty CROND[993]: (root) CMD ( 
/usr/share/msec/promisc_check.sh)

Another one:

Sep  1 10:06:01 karpaty CROND[781]: (root) CMD ( 
/usr/share/msec/promisc_check.sh)
Sep  1 10:06:29 karpaty kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 00000008
Sep  1 10:06:29 karpaty kernel:  printing eip:
Sep  1 10:06:29 karpaty kernel: c01721ce
Sep  1 10:06:29 karpaty kernel: *pde = 00000000
Sep  1 10:06:29 karpaty kernel: Oops: 0000
Sep  1 10:06:29 karpaty kernel: CPU:    0
Sep  1 10:06:29 karpaty kernel: EIP: 
0010:[leaf_copy_boundary_item+786/1796]
Sep  1 10:06:29 karpaty kernel: EFLAGS: 00010246
Sep  1 10:06:29 karpaty kernel: eax: 00001000   ebx: 00000017   ecx: 
c2d68f00   edx: 00000000
Sep  1 10:06:29 karpaty kernel: esi: 00003a70   edi: c0a18018   ebp: 
c0afe228   esp: c1ed57f8
Sep  1 10:06:29 karpaty kernel: ds: 0018   es: 0018   ss: 0018
Sep  1 10:06:29 karpaty kernel: Process gftp-gtk (pid: 768, 
stackpage=c1ed5000)
Sep  1 10:06:29 karpaty kernel: Stack: c0a18018 00001000 00000011 
00000017 ffffffff c2d68f00 00000240 c0175ad3
Sep  1 10:06:29 karpaty kernel:        c23c9000 c016c05a c2b38094 
00000017 c2555d20 c0172da9 c1ed58a4 c2d68f00
Sep  1 10:06:29 karpaty kernel:        00000001 ffffffff c1ed58a4 
c1ed5894 ffffffff 00000011 c0172ff0 c1ed58a4
Sep  1 10:06:29 karpaty kernel: Call Trace: [is_tree_node+67/88] 
[get_num_ver+330/864] [leaf_copy_items+153/244] [leaf_move_items+68/132] 
[leaf_shift_right+27/68]
Sep  1 10:06:29 karpaty kernel:    [balance_leaf+3666/9696] 
[schedule+614/916] [__wait_on_buffer+128/140] [bread+89/120] 
[clear_all_dirty_bits+17/24] [do_balance+142/256]
Sep  1 10:06:29 karpaty kernel:    [get_cnode+17/104] 
[reiserfs_insert_item+158/240] [indirect2direct+474/572] 
[maybe_indirect_to_direct+497/508] [reiserfs_cut_from_item+208/1104] 
[reiserfs_do_truncate+780/1052]
Sep  1 10:06:29 karpaty kernel:    [reiserfs_truncate_file+170/372] 
[reiserfs_file_release+828/864] [fput+56/192] [filp_close+92/100] 
[sys_close+67/84] [system_call+51/64]
Sep  1 10:06:29 karpaty kernel:
Sep  1 10:06:29 karpaty kernel: Code: 8b 42 08 ff d0 83 c4 08 85 c0 75 
07 31 c0 e9 d4 03 00 00 66
Sep  1 10:06:30 karpaty chronyd[415]: Selected source 153.19.253.204
Sep  1 10:07:00 karpaty CROND[792]: (root) CMD ( 
/usr/share/msec/promisc_check.sh)


I'm leaving on a vacation right now, and will be back on Sep 10, so if 
you want me to do further investigatons for you, contact me by e-mail then.

Best regards,
		Olo

Bug in reiserfs

[Jesús Malo Poyatos]

I have receive the next message when I was trying to remove an archive. I hope this information is useful for you.



kernel BUG at fs/reiserfs/journal.c:3098!
invalid operand: 0000 [#1]
Modules linked in: reiserfs dm_mod ne2k_pci 8390 via82cxxx fan thermal processor usb_storage usbhid uhci_hcd usbcore ide_disk ide_cd ide_core sg sr_mod sd_mod scsi_mod cdrom cramfs vfat fat nls_iso8859_1 nls_cp437 af_packet nvram
CPU:    0
EIP:    0060:[<c8f0b575>]    Not tainted VLI
EFLAGS: 00010246   (2.6.13-15-default) 
EIP is at journal_begin+0xe5/0xf0 [reiserfs]
eax: 00000000   ebx: c7069ed4   ecx: 00000012   edx: c7099400
esi: c7069f1c   edi: c7068000   ebp: c7099400   esp: c7069ebc
ds: 007b   es: 007b   ss: 0068
Process rm (pid: 2137, threadinfo=c7068000 task=c7e49590)
Stack: 00000012 c40df208 c40df208 c7069f68 00000000 c8ef9bbd 00000000 00000000 
       000a0f61 000a118d 00000000 00000000 00000000 00000000 c7069f1c c7099400 
       00000024 c767b84c c8f0b89d c40df208 00000024 c7069f68 c767b84c c8eedae4 
Call Trace:
 [<c8ef9bbd>] remove_save_link+0x1d/0xc0 [reiserfs]
 [<c8f0b89d>] journal_end+0x8d/0xc0 [reiserfs]
 [<c8eedae4>] reiserfs_delete_inode+0xe4/0x100 [reiserfs]
 [<c8eeda00>] reiserfs_delete_inode+0x0/0x100 [reiserfs]
 [<c01707ab>] generic_delete_inode+0x7b/0x120
 [<c0170a0a>] iput+0x5a/0x70
 [<c0167bd4>] sys_unlink+0xd4/0x130
 [<c0102d79>] syscall_call+0x7/0xb
Code: 00 00 00 89 46 04 89 df f3 a5 83 7b 04 01 7f cd 68 f0 6c f1 c8 55 e8 eb 1c ff ff 31 c9 5b 5e eb ab 0f 0b 38 0c 86 30 f1 c8 eb a1 <0f> 0b 1a 0c 86 30 f1 c8 eb c8 90 55 57 56 53 83 ec 10 89 cf 89 
 Badness in do_exit at kernel/exit.c:790
 [<c011e9e8>] do_exit+0x338/0x340
 [<c010468e>] die+0x13e/0x140
 [<c0104940>] do_invalid_op+0x0/0xa0
 [<c01049d1>] do_invalid_op+0x91/0xa0
 [<c8f0b575>] journal_begin+0xe5/0xf0 [reiserfs]
 [<c0103f0f>] error_code+0x4f/0x60
 [<c8f0b575>] journal_begin+0xe5/0xf0 [reiserfs]
 [<c8ef9bbd>] remove_save_link+0x1d/0xc0 [reiserfs]
 [<c8f0b89d>] journal_end+0x8d/0xc0 [reiserfs]
 [<c8eedae4>] reiserfs_delete_inode+0xe4/0x100 [reiserfs]
 [<c8eeda00>] reiserfs_delete_inode+0x0/0x100 [reiserfs]
 [<c01707ab>] generic_delete_inode+0x7b/0x120
 [<c0170a0a>] iput+0x5a/0x70
 [<c0167bd4>] sys_unlink+0xd4/0x130
 [<c0102d79>] syscall_call+0x7/0xb

BUG IN REISERFS SLES 10 :

[Masthan, Dudekula (STSD)]

Hi Folks,

I am using SLES 10 latest beta bits. Generally I will use sg_reset
command to reset my scsi device/bus. In sles 10 the machine is not
coming up ( or in otherwords the machine is hanging)  after issuing the
sg_reset command.
I tried the following command

# sg_reset -b /dev/sg3

and also i tried with scsi ioctls, still I am facing the same problem
I tried with the following standalone program

#include<stdio.h>
   :
   :
int main(int argc, char * argv[]) {
   int fd;
   int rc;
   int arg=2;
   if ((fd=open("/dev/sg3", O_RDWR)) < 0) {
      printf( "device open fails");
      return -1;
   }
   if ((rc=ioctl(fd,SG_SCSI_RESET,&arg)) < 0 ){
     printf( " ioctl failed "); 
     close (fd);
     return -1;
   }
  
  printf ( " reset success ");
  close (fd);
  return 0;
 }


After running above program also I am facing same problem. 


Is it bug in SLES 10 or is it bug in qlogic driver ?

Thanks in advance

BUG IN REISERFS SLES 10 :

[Masthan, Dudekula (STSD)]

Hi Folks,

I am using SLES 10 latest beta bits. Generally I will use sg_reset
command to reset my scsi device/bus. In sles 10 the machine is not
coming up ( or in otherwords the machine is hanging)  after issuing the
sg_reset command.
I tried the following command

# sg_reset -b /dev/sg3

and also i tried with scsi ioctls, still I am facing the same problem
I tried with the following standalone program

#include<stdio.h>
   :
   :
int main(int argc, char * argv[]) {
   int fd;
   int rc;
   int arg=2;
   if ((fd=open("/dev/sg3", O_RDWR)) < 0) {
      printf( "device open fails");
      return -1;
   }
   if ((rc=ioctl(fd,SG_SCSI_RESET,&arg)) < 0 ){
     printf( " ioctl failed "); 
     close (fd);
     return -1;
   }
  
  printf ( " reset success ");
  close (fd);
  return 0;
 }


After running above program also I am facing same problem. 


Is it bug in SLES 10 or is it bug in qlogic driver ?

Thanks in advance

Re: BUG IN REISERFS SLES 10 :

[Vladimir V. Saveliev]

Hello

On Fri, 2006-06-30 at 11:08 +0530, Masthan, Dudekula (STSD) wrote:
> Hi Folks,
> 
> I am using SLES 10 latest beta bits. Generally I will use sg_reset
> command to reset my scsi device/bus. In sles 10 the machine is not
> coming up ( or in otherwords the machine is hanging)  after issuing the
> sg_reset command.
> I tried the following command
> 
> # sg_reset -b /dev/sg3
> 
> and also i tried with scsi ioctls, still I am facing the same problem
> I tried with the following standalone program
> 
> #include<stdio.h>
>    :
>    :
> int main(int argc, char * argv[]) {
>    int fd;
>    int rc;
>    int arg=2;
>    if ((fd=open("/dev/sg3", O_RDWR)) < 0) {
>       printf( "device open fails");
>       return -1;
>    }
>    if ((rc=ioctl(fd,SG_SCSI_RESET,&arg)) < 0 ){
>      printf( " ioctl failed "); 
>      close (fd);
>      return -1;
>    }
>   
>   printf ( " reset success ");
>   close (fd);
>   return 0;
>  }
> 
> 
> After running above program also I am facing same problem. 
> 
> 
> Is it bug in SLES 10 or is it bug in qlogic driver ?
> 

To check whether it is filesystem problem you may want to try something
like:
mknod /ext2-mount/sg3 c 21 3
and then try your program patched with the below:
- if ((fd=open("/dev/sg3", O_RDWR)) < 0) {
+ if ((fd=open("/ext2-mount/sg3", O_RDWR)) < 0) {


> Thanks in advance
> 

BUG IN REISERFS

[Masthan, Dudekula (STSD)]

 

Hi Folks,

Mkreiserfs command is failing by showing " There are no enoguh blocks on
this device" , What is the minimum size of a disk to create reiserfs
file system

Regards,
Masthan

BUG IN REISERFS

[Masthan, Dudekula (STSD)]

 

Hi Folks,

Mkreiserfs command is failing by showing " There are no enoguh blocks on
this device" , What is the minimum size of a disk to create reiserfs
file system

Regards,
Masthan

Re: BUG IN REISERFS

[Erik Mouw]

Please choose your subject carefully. Claiming that you found a bug in
reiserfs while you only met a boundary condition isn't very polite.

On Fri, Jun 30, 2006 at 05:51:14PM +0530, Masthan, Dudekula (STSD) wrote:
> Mkreiserfs command is failing by showing " There are no enoguh blocks on
> this device" , What is the minimum size of a disk to create reiserfs
> file system

That mainly depends on the journal size. The default journal size is 32
MB which means that an actual useful disk size is about 100 MB. See
mkreiserfs(8), -s option.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: BUG IN REISERFS

[Vladimir V. Saveliev]

hello

On Fri, 2006-06-30 at 17:51 +0530, Masthan, Dudekula (STSD) wrote:
>  
> Hi Folks,
> 
> Mkreiserfs command is failing by showing " There are no enoguh blocks on
> this device" , What is the minimum size of a disk to create reiserfs
> file system
> 

Please let us see whole mkreiserfs output and the command line itself.

In case of standard journal minimal reiserfs size is 8212 blocks.

> Regards,
> Masthan
> 
> 

Re: BUG IN REISERFS

[Hans Reiser]

Masthan, Dudekula (STSD) wrote:

> 
>
>Hi Folks,
>
>Mkreiserfs command is failing by showing " There are no enoguh blocks on
>this device" , What is the minimum size of a disk to create reiserfs
>file system
>
>Regards,
>Masthan
>
>
>
>  
>
Please modify the error message so that it answers his question before
users think to ask it.:)

Hans