Date: Sat, 30 Apr 2005 18:29:57 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Danny Braniss <danny@cs.huji.ac.il> Cc: Oleg Sharoiko <os@rsu.ru> Subject: Re: diskless/unionfs panics Message-ID: <20050430182926.K71837@mail.chesapeake.net> In-Reply-To: <E1DRs0M-0006E4-9a@cs1.cs.huji.ac.il> References: <E1DRs0M-0006E4-9a@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> > @@ -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.
>
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050430182926.K71837>