From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 04:25:29 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C723106566C for ; Thu, 21 Apr 2011 04:25:29 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0925A8FC0C for ; Thu, 21 Apr 2011 04:25:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 1FE9012543B; Thu, 21 Apr 2011 13:25:28 +0900 (JST) Date: Thu, 21 Apr 2011 13:25:29 +0900 From: Daichi GOTO To: Daichi GOTO Message-Id: <20110421132529.4c0aa749.daichi@freebsd.org> In-Reply-To: <20110421124919.5dc64403.daichi@freebsd.org> References: <1303118948.2112.40.camel@localhost> <20110421124919.5dc64403.daichi@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: unionfs kernel panic while mounting (i386, R8.2) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 04:25:29 -0000 On Thu, 21 Apr 2011 12:49:19 +0900 Daichi GOTO wrote: > Hi Alex > > I have tried to reproduce your panic, but couldn't > get a panic. Would you please try unionfs on 8-stable? Now I got a panic, ok ;) > ps. > I do refreshing my patch to get merged into current. > After some tests, I'll open my new patch for public test. > thanks :) > > On Mon, 18 Apr 2011 13:29:08 +0400 > Alex Zimnitsky wrote: > > Hi everyone! > > > > > > There is a problem with unionfs mount procedure > > which consistently causes system crash. I observed > > this behavior (freshly installed release 8.2) on > > two i386 boxes one of which was an ancient laptop > > with 256MB RAM and the other was a not-so-old > > desktop with more than 4GB jf RAM. > > > > ******* How to reproduce: ************** > > > > mkdir /var/ftp > > > > mkdir /var/ftpdata1 > > mkdir /var/ftpdata2 > > ... > > mkdir /var/ftpdata15 > > > > mount -t unionfs /var/ftpdata1 /var/ftp > > mount -t unionfs /var/ftpdata2 /var/ftp > > ... > > mount -t unionfs /var/ftpdata15 /var/ftp > > > > mounting /var/ftpdata12 reliably caused > > kernel panic on the laptop in my case > > (desktop reliably crashed while mounting ftpdata10-12) > > > > ************ Possible cause **************** > > > > A little investigation revealed that this crash > > happens in unionfs_statfs which lives > > in /usr/src/sys/fs/unionfs/union_vfsops.c > > > > Debug printing showed that it calls itself > > recursively n+1 times depending on the > > quantity of previously mounted dirs: > > > > mount -t unionfs /var/ftpdata1 /var/ftp - 2 times > > mount -t unionfs /var/ftpdata2 /var/ftp - 3 times > > ... > > mount -t unionfs /var/ftpdata10 /var/ftp - 11 times > > ... > > > > It appears that the crash is caused by lack of system > > resources (stack I guess) > > > > The crash itself writes something like "double fault" > > or "double error" (I'm sure about that "double") > > > > > > **************** Workaround ************************ > > > > Reducing recursion eliminates the problem. > > > > unionfs_statfs part: > > > > old (with the problem): > > --------------------------------------------------------------- > > > > struct unionfs_mount *ump; > > int error; > > struct statfs mstat; > > uint64_t lbsize; > > > > ump = MOUNTTOUNIONFSMOUNT(mp); > > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > > (void *)mp, (void *)ump->um_lowervp, (void > > *)ump->um_uppervp); > > > > bzero(&mstat, sizeof(mstat)); > > > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > > > ----------------------------------------------------------------------- > > > > new (without crashes): > > ----------------------------------------------------------------------- > > struct unionfs_mount *ump; > > int error; > > struct statfs mstat; > > uint64_t lbsize; > > > > struct unionfs_mount *ump_aavzz; /*AAVZZ*/ > > > > /*ump = MOUNTTOUNIONFSMOUNT(mp);*/ /*AAVZZ*/ > > ump_aavzz = MOUNTTOUNIONFSMOUNT(mp); /*AAVZZ*/ > > > > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > > (void *)mp, (void *)ump->um_lowervp, (void > > *)ump->um_uppervp); > > > > bzero(&mstat, sizeof(mstat)); > > > > /*Dirty hack to fast forward*/ > > while (! > > strcmp(ump_aavzz->um_lowervp->v_mount->mnt_stat.f_fstypename, > > "unionfs")) { > > > > ump_aavzz=MOUNTTOUNIONFSMOUNT(ump_aavzz->um_lowervp->v_mount); > > } > > ump=ump_aavzz; > > /*end of dirty hack*/ > > > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > > > ------------------------------------------------------------------------------- > > > > > > **************************** Considerations ************************** > > > > I'm sure that the above is not the way to treat the problem. But > > I do not have deep understanding of the internal workings of filesystems > > in general and unionfs in particular and cannot come up with anything > > better. > > > > Probably this growing recursion should not take place at all, which > > requires defferent handling of ump->um_lowervp->v_mount during list > > creation (mount?). > > > > > > > > Regards, > > > > Alex > > > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > -- > Daichi GOTO > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto