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: Wed, 15 Feb 2012 14:40:37 +0000
Message-ID: <20120215144037.GH23916@ZenIV.linux.org.uk>
References: <4F29A37F.6070909@ontika.net>
 <20120212045629.GO23916@ZenIV.linux.org.uk>
 <4F3839CE.8040805@ontika.net>
 <20120212224358.GW23916@ZenIV.linux.org.uk>
 <4F3B1DD1.3000202@ontika.net>
 <20120215061012.GC23916@ZenIV.linux.org.uk>
 <20120215064728.GE23916@ZenIV.linux.org.uk>
 <20120215071119.GF23916@ZenIV.linux.org.uk>
 <20120215075750.GG23916@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]:39491 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758460Ab2BOOkj (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 15 Feb 2012 09:40:39 -0500
Content-Disposition: inline
In-Reply-To: <20120215075750.GG23916@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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.