Re: vfs - iget problem..

Re: vfs - iget problem..

[quetzalcoatl]

anybody have any ideas..?
please, anybody ever battled with something similar?
I'm totally stuck at it :/
tdk

----- Original Message ----- 
From: "quetzalcoatl" <quetzalcoatl@poczta.fm>
To: <nlo.lists.kernelnewbies@nl.linux.org>
Sent: Tuesday, 11 April 2006 00:16
Subject: vfs - putinode problem..


> Hi!
> I'm writing a kernel module that adds support to the Creative Labs' MINIFS filesystem, that is used on Nomad Jukebox/Zen/Xtra
> hdd-mp3 players. Actually it is the system part of the disk, naturally inaccesible by normal ways :) It a mere first 20megs of the
> disk and contains strings, fonts, blahblah..
>
> I was doing well when I was writing everything from the scratch and using direct file-like reads from /dev/sd*. But, at some 
> point,
> I thought that darn I'm in the kernel, so why dont I use all the caches :) So I took minimalistic BFS filesystem source code and
> tried to modify it to get basic functionality first.. And got stuck on inode reading and freeing.
>
> I implemented those functions:
> module init - creates inodecache, registers fs
> module exit - unregisters fs, destroys inodecache
> alloc inode - gets new inode from inodecache
> destroy inode - frees it
> read inode - if i_ino==0 only performs setup, for >0 reads data from device and sets it up
> fill super block - allocates custom info struct, sets blocksize, reads 3 bitmaps from the drive, igets inode 0, d_alloc_root on it
> put super block - frees custom info structure
> read inode - sets:
>  i_mode = 0555|SIFDIR
>  i_op = &routinetable
>  i_fop = &otherroutinetable
>  uid=gid=size=blocks=atime=mtime=ctime=0
>  i_nlink=1
>  i_blksize=sb->s_blocksize
> readdir - calculates position on the disk, reads 0x30 bytes, extracts filename, calls filldir_t.
> lookup - calculates position, reads sequentially 0x30 bytes until match found, calls iget with found inode number
>
> for testing only, i included cap on inode numbers, *only*inodes* 0 and 1 may be read. as you can see from readinode description,
> they arent even actually read, just being setup..
>
> now.. the behaviour..
>
> 1)
> I insmod module, mount the FS
> *initmodule entered
> **inodecache created
> **fillsb entered
> ***inode 0 allocated
> ***readinode called - success
> ***bitmaps read
> **fillsb ends
> I unmout, rmmod:
> *putinode called on inode #0 - i_count = 0
> *dropinode called on inode #0
> *clearinode called on inode #0
> *destroyinode called on inode #0
> *putsuper called
> *killmodule called
> **destroy inodecache - success
> *killmodule ends
>
> 2)
> I insmod module, mount the FS
> *initmodule entered
> **inodecache created
> **fillsb entered
> ***inode 0 allocated
> ***readinode called - success
> ***bitmaps read
> **fillsb ends
> I ls its mount point
> *readdir called
> **readdir reads first entry (inode#1) from the device's root dir, translates filename and sets up dentry
> *dir lookup called
> **dir lookup finds again the entry on device's roots dir
> **dir lookup igets inode #1 (let me state again: readinode only sets up few flags. all the reading is ripped out from it now)
> ** dir lookup ends
> *readdir called - found end of records
> ls shows me the correct filename
> then I unmout, rmmod:
> *putinode called on inode #1 - i_count = 2    (why 2?)
> *putinode called on inode #0 - i_count = 2    (why 2?)
> *putsuper called
> *putinode called on inode #1 - i_count = 2    (still 2???)
> *putinode called on inode #0 - i_count = 2    (still 2???)
> *killmodule called
> **destroy inodecache - error "VFS: busy inodes found after unmount, blahblah"
> Oops! (..)
> (..)
> _slab_error+0x
> (..)
> minifs_destroy_inodecache+0x
> minifs_killmodule+0x
> (..)
> sys_enter_past_esp
>
>
> My problems are:
> -Why the is 2 not 1? There is only superblock inode added to dentry - so #0 should have icount 1, and one inode added to file's
> dentry - it should have icount of 1, too..
> - Why the i_count doesnt decrease after calling my putinode function? as tests with mount/umount only shows, if the icount reaches 
> 0
> at unmount, the sequence dropinode-clearinode-destroyinode is fully maintained and everything is OK. But whenever whatever inode 
> is
> iget() everyting screws up
> - Busy inodes after unmount - ok. but why OOPS and _slab_error?? I nowhere do any memory damages, I've checked it many times,
> including memory dumps after each memcpying.. And the slab error seems serious, because after it catting /proc/slab results in
> another oops, and other FS's memory seem to be corrupted in random places..
>
> I have had the "FS" more developed, but I already stripped 95% of functionality from it, to find that friggin' bug.. Thats why
> readinode doesnt do anything apart setting few flags. If iget for sb is done only - everythning is ok.. If iget is called even 
> once
> after it, everything ends like I presented. It doesnt make any sense, because all the iget does is allocing new inode (100% 
> success,
> errorless) and call readinode (does virtually nothing)..
>
> Where the problem may be? I really triple-checked possible memory corruptions on my side, and even commented out every not needed
> memory operations..
>
> I'm after that bug now for more than 3 weeks.. help:D
> tdk
> 


----------------------------------------------------------------------
Poznaj Stefana! Zmien komunikator! >>> http://link.interia.pl/f1924

vfs - iget problem..

[quetzalcoatl]

Hi!
I'm writing a kernel module that adds support to the Creative Labs' MINIFS filesystem, that is used on Nomad Jukebox/Zen/Xtra
hdd-mp3 players. Actually it is the system part of the disk, naturally inaccesible by normal ways :) It a mere first 20megs of the
disk and contains strings, fonts, blahblah..

