Date: Sat, 30 Apr 2005 16:27:34 +0300 From: Danny Braniss <danny@cs.huji.ac.il> To: Oleg Sharoiko <os@rsu.ru> Cc: freebsd-current@freebsd.org Subject: Re: diskless/unionfs panics Message-ID: <E1DRs0M-0006E4-9a@cs1.cs.huji.ac.il> In-Reply-To: Message from Oleg Sharoiko <os@rsu.ru> of "Sat, 30 Apr 2005 12:30:22 %2B0400." <20050430114225.E654@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
> @@ -748,6 +748,9 @@
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1DRs0M-0006E4-9a>