public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: "quetzalcoatl" <quetzalcoatl@poczta.fm>
To: <linux-fsdevel@vger.kernel.org>
Subject: vfs - iget problem..
Date: Tue, 11 Apr 2006 02:23:04 +0200	[thread overview]
Message-ID: <007c01c65cfe$19eb08c0$4d00a8c0@grav> (raw)

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


             reply	other threads:[~2006-04-11  0:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-11  0:23 quetzalcoatl [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-04-16  9:20 vfs - iget problem quetzalcoatl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='007c01c65cfe$19eb08c0$4d00a8c0@grav' \
    --to=quetzalcoatl@poczta.fm \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox