unionfs kernel panic while mounting (i386, R8.2)

[Daichi GOTO]

Hi Alex

I have tried to reproduce your panic, but couldn't 
get a panic. Would you please try unionfs on 8-stable?

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 <aavzz at yandex.ru> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"

-- 
Daichi GOTO