From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 13:27:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8256816A4CE for ; Sat, 30 Apr 2005 13:27:36 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF66D43D2D for ; Sat, 30 Apr 2005 13:27:35 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DRs0M-0006E4-9a; Sat, 30 Apr 2005 16:27:34 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Oleg Sharoiko In-Reply-To: Message from Oleg Sharoiko of "Sat, 30 Apr 2005 12:30:22 +0400." <20050430114225.E654@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Apr 2005 16:27:34 +0300 From: Danny Braniss Message-ID: cc: freebsd-current@freebsd.org Subject: Re: diskless/unionfs panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2005 13:27:36 -0000 > 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.