Messages in this thread | | | Date | Sat, 20 Mar 1999 22:07:53 +0100 | From | Jan Kara <> | Subject | Questions about VFS |
| |
Hello.
I've send this to fs-devel list but because nobody replied I'm also sending it to linux-kernel (and I'm adding a few thigs I came accross today ;-)...
I've decided to read dcache and inode cache code and I found a few things which I didn't understood (or they are bugs ;-)?). I was reading code from 2.2.1 as I think it didn't differ much from current kernels... Here are the questions: 1) In dcache.c in select_parent() there is a test d_count == 0 and immediately after it is a test to d_subdirs being nonempty which I think can never pass when d_count == 0... 2) In namei.c in do_follow_link() when everything is OK only variable dentry is dput() but but variable base not (in other cases these variable is dput()...) but in lookup_dentry() from which this function is called the variable base is overwritten but old dentry isn't dput... Do I miss something? 3) In inode.c in sync_one() when inode is locked the function only waits for it to unlock and then silently exits. Shouldn't it also write the inode if needed? 4) In the same function when inode is written it is unlocked and the processes from wait queue are run but this is done with inode_lock held. I don't thing this is desirable... New things: 5) In dqput() there is a test whether the dquot is already on the free list (OK, when everything is right it shouldn't) and when it isn't a warning is printed but then the dquot is added to the list happily again. Also when dquot is put on the free list a wake_up is called but the dquot has use count == 0 so the queue should be free, shouldn't it? 6) Function isize_to_blocks is a bit... say strange. It does count indirect blocks but who has said us the filesystem use them. Also when we count indirect blocks we should at least consider blksize. But I agree this is a minor problem because this function is never called (at least I think it because ext2 counts blocks itself and other filesystems doesn't have quotas..). But maybe just returning size/blocksize could be better. 7) I see nothing which prevents races in dquot_transfer(). When we are gathering the quotas to move we can block and nothing prevents someone else from changing the dquots under us so that assumptions we have from tests might not be valid when updating structures... Also someone (ie invalidate_dquots() can dqput() the dquots we have...). 8) There is a buffer overrun in get_filesystem_info(). We are putting informations about mounts to the given page and we expect the length of one entry can't exceed 160 bytes which is a bit optimistic because we store also a mountpoint into the buffer...
If some of the mentioned things are bugs I can fix them. I just didn't want to make fixes to something which is right but I didn't understood it ;-).
Looking forward to your answers Honza.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |