All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.