On Fri, Feb 17, 2012 at 06:35:49PM +0000, Al Viro wrote: > On Fri, Feb 17, 2012 at 06:53:52PM +0100, Kai Bankett wrote: > > > Other than that (and assuming it survives your testing), I'm fine with > > > that variant. > > > > At least no problems with all my test images. Just ran a complete test > > (file reads, dir(s), filepermissions, symlink, hardlink, longfilenames, > > longdirectories etc.) over (mmi/be/le/1k/2k blocksize images). > > > > http://a6.ontika.net/patches/0001-fs-initial-qnx6fs-addition.patch.gz > > Hmmm... > > + if (len == de->de_size) > + /* normal filename */ > + ino = qnx6_match(s, len, name, de); > + if (ino) > + goto found; > + else if ((de->de_size == 0xff) && > > Actually, gcc ought to have screamed at that. Note that "else" here matches > the second "if", not the first one. And you are not guaranteed that > ino has _ever_ been assigned anything; that comparison is deep in nasal > daemon country... And in the same area, what happens if you have a long entry *and* ask for lookup for name that is exactly 255 bytes long? AFAICS, qnx6_match() will proceed to do memcmp() on 255 bytes - note that you pass it "len", not "thislen". Might (at least in theory) run out of page before it stops... Something like if (len <= QNX6_SHORT_NAME_MAX) { if (de->de_size != len) continue; <qnx6_match> } else { if (de->de_size != 0xff) continue; <qnx6_long_match> } would probably make sense... Wait. You've mentioned something about special characters in names forcing a longname entry even for short ones. Could you elaborate? -- 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
