Re: ext2fs panic with Dfly 1.5.2

[Csaba Henk <csaba.henk@xxxxxxx>]

On 2006-04-01, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
>     Hmm.  Is that ext2fs partition small enough that you can put the
>     raw disk image up somewhere?  It's probably something simple related
>     to the BUF/BIO 64 bit offset conversion work, but I don't think I
>     can track it down from that backtrace.

Well, *that* concrete partition is far from being small enough, and ATM
don't have a Dfly box handy which I could use for reproducing the issue
with artifically small partitions... but I looked a bit into the code
and the issue is quite clear.

ext2fs doesn't have a dedicated strategy + bmap, it just falls back on
those of ufs:

sys/vfs/gnu/ext2fs/ext2_vnops.c :
----------------------------
/* Global vfs data structures for ufs. */
struct vnodeopv_entry_desc ext2_vnodeop_entries[] = {
	{ &vop_default_desc,		(vnodeopv_entry_t) ufs_vnoperate },
----------------------------

This worked fine with the old ufs bmap.

But take a look at the effect of the

  "Major BUF/BIO work commit.  Make I/O BIO-centric and specify the disk or
  file location with a 64 bit offset instead of a 32 bit block number."

patch on sys/vfs/ufs/ufs_bmap.c :

  http://www.dragonflybsd.org/cvsweb/src/sys/vfs/ufs/ufs_bmap.c.diff?r1=1.9&r2=1.10&f=h 

Unlike the old ones, the new ufs_bmap() and ufs_bmaparray() utilizes an "fs"
thingy, which is initialized like this:

sys/vfs/ufs/ufs_bmap.c :
----------------------------
fs = VTOI(ap->a_vp)->i_fs;
----------------------------

Here the VTOI macro gives back the private field of the vnode as a struct
inode, which is fine for both of ufs and ext2fs. But fetching "i_fs" is bogus
-- struct inode looks like this:

sys/vfs/ufs/inode.h :
----------------------------
struct inode {
[...]
	union {			/* Associated filesystem. */
		struct	fs *fs;		/* FFS */
		struct	ext2_sb_info *e2fs;	/* EXT2FS */
	} inode_u;
#define	i_fs	inode_u.fs
#define	i_e2fs	inode_u.e2fs
[...]
}
----------------------------

That is, eventually the ufsish superblock-alike structure gets used in
ufs_bmap() and ufs_bmaparray(), regardless the actual "client" is being
ufs or ext2.

Sure, ext2fs won't be made happy by this maltreatment.

Regards,
Csaba