Date: Tue, 17 Mar 98 08:53:37 EST From: luoqi@watermarkgroup.com (Luoqi Chen) To: current@FreeBSD.ORG Cc: julian@whistle.com, mckusick@mcKusick.com Subject: softupdates allocindir panic Message-ID: <9803171353.AA23812@watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
Just had this panic myself. I studied the core dump a little bit. I found
something interesting. The relevent piece of code around the crash is
static void
setup_allocindir_phase2(bp, ip, aip)
struct buf *bp; /* in-memory copy of the indirect block */
struct inode *ip; /* inode for file being extended */
struct allocindir *aip; /* allocindir allocated by the above routines */
{
...
for (indirdep = NULL, newindirdep = NULL; ; ) {
...
newindirdep->ir_saveddata = (ufs_daddr_t *)bp->b_data;
newindirdep->ir_savebp =
getblk(ip->i_devvp, bp->b_blkno, bp->b_bcount, 0, 0);
bcopy((caddr_t)newindirdep->ir_saveddata,
newindirdep->ir_savebp->b_data, bp->b_bcount);
}
}
Obviously, the getblk() call assumes VOP_BMAP has been performed, and b_blkno
points to device relative block. But upon examining the core, I got
b_blkno = b_lblkno (= -12). The same is true for dumps posted on -current.
We probably should call VOP_BMAP before getblk() for the blkno == lblkno case.
-lq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9803171353.AA23812>