From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kai Bankett Subject: Re: [PATCH]QNX6 filesystem (RO) driver Date: Fri, 17 Feb 2012 22:38:12 +0100 Message-ID: <4F3EC8C4.3050707@ontika.net> 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> <20120217183548.GQ23916@ZenIV.linux.org.uk> <20120217185335.GR23916@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Received: from mailout11.t-online.de ([194.25.134.85]:36336 "EHLO mailout11.t-online.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752322Ab2BQUi0 (ORCPT ); Fri, 17 Feb 2012 15:38:26 -0500 In-Reply-To: <20120217185335.GR23916@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Am 02/17/2012 07:53 PM, schrieb Al Viro: >> 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... At least code was robust enough to deal with it ;) I guess ino was set to 0 anyways by compiler? At least it does not seem to have been sort of random. Otherwise testing would have shown strange effects - right? However, fixed. I just re-added the braces. At some point in time there were some ... seem they got lost somewhere in mod space. > 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; > > } else { > if (de->de_size != 0xff) > continue; > > } > 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? I just checked, but could not get qnx to split a short name in a long filename node. So we can bury that one ... also does not really make sense to design it that way. To me the length field clearly is the master. For short filenames always de_size < 0xff and equal the filename length. If de_size == 0xff, filename length has to be taken out of lf node. The interesting question is: What is in between? To me, the answer is: File-system error land. Just re-pull the patch and take a look ... http://a6.ontika.net/patches/0001-fs-initial-qnx6fs-addition.patch.gz BTW, I had a look at character and block device files. QNX drivers just dynamically add them to /dev if a driver offers any. There seems to be no way to create or move any by hand + they are not written to the fs.