From owner-freebsd-net@FreeBSD.ORG Tue Oct 15 19:48:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58D0F3FC for ; Tue, 15 Oct 2013 19:48:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 134AA2370 for ; Tue, 15 Oct 2013 19:48:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 22AD4B9A3; Tue, 15 Oct 2013 15:47:59 -0400 (EDT) From: John Baldwin To: Laurie Jennings Subject: Re: shm_map questions Date: Tue, 15 Oct 2013 15:21:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> In-Reply-To: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310151521.25231.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Oct 2013 15:47:59 -0400 (EDT) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:48:00 -0000 On Monday, October 14, 2013 8:40:28 pm Laurie Jennings wrote: > John, > > I got this working thanks to your help. I have to run my app on an old system and I can't > get shm_map to work on a 32-bit build. I've traced it to vm_fault_wire() returning 2 (KERN_PROTECTION_FAILURE). > This stuff is above my pay grade. Is there some option that I'm missing? I need to make this work and it's > driving me crazy! The fd you pass into the kernel has to be the result of a shm_open() with O_RDWR or I think the mapping can end up being read-only which might cause this. > Laurie > > > -------------------------------------------- > On Mon, 4/22/13, John Baldwin wrote: > > Subject: Re: shm_map questions > To: freebsd-net@freebsd.org > Cc: "Laurie Jennings" > Date: Monday, April 22, 2013, 8:43 AM > > On Saturday, April 20, 2013 9:18:24 > pm Laurie Jennings wrote: > > That does help. Is there a way for the kernel to access > the memory map > directlyby segment name? > > There is not, no. It wouldn't be hard to add, but the > issue there is that > the existing shm_map/unmap API assumes you have an open file > descriptor and > is tailored to having a userland process provide memory > rather than having > the kernel provide a SHM to userland, so even if you added a > shm_open() that > gave you a reference on the underlying shm object (struct > shmfd *), you would > need a slightly different shm_map/unmap that took that > object directly > rather than an fd. > > > Laurie > > > > --- On Thu, 4/18/13, John Baldwin > wrote: > > > > From: John Baldwin > > Subject: Re: shm_map questions > > To: freebsd-net@freebsd.org > > Cc: "Laurie Jennings" > > Date: Thursday, April 18, 2013, 6:50 AM > > > > On Thursday, April 11, 2013 10:58:14 am Laurie Jennings > wrote: > > > Im working on a simple project that shares a > memory segment between a user > > processand a kernel module. I'm having some problems > with shm_map and there > > doesn't seem to be much info on it. > > > Im not sure what happened to the memory when the > user process that creates > > it terminates. I have some questions. > > > 1) Does the kernel mapping keep the segment from > being garbage collected > > when the use process that creates it terminated? I've > experienced > shm_unmap() > > panic when tryingto unmap a segment > > > scenario: > > > User process Maps SegmentKernel maps it with > shm_map()User Process > > TerminatesKernel tries to shm_unmap() and it panics. > > > > The kernel mapping bumps the refcount on the underlying > vm object, so it > will > > not go away. OTOH, you should be keeping your own > reference count on the > > associated fd so that you can call shm_unmap(). > That is, the model should > be > > something like: > > > > struct mydata *foo; > > > > foo->fp = fget(fd); > > shm_map(fp, &foo->p); > > /* Don't call fdrop */ > > > > and then when unmapping: > > > > struct mydata *foo; > > > > shm_unmap(foo->fp, foo->p); > > fdrop(foo->fp); > > > > > 2) Is there a way for the kernel process to know > when the user process has > > goneaway? A ref count? > > > > You can install a process_exit EVENTHANDLER if you want > to destroy this when > a > > process goes away. I have used shm_map/unmap for > other objects that already > > had a reference count so I did my shm_unmap when that > object was destroyed. > > > > > 3) Does a SHM_ANON segment persist as long as the > kernel has it mapped, or > > doesit get garbage collected when the creating user > process terminates? > > > > It goes away when the backing 'struct file' goes > away. If you follow the > > model above of keeping a reference count on the > associated struct file then > > it won't go away until you fdrop() after the > shm_unmap. > > > > > 4) When using a named segment, can the kernel > "reuse" a mapping for a new > > userprocess? > > > Example: > > > User process creates shm segment with path > /fooKernel Maps shm segment > with > > shm_map()User process terminates.User process runs > again, opening segment > /foo > > > Does the kernel need to re-map, or is the original > mapping valid? > > > > The mapping is not per-process, so if you have mapped a > shm for /foo and > > mapped it, it will stay mapped until you call > shm_unmap. Multiple processes > > can shm_open /foo and mmap it and they will all share > the same memory. > > > > You could even share a SHM_ANON fd among multiple > processes by passing it > > across a UNIX domain socket. > > > > Hope this helps. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-net@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-net@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > John Baldwin > _______________________________________________ > freebsd-net@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- John Baldwin