Re: [PATCH]QNX6 filesystem (RO) driver

[Al Viro <viro@ZenIV.linux.org.uk>]

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?