From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH]QNX6 filesystem (RO) driver
Date: Fri, 17 Feb 2012 18:53:36 +0000
Message-ID: <20120217185335.GR23916@ZenIV.linux.org.uk>
References: <20120215061012.GC23916@ZenIV.linux.org.uk>
 <20120215064728.GE23916@ZenIV.linux.org.uk>
 <20120215071119.GF23916@ZenIV.linux.org.uk>
 <20120215075750.GG23916@ZenIV.linux.org.uk>
 <20120215144037.GH23916@ZenIV.linux.org.uk>
 <20120216100043.GJ23916@ZenIV.linux.org.uk>
 <2977b399b903a3b7bff1ffe93e8d3dd9.squirrel@www.ontika.net>
 <20120217162006.GO23916@ZenIV.linux.org.uk>
 <def86ad9f4b3bd6be39b1c8ebb95864b.squirrel@www.ontika.net>
 <20120217183548.GQ23916@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
To: Kai Bankett <chaosman@ontika.net>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:34060 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751556Ab2BQSxh (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 17 Feb 2012 13:53:37 -0500
Content-Disposition: inline
In-Reply-To: <20120217183548.GQ23916@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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?