Re: diskless/unionfs panics

On Sat, 30 Apr 2005, Danny Braniss wrote:

> > Hello!
> >
> > I've read your recent discussion about unionfs panics on current. I have some
> > additional information which can probably help solving this panic.
> > Unfortunately I know absolutely nothing about internal details of vfs
> > implementation and so I suppose, you'd know better what to do with the
> > information I've learned.
> >
> > 1. I can easily reproduce the panic at any time with the following commands
> > (no matter how early in the boot process it happens):
> >
> > # mount -t unionfs /rescue /mnt
> > # /mnt/ls
> >
> > 2. Panic happens in sys/kern/kern_exec.c line 794
> >
> > ---
> > int
> > exec_map_first_page(imgp)
> >  	struct image_params *imgp;
> > {
> >  	int rv, i;
> >  	int initial_pagein;
> >  	vm_page_t ma[VM_INITIAL_PAGEIN];
> >  	vm_object_t object;
> >
> >  	GIANT_REQUIRED;
> >
> >  	if (imgp->firstpage != NULL)
> >  		exec_unmap_first_page(imgp);
> >
> >  	object = imgp->vp->v_object;
> >  	VM_OBJECT_LOCK(object); // !!! line 794
> > ---
> >
> > kernel panics because imgp->vp->v_object is NULL

Thanks, NULL object is certainly from phk's object rework.  I'll fix it
though as he seems to be very busy lately.

> >
> > Before it were the facts, further go my assumptions:
> >
> > 1. imgp->vp->v_tag is "union" (or "unionfs" don't remember exactly but it
> > doesn't matter) so I suppose this vnode was created (? or at least returned)
> > by unionfs.
> >
> > 2. I compared unionfs and nullfs (which seems to be the most close to unionfs
> > and doesn't panic on exec). I'll skip the description of comparison process
> > and provide the results:
> >
> > In nullfs the method null_open() (which implements vop_open()) returns vnode
> > with v_object not being NULL. This is how it's done (sys/fs/nullfs_vnops.c,
> > lines 378-390):
> >
> > ---
> > static int
> > null_open(struct vop_open_args *ap)
> > {
> >  	int retval;
> >  	struct vnode *vp, *ldvp;
> >
> >  	vp = ap->a_vp;
> >  	ldvp = NULLVPTOLOWERVP(vp);
> >  	retval = null_bypass(&ap->a_gen);
> >  	if (retval == 0)
> >  		vp->v_object = ldvp->v_object;
> >  	return (retval);
> > }
> > ---
> >
> > As far as I understand v_object is simply copied from vnode of the lower
> > level fs.
> >
> > I added some debugging printf's into union_vnops.c and it looks like
> > union_open() leaves v_object unset. Indeed on return from union_open it's
> > NULL and it's NULL for exactly that vnode which later panics in
> > exec_map_first_page()
> >
> > I made a very simple patch based on the way nullfs is implemented:
> > -----
> > --- union_vnops.c.orig  Sat Apr 30 11:36:00 2005
> > +++ union_vnops.c       Sat Apr 30 11:36:48 2005
> > _at__at_ -748,6 +748,9 _at__at_
> >          if (error == 0)
> >                  error = VOP_OPEN(tvp, mode, cred, td, -1);
> >
> > +       if (error == 0)
> > +               ap->a_vp->v_object = tvp->v_object;
> > +
> >          /*
> >           * Release any locks held.
> >           */
> > -----
> >
> > With this patch unionfs doesn't panic on exec. I absolutely not sure about
> > this patch. I understand that this may be a wrong patch because as I've
> > already said I know nothing about FreeBSD's vm and vfs and relations of their
> > objects. But at least this can probably help you solving the problem.
> >
>
> it did!
> im now make'ing buildword, and all seems 'back to normal'
>
>
>
> > And just a note: I'd also say that unfortunately unionfs still stays very
> > unstable. It can easily panic kernel in other parts. I've seen 'locking
> > against myself' and other locking panics with and without my patch. That's
> > too bad as it's a very nice feature for jails. It if goes this way I'd say it
> > would be better to disable it in 6.0 I'd be happy to spend some time fixing it
>
> we use it to mount ro /etc with an md, then populate it with private stuff, so
> for that it seems to fit the bill.
>
> > but I don't have it now. BTW: could you please suggest anything to read about
> > this vnodes, v_objects and other vfs/vm related objects so that I could
> > understand their relations and try to dig unionfs in case I have time?
> >
> apart for sending you to look at the source :-), i guess i'll let others
> chip in.
>
> thanks!
>
> 	danny
>
> > --
> > Oleg Sharoiko.
> > Software and Network Engineer
> > Computer Center of Rostov State University.
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>