I was doing well when I was writing everything from the scratch and using direct file-like reads from /dev/sd*. But, at some point,
I thought that darn I'm in the kernel, so why dont I use all the caches :) So I took minimalistic BFS filesystem source code and
tried to modify it to get basic functionality first.. And got stuck on inode reading and freeing.

I implemented those functions:
module init - creates inodecache, registers fs
module exit - unregisters fs, destroys inodecache
alloc inode - gets new inode from inodecache
destroy inode - frees it
read inode - if i_ino==0 only performs setup, for >0 reads data from device and sets it up
fill super block - allocates custom info struct, sets blocksize, reads 3 bitmaps from the drive, igets inode 0, d_alloc_root on it
put super block - frees custom info structure
read inode - sets:
  i_mode = 0555|SIFDIR
  i_op = &routinetable
  i_fop = &otherroutinetable
  uid=gid=size=blocks=atime=mtime=ctime=0
  i_nlink=1
  i_blksize=sb->s_blocksize
readdir - calculates position on the disk, reads 0x30 bytes, extracts filename, calls filldir_t.
lookup - calculates position, reads sequentially 0x30 bytes until match found, calls iget with found inode number

for testing only, i included cap on inode numbers, *only*inodes* 0 and 1 may be read. as you can see from readinode description,
they arent even actually read, just being setup..

now.. the behaviour..

1)
I insmod module, mount the FS
*initmodule entered
**inodecache created
**fillsb entered
***inode 0 allocated
***readinode called - success
***bitmaps read
**fillsb ends
I unmout, rmmod:
*putinode called on inode #0 - i_count = 0
*dropinode called on inode #0
*clearinode called on inode #0
*destroyinode called on inode #0
*putsuper called
*killmodule called
**destroy inodecache - success
*killmodule ends

2)
I insmod module, mount the FS
*initmodule entered
**inodecache created
**fillsb entered
***inode 0 allocated
***readinode called - success
***bitmaps read
**fillsb ends
I ls its mount point
*readdir called
**readdir reads first entry (inode#1) from the device's root dir, translates filename and sets up dentry
*dir lookup called
**dir lookup finds again the entry on device's roots dir
**dir lookup igets inode #1 (let me state again: readinode only sets up few flags. all the reading is ripped out from it now)
** dir lookup ends
*readdir called - found end of records
ls shows me the correct filename
then I unmout, rmmod:
*putinode called on inode #1 - i_count = 2    (why 2?)
*putinode called on inode #0 - i_count = 2    (why 2?)
*putsuper called
*putinode called on inode #1 - i_count = 2    (still 2???)
*putinode called on inode #0 - i_count = 2    (still 2???)
*killmodule called
**destroy inodecache - error "VFS: busy inodes found after unmount, blahblah"
Oops! (..)
(..)
_slab_error+0x
(..)
minifs_destroy_inodecache+0x
minifs_killmodule+0x
(..)
sys_enter_past_esp


My problems are:
-Why the is 2 not 1? There is only superblock inode added to dentry - so #0 should have icount 1, and one inode added to file's
dentry - it should have icount of 1, too..
- Why the i_count doesnt decrease after calling my putinode function? as tests with mount/umount only shows, if the icount reaches 0
at unmount, the sequence dropinode-clearinode-destroyinode is fully maintained and everything is OK. But whenever whatever inode is
iget() everyting screws up
- Busy inodes after unmount - ok. but why OOPS and _slab_error?? I nowhere do any memory damages, I've checked it many times,
including memory dumps after each memcpying.. And the slab error seems serious, because after it catting /proc/slab results in
another oops, and other FS's memory seem to be corrupted in random places..

I have had the "FS" more developed, but I already stripped 95% of functionality from it, to find that friggin' bug.. Thats why
readinode doesnt do anything apart setting few flags. If iget for sb is done only - everythning is ok.. If iget is called even once
after it, everything ends like I presented. It doesnt make any sense, because all the iget does is allocing new inode (100% success,
errorless) and call readinode (does virtually nothing)..

Where the problem may be? I really triple-checked possible memory corruptions on my side, and even commented out every not needed
memory operations..

I'm after that bug now for more than 3 weeks.. help:D
tdk


----------------------------------------------------------------------
Poznaj Stefana! Zmien komunikator! >>> http://link.interia.pl/f1924