On Wed, Feb 15, 2012 at 07:57:50AM +0000, Al Viro wrote: > On Wed, Feb 15, 2012 at 07:11:19AM +0000, Al Viro wrote: > > > One more thing - unless I'm misreading the code it looks like your ->sb becomes > > a dangling pointer once fill_super finishes and ->statfs() is dereferencing > > it... > > BTW, what happens if root directory grows to more than one level of > pointers? AFAICS, qnx6_checkroot() assumes that it won't happen... > And why not do that after getting the root inode, anyway? Ho-hum... I've added conversion of qnx6_iget() to pagecache and checkroot move past getting root; result: * qnx6_bread/qnx6_getblk are gone * qnx6_block_map() has only one caller left * s_inodebits/s_dirent_blk/s_inodes_blk gone s_ptrbits remains, of course, but that one has to survive - it determines the way indirect blocks' tree is branched. Remaining issues I see: * sbi->sb dangling pointer (those brelse() in success case of fill_super()). Probably only one of them needs to be dropped at that point, leaving the other in sbi->sb_bh to be dropped by put_super * sb_set_blocksize() can and will invalidate buffer_heads of the wrong size. qnx6_fill_super() probably needs to redo sb_bread() on the primary superblock after it has done the second sb_set_blocksize(). * readdir handling of errors (especially in longname case) needs to be done better. Other than that... this stuff could use some tidying up, but that's not a big deal. I really wonder if these config options are worthwhile - might be better to stick endianness and mmi to y unconditionally. And of course all those incrementals are completely untested and might very well br broken. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html