DragonFly BSD
DragonFly bugs List (threaded) for 2006-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: ext2fs panic with Dfly 1.5.2

From: Csaba Henk <csaba.henk@xxxxxxx>
Date: 02 Apr 2006 01:36:55 GMT

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 :


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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]