From mboxrd@z Thu Jan 1 00:00:00 1970 From: "quetzalcoatl" Subject: Re: vfs - iget problem.. Date: Sun, 16 Apr 2006 11:20:14 +0200 Message-ID: <005001c66136$f8cf47e0$4d00a8c0@grav> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Return-path: Received: from [80.48.65.9] ([80.48.65.9]:54668 "EHLO smtp.poczta.interia.pl") by vger.kernel.org with ESMTP id S1751450AbWDPJUs (ORCPT ); Sun, 16 Apr 2006 05:20:48 -0400 Received: from poczta.interia.pl (mi03.poczta.interia.pl [10.217.12.3]) by smtp.poczta.interia.pl (INTERIA.PL) with ESMTP id CA13FD0DBE for ; Sun, 16 Apr 2006 11:20:46 +0200 (CEST) Received: from grav (yj202.internetdsl.tpnet.pl [80.55.243.202]) by www.poczta.fm (INTERIA.PL) with ESMTP id ACC2E3C335 for ; Sun, 16 Apr 2006 11:20:45 +0200 (CEST) To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org anybody have any ideas..? please, anybody ever battled with something similar? I'm totally stuck at it :/ tdk ----- Original Message ----- From: "quetzalcoatl" To: 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