Re: diskless/unionfs panics

> 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
> 
> 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.