> 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. I've fixed sbi->sb and sb_set_blocksize(). I also fixed inodebits thing. (stupid me ... ;)) Missing brelse()'s in dir_longfilename fixed. (together with error handling) Where do I find your vfs.git tree? Cloned git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git, but could not find it there. If I got it right, you would like to always receive complete patches - right? -- 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
